[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567024#action_12567024 ]
Bill Mitchell commented on AXIS2C-884: -------------------------------------- You're very welcome. By the way, to implement a call to initialize libxml in my main thread, I did not have to include all the libxml includes which caused some conflicts with other xml related includes I had. Instead I excerpted just the fragment of the header file for initialization and encapsulated it under an ifdef in my app: // If libxml2 is used, instead of guththila, then we need to explicitly initialize outside of Axis2c #if AXIS_LIBXML_INIT_IN_MAIN_THREAD // Define libxml entry points directly, to avoid conflicts with Xerces #ifdef __cplusplus extern "C" { #endif #include <libxml/xmlexports.h> XMLPUBFUN void XMLCALL xmlInitParser (void); XMLPUBFUN void XMLCALL xmlCleanupParser (void); #ifdef __cplusplus } #endif #endif Then I added a call to xmlInitParser() in my main thread, again under ifdef, and worked around the problem. I may have had another issue to make sure that libxml2 and its friends are built with the VS debug C runtime included in the manifest, but I had already solved that issue in order to debug libxml2. The other, simpler workaround is to rebuild Axis to use the guththila parser. I only went back to libxml2 as I was encountering guththila problems that I thought would take some time to resolve. All the ones I encountered in my app have been fixed in 1.3 and it works fine for me. There are a couple of other minor ones that are preventing the guththila parser becoming the default parser today. I think the general direction is to move to guththila as soon as practicable. For your app, like mine, it may be there already. > 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 > Attachments: axis2.trace, desc_builder_diff.txt > > > 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]