Created attachment 139184 [details] Crashes LO on load, if macros are enabled! I'm replicating the StarBasic macro code here: Sub Main oMakroDoc = StarDesktop.currentComponent MsgBox "Lets crash LO" oMakroDoc.Close(true) End Sub In the attached document, the macro is connected to the onLoad event. You have been warned! LO 4.1.6, 5.1.6, 5.2.6 and master (6.1 = 30a3011a5229ea2e6228f6aa265d80204dd4263c) just crash after OK. Seldomly you get the document recovery dialog, most times it doesn't recover at all. Obviously you get a slightly different bt per VCL backend #0 0x00007fc6a673b260 in osl::Mutex::acquire() #1 0x00007fc6a67476c3 in osl::Guard<osl::Mutex>::Guard(osl::Mutex&) #2 0x00007fc6a677fa80 in cppu::OInterfaceIteratorHelper::~OInterfaceIteratorHelper() #3 0x00007fc6a490ef1a in cppu::OInterfaceContainerHelper::forEach<com::sun::star::document::XEventListener, (anonymous namespace)::NotifySingleListenerIgnoreRE<com::sun::star::document::XEventListener, com::sun::star::document::EventObject> >((anonymous namespace)::NotifySingleListenerIgnoreRE<com::sun::star::document::XEventListener, com::sun::star::document::EventObject> const&) #4 0x00007fc6a490e76b in SfxBaseModel::postEvent_Impl(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::frame::XController2> const&) #5 0x00007fc6a490dc2f in SfxBaseModel::Notify(SfxBroadcaster&, SfxHint const&) #6 0x00007fc6a3d08bab in SfxBroadcaster::Broadcast(SfxHint const&) #7 0x00007fc6a43e41ad in SfxEventAsyncer_Impl::IdleHdl(Timer*) #8 0x00007fc6a43e3f78 in SfxEventAsyncer_Impl::LinkStubIdleHdl(void*, Timer*) #9 0x00007fc69f04e5e8 in Link<Timer*, void>::Call(Timer*) const #10 0x00007fc69f04e447 in Timer::Invoke() #11 0x00007fc69f00a9c3 in Scheduler::ProcessTaskScheduling() #12 0x00007fc69f009bed in Scheduler::CallbackTaskScheduling() #13 0x00007fc68b9d48f6 in SalTimer::CallCallback() #14 0x00007fc68b9d35cd in X11SalData::Timeout() #15 0x00007fc68b9d39d5 in SalXLib::CheckTimeout(bool) #16 0x00007fc68b9d3ed2 in SalXLib::Yield(bool, bool) #17 0x00007fc68b9ef62f in X11SalInstance::DoYield(bool, bool) #18 0x00007fc69f03de21 in ImplYield(bool, bool) #19 0x00007fc69f038ad4 in Application::Yield() #20 0x00007fc69f038a60 in Application::Execute() #21 0x00007fc6aa12345c in desktop::Desktop::Main() #22 0x00007fc69f04a8f5 in ImplSVMain() #23 0x00007fc69f04c4d8 in SVMain() #24 0x00007fc6aa18c85d in soffice_main() #25 0x000000000040096d in sal_main #26 0x0000000000400947 in main OOo 3.2.1 just continues to run in the background, after the window vanishes.
Created attachment 139185 [details] Backtrace of the crash.
Reproduced in Version: 6.1.0.0.alpha0+ Build ID: 226804c8f7d2306562380283edfd919a88863807 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded However, i can't reproduce it in Versión: 6.0.0.2 Id. de compilación: 06b618bb6f431d27fd2def25aa19c833e29b61cd Subproc. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group It looks similar to bug 106294
Created attachment 139189 [details] BT @ SfxBaseModel::close So this crashes, when it's rewinding the stack when coming back from processing close in the onLoad call. In comparison to the crash it looks like something has to acquire a reference on the interface, probably the notifier.
(In reply to Xisco Faulí from comment #2) > It looks similar to bug 106294 Kind of, except I'm just closing the document not LO itself, but the result might be the same. It also crashes, if you have an other open changed dummy document and open the attached document additionally.
(In reply to Xisco Faulí from comment #2) > However, i can't reproduce it in > > Versión: 6.0.0.2 > Id. de compilación: 06b618bb6f431d27fd2def25aa19c833e29b61cd > Subproc. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; > Configuración regional: es-ES (es_ES); Calc: group So on Windows the window just closes but LO keeps running in the background?
BTW: running the code from the StarBasic editor won't crash, as the editor window will veto the close of its parent window. Instead one gets a CloseVetoException from the interpreter.
bibisect-43all$ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b # good: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c git bisect good 351622aec2dff3cc3bbbb020ad0097c4322d2a21 # bad: [378efb6e51212a05d1bd4b85c916eec5753c1744] source-hash-d453788ac0476cc02b929b0907718ca771d6d956 git bisect bad 378efb6e51212a05d1bd4b85c916eec5753c1744 # bad: [1a3c4b54a8782fe0f4bdba221e87012a92e4d323] source-hash-a330f38093e2643a26239557050561afae9ff23d git bisect bad 1a3c4b54a8782fe0f4bdba221e87012a92e4d323 # bad: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5 git bisect bad cf86b7f14a98d2d81a5cd93507acb35ff6775d8b # good: [a1427605523fb24cf51c0a9e01ae9e98e6cc0fa8] source-hash-b95bb2da9a197f950a2f40715ad731296cdb5296 git bisect good a1427605523fb24cf51c0a9e01ae9e98e6cc0fa8 # good: [bf468d032342783bc2ae3f8be5de91a8f073c137] source-hash-558b5ea32a99654dcb63526f107726f7aec4747f git bisect good bf468d032342783bc2ae3f8be5de91a8f073c137 # first bad commit: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
Hmm - the previous bisect is not really correct. After re-trying the good and bad bibisect commits it failed in good and worked in bad. So I tried to define good by running the macro five times, and just if it always survived it was good. OTOH some bad just failed once in the 5 times :-( So be aware that both bibisect aren't really reliable. There seems to be a point, where it became much worse with a low chance to still run in the background. I never had a background LO with master or any other tested LO, but these tests were just once or twice. bibisect-43all$ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # skip: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect skip e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # bad: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f git bisect bad 9daa289e178460daaafa4b3911031df5b8736218 # bad: [6d5c8da992dd6f7af0bda654787652a9221659e8] source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20 git bisect bad 6d5c8da992dd6f7af0bda654787652a9221659e8 # bad: [5b4693bb72eca5e38e3f56d036bca425c9a21b37] source-hash-e3633f60b349022994e291aa3d1a0c90c3403b2e git bisect bad 5b4693bb72eca5e38e3f56d036bca425c9a21b37 # bad: [9b4f3578f6e2c55d1aa4634218e9c2e3050e20e9] source-hash-14c4c26cea838b3fffb0b17ba440c29a6066fad1 git bisect bad 9b4f3578f6e2c55d1aa4634218e9c2e3050e20e9 # bad: [1a3c4b54a8782fe0f4bdba221e87012a92e4d323] source-hash-a330f38093e2643a26239557050561afae9ff23d git bisect bad 1a3c4b54a8782fe0f4bdba221e87012a92e4d323 # good: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c git bisect good 351622aec2dff3cc3bbbb020ad0097c4322d2a21 # bad: [5da527e58c09a5e88e94b73289c2cc15c32b851e] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 git bisect bad 5da527e58c09a5e88e94b73289c2cc15c32b851e # bad: [29d2530baf73c24f887fd5d19b226f3fb1b0e9ff] source-hash-10f977981d2cfb6ba0ccd0185ccb12e212010bc2 git bisect bad 29d2530baf73c24f887fd5d19b226f3fb1b0e9ff # good: [37d2ecfed54a2e87a77c012838c03fb75eb5d6c5] source-hash-817bf1d41bb07aeb3ed7649d25c2b44ee4acb1fe git bisect good 37d2ecfed54a2e87a77c012838c03fb75eb5d6c5 # bad: [a1427605523fb24cf51c0a9e01ae9e98e6cc0fa8] source-hash-b95bb2da9a197f950a2f40715ad731296cdb5296 git bisect bad a1427605523fb24cf51c0a9e01ae9e98e6cc0fa8 # first bad commit: [a1427605523fb24cf51c0a9e01ae9e98e6cc0fa8] source-hash-b95bb2da9a197f950a2f40715ad731296cdb5296 So eventually the bug was actually introduced in the range: 817bf1d41bb07aeb3ed7649d25c2b44ee4acb1fe~1 .. 85c6244b85b29c1d2bb9d89b62e9512dd65378b ; FWIW - that's LO 3.5…
All this crashes in the bibisect might also be different bugs, code wise. I just ran the LO versions - no debugger. If you see bug 106294 there were also fixes preventing macro crashes at different points.
(In reply to Jan-Marek Glogowski from comment #8) > So eventually the bug was actually introduced in the range: > 817bf1d41bb07aeb3ed7649d25c2b44ee4acb1fe~1 .. > 85c6244b85b29c1d2bb9d89b62e9512dd65378b ; FWIW - that's LO 3.5… I went through the list of commits, but nothing looks really suspect there.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1841fcf896f50b7df1375d431857ecddd5f5b392 tdf#115090 keep internal BaseModel alive long enough It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Thorsten, in Version: 6.1.0.0.alpha0+ Build ID: 75802ae40ae67737ae9e4f1a38434e0587affff6 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded it no longer crashes, however, it keeps running in the background. Is this the expected behaviour?
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bda331afdbdfe42ae519d325014dd4fa9ef9ec2 tdf#115090 prevent SfxBaseModel destruction during notifications It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b16a0ffce51df1af9fb0656ec07ca1e643f8edfa&h=libreoffice-6-0 tdf#115090 keep internal BaseModel alive long enough It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.