apache debuggen unter vserver etch kernel 2.6.9-023stab044.4

[floogy]

Hallo,

Ich komme hier überhaupt nicht weiter:
Der apache meldet seit dem update auf php5 (5.2.0) von php5.1 (apt-get.org) ständig folgendes bei Seitenaufrufen:

Code: Alles auswählen

[Wed Sep 19 09:41:43 2007] [notice] child pid 9772 exit signal Segmentation fault (11)
[Wed Sep 19 09:41:45 2007] [notice] child pid 9594 exit signal Segmentation fault (11)
[Wed Sep 19 09:41:47 2007] [notice] child pid 9593 exit signal Segmentation fault (11)
[Wed Sep 19 09:41:49 2007] [notice] child pid 9584 exit signal Segmentation fault (11)

Ich nehme an, dass er sofort wieder neue threads startet, weil die Webseiten trotzdem funktionieren.
Nun wollte ich apache debuggen, aber der gdb steigt aus:

Code: Alles auswählen

# gdb --args apache -X  -f /etc/apache/httpd.confGNU gdb 6.4.90-debian
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 "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/sbin/apache -X -f /etc/apache/httpd.conf
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Cannot find user-level thread for LWP 30275: generic error
(gdb) bt
#0  0xb7ff7010 in _dl_debug_state () from /lib/ld-linux.so.2
#1  0xbfffd860 in ?? ()
#2  0xb7fedc35 in ?? () from /lib/ld-linux.so.2
#3  0xb80011e0 in _rtld_global () from /lib/ld-linux.so.2
#4  0xb80016a4 in ?? ()
#5  0x00000000 in ?? ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Ich kann dazu nichts geeignetes finden, und wüsste gern, ob es den gdb 6.6 als backport für etch gibt.
Oder funktioniert gdb bei threaded Programmen nicht in einem vserver?
Hier ein Link, den ich gefunden habe:
http://groups.google.com/group/linux.de ... 709e6b10cc
Auch das argument -X für apache wird ja scheinbar völlig ignoriert, da apache ja einen neuen thread öffnen will, oder gdb einen thread erwartet.

http://svn.collab.net/repos/svn/tags/0. ... _setup.txt

ADDENDUM 2: Debugging Apache

'mod_dav_svn.so' contains the main Subversion server logic; it runs
as a module within mod_dav, which runs as a module within httpd.

If you need to debug the server, follow this recipe:

% gdb httpd
(gdb) run -X
^C
(gdb) break some_func_in_mod_dav_svn
(gdb) continue

The '-X' switch runs httpd in a single thread, and insures it won't
detach from the tty. As soon as it starts, it will sit and wait for
requests. Then hit control-C and set your breakpoint.

kfogel adds:

Hmmm, I had thought httpd 2.0 also had these options: -DONE_PROCESS
and -DNO_DETACH. How are they related to -X, and/or should they be
used in combination with -X? Anyone know?

http://techpubs.sgi.com/library/tpl/cgi ... -for-linux

3.3.2 gdb unable to debug threaded apps

When using gdb to debug applications, you may see the error messages
similar to the following:

Error while reading shared library symbols:
Cannot get thread info: generic error
Cannot find user-level thread for LWP 8273: no LWP to satisfy query

Siehe auch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323773

EDIT:
Musste gerade feststellen, dass die Segmentation fault (11) ausbleiben, wenn ich den apache stoppe, und von der Commandline als single thread mit der -X option starte (das muss ich noch weiter testen). Könnte es sein, dass php5.2 einen höheren Speicherbedarf hat, und mein vserver in die Knie geht?

Ok, Ich versuche es jetzt mal mit excepionHooks:
http://httpd.apache.org/docs/1.3/mod/co ... eptionhook
http://publib.boulder.ibm.com/httpserv/ ... ledus.html

Hmmm... was sagt mir das nun?

Code: Alles auswählen

[Wed Sep 19 15:04:30 2007] [notice] child pid 19680 exit signal Segmentation fault (11)
[Wed Sep 19 15:04:31 2007] pid 19679 mod_backtrace backtrace for signal 11
[Wed Sep 19 15:04:31 2007] pid 19679 mod_backtrace main() is at 8061680
/usr/lib/apache/1.3/mod_backtrace.so[0xb67eeb85]
/usr/sbin/apache[0x805deb6]
/lib/tls/libpthread.so.0[0xb7fb5668]
/lib/ld-linux.so.2[0xb7ff2b07]
/lib/ld-linux.so.2[0xb7ff62f9]
/lib/ld-linux.so.2[0xb7ff6090]
/lib/tls/librt.so.1[0xb6f6e6e7]
/lib/ld-linux.so.2[0xb7ff6ede]
/lib/tls/libc.so.6(exit+0xd0)[0xb7d554f0]
/usr/sbin/apache[0x805d51a]
/usr/sbin/apache[0x805f746]
/usr/sbin/apache[0x805fe46]
/usr/sbin/apache[0x8060bf8]
/usr/sbin/apache(main+0x759)[0x8061dd9]
/lib/tls/libc.so.6(__libc_start_main+0xc8)[0xb7d3eea8]
/usr/sbin/apache[0x804f6a1]
[Wed Sep 19 15:04:31 2007] pid 19679 mod_backtrace end of report
[Wed Sep 19 15:04:31 2007] pid 19679 mod_whatkilledus sig 11 crash
[Wed Sep 19 15:04:31 2007] pid 19679 mod_whatkilledus no active connection at crash
[Wed Sep 19 15:04:31 2007] pid 19679 mod_whatkilledus no request active at crash
[Wed Sep 19 15:04:31 2007] pid 19679 mod_whatkilledus end of report

