[
https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nandika Jayawardana reassigned AXIS2C-884:
------------------------------------------
Assignee: Nandika Jayawardana
> 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
> Assignee: Nandika Jayawardana
> 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]
