To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=80902
User fs changed the following:
What |Old value |New value
================================================================================
CC|'andreschnabel,mhu,msc,reg|'andreschnabel,dvo,jl,mhu,
|ina' |msc,regina,sb'
--------------------------------------------------------------------------------
Assigned to|fs |lo
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Tue Aug 21 20:36:17 +0000
2007 -------
fs->lo: we have a race condition here between different clients of libxml:
The jvmfwk code (which determines which Java VM to use) is client one. It uses
libxml (without any wrapper) read some settings files.
The second client is the unoxml module, which provides an UNO wrapper around
libxml for reading XML files.
Now unoxml decides to call an "xmlMemSetup" (in
unoxml/source/dom/documentbuilder.cxx), which re-routes the memory management
functions of libxml to the proper sal routines. Good idea, so far.
Unfortunately, if this happens after client 1 - jvmfwk - already started to use
libxml, the memory which formerly has been allocated using system's "malloc" is
deleted with rtl_freeMemory - which obviously crashs often enough.
This bug is triggered only recently, since nowadays the online update check,
which runs in an own thread, uses unoxml. This update check thread (running a
few seconds after OOo has been started) thus interferes with the jvmfwk client.
To reproduce this in a debugger:
- set a breakpoint in libxml2/wntmsci10/misc/build/libxml2-2.6.17/hash.c,
function xmlHashFree
- set a breakpoint in libxml2/wntmsci10/misc/build/libxml2-2.6.17/xmlmemory.c,
function xmlMemSetup
- start OOo
- quickly select File / Wizard /Web Wizard
(this will start the first client, the jvmfwk, since the wizard is
implemented in Java)
=> breakpoint 1 (in xmlHashFree) is hit
- wait a few seconds
- continue execution
=> breakpoint 1 is hit 3 more times, always simply continue execution
=> breakpoint 2 (in xmlMemSetup) is hit, within the update check thread
- continue execution
=> breakpoint 1 is hit
- step through the xmlHashFree function
=> as soon as the deallocater function passed to xmlHashFree is invoked,
there are multiple assertions from the SAL memory manager
This proves that it is a bad idea to override libxml's memory management from
within unoxml, at least as long as you cannot guarantee that you are really the
first instance using libxml.
---------------------------------------------------------------------
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
