Created attachment 153804 [details] Test document to show the problem - embedded pictures are removed I have saved an odt document with LO 6.4.0 Version: 6.4.0.0.alpha0+ (x64) Build-ID: 0fb2927a8fe06e6c3255544b8e4c4c9c0f5a67d3 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-27_22:13:47 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded See meta.xml within the attached odt document! The document can be opened with this build or older and also with LO 6.3.1 rc2. But LO 6.4.0 crashes when I try to open this document with Version: 6.4.0.0.alpha0+ (x64) Build-ID: 5a7c684b03510b4b568b4f10b38d6c433e4a291e CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-31_14:39:09 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded or newer (2019-09-01_00:07:05 - first seen with this build) Open with build from 2019-08-31_14:39:09 and newer also crashes with the almost same document when it is saved with LO 6.3.1. Because my document is very big (about 100 MB) I have removed all embedded pictures from the document (folder Pictures within the document) to decrease the file size. The crash can be reproduced also with this "doownsized" document with LO 6.4.0 from 2019-08-31_14:39:09 and 2019-09-01_00:07:05. With builds from 2019-08-27_22:13:47 and older it can be opened without problems - only instead of pictures message "read error" is shown.
Cannot reproduce with Version: 6.4.0.0.alpha0+ (x64) Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
This is surprising! I have also just tested with this version (Build-ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4) on 2 computers with Win10 and can reproduce the crash on both. Version: 6.4.0.0.alpha0+ (x64) Build-ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_22:04:10 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: e8c7f4cd5bd95b8112c1795ed11b7ac7caed00a2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Nor in Versión: 6.3.0.3 (x86) Id. de compilación: c75130c129d9c5e43b76e4f26881b3db8bdb5c91 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
I can open file with Version: 6.4.0.0.alpha0+ Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Because nobody can reproduce the problem I have made further tests. I have reset all settings to default settings and also reset all settings of the user interface, but not reset all settings in my user profile. After this I could resp. can open the test document and also any other odt documents. I can change the user interface without problems from "Default" (?, in German "Standard") to "Compact" and/or to "Sidebar". But LO crashes when any (!) odt document is open and I change UI to "in registers", "in registers compact", "in groups compact" or "depending on context compact". After a restart of LO 6.4.0.0 LO crashes when I try to open any odt document. Therefore I make more precise the bug description. ods documments are not affected by the problem.
Problem after https://git.libreoffice.org/core/+/e0d29fb937b0f423f151e0a504bfe326f4d8279e%5E%21/vcl/source/window/builder.cxx , which made > ModuleMap::iterator aI = g_aModuleMap.find("libsfxlo.so"); > pFunction = reinterpret_cast<customMakeWidget>(aI->second->getFunctionSymbol("makeNotebookbarToolBox")); get executed in *all* platforms, including Windows (!), and dereference the returned iterator unconditionally (!).
eh, I asked about iterator but then missed it in the next revision and pushed. We will fix with Sumit that issue
Sumit Chauhan committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/0473141a91a686de700fd73118bcc142b4f636b4%5E%21 tdf#127272 Writer crash issue resolve It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks like fixed in my testing.
(In reply to Mike Kaganski from comment #10) > Looks like fixed in my testing. Hi Mike and Sumit Chauhan, Thanks for the quick fix. I see you have changed the file quite a lot < https://cgit.freedesktop.org/libreoffice/core/log/vcl/source/window/builder.cxx > so i'm hesitant to cherry-pick it to libreoffice-6-3 Could you please cherry-pick it to 6-3 ?
Oh does it affect also 6-3? I wasn't aware...
(In reply to Mike Kaganski from comment #12) > Oh does it affect also 6-3? I wasn't aware... oh wait, I didn't say anything... no need for backporting, I got confusing... I guess I need more coffee
Test was OK (no crash at open or change UI) with Version: 6.4.0.0.alpha0+ (x86) Build ID: 2c7aa60b69967a80b7874503f0e9e85546a04cde CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-09-04_06:15:45 Locale: de-DE (de_DE); UI-Language: en-US Calc: CL Many thanks! I hope soon comes also a new build on Win-x86_64@62-TDF or at least on Win-x86@62-TDF...
(In reply to Stefan_Lange_KA@T-Online.de from comment #14) > Test was OK (no crash at open or change UI) with > Version: 6.4.0.0.alpha0+ (x86) > Build ID: 2c7aa60b69967a80b7874503f0e9e85546a04cde > CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86@42, Branch:master, Time: 2019-09-04_06:15:45 > Locale: de-DE (de_DE); UI-Language: en-US > Calc: CL > > Many thanks! > > I hope soon comes also a new build on Win-x86_64@62-TDF or at least on > Win-x86@62-TDF... Thanks for retesting. Let's close it as VERIFIED FIXED then