Description: having cells B6:J6 filled with formulas, copied and want to shift-Pg-down to paste there, somewhere around row 15000 -> crash, pasted in portions, filled to around row 20000 -> cell focus doesn't follow cursor, erratic jump around, further actions impossible, also in other attempts, fresh sheet, same formulas, similar fill -> cursor stops working, neither pg-down, -up, cursor-down, -up, -left, -right nor pos1 or end have any effect, pointing and scrolling with the mouse still possible, input in cells not, :-( Steps to Reproduce: 1. see description, 2. 3. Actual Results: crashes and stalls Expected Results: usable program Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: 420(Build:3) CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 4:24.2.0-1 Calc: threaded
Please test in safe mode, Menu/Help/Restart in Safe Mode
Same, rows up to ~13k filled, copied from last row, selected cells from there up to row ~26k, ctrl-v, no reaction, jump to last data with ctrl-cursor-up doesn't work, some moves up and crash. Second try, filling in smaller chunks works, trying to mark cells up to exactly 65536 at some point cursor moves switch to random move in intended or opposite direction, while trying to understand crash. Third try, normal mode, filling in chunks smaller than 10k works to even more than 100k rows, at some point ctrl-cursor-down marks the cells as like shift-ctrl-cursor-down, after that sometimes up or down switches columns, left or right moves up or down, while trying around crash. With other programs on that machine no such problems. Do we have something like log in terminal or crash-backlog? More experimenting once Calc has a working hidpi mode, as of now it's eye-torture on a 4k screen.
in terminal: X-Error: BadLength (poly request too large or internal Xlib length error) Major opcode: 18 (X_ChangeProperty) Resource ID: 0x3e2 Serial No: 610806 (610806) These errors are reported asynchronously, set environment variable SAL_SYNCHRONIZE to 1 to help debugging Unspecified Application Error
Please attach an example file. Do you see this with 24.8 or a daily build? I noticed you have VCL: x11, so you are using the fallback UI, which is not normal. Is this intentional? If not, you are missing a package such as libreoffice-gtk3 or libreoffice-kf6.
(In reply to b. from comment #2) > Do we have something like log in terminal or crash-backlog? If you have access to debug symbols you can get a backtrace: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
@Buovjaga > you are missing a package such as libreoffice-gtk3 thks for help, can't remember having done more evil than sudo apt install libreoffice, at some point ( can't tell if before or after this bug ) used `GDK_SCALE=1 SAL_FORCEDPI=192 libreoffice --calc`reg. tiny icons and letters, now add. installed libreoffice-gtk3, couldn't repro issue, but UI slllooowwww..... have high keyboard repeat, holding cursor down for one second has one minute of screen scroll down row by row.
[Automated Action] NeedInfo-To-Unconfirmed
Back to needinfo while we wait for the file.
@NEEDINFO: think there won't be a file, changed to libreoffice-gtk3 acc. hint from Buovjaga, couldn't repro issue, issue now: slow UI, slow in reaction to cursoring. Shift-PgDowning to rows around 30.000 takes ~ten seconds press and hold 'shift-pgdown', and then wait ~1:45 minutes for the screen to reach somewhere near that. Not going to use such in allday work, not going to investigate, just hints, VCL: did crash, gtk3: massively lags behind keystrokes.
(In reply to b. from comment #9) > @NEEDINFO: > > think there won't be a file, changed to libreoffice-gtk3 acc. hint from > Buovjaga, couldn't repro issue, issue now: slow UI, slow in reaction to > cursoring. But if the issue persists with the gen backend, it would be great to investigate it with an example file.
The gtk3 issue might be bug 78254 which obviously evolved over time, but do check the last comments.
@Buovjaga, thanks for your hints, be sure I'll continue to report things I stumble on, but I'll not investigate into differences between frontends or ten year old problems. I think late processing and 'managing instead of treating' leads to an exponential explosion of the impact of errors, and is one of the central problems of LO. The German IT blogger FEFE has coined a nice term for this: 'Bug-Welle', in english: 'bug-wave'?.
(In reply to b. from comment #12) > @Buovjaga, > > thanks for your hints, > > be sure I'll continue to report things I stumble on, > > but I'll not investigate into differences between > frontends or ten year old problems. It's ok, I can do the investigation, if you just provide me the means to do so. We are very much interested in getting rid of crashes.