You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/03/31 21:59:17 UTC
anybody using Sun's compiler and getting libthread referenced by
executables but not libpthread?
I'm using Sun WorkShop 5.0 sometimes, and these builds result in
executables like httpd referencing libthread but not libpthread.
We pass cc the -mt switch, but at least with this version that switch
isn't enough to pull in libpthread. Can anybody confirm that with a
more recent Sun compiler APR apps are getting libpthread?
This apparently results in apr_proc_create() forking more than just the
calling thread, and you can get anoying stuff like this when running
Apache's mod_ext_filter with the worker MPM:
[Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
(client socket)
(By the time the fork()-ed child of the calling thread got around to
exec()-ing the external filter program, the copy of the listener thread
in the forked() child reached the accept() call.)
There was other undiagnosed havoc going on, including a child process
exiting with a fatal error code which led to the parent bailing out with
a large number of children left to clean up manually. This was probably
the neatest failure:
ibthread panic: fault in libthread critical section : dumping core (PID:
4894 LWP 12)
stacktrace:
ff0faaa8
ff0fa8fc
ff103498
ff0ff8f0
ff105558
ff2d2bac
36964
ff2d29bc
ff10b728
ff2d2978
Cool, huh?
I haven't gotten to the point of teaching APR to pull in libpthread in
this situation and rebuilding Apache's httpd and retesting, but I
thought I'd put this out there to see if somebody with a newer compiler
is getting better results.
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz wrote:
> --On Monday, March 31, 2003 14:59:17 -0500 Jeff Trawick
> <tr...@attglobal.net> wrote:
>
>> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
>> executables like httpd referencing libthread but not libpthread. We pass
>> cc the -mt switch, but at least with this version that switch isn't
>> enough to pull in libpthread. Can anybody confirm that with a more
>> recent Sun compiler APR apps are getting libpthread?
>
>
> Can you please send the relevant config for mod_ext_filter?
here is a simplified version:
ExtFilterDefine traceplain \
cmd="/usr/bin/tee /tmp/traceplain"
<Location /some/location>
setoutputfilter traceplain;deflate
</Location>
testing with an httpd that didn't link to libpthread (but did link to
libthread) showed the problem
I'm about to get a build that links to libpthread and I'll try to reproduce
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by Justin Erenkrantz <je...@ics.uci.edu>.
--On Monday, March 31, 2003 14:59:17 -0500 Jeff Trawick
<tr...@attglobal.net> wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread. We pass
> cc the -mt switch, but at least with this version that switch isn't
> enough to pull in libpthread. Can anybody confirm that with a more
> recent Sun compiler APR apps are getting libpthread?
Can you please send the relevant config for mod_ext_filter?
I know that WS 5.0 is *really* out-of-date. You also need to make sure
that you've applied all of the 5.x updates (as well as OS updates). ISTR
we had problems before with 5.0 that disappeared when we applied all of the
patches for both the OS and compiler/linker.
I believe that the -lpthread doesn't matter due to the way Solaris's thread
libraries are implemented. It'd map to the same function call. -- justin
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31/3/03 20:59, "Jeff Trawick" <tr...@attglobal.net> wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpthread. Can anybody confirm that with a
> more recent Sun compiler APR apps are getting libpthread?
>
> This apparently results in apr_proc_create() forking more than just the
> calling thread, and you can get anoying stuff like this when running
> Apache's mod_ext_filter with the worker MPM:
>
> [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
> (client socket)
>
> (By the time the fork()-ed child of the calling thread got around to
> exec()-ing the external filter program, the copy of the listener thread
> in the forked() child reached the accept() call.)
>
> There was other undiagnosed havoc going on, including a child process
> exiting with a fatal error code which led to the parent bailing out with
> a large number of children left to clean up manually. This was probably
> the neatest failure:
>
> ibthread panic: fault in libthread critical section : dumping core (PID:
> 4894 LWP 12)
> stacktrace:
> ff0faaa8
> ff0fa8fc
> ff103498
> ff0ff8f0
> ff105558
> ff2d2bac
> 36964
> ff2d29bc
> ff10b728
> ff2d2978
>
> Cool, huh?
>
> I haven't gotten to the point of teaching APR to pull in libpthread in
> this situation and rebuilding Apache's httpd and retesting, but I
> thought I'd put this out there to see if somebody with a newer compiler
> is getting better results.
Jeff/all... We got Forte on Nagoya, thanks to the freaks @ Sun! :-)
/opt/forte/....
Pier
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by Jeff Trawick <tr...@attglobal.net>.
Spinka, Kristofer wrote:
> To be sure that the compiler is respecting the POSIX behavior, remove
> the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread.
"man pthread_create" says "cc -mt foo.c -lpthread"
_POSIX_C_SOURCE=199506L sounds like something to force my program to use
only those interfaces described in some particular document... we want
access to everything the platform offers
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by "Spinka, Kristofer" <ks...@style.net>.
The -mt compiler option only instructs the C++ compiler to perform some
multithread safe checks and preserve a specific linking order with the
Solaris thread library.
On Solaris, the POSIX thread library is an abtraction of Sun's native
thread support. So any application that wishes to use this abstraction
should link first with libpthread.so (POSIX), which implicitly links
libthread.so (Solaris). In reality they all call lwp_create(), but the
parameters, limits, etc. are specific to the abstracted interface.
To be sure that the compiler is respecting the POSIX behavior, remove
the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread.
There is in fact a mixed mode identifier, but I don't think it is necessary here.
/kristofer
On Mon, 31 Mar 2003, Jeff Trawick wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpthread. Can anybody confirm that with a
> more recent Sun compiler APR apps are getting libpthread?
>
> This apparently results in apr_proc_create() forking more than just the
> calling thread, and you can get anoying stuff like this when running
> Apache's mod_ext_filter with the worker MPM:
>
> [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
> (client socket)
>
> (By the time the fork()-ed child of the calling thread got around to
> exec()-ing the external filter program, the copy of the listener thread
> in the forked() child reached the accept() call.)
>
> There was other undiagnosed havoc going on, including a child process
> exiting with a fatal error code which led to the parent bailing out with
> a large number of children left to clean up manually. This was probably
> the neatest failure:
>
> ibthread panic: fault in libthread critical section : dumping core (PID:
> 4894 LWP 12)
> stacktrace:
> ff0faaa8
> ff0fa8fc
> ff103498
> ff0ff8f0
> ff105558
> ff2d2bac
> 36964
> ff2d29bc
> ff10b728
> ff2d2978
>
> Cool, huh?
>
> I haven't gotten to the point of teaching APR to pull in libpthread in
> this situation and rebuilding Apache's httpd and retesting, but I
> thought I'd put this out there to see if somebody with a newer compiler
> is getting better results.
>
>
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31/3/03 20:59, "Jeff Trawick" <tr...@attglobal.net> wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpthread. Can anybody confirm that with a
> more recent Sun compiler APR apps are getting libpthread?
>
> This apparently results in apr_proc_create() forking more than just the
> calling thread, and you can get anoying stuff like this when running
> Apache's mod_ext_filter with the worker MPM:
>
> [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
> (client socket)
>
> (By the time the fork()-ed child of the calling thread got around to
> exec()-ing the external filter program, the copy of the listener thread
> in the forked() child reached the accept() call.)
>
> There was other undiagnosed havoc going on, including a child process
> exiting with a fatal error code which led to the parent bailing out with
> a large number of children left to clean up manually. This was probably
> the neatest failure:
>
> ibthread panic: fault in libthread critical section : dumping core (PID:
> 4894 LWP 12)
> stacktrace:
> ff0faaa8
> ff0fa8fc
> ff103498
> ff0ff8f0
> ff105558
> ff2d2bac
> 36964
> ff2d29bc
> ff10b728
> ff2d2978
>
> Cool, huh?
>
> I haven't gotten to the point of teaching APR to pull in libpthread in
> this situation and rebuilding Apache's httpd and retesting, but I
> thought I'd put this out there to see if somebody with a newer compiler
> is getting better results.
Jeff/all... We got Forte on Nagoya, thanks to the freaks @ Sun! :-)
/opt/forte/....
Pier
Re: anybody using Sun's compiler and getting libthread referenced
by executables but not libpthread?
Posted by "Spinka, Kristofer" <ks...@style.net>.
The -mt compiler option only instructs the C++ compiler to perform some
multithread safe checks and preserve a specific linking order with the
Solaris thread library.
On Solaris, the POSIX thread library is an abtraction of Sun's native
thread support. So any application that wishes to use this abstraction
should link first with libpthread.so (POSIX), which implicitly links
libthread.so (Solaris). In reality they all call lwp_create(), but the
parameters, limits, etc. are specific to the abstracted interface.
To be sure that the compiler is respecting the POSIX behavior, remove
the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread.
There is in fact a mixed mode identifier, but I don't think it is necessary here.
/kristofer
On Mon, 31 Mar 2003, Jeff Trawick wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpthread. Can anybody confirm that with a
> more recent Sun compiler APR apps are getting libpthread?
>
> This apparently results in apr_proc_create() forking more than just the
> calling thread, and you can get anoying stuff like this when running
> Apache's mod_ext_filter with the worker MPM:
>
> [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
> (client socket)
>
> (By the time the fork()-ed child of the calling thread got around to
> exec()-ing the external filter program, the copy of the listener thread
> in the forked() child reached the accept() call.)
>
> There was other undiagnosed havoc going on, including a child process
> exiting with a fatal error code which led to the parent bailing out with
> a large number of children left to clean up manually. This was probably
> the neatest failure:
>
> ibthread panic: fault in libthread critical section : dumping core (PID:
> 4894 LWP 12)
> stacktrace:
> ff0faaa8
> ff0fa8fc
> ff103498
> ff0ff8f0
> ff105558
> ff2d2bac
> 36964
> ff2d29bc
> ff10b728
> ff2d2978
>
> Cool, huh?
>
> I haven't gotten to the point of teaching APR to pull in libpthread in
> this situation and rebuilding Apache's httpd and retesting, but I
> thought I'd put this out there to see if somebody with a newer compiler
> is getting better results.
>
>