You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Michael B Allen <io...@gmail.com> on 2008/04/10 22:52:33 UTC

FPE in linux loader on custom PHP extension

Sorry this is a bit OT but I'm not sure what to do next and would
really appreciate some ideas.

One of my clients is seeing an FPE in ld-linux-x86-64.so when loading
a custom PHP extension. The backtrace is inlined below.

At least I assume it's blowing up loading my extension - with my
extension disabled, everything loads and runs ok.

# gdb /usr/sbin/httpd2-prefork
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run -X
Starting program: /usr/sbin/httpd2-prefork -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

[snipped]

[Thread debugging using libthread_db enabled]
[New Thread 47783686579872 (LWP 11366)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

[snipped]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 47783686579872 (LWP 11366)]
0x00002b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00002b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1  0x00002b7580304a77 in _dl_lookup_symbol_x () from
/lib64/ld-linux-x86-64.so.2
#2  0x00002b7580306028 in _dl_relocate_object () from
/lib64/ld-linux-x86-64.so.2
#3  0x00002b758030c2a5 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#4  0x00002b75803081f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5  0x00002b758030bacb in _dl_open () from /lib64/ld-linux-x86-64.so.2
#6  0x00002b75811961fa in dlopen_doit () from /lib64/libdl.so.2
#7  0x00002b75803081f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8  0x00002b758119658d in _dlerror_run () from /lib64/libdl.so.2
#9  0x00002b7581196171 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#10 0x00002b7582edf486 in php_dl () from /usr/lib64/apache2/mod_php5.so
#11 0x00002b7582f3dfe3 in ?? () from /usr/lib64/apache2/mod_php5.so
#12 0x00002b7582f6e937 in zend_llist_apply () from
/usr/lib64/apache2/mod_php5.so
#13 0x00002b7582f3dfaa in php_ini_register_extensions () from
/usr/lib64/apache2/mod_php5.so
#14 0x00002b7582f388bb in php_module_startup () from
/usr/lib64/apache2/mod_php5.so
#15 0x00002b7582ff5825 in ?? () from /usr/lib64/apache2/mod_php5.so
#16 0x00002b7582ff58ad in ?? () from /usr/lib64/apache2/mod_php5.so
#17 0x000055555558c93c in ap_run_post_config () from /usr/sbin/httpd2-prefork
#18 0x0000555555579fd7 in main () from /usr/sbin/httpd2-prefork
(gdb) q
The program is running.  Exit anyway? (y or n) y

I have an OpenSUSE 10.3 install here and the extension loads and runs
perfectly. I have many other people using the extension and no one has
reported this problem. I have recompiled *everything* with no change. It
seems to be this one particular installation.

Ldd on all binaries yields the expected "ELF 64-bit LSB executable,
AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked
(uses shared libs), for GNU/Linux 2.6.4, stripped" with the exception
of my extension which is "not stripped".

The PHP extension is very small but it is linked with a large (5MB) .so
created from numerous .a archives of -fpic compiled code. The
resulting .so is created using a version script so that only the handful
of symbols used by the extension are exported.

So httpd loads mod_php.so which calls dlopen on my extension and
at that point an FPE occurs in do_lookup_symbol_x.

Could it be that the loader is trying to relocate something that is not
relocatable because of how things are linked?

Has anyone seen anything like this before?

Can anyone recommend a method for debugging this issue?

Any help would be appreciated,
Mike

Re: FPE in linux loader on custom PHP extension

Posted by Michael B Allen <io...@gmail.com>.
On 4/10/08, Michael B Allen <io...@gmail.com> wrote:
> Sorry this is a bit OT but I'm not sure what to do next and would
>  really appreciate some ideas.
>
>  One of my clients is seeing an FPE in ld-linux-x86-64.so when loading
>  a custom PHP extension. The backtrace is inlined below.
>
>  At least I assume it's blowing up loading my extension - with my
>  extension disabled, everything loads and runs ok.
>
>  # gdb /usr/sbin/httpd2-prefork
>  GNU gdb 6.6
>  Copyright (C) 2006 Free Software Foundation, Inc.
>  GDB is free software, covered by the GNU General Public License, and you are
>  welcome to change it and/or distribute copies of it under certain
>  conditions.
>  Type "show copying" to see the conditions.
>  There is absolutely no warranty for GDB.  Type "show warranty" for details.
>  This GDB was configured as "x86_64-suse-linux"...
>  (no debugging symbols found)
>  Using host libthread_db library "/lib64/libthread_db.so.1".
>  (gdb) run -X
>  Starting program: /usr/sbin/httpd2-prefork -X
>  (no debugging symbols found)
>  (no debugging symbols found)
>  (no debugging symbols found)
>
>  [snipped]
>
>  [Thread debugging using libthread_db enabled]
>  [New Thread 47783686579872 (LWP 11366)]
>  (no debugging symbols found)
>  (no debugging symbols found)
>  (no debugging symbols found)
>
>  [snipped]
>
>  Program received signal SIGFPE, Arithmetic exception.
>  [Switching to Thread 47783686579872 (LWP 11366)]
>  0x00002b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
>  (gdb) bt
>  #0  0x00002b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2

This turned out to be a backward compatibility problem with .hash vs
newer .hash.gnu sections in the libs. Google on "SIGFPE do_lookup_x"
for details.

Signing off,
Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/