Dear All,
One of my clients is seeing an FPE in ld-linux-x86-64.so when loading
extensions with my custom extension loaded. The backtrace is inlined
below.
With my extension disabled, everything loads and runs ok. I can't tell
if the loader is in the process of loading my extension.
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.
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".
I have recompiled everything with no change.
Has anyone seen anything like this before?
Can anyone recommend a method for debugging this issue?
It seems to be this one particular server. I have not been able to
reproduce the issue here.
Any help would be appreciated,
Mike
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
Can anyone recommend a method for debugging this issue?
I'd start with --enable-debug and valgrind.
It seems to be this one particular server. I have not been able to
reproduce the issue here.
What's the difference between this server and the others?
Do the others use different Apache version/build?
Other architecture maybe? LD version?
I've seen problems with native Apache on SuSE because they seem to add
-D_FILE_OFFSET_BITS=64 to CFLAGS, which changes size of many internal structs.
--
Wbr,
Antony Dovgal
Can anyone recommend a method for debugging this issue?
I'd start with --enable-debug and valgrind.
It seems to be this one particular server. I have not been able to
reproduce the issue here.What's the difference between this server and the others?
Do the others use different Apache version/build?
Other architecture maybe? LD version?
Actually it looks like this does have to do with the LD version and
specifically the .hash vs .hash.gnu section in the binaries. I was
building x86_64 binaries on a machine that only used the newer
.hash.gnu section (contrary to the man page which claims sysv style is
the default). I suspect that the client is using an older system who's
loader only supports the traditional sysv style .hash section. It
seems the solution is to use -Wl,--hash-style=both so that the dso and
library it's linked with have both the .hash and .hash.gnu sections
(confirmed with objdump -h foo.so).
But I'm waiting to hear back from the client for the verdict. I'll
post a followup.
Mike
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
Can anyone recommend a method for debugging this issue?
I'd start with --enable-debug and valgrind.
It seems to be this one particular server. I have not been able to
reproduce the issue here.What's the difference between this server and the others?
Do the others use different Apache version/build?
Other architecture maybe? LD version?Actually it looks like this does have to do with the LD version and
specifically the .hash vs .hash.gnu section in the binaries. I was
building x86_64 binaries on a machine that only used the newer
.hash.gnu section (contrary to the man page which claims sysv style is
the default). I suspect that the client is using an older system who's
loader only supports the traditional sysv style .hash section. It
seems the solution is to use -Wl,--hash-style=both so that the dso and
library it's linked with have both the .hash and .hash.gnu sections
(confirmed with objdump -h foo.so).
Confirmed that this is the fix.
Thanks,
Mike
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/