[floogy]

Ich habe mit ps axu festgestellt, dass 5 apache prozesse laufen plus fcgi, was wohl Speicherprobleme mit sich brachte.
Ich habe die Prozesszahl nun begrenzt, und fcgi herausgeschmissen (dpkg-reconfigure apache).

Code: Alles auswählen

# grep -n SpareServers /etc/apache/httpd.conf
[...]
144:MinSpareServers 2
145:MaxSpareServers 4

Vielleicht lag es auch ausschließlich am fcgi modul? Jedenfalls kommen die Fehler nun nicht mehr.
Falls jemand etwas zu dem gdb bug weiß, oder ob es nur am vserver-kernel liegt, der kann ja mal kurz eine Notiz hier hinterlassen.
Ich werde auf Dauer nicht herumkommen den Server zu wechseln, wie es aussieht...

EDIT: die segfaults sind doch noch nicht weg

[floogy]

Kann niemand etwas damit anfangen? Wie schon erwähnt hat sich das Problem leider noch nicht gelöst, und logcheck spammt mich damit zu.

EDIT:
Merkwürdig:
Nach einem weiteren dpkg-reconfigure apache, und folgendem Eintrag in der httpd.conf

Code: Alles auswählen

LogLevel debug

#Enable Core Dumps
#http://issues.apache.org/bugzilla/show_bug.cgi?id=30909
#http://httpd.apache.org/dev/debugging.html#gcore
#http://library.pantek.com/Mailing%20Lists/httpd.apache.org/bugs/03/12/11117.html
#http://www.wikiservice.at/dse/wiki.cgi?MarkusRechberger/C/CoreDump
CoreDumpDirectory /tmp

#EnableExceptionHook controls whether or not an exception hook implemented by a module will be called after a child process crash. The exception hook allows modules to log diagnostic information that may help determine the cause of the crash.
#http://httpd.apache.org/docs/1.3/mod/core.html#enableexceptionhook
#http://www.linuxserverforum.de/vb/archive/index.php/t-781.html
#<IfModule mod_backtrace.c>
#EnableExceptionHook On
#</IfModule>

EnableExceptionHook On

und einer zusätzlichen Zeile in der /etc/apache/modules.conf

Code: Alles auswählen

LoadModule prctl_module /usr/lib/apache/1.3/mod_prctl.so

und

Code: Alles auswählen

ulimit -c unlimited

tut sich jetzt nichts mehr: Keine weiteren sgsegv 11 ???

Dazu hatte ich mod_prctl.c kompiliert (um CoreDumps zu bekomen):

Code: Alles auswählen

wget http://www.apache.org/~trawick/mod_prctl.c
apxs -c mod_prctl.c
cp -av mod_prctl.so /usr/lib/apache/1.3

Code: Alles auswählen

# tail -f /var/log/apache/error.log
[Tue Oct  2 12:33:47 2007] [info] removed PID file /var/run/apache.pid (pid=15930)
[Tue Oct  2 12:33:47 2007] [notice] caught SIGTERM, shutting down
[Tue Oct  2 12:36:21 2007] [info] mod_unique_id: using ip addr 127.0.0.1
[Tue Oct  2 12:36:23 2007] [info] mod_unique_id: using ip addr 127.0.0.1
[Tue Oct  2 12:36:24 2007] [info] created shared memory segment #557057
[Tue Oct  2 12:36:24 2007] [notice] Apache/1.3.34 (Debian) mod_mp3/0.39 mod_gzip/1.3.26.1a mod_filter/1.4 PHP/5.2.0-8+etch7 mod_auth_pam/1.1.1 mod_ssl/2.8.25 OpenSSL/0.9.8c mod_perl/1.29 configured -- resuming normal operations
[Tue Oct  2 12:36:24 2007] [info] Server built: Mar  4 2007 01:34:14
[Tue Oct  2 12:36:24 2007] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Tue Oct  2 12:36:39 2007] [info] mod_unique_id: using ip addr 127.0.0.1
[Tue Oct  2 12:36:40 2007] [crit] (98)Address already in use: make_sock: could not bind to port 80

crit] (98)Address already in use: make_sock: could not bind to port 80 macht mir noch Sorgen.
Ich hoffe, dass die Segmentation fault (11) nun ausbleiben, habe aber keinerlei Vorstellung, weshalb das so sein könnte.... Also, wenn da jemand eine Idee hat: Nur zu!

[floogy]

Es gibt nun einen Bugreport zum Thema:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449027