axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <>
Subject [jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
Date Mon, 07 Jan 2008 14:20:34 GMT


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
     libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x036ead98)  Line 1679 + 0x9 bytes
     libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x036f4d98)  Line 2196 + 0xc bytes
     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)
    return AXIS2_SUCCESS;

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_cleanup(    )
    if ((xml_init_count > 0) &&
        (--xml_init_count == 0)) 
    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:
>             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,
>            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:
For additional commands, e-mail:

View raw message