Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PHP CLI bails with threaded libraries

3 views
Skip to first unread message

Oliver Crow

unread,
Apr 16, 2008, 4:31:55 PM4/16/08
to freebs...@freebsd.org
Hi all,

I'm looking for advice on a problem with PHP on FreeBSD 7.0, which
appears to be related to threading. Whenever I run the command line
'php' program I get a core dump with a series of error messages:

> Fatal error 'Cannot allocate red zone for initial thread' at line 384
in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)

This happens only when I configure php/extensions.ini to load a module
which links with the libthr.so.3 threading library. For example loading
'mhash.so' or 'pgsql.so' triggers the core dump, but other modules are
fine. Both of those modules require libthr.so.3 (according to objdump
-p). I don't get any core dump when running the Apache php pre-fork
module, whether or not I load the offending modules. I only get the core
dump when I run 'php' or 'php-cgi' from the command line.

Other posts with this error message have suggested upgrading all ports
after upgrading to 7.0. I did do that. I may have missed something, but
I don't think so. I tried compiling mhash and libpq with threading
turned off. That fixed the problem, but I don't see why this is necessary.

Is there something wrong with loading a PHP module that links the posix
thread library? Surely the PHP command line tool doesn't even use threads?!

If you have mhash.so or pgsql.so loading from php/extensions.ini, does
libthr.so.3 appear as a NEEDED line in your objdump output? Can you run
php from the cli without an immediate core dump?
% objdump -p /usr/local/lib/libpq.so.5
% objdump -p /usr/local/lib/libmhash.so.2
% php -v


For reference, I disabled linking with the thread libraries by creating
/usr/ports/security/mhash/Makefile.local with the line:
CONFIGURE_ARGS+= --with-LDFLAGS=""

and /usr/ports/databases/postgresql83-server/Makefile.local with the line:
CONFIGURE_ARGS+= --disable-thread-safety

(Note that although there are some posts claiming you can do something
like this:
make CONFIGURE_ARGS+=--disable-thread-safety
it doesn't appear to actually work -- examining config.log reveals that
the other args to configure get clobbered -- the "+=" isn't doing what
you'd think.)


php -i reports:
Thread Safety => disabled

I'm using the following packages, compiled from ports:
apache-2.2.8
php5-5.2.5_1
php5-mhash-5.2.5_1
php5-pgsql-5.2.5_1
postgresql-client-8.3.1
postgresql-server-8.3.1

# ldd /usr/local/bin/php
/usr/local/bin/php:
libcrypt.so.3 => /lib/libcrypt.so.3 (0x28261000)
libm.so.4 => /lib/libm.so.4 (0x28279000)
libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x28292000)
libz.so.3 => /lib/libz.so.3 (0x283b4000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x283c5000)
libc.so.6 => /lib/libc.so.6 (0x284a3000)
libz.so.4 => /lib/libz.so.4 (0x2858d000)
libm.so.5 => /lib/libm.so.5 (0x2859f000)
libc.so.7 => /lib/libc.so.7 (0x285b4000)

The php.core stack trace is:
#0 0x284fd273 in _UTF8_init () from /lib/libc.so.6
#1 0x284fd71a in _UTF8_init () from /lib/libc.so.6
#2 0x284fd80e in _UTF8_init () from /lib/libc.so.6
#3 0x284fda97 in _UTF8_init () from /lib/libc.so.6
#4 0x284fe397 in _UTF8_init () from /lib/libc.so.6
#5 0x284fe480 in malloc () from /lib/libc.so.6
#6 0x288b8e97 in pthread_kill () from /lib/libthr.so.3
#7 0x288b9911 in pthread_join () from /lib/libthr.so.3
#8 0x288b6344 in pthread_self () from /lib/libthr.so.3
#9 0x288b6650 in pthread_rwlock_timedwrlock () from /lib/libthr.so.3
#10 0x285620f6 in abort () from /lib/libc.so.6
#11 0x288bb28d in pthread_attr_destroy () from /lib/libthr.so.3
#12 0x288b9bae in pthread_join () from /lib/libthr.so.3

... last 5 repeated many times until ...

#2213 0x288b6344 in pthread_self () from /lib/libthr.so.3
#2214 0x288b6650 in pthread_rwlock_timedwrlock () from /lib/libthr.so.3
#2215 0x288b975e in pthread_join () from /lib/libthr.so.3
#2216 0x288b9c02 in pthread_join () from /lib/libthr.so.3
#2217 0x288bbea5 in __error () from /lib/libthr.so.3
#2218 0x28254574 in ?? () from /libexec/ld-elf.so.1
#2219 0x2825d3b0 in ?? ()
#2220 0xbfbfe528 in ?? ()
#2221 0x288b1871 in ?? () from /lib/libthr.so.3
#2222 0x2822f96b in dl_iterate_phdr () from /libexec/ld-elf.so.1

Thanks for any advice or assistance!

Oliver

Xin LI

unread,
Apr 16, 2008, 5:23:55 PM4/16/08
to Oliver Crow, freebs...@freebsd.org
Oliver Crow wrote:
> Hi all,
>
> I'm looking for advice on a problem with PHP on FreeBSD 7.0, which
> appears to be related to threading. Whenever I run the command line
> 'php' program I get a core dump with a series of error messages:
>
> > Fatal error 'Cannot allocate red zone for initial thread' at line 384
> in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)

You may have to rebuild all related stuff to get rid of this. Linking
against different libc versions is not supported.

Cheers,
--
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!

Oliver Crow

unread,
Apr 16, 2008, 6:47:47 PM4/16/08
to d...@delphij.net, freebs...@freebsd.org
Xin LI wrote:

> Oliver Crow wrote:
>> I'm looking for advice on a problem with PHP on FreeBSD 7.0, which
>> appears to be related to threading. Whenever I run the command line
>> 'php' program I get a core dump with a series of error messages:
>>
>> > Fatal error 'Cannot allocate red zone for initial thread' at line
>> 384 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)
>
> You may have to rebuild all related stuff to get rid of this. Linking
> against different libc versions is not supported.

I did a portupgrade -f lang/php5, and that did the trick! I can now load
php extensions such as mhash and pgsql which use libthr without dumping
core.

I guess this should have clued me in:
# ldd /usr/local/bin/php
...
libc.so.6 => /lib/libc.so.6 (0x284a3000)
...
libc.so.7 => /lib/libc.so.7 (0x285b4000)

After the portupgrade ldd shows only libc.so.7

Thanks!
Oliver


0 new messages