Summary: | Crash swlo!SwFrame::SetInvalidVert+0x4397 | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Telesto <telesto> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | buzea.bogdan, serval2412, stephane.guillou |
Priority: | medium | Keywords: | wantBacktrace |
Version: | 7.4.0.0 alpha0+ | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=119126 https://bugs.documentfoundation.org/show_bug.cgi?id=146615 https://bugs.documentfoundation.org/show_bug.cgi?id=160913 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 133092 | ||
Attachments: |
Example file
BT without symbols |
Description
Telesto
2022-01-06 13:08:36 UTC
Created attachment 177347 [details]
Example file
Created attachment 177348 [details]
BT without symbols
Alternative 1. Open attached file 2. Place the cursor in the top left table cell 3. CTRL+A 4. F12 (toggle numbering on) 5. CTRL+Z Does throw different warning SAL warning, prior crash, but well BT stack nearly identical On pc Debian x86-64 with master sources updated today, I don't reproduce the crash with first mechanism. However, I don't have any part in green anymore after Ctrl-Z I noticed different kinds of warns: warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:2710: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 warn:legacy.osl:55675:55675:sw/source/core/layout/flowfrm.cxx:2563: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied warn:sw.layout:55675:55675:sw/source/core/layout/tabfrm.cxx:900: Cannot remove in-use Follow Flow Line warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:893: There should be a flowline in the follow warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:1368: Joining follow flow line I suppose there are already similar bugtrackers with this kind of doc (complicated, at least for LO, layout with tabs) which crashes so I suppose it needs someone to care about these before creating new bugtrackers. It also needs to speed up the layout mechanism, it's really slow. (In reply to Julien Nabet from comment #4) > On pc Debian x86-64 with master sources updated today, I don't reproduce the > crash with first mechanism. > However, I don't have any part in green anymore after Ctrl-Z > > I noticed different kinds of warns: > warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:2710: debug > assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by > fix i44910 > warn:legacy.osl:55675:55675:sw/source/core/layout/flowfrm.cxx:2563: > <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move > Backward> applied > warn:sw.layout:55675:55675:sw/source/core/layout/tabfrm.cxx:900: Cannot > remove in-use Follow Flow Line > warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:893: There > should be a flowline in the follow > warn:legacy.osl:55675:55675:sw/source/core/layout/tabfrm.cxx:1368: Joining > follow flow line > > I suppose there are already similar bugtrackers with this kind of doc > (complicated, at least for LO, layout with tabs) which crashes so I suppose > it needs someone to care about these before creating new bugtrackers. > > It also needs to speed up the layout mechanism, it's really slow. Well those warnings are around for a while.. but mostly doesn't end up with crash, as far I recall. Confirming based on BT at bug 146621 Comment 0 steps on Linux: - 7.4.0.3: no crash, but poor performance - 7.6.6.3: frozen - 24.2.2.2: not frozen anymore, although poor performance - 24.8 alpha0+: no freeze, no performance issue / loop Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ce454f382d0d005dd3de021c7820be3ffa0bb582 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded On Windows: - 7.5.0.3: no crash, but poor performance - 24.8 alpha0+: no freeze, no performance issue / loop Closing as "works for me", but please confirm it's good on your end too, Telesto. (In reply to Stéphane Guillou (stragu) from comment #7) > Closing as "works for me", but please confirm it's good on your end too, > Telesto. I'm unable to repro the exact steps. Performance is reasonable. However the same/similar issue is still present in multipage view (bug 160913) Didn't check for warnings a noted in comment 4. I expect those to be present. I even assume that all bugs throwing "format of table lowers suppressed by fix i44910" having the same root cause (as noted in comment 4) |