axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <sam...@wso2.com>
Subject Re: malloc, realloc, free and readdir failing
Date Tue, 10 Jul 2007 01:18:13 GMT
Can you get a single thread working? Just start one thread with one 
service client instance and see if that works.

Also, did you set axis2_options_set_xml_parser_reset option setting to 
AXIS2_FALSE?

Can you post the code in a Jira issue so that I can have a look into the 
code?

Thanks,
Samisa...


Stefano Pettini wrote:
> Thanks again Samisa for your answer.
>
> I'm still tracking the countinous problems and crashes with absolutely 
> no progress. I don't know what to think or do :-(
>
> Has anybody even tried to run multiple svc_clients in parallel?
> Is axis2_svc_client_create thread safe?
> Is the one-environment-per-thread solution thread safe? Not sure about 
> shared error_t structures...
>
> This is a typical result of my test, just to prove you I'm not dreaming.
>
> Heap corruption detected at 00EA42E0
> First-chance exception in Manager.exe (NTDLL.DLL): 0xC0000005: Access 
> Violation.
> Heap corruption detected at 00EA7210
> HEAP[Manager.exe]: HEAP: Free Heap block ea7208 modified at ea721c 
> after it was freed
>
> got randomly during parallel calls to axis2_svc_client_create, that 
> fail with AXIS2_ERROR_CREATING_XML_STREAM_READER :-(
>
> If I don't solve this problem, I'll have to abandon Axis2 and look for 
> something else able to send an XML string to a SOAP endpoint and to 
> give back the response as XML string.
>
> Any suggestion?
>
> Thanks!
> Stefano
>
> Samisa Abeysinghe wrote:
>> Stefano Pettini wrote:
>>> Hi Samisa,
>>>
>>> thank you for your reply.
>>>
>>> May you tell me if these pseudo-code fragments are conceptually right?
>> When you are using threads, each thread should have its own env. 
>> Hence Fragment 1 looks the more correct one.
>>
>> Fragment 2 and 3 are likely yo fail, because they use the same env 
>> across threads.
>>>
>>> Fragment 1)
>>> Main thread:
>>>    start threads 1...N
>>> Thread n:
>>>    create environment env[n]
>>>    create service client client_a[n] from env[n]
>>>    create service client client_b[n] from env[n]
>>>    create service client client_c[n] from env[n]
>>>    use service client client_a[n]
>>>    use service client client_b[n]
>>>    use service client client_c[n]
>>>  
>>> Fragment 2)
>>> Main thread:
>>>    create environment env
>>>    start threads 1...N
>>> Thread n:
>>>    create service client client_a[n] from env
>>>    create service client client_b[n] from env
>>>    create service client client_c[n] from env
>>>    use service client client_a[n]
>>>    use service client client_b[n]
>>>    use service client client_c[n]
>>>
>>> Fragment 3)
>>> Main thread:
>>>    create environment env
>>>    create service client client_a from env
>>>    create service client client_b from env
>>>    create service client client_c from env
>>>    start threads 1...N
>>> Thread n:
>>>    use service client client_a
>>>    use service client client_b
>>>    use service client client_c
>>>
>>> Whatever option I try, I still have A LOT of errors during C-Runtime 
>>> library function invocations. malloc returning null, user 
>>> exceptions, null pointers, heap corruption messages, ...
>>>
>>> I still think there's something I'm missing, like calling an 
>>> initialization function at the beginning of a thread.
>>>
>>> I develop on MFC framework, so I use CWinThread and AfxBeginThreads 
>>> (that encapsulate native Win32's CreateThread) to spawn new threads.
>>>
>>> Another question, probably linked with heap corruption: strings! I 
>>> use axutil_string_create whenever I have to pass an axis's string, 
>>> and I pass string literal constants ("hello") or const char* 
>>> whenever a function needs an axis'2 char_t. I saw a similar usage in 
>>> examples, but these days, reading the mailing list, I saw you 
>>> instead suggest strdup and similar... What's the official "correct" 
>>> way of handling string (and in general, memory management)? I can't 
>>> find it explained anywhere, and I think it's a key point for every 
>>> user/developer to avoid memory leaks.
>> axutil_string_t wraps axis2_char_t. You can choose to use whatever 
>> you like.
>> Handling axis2_char_t pointers is similar to handling char* in C, if 
>> you choose to use axis2_char_t.
>> When you are using axutil_string_t, you have to use the correct 
>> create method, depending on the way you want to handle the buffer you 
>> pass to the create method. axutil_string_create creates a deep copy, 
>> so the buffer you pass to the create method is your responsibility, 
>> meaning you have to free it. axutil_string_create_assume_ownership 
>> assumes the ownership of the buffer, meaning when the string is 
>> freed, it will free the buffer you pass and you do not have to free 
>> it.  axutil_string_create_const makes a shallow copy and also do not 
>> assume the ownership of the buffer, you have to be responsible to 
>> manage the buffer and have to ensure the buffer you pass goes out of 
>> scope after the string is freed. Please have a look into the 
>> implementation for further details.
>>
>> Thanks,
>> Samisa...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>


-- 
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


Mime
View raw message