In a fresh build as of yesterday (2010-11-08) of the libreoffice-3-3 branch for Windows, --with-distro=NovellWin32, installed on Windows XP SP3, if I start LO and then immediately exit it, it crashes. I have previously seen the same also in a build using no patches (using no --with-distro option). The backtrace in Visual Studio looks like this: ntdll.dll!_RtlpCoalesceFreeBlocks@16() + 0x31f bytes ntdll.dll!_RtlFreeHeap@12() + 0x91f bytes > msvcr90.dll!free(void * pBlock=0x04ef9530) Line 110 C cppu3.dll!`anonymous namespace'::deleteExceptions() + 0x24 bytes C++ cppu3.dll!`anonymous namespace'::deleteExceptions() + 0x206 bytes C++ cppu3.dll!_typelib_typedescription_release() + 0xde bytes C++ cppu3.dll!TypeDescriptor_Init_Impl::~TypeDescriptor_Init_Impl() + 0xd1 bytes C++ cppu3.dll!_CRT_INIT(void * hDllHandle=0x04284c04, unsigned long dwReason=0x04284bd8, void * lpreserved=0x04284bd8) Line 449 C cppu3.dll!__DllMainCRTStartup(void * hDllHandle=0x01570000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000000) Line 560 + 0x8 bytes C cppu3.dll!_DllMainCRTStartup(void * hDllHandle=0x01570000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) Line 510 + 0xe bytes C ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes ntdll.dll!_LdrShutdownProcess@0() - 0xfe bytes kernel32.dll!__ExitProcess@4() + 0x42 bytes kernel32.dll!7c81cb26() msvcr90.dll!__crtExitProcess(int status=0x00000000) Line 731 + 0x9 bytes C msvcr90.dll!doexit(int code=0x00000000, int quick=0x00000000, int retcaller=0x00000000) Line 632 C msvcr90.dll!exit(int code=0x00000000) Line 412 + 0xc bytes C soffice.bin!__tmainCRTStartup() Line 549 C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes I.e., the crash happens after the call to exit(). There is just one thread left, the "main" one. Looks like heap corruption to me... I tried to build with --enable-dbgutil so that it would use the debugging C/C++ runtime msvcrt90d.dll, and eventually got that build to finish (I had to fix a bunch of compilation errors; apparently nobody has built with --enable-dbgutil in a while). But unfortunately I couldn't get that build to even start on XP, and when run from a PKGFORMAT=installed "installation" on my development machine (Windows 7), it crashes during the splash screen, with a totally senseless call stack. Could be related, or not.
Note that it isn't as such the crash at exit that worries me; if that indeed is the only problem, and we can't find the root cause for it, we could just hack in something so that the process would be more brutally killed and not bother with any cleanups and destructors etc, during the execution of which it is that the crash happens. But presumably, if this is just a symptom of heap corruption than happens much earlier, that can cause totally random other behaviour, too.
I ran soffice.bin under the trial version of Purify, and it didn't find any heap corruptions. I don't know how well I can trust that, but anyway, if I actually use the build of LibreOffice a bit and do various operations in Writer or Calc, I don't get any crash during that. So probably the root cause is not a heap corruption, but the UNO type data structures are slightly broken so that the destruction of them at exit then crashes. Or the code just is buggy. But why then no crash on Linux? Is the TypeDescriptor_Init_Impl::~TypeDescriptor_Init_Impl() called at the wrong time on Windows (compared to when it gets called on Linux)? Anyway, we could always just re-introduce the CPPU_LEAK_STATIC_DATA thing on Windows that used to be there at least in 3.2.1... (I.e. ifdef out most of TypeDescriptor_Init_Impl::~TypeDescriptor_Init_Impl(). It would be interesting to find some information at what stage in the history of OOo that was introduced, and if anybody understood the exact mechanism why it was needed. http://qa.openoffice.org/issues/show_bug.cgi?id=107490 which concerns removing the CPPU_LEAK_STATIC_DATA doesn't tell why it was introduced in the first place, or what has changed so that it is no longer thought to be necessary. Of course, presumably the vanilla OOo does not have this crash-on-exit problem on Windows, so it is some of the changes in LibreOffice that has reintroduced the need to do the CPPU_LEAK_STATIC_DATA thing. Unless we can actually fix the root cause for the crash, that is...
I committed and pushed back the 3.2.1 hack to skip most of TypeDescriptor_Init_Impl::~TypeDescriptor_Init_Impl() but for Windows only this time... Will keep this bug open as that is just a horrible workaround. (Or, if that is an acceptable thing to do, why not then do it on all platforms? But I guess that it does cause some real trouble in some situations, see OOo issue i#107490.)
I have a windows build in progress, if it ever ends, and if its reproducible for me, I'll have a poke at it.
I don't like the look of the configmgr flush changes thread that gets spawned off when that .dll gets unloaded.
bah, so much for that theory
Also don't like the look of globals e.g. "lock" mutex in configmgr being destroyed before unotools releases some configmgr derived reference.
Created attachment 40362 [details] possibly part of the solution
Created attachment 40363 [details] probably also good to do
Had to hack out pretty much all threads in order to find what might be the root problems here. Have to try a fresh build to see if it makes a difference in the real world.
*** Bug 31703 has been marked as a duplicate of this bug. ***
Added me to CC Pls note that all windows users are nagged with this bug on exiting from beta3
*** Bug 31735 has been marked as a duplicate of this bug. ***
Bumping prio, assigning to Caolan - you seem to be working on a fix.
*** Bug 31752 has been marked as a duplicate of this bug. ***
CC
*** Bug 31795 has been marked as a duplicate of this bug. ***
Edited the subject from "Windows XP" to "Windows", since i confirm this also happen under Windows 2000 SP4. Cesare.
I've noted another thing: if the quickstart icon is present, the crash on exit doesn't happen (tryed with writer, calc and impress). But it happens if i try to close the quickstart icon. The error is always the same: ----- soffice.bin - Application error The instruction at "0x784ad989" reference memory at "0xffffffff". The memory could not be "read". Click OK to terminate the program. ----- One time i've seen the same error message, but with this title: DDE Server Windows: soffice.bin Cesare.
If the "QuickStarter" is turned on (its icon is present), OpenOffice.org / LibreOffice is still running and never exits, so what you say is completely expected. (In my humble opinion, the whole "QuickStarter" thing is misleading marketing. It would be more honest to just tell people to not close their OOo/LO window if they want it to be available quickly.) The mention of "DDE" in some cases in the error message window is a red herring, and can be ignored.
+1, bug appears on XP SP3 2600 system after upgrade from OO 3.2.1. to LO 3.3 beta 3
Created attachment 40471 [details] Picture of bug
Correct Version
*** Bug 31848 has been marked as a duplicate of this bug. ***
For me since this new installation (upgrade beta 2 to beta 3 I have this error on exit : L'instruction à "0x7c92019" emploie l'adresse mémoire "0xffffffff", la mémoire ne peut pas être "read"
This is not really blocking the 3.3 release as the workaround is in place in the libreoffice-3-3 branch.
Maybe is linked to bug 31096?
Florian: Don't think so, as the MacOSX stack traces in that other bug seem to talk about clipboard related things, and also the crash there is happening while main() is still running. This bug happens during exit() processing, and/or after main() has returned. But I might be wrong of course.
Seems good, fixed with http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-3&id=f10c27040a40cbc9e0b97258c1a0edc5f721d37f Definitely shuts down here without an error now with a debugging windows build with that in place. We can leave the hackaround in place for 3.3, shouldn't hurt I think. And what I believe is the core problem is fixed there as well.
Just to have that noted here for further dupes - seeing the crash now on mac, too (beta3 build). Happened on shutdown after loading all docs from bug 31734 .