[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 User pjentsch changed the following: What|Old value |New value CC|'cmc,dtardon,kr,mba,pl,sb'|'cmc,dtardon,kr,mba,pjents | |ch,pl,sb' - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from k...@openoffice.org Thu Jun 24 11:26:55 + 2010 --- SolarMutex implementations can be found in: vcl/os2/source/app/salinst.cxx vcl/unx/headless/svpinst.cxx vcl/unx/source/app/salinst.cxx vcl/unx/gtk/app/gtkinst.cxx vcl/win/source/app/salinst.cxx vcl/aqua/source/app/salinst.cxx - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from k...@openoffice.org Thu Jun 24 11:22:08 + 2010 --- It could, the steps are: -1- consolidate / reduce the SalYieldMutex implementations in VCL: There is still some craft in there from a mythical Java client. -2- Create a Uno Purpose Bridge for the SolarMutex: http://wiki.services.openoffice.org/wiki/Uno/Cpp/Spec/Purpose_Bridge_Implementat ion_Helper (seems that some of may pages have been deleted by WikiBot). -3- Adapt the belonging components to be loaded into the "solarmutex" environment. -4- Remove any left overs, including all the guards etc. Step -1- is not trivial and error prone. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Thu Jun 24 09:53:47 + 2010 --- just for the record: the sw::UnoImplPtr that takes the SolarMutex is new in DEV300m71. i've introduced it to solve issue 105557, which led to crashes due to race conditions. the entire UNO API implementation of the writer uses the SolarMutex for locking. and this crash doesn't seem to happen "often", i think i've seen it only once. hmmm... i wonder if the mythical UNO threading framework would solve this problem :) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from k...@openoffice.org Thu Jun 24 09:44:25 + 2010 --- I remember, you are right. The SolarMutex is platform native implemented, ... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Thu Jun 24 09:32:01 + 2010 --- That would indeed be a very welcomed change. AFAIR the implementation if SolarMutex is special and can't be changed that way. pl should know that better than anyone else. :-) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from k...@openoffice.org Thu Jun 24 09:09:05 + 2010 --- Matthias, thanks for clarifying. That's what I expected. What about doing it "right" and utilizing the OSL GlobalMutex for VCL and friends? The minimum would be to move the implementation of the VCL SolarMutex to the Tools, AFAIR VCL depends on Tools anyway. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Thu Jun 24 09:01:01 + 2010 --- The reason for tools::SolarMutex is that you can use it without linking against vcl. This was necessary to remove vcl build dependencies from some libraries. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from k...@openoffice.org Thu Jun 24 08:35:16 + 2010 --- ... somehow I have been added to this issue. Regarding remote references to (Uno) objects in the office process, it is either correct to * programmatically shutdown any remote bridges (including in process runtimes such as Java), or * to ensure that reachable objects are valid. We need to define the meaning of "file/exit" accordingly, as already suggested. The object life cycle in OOo is (partly) ref-count based, objects reachable are alive, objects becoming unreachable are (mostly synchronously) destroyed. Ideally VCL would follow this approach, e.g. create a "Display" with some controls on it, the controls hold references to the "Display", ensuring that it is kept alive at least wrt memory. Philipp is right about VCL's SolarMutex, the SolarMutex as well as VCL must not be in use after DeInitVCL (by they way, wasn't there any debugging aid to ensure this?). This bears the question what the sense of Tools SolarMutex is. Either use the VCL SolarMutex or the OSL GlobalMutex. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from c...@openoffice.org Thu Jun 24 08:25:37 + 2010 --- My own 2 cents is that I'd like to see a much longer stack to see some more details of this particular example, i.e. --num-callers=50 or something. We get quite a few crash-on-shutdown traces in fedora as our crash-reporting infrastructure is global over all apps and over their entire lifetime. And they fall into two main categories. I've seen ones like this one with a11y shutdown where the a11y shutdown and release of uno references is called effectively from "spi_atk_bridge_exit_func" which nightmarishly is called from atexit from the accessibility libs which makes avoiding this tricky. The other family is due to the current cppu shutdown being crippled to attempt to "leak" resources to avoid accessing dead ones, but this has the side effect of not calling the dtors which cleanly bring down the remotebridge reader/writer threads leaving them generally blocked on mutexes and then after those global mutex gets destroyed on main processes exit the threads unblock and trample all over the corrupt corpse of OOo. The common case is unopkg crashes which are no fault of unopkg. See issue 107490 for some thoughts on fixing that up. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 User dtardon changed the following: What|Old value |New value CC|'kr,mba,pl,sb'|'cmc,dtardon,kr,mba,pl,sb' - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from p...@openoffice.org Wed Jun 23 11:31:05 + 2010 --- ... with the added benefit that you cannot logout or shutdown anymore because of a still running application. Great :-( - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Wed Jun 23 09:54:07 + 2010 --- The user will still be able to close the application (means: all its windows) - but it will stay in memory (and in its message loop) until all external connections are closed. In the meantime the user also will be able to open new documents from his desktop, thus again establishing the "internal" refcount on the application. So a hanging external connection in the worst case would just prevent OOo from being removed from memory - it would act as a UI less quickstarter. ;-) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from p...@openoffice.org Wed Jun 23 09:43:51 + 2010 --- Just that looping code (aka bugs) is still possible should not prevent us from being at least moderately safe from forgotten references; no need to make the situation worse IMHO. And WRT "exactly as we did", why should external connections preventing the user from exiting the application a good thing ? He'll invariably think that OOo hangs. If this "exit prevention" need be I'd at least want to have some kind of message box querying "Connections are still open, do you really want to quit" or some such. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Wed Jun 23 09:25:42 + 2010 --- > So any number of code gone wrong (hanging server, forgotten refcount) can then > prevent the application from ever quitting again. Just saying. Sure. So as all code in office that loops prevents the office from being shut down. > That is prevent framework from calling DeInitVCL before all such references > are > cleared. I would even prevent OOo from leaving the message loop as then it still can receive user requests. That's exactly as we did it when the only external connections we had were COM connections. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from p...@openoffice.org Wed Jun 23 09:10:15 + 2010 --- So any number of code gone wrong (hanging server, forgotten refcount) can then prevent the application from ever quitting again. Just saying. However preventing vcl "shutdown" is simple, just don't call DeInitVCL until you mean it. That is prevent framework from calling DeInitVCL before all such references are cleared. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Wed Jun 23 09:00:29 + 2010 --- The SolarMutex protects all code in VCL and all other code where the developers where too lazy or not able to create their own mutex. You are right if the object in question has some dependency on VCL code. But if not (and that might be something easier to achieve as we are only talking about the code in a dtor), a SolarMutex outside of VCL could help. Besides that, I still would prefer the other solution: if a refcounted object requires something from VCL (e.g. SolarMutex) there must be a way to avoid VCL shutdown as long as the object exists. A possible way could be to add a member to all UNO objects using the SolarMutex that "refcounts" the VCL based application and prevents that it is shut down. We also could fix that in UNO - every bridge can hold such a reference so that the application can't go down as long as an external bridge exist. That would be something as the COM solution I mentioned. In the olden times we counted an reference on our Application class for every COM connection plus one reference if the application also was started by a user action. Even if the user called "File-Exit", the application did not terminate until all external connections had been released. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from p...@openoffice.org Wed Jun 23 08:03:17 + 2010 --- easy would not be the problem. Just that would be no solution. So you have a SolarMutex outside vcl's lifetime and then what ? The mutex is just for protecting the underlying vcl (or vcl derived) object, which you would probably want to access -> crash in object instead of solar mutex. No gain. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from m...@openoffice.org Wed Jun 23 07:43:32 + 2010 --- It can't be avoided that such references exist - if they are held in a Java program it's the garbage collection that decides when they are released. The real problem is that we never implemented a life time control of UNO objects. VCL shouldn't be shut down as long as any external reference exist. COM has such a mechanism and many years ago I suggested something similar to Markus Meyer for UNO objects and services. Unfortunately that wasn't seen as important enough to judge the effort of its implementation. Alternatively the life time of the SolarMutex could be controlled outside of VCL. But AFAIK and as you probably know even better, that most probably also isn't easy. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 --- Additional comments from p...@openoffice.org Wed Jun 23 06:58:51 + 2010 --- Reference or no; any call to any vcl class or even object after DeInitVCL has been called is an error and likely to crash. Your problem is more that there is a reference of SwXTextCursor flying around after the application (including the framework) is already gone. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 112605] [sw] crash during shutdow n: no SolarMutex
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=112605 Issue #|112605 Summary|[sw] crash during shutdown: no SolarMutex Component|Word processor Version|DEV300m80 Platform|All URL| OS/Version|All Status|NEW Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P4 Subcomponent|code Assigned to|mst Reported by|mst --- Additional comments from m...@openoffice.org Tue Jun 22 15:03:51 + 2010 --- just captured this most peculiar critter: alDisplay::~SalDisplay() SalDisplay::DeInitRandR() GtkXLib::~GtkXLib() ==26317== Thread 7: ==26317== Invalid read of size 4 ==26317==at 0xA6B2081: Application::GetSolarMutex() (svapp.cxx:528) ==26317==by 0x1DE39D19: sw::UnoImplPtr::~UnoImplPtr() (unobaseclass.hxx:126) ==26317==by 0x1DE34AF1: SwXTextCursor::~SwXTextCursor() (unoobj.cxx:919) ==26317==by 0x74F7C0D: cppu::OWeakObject::release() (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppuhelpergcc3.so.3) ==26317==by 0x1DE39A38: cppu::WeakImplHelper12::release() (implbase12.hxx:120) ==26317==by 0x1DE2C714: SwXTextCursor::release() (unoobj.cxx:3199) ==26317==by 0x101932F7: ??? (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libgcc3_uno.so) ==26317==by 0x75ABAA9: ??? (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppu.so.3) ==26317==by 0x75B4108: ??? (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppu.so.3) ==26317==by 0x75B4181: uno_Environment_invoke_v (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppu.so.3) ==26317==by 0x75B41B4: uno_Environment_invoke (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppu.so.3) ==26317==by 0x75A73A9: ??? (in inst/OO_m80_pooltest_li/OOo_DEV300m80_Linux_x86_install-arc_en-US/openoffice.org/ure/lib/libuno_cppu.so.3) ==26317== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==26317== ==26317== ==26317== Process terminating with default action of signal 11 (SIGSEGV) ==26317== Access not within mapped region at address 0x4 ==26317==at 0xA6B2081: Application::GetSolarMutex() (svapp.cxx:528) ==26317==by 0x1DE39D19: sw::UnoImplPtr::~UnoImplPtr() (unobaseclass.hxx:126) ==26317==by 0x1DE34AF1: SwXTextCursor::~SwXTextCursor() (unoobj.cxx:919) so it seems that during shutdown the SolarMutex may actually be 0... but Application::GetSolarMutex() returns a reference, not a pointer... [ but a crash during shutdown won't impact the user much and isn't so important... ] - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
