You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Bill Mitchell (JIRA)" <ji...@apache.org> on 2008/01/05 00:38:34 UTC
[jira] Created: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Resolved: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Nandika Jayawardana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nandika Jayawardana resolved AXIS2C-884.
----------------------------------------
Resolution: Fixed
Applied the patch provided. Also added doc comment to the libxml_reader_wrapper_free function where the crash pop up. Also there is a workaround to solve the problem using axis2_options_set_xml_parser_reset function.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Nandika Jayawardana (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556180#action_12556180 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
Much as I like the source fix in my recommendation, as it does fix one symptom of the problem and frees resources, including files, sooner rather than later, I must admit it is not a complete solution. The initial crash I reported is remedied, but I still see other bizarre behavior from libxml when invoked from multiple threads.
The libxml documentation indicates that it expects to be initialized once in the "main" thread before multithreaded operation begins. Instead, Axis2 does the initialization each time the op_client is created, which happens in my case in one of the multiple threads after application initialization. I have tried doing the initialization just once with a call to xmlInitParser() in the main application thread before any call to the Axis2 routines, but this reintroduces the crash in xmlGetGlobalState. So I can't honestly recommend that moving the xmlInitParser call earlier, say when the first environment was created which might happen in the application main thread, would alleviate any problem.
This suggests that libxml is not as thread-safe as we would like, and that each thread must create and use its own set of svc clients, instead of sharing them in a connection pool. Of course, the guththila parser does not suffer from this particular thread problem.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556174#action_12556174 ]
Senaka Fernando commented on AXIS2C-884:
----------------------------------------
Hi Bill,
I see you have a good point here. The should cause no-harm to the existing API, and if it adds that additional functionality of what you've mentioned here, +1 for a fix.
Regards,
Senaka
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556935#action_12556935 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial "main" thread, even when the main thread no longer exists.
I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free.
So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570428#action_12570428 ]
Frank Huebbers commented on AXIS2C-884:
---------------------------------------
Hi Bill,
I just wanted to let you know that I got everything to work with the guththila parser. A simple recompilation was all that was needed (Snapshot from 7\2\2008). So, it looks like it does suffice for my application.
Thanks again for the great feedback.
Cheers,
Frank
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556569#action_12556569 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
To isolate what kind of fix might work for the multithreading case, for testing I commented out the xmlInitParser() and xmlCleanupParser() calls and moved these into the application threads. If these calls are issued once at the start of the application and once at the end, all works well. The same is not true when attempting to use libxml2 serially in multiple threads. In particular, I tried creating and freeing the stub around each SOAP message, and performing an xmlInitParser and xmlCleanupParser around each use. Even in the application where mutex's can ensure that the xmlCleanupParser() completes before an xmlInitParser() is issued, and the use_counts are maintained under mutex to avoid race conditions, the first time libxml2 is initialized in a second thread after being freed in the first thread, the crash in xmlGetGlobalState reappears. See the traceback below, as well as relevant trace lines from my application trace.
ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!7c80e98b()
> msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x00002220, int nLine=67225284) Line 268 + 0x15 bytes C++
msvcr80d.dll!malloc(unsigned int nSize=17792788) Line 154 + 0x15 bytes C++
libxml2.dll!xmlGetGlobalState() Line 570 C
T@5 : | | | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | info: Freeing libxml2
T@5 : | | | | | | | | info: Initializing libxml2
T@5 : | | | | | | | | info: Freeing libxml2
T@6 : | | | | | | | | info: Initializing libxml2
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558762#action_12558762 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
One reason it is difficult to isolate exactly what is happening is that WindowsXP exhibits different behavior in a multiple CPU environment than it does in a single CPU environment. In a single CPU environment, using axis2_options_set_xml_parser_reset to disable the xmlCleanupParser() call on each service termination may succeed in avoiding the libxml seg faults. This does not work in the multiple CPU environment, as seen in the crash below. This crash can happen even when only one service is created and there is no parser reset call, provided that the service is created in a "transient" thread that no longer exists when the service is freed.
ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!7c80e98b()
> msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x0000239c, int nLine=40696612) Line 268 + 0x15 bytes C++
msvcr80d.dll!malloc(unsigned int nSize=16809748) Line 154 + 0x15 bytes C++
libxml2.dll!xmlGetGlobalState() Line 570 C
libxml2.dll!__xmlDefaultSAXHandler() Line 821 + 0x5 bytes C
libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x02ac6b88) Line 1691 + 0xd bytes C
libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x02a81898) Line 2196 + 0xc bytes C
axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 512 + 0x9 bytes C
axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 35 C
axiom.dll!axiom_stax_builder_free(axiom_stax_builder * om_builder=0x02b07938, const axutil_env * env=0x019cb498) Line 885 C
axiom.dll!axiom_soap_builder_free(axiom_soap_builder * soap_builder=0x02a875e8, const axutil_env * env=0x019cb498) Line 189 C
axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope * soap_envelope=0x02a85a58, const axutil_env * env=0x019cb498) Line 168 C
axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x02aa5e18, const axutil_env * env=0x019cb498) Line 374 C
axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x02aea0a0, const axutil_env * env=0x019cb498) Line 165 C
axis2_engine.dll!axis2_op_client_free(axis2_op_client * op_client=0x02aa3ca8, const axutil_env * env=0x019cb498) Line 615 C
axis2_engine.dll!axis2_svc_client_free(axis2_svc_client * svc_client=0x019f5028, const axutil_env * env=0x019cb498) Line 1287 C
axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x019cb760, const axutil_env * env=0x019cb498) Line 129 C
I have not delved into the lower level Windows code to see if the thread management is doing something special in the multiple CPU case, or if this is just a race condition that appears more easily in a multi-CPU environment.
Evidently, the only way to avoid the crash is to create Axis initialization and termination entry points, as suggested above, that can be called by the application in a persistent thread, or to build enough functionality into guththila that it can replace libxml.
As it stands today, for the multithreaded application to avoid the crash it must perform the xmlInitParser() call to libxml2 itself when it starts up, before multithreaded processing begins, and also set_xml_parser_reset false in the options of every service client.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556572#action_12556572 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
To handle the multithreaded case, clearly the libxml2 documentation means what it says and there must be one initialize and one cleanup for the entire application. This means creating new entry points, say axis2_initialize() and axis2_cleanup, that the application client calls at the appropriate points. But demanding that all clients call these as appropriate means changing all the test cases, all the samples, all the documentation....
So, my suggestion is:
(1) Add new entry points, axis2_initialize() and axis2_cleanup() that the client may call to manage the initialization and tear down itself. This would be required for correct multi-thread operation with libxml.
(2) Add internal entry points, axis2_implicit_initialize, and axis2_implicit_cleanup, that op_client.c could use to accomplish the axiom_xml_reader_init() and cleanup. These routines would keep a use-count of active users, and, when there was no explicit initialize, would perform the underlying initialization only on the first use and the cleanup only when the last use was complete.
Change (2) will fix the single-thread crash above by ensuring that no xmlCleanupParser is issued while any structures are still in use. And libxml2 seems to tolerate serial reuse as long as it is in a single thread. Change (1) gives the multithreaded client the chance to take control of the initialization and termination.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556568#action_12556568 ]
Bill Mitchell commented on AXIS2C-884:
--------------------------------------
I modified my client application to create and reuse service stubs separately within each thread. Using just one thread to with multiple service stubs to different URLs, I saw a similar libxml2 crash when the stub / svc clients are freed. See the traceback below:
msvcr80d.dll!CheckBytes(unsigned char * pb=0xfeeefee8, unsigned char bCheck='í', unsigned int nSize=3) Line 1654 + 0x7 bytes C++
msvcr80d.dll!_free_dbg_nolock(void * pUserData=0xfeeefeee, int nBlockUse=1) Line 1257 + 0x17 bytes C++
msvcr80d.dll!_free_dbg(void * pUserData=0xfeeefeee, int nBlockUse=1) Line 1220 + 0xd bytes C++
msvcr80d.dll!free(void * pUserData=0xfeeefeee) Line 1178 + 0xb bytes C++
libxml2.dll!xmlCharEncCloseFunc(_xmlCharEncodingHandler * handler=0x036f0760) Line 2115 + 0xc bytes C
libxml2.dll!xmlFreeParserInputBuffer(_xmlParserInputBuffer * in=0x036eace8) Line 2204 + 0xc bytes C
libxml2.dll!xmlFreeInputStream(_xmlParserInput * input=0x036fb020) Line 1269 + 0xb bytes C
libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x036ead98) Line 1679 + 0x9 bytes C
libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x036f4d98) Line 2196 + 0xc bytes C
axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * parser=0x036fbc60, const axutil_env * env=0x0183ce10) Line 503 + 0x9 bytes C
axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader * parser=0x036fbc60, const axutil_env * env=0x0183ce10) Line 35 C
axiom.dll!axiom_stax_builder_free(axiom_stax_builder * om_builder=0x036fa788, const axutil_env * env=0x0183ce10) Line 885 C
axiom.dll!axiom_soap_builder_free(axiom_soap_builder * soap_builder=0x036fa930, const axutil_env * env=0x0183ce10) Line 189 C
axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope * soap_envelope=0x036fb748, const axutil_env * env=0x0183ce10) Line 168 C
axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x036e8658, const axutil_env * env=0x0183ce10) Line 374 C
axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x03700950, const axutil_env * env=0x0183ce10) Line 165 C
> axis2_engine.dll!axis2_op_client_free(axis2_op_client * op_client=0x03700868, const axutil_env * env=0x0183ce10) Line 615 C
axis2_engine.dll!axis2_svc_client_free(axis2_svc_client * svc_client=0x01864028, const axutil_env * env=0x0183ce10) Line 1287 C
axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x0186c630, const axutil_env * env=0x0183ce10) Line 129 C
The 0xfeeefeee is a prime indication that, when the second svc client is freed, libxml2 is trying to access memory that it already.
Looking at the op_client.c and libxml2_reader_wrapper.c, it appear that Axis2c issues an xmlInitParser and xmlCleanupParser call for each op_client, apparently expecting that libxml2 will be tolerant and keep a count of users. This does not match the libxml2 documentation, which is very insistent that it expects one init at the beginning of the application, and one cleanup when all access is done.
For testing, I tried modifying libxml2_reader_wrapper.c to keep a use_count and perform the xmlInitParser only on the first call, and the xmlCleanupParser only when all users are done:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_init( )
{
if (xml_init_count++ == 0)
{
xmlInitParser();
}
return AXIS2_SUCCESS;
}
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_cleanup( )
{
if ((xml_init_count > 0) &&
(--xml_init_count == 0))
{
xmlCleanupParser();
}
return AXIS2_SUCCESS;
}
This change remedies this second crash in msvcr80d.dll CheckBytes. But crashes of the first type, in libxml2 xmlGetGlobalState still happen as soon as activity occurs in multiple threads.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Nandika Jayawardana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600692#action_12600692 ]
Nandika Jayawardana commented on AXIS2C-884:
--------------------------------------------
Now Axis2/C uses guththila as the default parser. When using Axis2/C with guththila, Axis2/C has better performance and does not have this issue.
In case of using Libxml2 parser in a multithreaded application with Axis2/C, the way to avoid crash problems is to call xmlInitParser() function from libxml2 in main thread and when creating a client, have the axis2_options_set_xml_parser_reset false option set.
xml_reader.h provides wrapper functions to both xmlInitParser() and xmlCleanupParser() functions as axiom_xml_parser_init() and axiom_xml_parser_cleanup(). Therefore we have something similar to requested axis2_initialize() function.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Nandika Jayawardana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600093#action_12600093 ]
Nandika Jayawardana commented on AXIS2C-884:
--------------------------------------------
Applied the patch provided for the desc_builder.c .
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2C-884) Seg fault in libxml when
svc client torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556935#action_12556935 ]
wtmitchell3 edited comment on AXIS2C-884 at 1/9/08 1:21 PM:
--------------------------------------------------------------
Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before.
I tried disabling parser_reset for all the terminations except the last. It turns out that this can still crash libxml2 in getGlobalState when issued from a thread different from the initial thread. (This is essentially the same as the traceback above when the parser cleanup was issued after each operation and the parser re-initialized for the next operation.)
ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!7c80e98b()
> msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x0000239c, int nLine=40631000) Line 268 + 0x15 bytes C++
msvcr80d.dll!malloc(unsigned int nSize=16744212) Line 154 + 0x15 bytes C++
libxml2.dll!xmlGetGlobalState() Line 570 C
00000001()
I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free, or it may appear as a standalone crash in xmlGetGlobalState with no calling information available.
So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple initializations or multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset.
In a true multi-threaded case, the only way for the application to be assured a way to cleanup the libxml parser is if new entry points are created so that the application can perform the initialization in a persistent thread, and not allow the parser initialization to happen in just whichever thread happens to first create a stub/svc client.
was (Author: wtmitchell3):
Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial "main" thread, even when the main thread no longer exists.
I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free.
So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566923#action_12566923 ]
Frank Huebbers commented on AXIS2C-884:
---------------------------------------
I only wanted to say that I just ran into this problem and now, at least, understand where it's coming from.
thanks for the great discussion!
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2C-884) Seg fault in libxml when
svc client torn down in a multithreaded client
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556174#action_12556174 ]
senakafdo edited comment on AXIS2C-884 at 1/4/08 9:28 PM:
----------------------------------------------------------------
Hi Bill,
I see you have a good point here. This should cause no-harm to the existing API, and if it adds that additional functionality of what you've mentioned here, +1 for a fix.
Regards,
Senaka
was (Author: senakafdo):
Hi Bill,
I see you have a good point here. The should cause no-harm to the existing API, and if it adds that additional functionality of what you've mentioned here, +1 for a fix.
Regards,
Senaka
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-884) Seg fault in libxml when svc client
torn down in a multithreaded client
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-884:
---------------------------------
Attachment: desc_builder_diff.txt
axis2.trace
There is really no reason to keep the xml_reader/parser around after the configuration file is read, as the entire file is read into a document before the configuration parameters are processed. So the trick is for the desc_builder to free the stax_builder as soon as the document is read. Although it might be nice to turn the ownership of the document over to the callers, this would be a significant change to them and make error cleanup harder.
In the attached diff file, I developed a relatively clean solution similar to what is done elsewhere in Axis. In axis2_desc_builder_build_om, instead of keeping the stax builder around until the desc_builder is freed, we can immediately free the stax_builder and retain only the resulting node tree structure. This avoids the libxml crash by ensuring that the reader/parser is freed right away, while in the same thread.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org