Seg fault in libxml when svc client torn down in a multithreaded client
-----------------------------------------------------------------------
Key: AXIS2C-884
URL: https://issues.apache.org/jira/browse/AXIS2C-884
Project: Axis2-C
Issue Type: Bug
Components: core/deployment
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml
2.6.30, libcurl
Reporter: Bill Mitchell
In a multithreaded application, if the stub/svc client is freed in a thread
different from that used when the svc client was built, libxml crashes. The
trace below shows the information available from a release build with debug
information embedded.
I have verified this is not an effect of combining debug and release C
runtimes, or different versions of the C runtime. Rebuilding all the libxml
related dlls with the same runtime as is used for Axis and the client app does
not solve the problem.
Interestingly, rebuilding libxml with threads disabled does make the crash go
away. But the default build of libxml commonly available has native threads
enabled, and building without thread support may make the library not thread
safe.
By adding debug trace statements in the axis2.trace file, I have verified that
the xml_reader being torn down when the crash happens is the one used to read
the axis2.xml file when the configuration was first read. (axis2.trace file
attached.)
Looking at the code in libxml, it appears that libxml decides to close the
reader using an internal close routine intended for closing compressed channels
through zlib. Apparently the C runtime library returns a -1 EOF status when
closing a file opened for read. The close routine, gzio.c in zlib, treats this
as an error, and when libxml attempts to report the error and determines that
it is in a different thread, things really go downhill fast. I have not
isolated why the EnterCriticalSection call crashes in the system, but it does.
One way to avoid the problem would be to guarantee that the stub/svc client is
freed in the same thread as created it. In my multithreaded client
application, though, I work hard to share the stub across threads deliberately
to reduce the number of distinct service clients and the associated demand on
the server.
Windows call traceback at time of crash:
ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
msvcr80.dll!78134d09()
ntdll.dll!7c910e91()
ntdll.dll!7c9106eb()
msvcr80.dll!78134d83()
ntdll.dll!7c90104b()
> libxml2.dll!xmlGetGlobalState() Line 570 C
libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C
libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)*
schannel=0x00000000, void (void *, const char *, <no type>)*
channel=0x00000000, void * data=0x00000000, void * ctx=0x00000000, void *
nod=0x00000000, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR,
const char * file=0x00000000, int line=0, const char * str1=0x00c5d420, const
char * str2=0x00000000, const char * str3=0x00000000, int int1=0, int col=0,
const char * msg=0x00c5d360, ...) Line 452 + 0x5 bytes C
libxml2.dll!__xmlSimpleError(int domain=8, int code=0, _xmlNode *
node=0x00000000, const char * msg=0x00c5d360, const char * extra=0x00c5d420)
Line 657 + 0x2d bytes C
libxml2.dll!__xmlIOErr(int domain=8, int code=0, const char *
extra=0x00c5d420) Line 417 + 0x1a bytes C
libxml2.dll!xmlGzfileClose(void * context=0x03301f80) Line 1155 + 0x10
bytes C
libxml2.dll!xmlFreeParserInputBuffer(_xmlParserInputBuffer *
in=0x03304578) Line 2207 + 0x5 bytes C
libxml2.dll!xmlTextReaderClose(_xmlTextReader * reader=0x03304760)
Line 2244 + 0x6 bytes C
axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader *
parser=0x03301e00, const axutil_env * env=0x031aa150) Line 510 C
axiom.dll!axiom_stax_builder_free(axiom_stax_builder *
om_builder=0x03271aa8, const axutil_env * env=0x031aa150) Line 886 C
axis2_engine.dll!axis2_desc_builder_free(axis2_desc_builder *
desc_builder=0x03301d58, const axutil_env * env=0x031aa150) Line 141 C
axis2_engine.dll!axis2_conf_builder_free(axis2_conf_builder *
conf_builder=0x03301d70, const axutil_env * env=0x031aa150) Line 128 C
axis2_engine.dll!axis2_dep_engine_free(axis2_dep_engine *
dep_engine=0x031aa2e8, const axutil_env * env=0x031aa150) Line 380 C
axis2_engine.dll!axis2_conf_free(axis2_conf * conf=0x0330cad8, const
axutil_env * env=0x031aa150) Line 328 C
axis2_engine.dll!axis2_conf_ctx_free(axis2_conf_ctx *
conf_ctx=0x00000000, const axutil_env * env=0x031aa150) Line 439 C
axis2_engine.dll!axis2_svc_client_free(axis2_svc_client *
svc_client=0x031aa1a8, const axutil_env * env=0x031aa150) Line 1303 C
axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x031aa198, const
axutil_env * env=0x031aa150) Line 131 C
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
