All that i had to do is open libreoffice and then close it and windows would show the dialog of libreoffice had stopped working.
Created attachment 116193 [details] windbg backtrace
I don't reproduce it under Win8.1 x64 using LibO 5.1.0.0.alpha1+ Build ID: 6c1cabe677f5eb24b465dd6e316c8c66df64bb29 TinderBox: Win-x86@39, Branch:master, Time: 2015-05-29_06:48:08 Locale: en-US (it_IT) please give details of the 5.1 build you are using
I've found a similar report about 4.4.x Bug 90482 - Crash on Exit have you tried temporarily downgrading from 5.1.x to 4.4.x to see if that error message persists?
The build i tested was 2015-05-30 @62-merge-TDF and it happened just now on today's master. Version: 5.1.0.0.alpha1+ Build ID: 8d46bc15e93687f93d7c85064acc71231e2f08b1 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-02_05:16:07 Steps: 1) Open Start Center 2) Open Tools > Options 3) Click Cancel or Okay 4) Close LO 5) Crash
stil no crash on my Win8.1 x64 machine using LibO 5.1.0.0.alpha1+ Build ID: 8d46bc15e93687f93d7c85064acc71231e2f08b1 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-02_05:16:07 Locale: en-US (it_IT)
I'm running Windows 7 64-bit. Hopefully a dev can look into the backtrace and determine what is going wrong.
If it's Calc, then looks similar to Bug 91214.
(In reply to Timur from comment #7) > If it's Calc, then looks similar to Bug 91214. Looking at the crash log, it is likely different, but we'd need a dev to confirm it. @Michael: As you checked the crash log in the other bug can you see if this one is a duplicate.
What a fun bug =) I have a build somewhat after the commit you highlight with dbgutil enabled, and I can't reproduce the issue on my Windows 7 Enterprise 64bit machine; my hash is c377dfddd but I don't see much that would have fixed such a bug as this in the meantime so ... You still have that ?
Created attachment 116386 [details] user profile So i checked and the crash still happens, but wont with with a new profile, so i've attached my profile. Version: 5.1.0.0.alpha1+ Build ID: 2da066628f02925ade2590229eb069d4765f619a TinderBox: Win-x86@39, Branch:master, Time: 2015-06-07_00:10:24
Not sure how i assigned this to myself. :D
Installed the profile into my dev-build; I get: vcl/opengl/win/WinDeviceInfo.cxx:914: error parsing blacklist but that looks benign; and no crash on tools->options ... looked around a lot ... 'ok', file->exit and ... nothing. Then again it doesn't appear to exit terribly cleanly either; digging.
Hmm; nope - can't reproduce this - the apparent hang was just me running something else in the console impatiently =) Can you still reproduce this Jay ? - I guess it is the ThumbnailView not stopping updating its items during shutdown which is ... odd ... sfxlo!ThumbnailView::updateItems+0x9fa2 00d4fa88 6c3bc0fd 00d4faac 6c3305f8 00000000 sfxlo!ThumbnailView::updateItems+0x3805
No info; -> moving back to unconfirmed for now; Jay ? =)
@Jay, the NEEDINFO is to you. Any recurrences with more recent builds or with additional profiles? Or was this one off and resolve WFM? If just a one off probably not a MAB @Joel, one for you "corruptProfile" category.
Migrating Whiteboard tags to Keywords: (bibisectRequest, corruptProfile)
Still crashing with steps from comment 4. Version: 5.2.0.0.alpha0+ Build ID: 6d5eeb6af585ae525645d844cbbd56e76678a0af CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-22_00:12:04 Locale: en-US (en_US)
(In reply to Yousuf (Jay) Philips from comment #17) > Still crashing with steps from comment 4. > @Jay, regards your steps from comment 4 -- exactly how are your closing LO from the StartCenter when LO crashes? 1. the [X] on the Windows "non-client area" frame 2. <alt>+F4 3. <ctrl>+W. 4. <ctrl>+Q 5. <alt>+F -> <Ctrl>+Q 6. <alt>+F -> X 7. mouse click on File -> X 8. mouse click on File, mouse click on "Exit LibreOffice" 9. mouse click on File -> <Ctrl>+Q 10. mouse click on File -> cursor to "Exit LibreOffice" -> press enter Point being that each of these actions "should" cleanly close LibreOffice on Windows but each has its own interplay with key and mouse press actions to initiate the process. =-note-= Bug 97511 suggests neither of the focus to menu <Ctrl>+Q options (5, 9) are working.
(In reply to V Stuart Foote from comment #18) > @Jay, regards your steps from comment 4 -- exactly how are your closing LO > from the StartCenter when LO crashes? Hope the screencast helps. Of course this is with this user profile (attachment 116386 [details])? https://drive.google.com/file/d/0B6qJrVIa0SAlMUkwUDVPZ0JJLUE/view?usp=sharing
(In reply to Yousuf (Jay) Philips from comment #19) > https://drive.google.com/file/d/0B6qJrVIa0SAlMUkwUDVPZ0JJLUE/view?usp=sharing @Jay, had a look and you are using the red [X] from the Windows program non-client area. Unfortunately that is the Windows method of closing a program that a program has the least internal control over--and would be most likely to catch LibreOffice in an unstable state. In other words, closing that way is asking for trouble. Not saying it is right, but I'd be willing to bet internally we handle that messaging different from <Ctrl>+W or <Alt>+F4 or <Ctrl>+Q key entries or menu selections.
(In reply to V Stuart Foote from comment #20) > @Jay, had a look and you are using the red [X] from the Windows program > non-client area. > > Unfortunately that is the Windows method of closing a program that a program > has the least internal control over--and would be most likely to catch > LibreOffice in an unstable state. > > In other words, closing that way is asking for trouble. > > Not saying it is right, but I'd be willing to bet internally we handle that > messaging different from <Ctrl>+W or <Alt>+F4 or <Ctrl>+Q key entries or > menu selections. @Stuart: It will crash which ever way i close it - Alt+F4, File > Exit, Ctrl+W, and Ctrl + Q.
> In other words, closing that way is asking for trouble. Um =) we should be able to handle a clean shutdown here =) There is clearly some problem with updating the thumbnail view on exit. Jay - can you reproduce this with a recent dbgutil build and get a stack-trace with full symbol / file-line information ? =) Also - for intermittent issues when exiting (such as bug#90482) it is most helpful to have a drmemory trace so we can work out what memory is getting corrupted / mis-used; indeed - I suspect it'd be useful to have one here too. Thanks !
Created attachment 123374 [details] backtrace (In reply to Michael Meeks from comment #22) > Jay - can you reproduce this with a recent dbgutil build and get a > stack-trace with full symbol / file-line information ? =) Hope this is sufficient. Version: 5.2.0.0.alpha0+ Build ID: 1b6a84a5a24e7e02c6066ca0fcb5a0011d2decd6 CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2016-02-24_07:29:17 Locale: en-US (en_US.UTF-8) Build taken from - http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/2016-02-24_07.29.17/
Created attachment 123375 [details] stacktrace
Hi jay - the stacktrace file is really an strace (system-call trace ;-). The backtrace seems to be from running soffice --help - or somesuch: #8 0x00007ffff395d142 in (anonymous namespace)::UsageInfo::save (this=0x7ffff431b940 <rtl::Static<(anonymous namespace)::UsageInfo, (anonymous namespace)::theUsageInfo>::get()::instance>) at /home/buildslave/source/libo-core/sfx2/source/control/unoctitm.cxx:678 #9 0x00007ffff395ca76 in (anonymous namespace)::UsageInfo::~UsageInfo (this=0x7ffff431b940 <rtl::Static<(anonymous namespace)::UsageInfo, (anonymous namespace)::theUsageInfo>::get()::instance>, __in_chrg=<optimized out>) at /home/buildslave/source/libo-core/sfx2/source/control/unoctitm.cxx:619 Sadly the "--strace" parameter you passed seems to have got passed into the actual app - (perhaps this caused the gdb failure) ? What parameters did you run libreoffice with under gdb ? ah ! now I read the code this is the usage stats crashing on exit as we try to write them: aybuke's code looks like it may be responsible: bool bCollecting = officecfg::Office::Common::Misc::CollectUsageInformation::get(); There are real problems using configmgr at shutdown - I would strongly suggest that you fetch this parameter during startup - ie. when this thing is created and store it in a member variable. Then - we can use that safely during shutdown =) does that make sense ? failing that just catch the exception - but be aware that you won't get the setting. Failing that - you need to clean this up much earlier. A good time might be at VCL shutdown - you can use: vcl::DeleteOnDeinit< Foo > For your global type - and this will be cleaned up much earlier as we take the toolkit down - and you may be able to use configmgr safely there =) HTH !
(In reply to Michael Meeks from comment #25) > HTH ! Michael, great code points for aybuke, but seems but like the enhancement for bug 96434 came in much later than Jay's crasher on exiting from Windows. Is there any reason to think the issue in Jay's Linux build ST is related to the crashing on close from Windows? Don't we still need a valid ST from a crash on Windows? Seems like TB39 ought to be used. Unfortunately this crash does not happen for me on any Windows system with any build or profile. I have no way to reproduce. Jay NEEDINFO back to you...
@Jay, also in catching the crash in WinDbg before running the !analyze -V against the TB39 soffice.bin; on crash/break can you run the "~* kp" to dump the whole stack and include that.
No idea =) I just read the second backtrace; and that's what it points at - it is an unrelated crasher to the windbg back-trace; really we should split the bug, get some nice titles: "UsageInfo crash on exit", "Thumbnail crash on exit" and get a nice windbg trace for the initial, thumbnail issue as well =) Thanks !
Created attachment 123388 [details] backtrace with '~* kp'
@Jay, (In reply to Yousuf (Jay) Philips from comment #29) > Created attachment 123388 [details] > backtrace with '~* kp' Thanks, and hate to pester. But that ST looks like you're only pointing to MS symbol files. Could you change your WinDbg symbol search path to include symbols for Kendy's TB39 32-bit build and allow it to build locally (a couple cycles of, "~* kp" dumps on breaks. https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
@Stuart, (In reply to V Stuart Foote from comment #30) > @Jay, > Thanks, and hate to pester. But that ST looks like you're only pointing to > MS symbol files. > > Could you change your WinDbg symbol search path to include symbols for > Kendy's TB39 32-bit build and allow it to build locally (a couple cycles of, > "~* kp" dumps on breaks. Kendy's @39 symbol search is already in the symbol path. Is there a means of telling windbg to reload the symbols?
(In reply to Yousuf (Jay) Philips from comment #31) > > Could you change your WinDbg symbol search path to include symbols for > > Kendy's TB39 32-bit build and allow it to build locally (a couple cycles of, > > "~* kp" dumps on breaks. > > Kendy's @39 symbol search is already in the symbol path. Is there a means of > telling windbg to reload the symbols? With WinDbg running and attached to an soffice.bin process... Open the File -> Symbol File Path dialog. The Path should show the local CACHE, and the SRV for Kendy's TB39, possibly Cloph's production symstor, and the SRV for Microsoft VS. Basically the string from the How to get a backtrace Wiki. At the bottom of the dialog is a "Reload" check box--check that and OK. Same can also be done issuing a ".reload" command. What I do is take the LibreOffice session near to where I expect the error to occur, then Debug -> Break, and issue the "~* kp" to force the symbol lookup. It takes some time, but then most of the symbols are resolved and held in cache--you can tell in resulting the stack trace(s) if the symbol lookup are populating. Couple rounds of that. Then "g" to continue the run and allow the crash--this time with a pretty full symbol cache to work against. You'll get a good stack trace, and the "!Analyze -v" may be more complete.
Created attachment 123396 [details] another backtrace (In reply to V Stuart Foote from comment #32) > With WinDbg running and attached to an soffice.bin process... > Open the File -> Symbol File Path dialog. > > The Path should show the local CACHE, and the SRV for Kendy's TB39, possibly > Cloph's production symstor, and the SRV for Microsoft VS. Basically the > string from the How to get a backtrace Wiki. > > At the bottom of the dialog is a "Reload" check box--check that and OK. Same > can also be done issuing a ".reload" command. Would be good to add the reload info to the wiki. > What I do is take the LibreOffice session near to where I expect the error > to occur, then Debug -> Break, and issue the "~* kp" to force the symbol > lookup. > It takes some time, but then most of the symbols are resolved and held in > cache--you can tell in resulting the stack trace(s) if the symbol lookup are > populating. Couple rounds of that. > > Then "g" to continue the run and allow the crash--this time with a pretty > full symbol cache to work against. You'll get a good stack trace, and the > "!Analyze -v" may be more complete. Gave it another shot, so hope its sufficient.
Hi Jay; you're still missing the right symbols somehow: cf. WARNING: Stack unwind information not available. Following frames may be wrong. And also: 00d3f4e8 7498afd5 00d3f4f8 240264e7 00000000 comphelper!comphelper::getProcessServiceFactory+0xd7 this guy doesn't have a file-name and a line-number - which is expected when you have symbols =)
@Jay, > Gave it another shot, so hope its sufficient. Sorry, as Michael notes, something is still not right with your install of LO and linkage to a project Symbols server. Are you using Kendy's TB39 build of master? Was it done as a "/a" administrative install in parallel, or did you actually install it (I don't think I've every tried debugging against an installed TB build, just Cloph's production builds when installed). Anyhow, below is an example of a reasonably complete ST w/symbols on a TB39 build "/a" install. It is thread 0, from WinDbg attached of the bug 97195 Diamond transition crash. An "!analyze -v" against the hang points to the "ogltrans_transitionimpl.cxx @ 298" Notice the module info for the build all comes from Kendy's build system, e.g. [c:\cygwin\home\tinderbox\master... ] your install does not seem to be picking up similar. =-example thread 0, from reload and a "~* kp" ST for bug 97195, another dozen or so threads omitted-= ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred CACHE*C:\symbols Deferred SRV*http://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols Deferred SRV*http://dev-downloads.libreoffice.org/symstore/symbols Deferred SRV*http://msdl.microsoft.com/download/symbols 0:000> .reload Reloading current modules ................................................................ ................................................................ ................................................. 0:000> ~* kp . 0 Id: f58.3d8 Suspend: 1 Teb: 7f3ff000 Unfrozen ChildEBP RetAddr 014bedcc 56fd25e8 OGLTranslo!displayPrimitives(class std::vector<Primitive,std::allocator<Primitive> > * primitives = 0x0a979a50, int primitiveTransformLocation = 0n3, double nTime = 0, double WidthScale = 0.97050938337801607, double HeightScale = 0.52821011673151752, class std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<int> > > first = class std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<int> > >)+0x61 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\ogltrans\generic\ogltrans_transitionimpl.cxx @ 298] 014bee44 56fd2d8b OGLTranslo!OGLTransitionImpl::displaySlide(double nTime = 0, long glSlideTex = 0n1, class std::vector<Primitive,std::allocator<Primitive> > * primitives = 0x0a979a50, double SlideWidthScale = 0.97050938337801607, double SlideHeightScale = 0.52821011673151752)+0xc8 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\ogltrans\generic\ogltrans_transitionimpl.cxx @ 314] 014bee70 56fd20d6 OGLTranslo!`anonymous namespace'::SimpleTransition::displaySlides_(double nTime = 0, long glLeavingSlideTex = 0n1, long glEnteringSlideTex = 0n2, double SlideWidthScale = 0.97050938337801607, double SlideHeightScale = 0.52821011673151752)+0x7b [c:\cygwin\home\tinderbox\master\slideshow\source\engine\ogltrans\generic\ogltrans_transitionimpl.cxx @ 560] 014beeac 56fc1639 OGLTranslo!OGLTransitionImpl::display(double nTime = 0, long glLeavingSlideTex = 0n1, long glEnteringSlideTex = 0n2, double SlideWidth = 724, double SlideHeight = 543, double DispWidth = 746, double DispHeight = 1028)+0xb6 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\ogltrans\generic\ogltrans_transitionimpl.cxx @ 277] 014bef2c 571d37ef OGLTranslo!`anonymous namespace'::OGLTransitionerImpl::update(double nTime = 0)+0x199 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\ogltrans\generic\ogltrans_transitionerimpl.cxx @ 1220] 014bef48 571cf5d5 slideshowlo!slideshow::internal::`anonymous namespace'::PluginSlideChange::TransitionViewPair::update(double t = 0)+0x2f [c:\cygwin\home\tinderbox\master\slideshow\source\engine\transitions\slidetransitionfactory.cxx @ 112] 014bef6c 5707d060 slideshowlo!slideshow::internal::`anonymous namespace'::PluginSlideChange::operator()(double t = 0)+0x65 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\transitions\slidetransitionfactory.cxx @ 186] 014bef84 57085e1f slideshowlo!slideshow::internal::`anonymous namespace'::SimpleActivity<1>::perform(double nModifiedTime = 0, unsigned long __formal = 0)+0x60 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\activities\activitiesfactory.cxx @ 907] 014bef9c 5708ce54 slideshowlo!slideshow::internal::ContinuousActivityBase::simplePerform(double nSimpleTime = 0, unsigned long nRepeatCount = 0)+0x2f [c:\cygwin\home\tinderbox\master\slideshow\source\engine\activities\continuousactivitybase.cxx @ 38] 014bf004 5708ba2c slideshowlo!slideshow::internal::SimpleContinuousActivityBase::perform(void)+0x174 [c:\cygwin\home\tinderbox\master\slideshow\source\engine\activities\simplecontinuousactivitybase.cxx @ 238] 014bf1f8 57186a3b slideshowlo!slideshow::internal::ActivitiesQueue::process(void)+0x23c [c:\cygwin\home\tinderbox\master\slideshow\source\engine\activitiesqueue.cxx @ 110] 014bf258 58621f96 slideshowlo!`anonymous namespace'::SlideShowImpl::update(double * nNextTimeout = 0x014bf2e4)+0x14b [c:\cygwin\home\tinderbox\master\slideshow\source\engine\slideshowimpl.cxx @ 2016] 014bf30c 58621ebf sdlo!sd::SlideshowImpl::updateSlideShow(void)+0xb6 [c:\cygwin\home\tinderbox\master\sd\source\ui\slideshow\slideshowimpl.cxx @ 1765] 014bf318 58612f1f sdlo!sd::SlideshowImpl::updateHdl(class Timer * __formal = 0x069e6e68)+0xf [c:\cygwin\home\tinderbox\master\sd\source\ui\slideshow\slideshowimpl.cxx @ 1751] 014bf324 5e51b163 sdlo!sd::SlideshowImpl::LinkStubupdateHdl(void * instance = 0x069e6e28, class Timer * data = 0x069e6e68)+0xf [c:\cygwin\home\tinderbox\master\sd\source\ui\slideshow\slideshowimpl.cxx @ 1748] 014bf338 5e51b186 vcllo!Link<Timer *,void>::Call(class Timer * data = 0x069e6e68)+0x23 [c:\cygwin\home\tinderbox\master\include\tools\link.hxx @ 84] 014bf348 5e4f7560 vcllo!Timer::Invoke(void)+0x16 [c:\cygwin\home\tinderbox\master\vcl\source\app\timer.cxx @ 89] 014bf354 5e4f76a4 vcllo!ImplSchedulerData::Invoke(void)+0x60 [c:\cygwin\home\tinderbox\master\vcl\source\app\scheduler.cxx @ 46] 014bf414 5e511405 vcllo!Scheduler::ProcessTaskScheduling(bool bTimerOnly = true)+0x134 [c:\cygwin\home\tinderbox\master\vcl\source\app\scheduler.cxx @ 178] 014bf658 5e5133ee vcllo!ImplYield(bool i_bWait = false, bool i_bAllEvents = false, unsigned long nReleased = 0)+0x425 [c:\cygwin\home\tinderbox\master\vcl\source\app\svapp.cxx @ 519] 014bf66c 5e50f4fd vcllo!Application::Yield(void)+0xe [c:\cygwin\home\tinderbox\master\vcl\source\app\svapp.cxx @ 551] 014bf6b4 60f30929 vcllo!Application::Execute(void)+0x1ad [c:\cygwin\home\tinderbox\master\vcl\source\app\svapp.cxx @ 471] 014bf6bc 60f357b1 sofficeapp!desktop::Desktop::DoExecute(void)+0x9 [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 1340] 014bfce8 5e51990c sofficeapp!desktop::Desktop::Main(void)+0x1811 [c:\cygwin\home\tinderbox\master\desktop\source\app\app.cxx @ 1659] 014bfd18 5e519d7f vcllo!ImplSVMain(void)+0xbc [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 167] 014bfd24 60f6d674 vcllo!SVMain(void)+0x2f [c:\cygwin\home\tinderbox\master\vcl\source\app\svmain.cxx @ 205] *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\LODev520_x86_20160303_TB39\program\soffice.bin - 014bfd98 003b100a sofficeapp!soffice_main(void)+0x74 [c:\cygwin\home\tinderbox\master\desktop\source\app\sofficemain.cxx @ 135] WARNING: Stack unwind information not available. Following frames may be wrong. 014bfda4 003b103a soffice+0x100a 014bfdb0 003b1078 soffice!main+0x1a 014bfdc8 003b12ce soffice!main+0x58 014bfe14 76927c04 soffice!main+0x2ae 014bfe28 773bab8f KERNEL32!BaseThreadInitThunk+0x24 014bfe70 773bab5a ntdll!__RtlUserThreadStart+0x2f 014bfe80 00000000 ntdll!_RtlUserThreadStart+0x1b
Created attachment 123416 [details] another backtrace 2 @Stuart, (In reply to V Stuart Foote from comment #35) > @Jay, > Are you using Kendy's TB39 build of master? Was it done as a "/a" > administrative install in parallel, or did you actually install it (I don't > think I've every tried debugging against an installed TB build, just Cloph's > production builds when installed). Yes using kendy's build and extracting using `msiexec /qr /a`. So i downloaded the 12gb of symbols from kendy's server and added it to the local cache and ran another backtrace which is attached. If this still isnt sufficient, then please close the bug.
Jay's crasher here looks like it is down to trying to save some UI / user data after the application has de-initialized. I believe there was another bug for that somewhere. I imagine kendy recalls which one that was =)
setting to unconfirmed as my part is done. thank god.
Lets set this to new as backtrace is submitted.
(In reply to Michael Meeks from comment #37) > Jay's crasher here looks like it is down to trying to save some UI / user > data after the application has de-initialized. I believe there was another > bug for that somewhere. I imagine kendy recalls which one that was =) Here is the bug report about saving user metrics. bug 95505
LibreOffice 5.3.0.1 crashes on exit every other run. I have sent 3-4 crash reports in the past couple of days that I have been using it under Windows 7 x64 Hope the reports help to find the problem.
Here is another one http://crashreport.libreoffice.org/stats/crash_details/01d3015e-4001-4a4c-ac54-0df0fb93e805 Hope this helps!
Resolving this out WFM, this was only affecting the 5.1 builds. Just opened bug 105097 for Windows builds crash on exit in: ScTransferObj::~ScTransferObj() at 5.2.4 and 5.3.0 http://crashreport.libreoffice.org/stats/signature/ScTransferObj::~ScTransferObj()?page=1 @Pedro, please elaborate there.