[OpenSER-Devel] [ openser-Bugs-1835638 ] mi_xmlrpc corrupts stack and memory

[SourceForge.net]

Bugs item #1835638, was opened at 2007-11-21 11:49
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1835638&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mi_xmlrpc corrupts stack and memory

Initial Comment:
When compiled against libxmlrpc-c3 newer than 1.0.0, the mi-xmlrpc corrupts stack and memory.
The issues is in the libxmlrpc-c3 library - prior to 1.0.0 it was by default compiled with fork-support (multi process model), but later it was switch to pthread-support (multi thread model).

Unfortunately multi threading does not work in openser, leading to data curruption and crashes in other modules.

It seams there is no way to select at runtime (or link time) what model the libxmlrpc should use. And in all the distro it comes by default with multi-thread support :(.

The solutions? Hmm....
1) do not compile against versions newer (than 1.0.0) - but not so nice
2) import some code from libxmlrpc into mi_xmlrpc module in order to compile it with fork and not pthread support - ugly, but it will cover all cases.
3) approach the libxmlrpc developers to added a more flexible way of selecting the support you need (not only at compile time) - this is a future solution


For 1.3 release, I think I will try to go for solution (2) and if too difficult, it will fall back to (1). (3) is not a present solution.

Many thanks to Dan Pascu for helping in troubleshooting and identifying the problem.

Bogdan



----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2007-11-28 21:56

Message:
Logged In: YES 
user_id=1275325
Originator: YES

There is some more testing needed before porting this to 1.2.
Unfortunately the backport is a must as the same critical bug affects 1.2
also, making mi_xmlrpc un-usable with libxmlrpc other than 0.9.10.

Bogdan 

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2007-11-21 14:45

Message:
Logged In: YES 
user_id=1275325
Originator: YES

Hi Henning,

yes threads in openser are known not to work - data handling, pkg memory
manager, etc are not thread safe.
The problem with libxmlrpc lib is that originaly was compiled with fork
support and than they switched to pthread support :(...And even worst, this
selection is available only at compile time...
And asking the openser users not to use libxmlrpc from distro, bur to
compile by themself the lib is not a good option (at least not in my
opinion).

I will push the issue to the developers for discussions.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Henning Westerholt (henningw)
Date: 2007-11-21 13:58

Message:
Logged In: YES 
user_id=337916
Originator: NO

Hello Bogdan,

i faced similar issues with the multithreaded mysql module..
Threads simply don't fit well into the fork/ multi-process model that the
server use.

One comment in regards to solution 3:
The libxmlrpc lib could also provide some pthread_atfork handler to
protect
its internal state against forking application, then it would be safe
to use the multithreading library with mi_xmlrpc. If they don't provide
this
handler and support only threads, then this should be reported as a bug to
the
developers, because its impossible/ really difficult to use the lib save
with any
application using fork.

Cheers,

Henning

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1835638&group_id=139143