26 Sep
2007
26 Sep
'07
9:27 p.m.
Bastian,
I agree with all that you said... I found that documentation and thought that it might
apply to the error I was experiencing. In fact perl does not use iThread, openser forks
itself.
I guess that should exist a warning on the OpenSER Perl module documentation saying that
even if the Perl module handles the errors originated inside the Perl scripts, is possible
that the Perl module does not handle errors originated inside the Perl packages,
especially if the package is a .so lib (XS Perl package). In the worst case an error
originated inside this package can crash OpenSER.
Thanks for the help,
Murilo
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of Bastian
Friedrich
Sent: quarta-feira, 26 de setembro de 2007 07:33
To: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
Hi,
sorry for not replying any earlier; I'm currently on my holidays and
(yet) have a very limited time for computer stuff :)
Your evaluation probably already pointed out the problems you
experience. Your backtrace shows that the segfault occurs during the
code in ODBC.so.
On Montag 24 September 2007, Murilo Lacerda Yoshida wrote:
So first of all a question: does the Perl module
uses iThreads?
The OpenSER perl module is linked against the system's perl library --
which will in most cases use the POSIX threading model (pthread) as its
underlying technology.
iThreads -- as far as I understood things -- refers to threading within
Perl itself, i.e. when you create threads from within Perl. In OpenSER,
the server itself forks.
The sections in the documentation that you found nonetheless probably
refer to the problems that you experience.
If the perl module really uses iThreads, then what I
have to do is
clear, right? I have to take another path to communicate with my DB,
as the perl module isn't reliable when it uses DBI in multi threaded
environments.
... or you need to find a way to communicate without using DBI -- which
may be quite a problem, anyway.
Another path would be to make openser work in only
one thread, but
that will affect the performance of my server.
Probably not an option, if you are stress testing your server?
Another question is: If the perl module really uses
iThreads, then
is there another perl extension (like DBI) in which the same problem
occurs?
Most Perl packages are "Perl only"; I would not expect to occur any
thread/multi-process related problems in these packages. Packages
with "XS" components (C libraries, resulting in .so files) are more
prone to raising problems similar to the one you are experiencing; code
they contain run in the same address space as the OpenSER server. Due
to this, they can crash the server and do (more or less) whatever they
want. Given the number of Perl packages (more than 4000 on cpan.org),
we cannont evaluate each of them :(
I'm not aware of any other "dangerous" packages, though.
I will add a "warnings" section in the perl module documentation as soon
as I have time.
Happy scripting,
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ A man with one watch knows what time it is.
\ A man with two watches is never quite sure.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users