Bug Hunting Session
Bug 91770 - Crash on closing on Windows
Summary: Crash on closing on Windows
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other Windows (All)
: highest major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, corruptProfile, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2015-05-31 12:02 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-01-04 14:17 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
windbg backtrace (16.96 KB, text/plain)
2015-05-31 12:03 UTC, Yousuf Philips (jay) (retired)
Details
user profile (439.92 KB, application/zip)
2015-06-08 20:46 UTC, Yousuf Philips (jay) (retired)
Details
backtrace (6.51 KB, text/plain)
2016-03-07 12:11 UTC, Yousuf Philips (jay) (retired)
Details
stacktrace (2.58 MB, text/plain)
2016-03-07 12:19 UTC, Yousuf Philips (jay) (retired)
Details
backtrace with '~* kp' (18.32 KB, text/plain)
2016-03-07 17:58 UTC, Yousuf Philips (jay) (retired)
Details
another backtrace (25.75 KB, text/plain)
2016-03-08 05:03 UTC, Yousuf Philips (jay) (retired)
Details
another backtrace 2 (24.53 KB, text/plain)
2016-03-09 04:34 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-05-31 12:02:24 UTC
All that i had to do is open libreoffice and then close it and windows would show the dialog of libreoffice had stopped working.
Comment 1 Yousuf Philips (jay) (retired) 2015-05-31 12:03:17 UTC
Created attachment 116193 [details]
windbg backtrace
Comment 2 tommy27 2015-06-02 07:15:00 UTC
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
Comment 3 tommy27 2015-06-02 07:23:02 UTC
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?
Comment 4 Yousuf Philips (jay) (retired) 2015-06-02 13:04:16 UTC
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
Comment 5 tommy27 2015-06-02 16:32:39 UTC
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)
Comment 6 Yousuf Philips (jay) (retired) 2015-06-02 20:29:26 UTC
I'm running Windows 7 64-bit. Hopefully a dev can look into the backtrace and determine what is going wrong.
Comment 7 Timur 2015-06-05 13:59:55 UTC
If it's Calc, then looks similar to Bug 91214.
Comment 8 Yousuf Philips (jay) (retired) 2015-06-06 10:31:45 UTC
(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.
Comment 9 Michael Meeks 2015-06-08 14:51:21 UTC
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 ?
Comment 10 Yousuf Philips (jay) (retired) 2015-06-08 20:46:27 UTC
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
Comment 11 Yousuf Philips (jay) (retired) 2015-06-13 22:57:21 UTC
Not sure how i assigned this to myself. :D
Comment 12 Michael Meeks 2015-07-03 15:22:53 UTC
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.
Comment 13 Michael Meeks 2015-07-03 15:26:31 UTC
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
Comment 14 Michael Meeks 2015-07-14 11:59:20 UTC
No info; -> moving back to unconfirmed for now; Jay ? =)
Comment 15 V Stuart Foote 2015-10-17 13:50:45 UTC
@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.
Comment 16 Robinson Tryon (qubit) 2015-12-10 03:10:29 UTC Comment hidden (obsolete)
Comment 17 Yousuf Philips (jay) (retired) 2016-03-05 07:08:26 UTC
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)
Comment 18 V Stuart Foote 2016-03-05 15:03:31 UTC
(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.
Comment 19 Yousuf Philips (jay) (retired) 2016-03-05 16:25:40 UTC
(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
Comment 20 V Stuart Foote 2016-03-05 18:24:16 UTC
(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.
Comment 21 Yousuf Philips (jay) (retired) 2016-03-05 18:35:10 UTC
(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.
Comment 22 Michael Meeks 2016-03-07 10:45:08 UTC
> 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 !
Comment 23 Yousuf Philips (jay) (retired) 2016-03-07 12:11:15 UTC
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/
Comment 24 Yousuf Philips (jay) (retired) 2016-03-07 12:19:09 UTC
Created attachment 123375 [details]
stacktrace
Comment 25 Michael Meeks 2016-03-07 15:16:01 UTC
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 !
Comment 26 V Stuart Foote 2016-03-07 15:41:44 UTC
(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...
Comment 27 V Stuart Foote 2016-03-07 15:46:01 UTC
@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.
Comment 28 Michael Meeks 2016-03-07 16:24:28 UTC
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 !
Comment 29 Yousuf Philips (jay) (retired) 2016-03-07 17:58:07 UTC
Created attachment 123388 [details]
backtrace with '~* kp'
Comment 30 V Stuart Foote 2016-03-07 18:15:55 UTC
@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
Comment 31 Yousuf Philips (jay) (retired) 2016-03-07 21:29:50 UTC
@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?
Comment 32 V Stuart Foote 2016-03-07 23:10:27 UTC
(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.
Comment 33 Yousuf Philips (jay) (retired) 2016-03-08 05:03:04 UTC
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.
Comment 34 Michael Meeks 2016-03-08 17:35:25 UTC
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 =)
Comment 35 V Stuart Foote 2016-03-08 18:11:19 UTC
@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
Comment 36 Yousuf Philips (jay) (retired) 2016-03-09 04:34:02 UTC
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.
Comment 37 Michael Meeks 2016-04-01 10:53:34 UTC
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 =)
Comment 38 Yousuf Philips (jay) (retired) 2016-04-08 21:52:58 UTC
setting to unconfirmed as my part is done. thank god.
Comment 39 Yousuf Philips (jay) (retired) 2016-08-09 02:32:19 UTC
Lets set this to new as backtrace is submitted.
Comment 40 Yousuf Philips (jay) (retired) 2016-09-11 18:42:48 UTC
(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
Comment 41 Pedro 2017-01-04 10:38:18 UTC
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.
Comment 42 Pedro 2017-01-04 12:41:53 UTC
Here is another one

http://crashreport.libreoffice.org/stats/crash_details/01d3015e-4001-4a4c-ac54-0df0fb93e805

Hope this helps!
Comment 43 V Stuart Foote 2017-01-04 14:17:43 UTC
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.