Wie debuggt man einen Semop-Fehler?

Question

Unter 2.6.30-gentoo-r4Linux wird ein sehr komplexes Codesystem phpausgeführt (mit 4.4.9-pl0-gentoo und 5.2.10-pl0-gentoo), das gelegentlich auf ein Semaphorblockierungsproblem stößt. Der Aufruf der phpFunktion sem_acquirewird blockiert, was letztendlich zum Systemabsturz führt.

Allerdings scheint dieser Semaphor nicht von einem anderen phpProzess blockiert zu sein, was mich zu weiteren Untersuchungen veranlasste. Ich konnte den phpfraglichen Prozess identifizieren und straceihn identifizieren, der zum blockierenden Semaphor führte:

....
09:03:25 gettimeofday({1415696605, 778078}, NULL) = 0
09:03:25 close(5)                       = 0
09:03:25 gettimeofday({1415696605, 778483}, NULL) = 0
09:03:25 gettimeofday({1415696605, 778708}, NULL) = 0
09:03:25 semop(0, 0xbf8f1692, 1 <unfinished ...>

Diese spezielle Ausgabe semop(0, 0xbf8f1692, 1)hilft mir nicht viel, da ich den Inhalt von struct sembuf(zweites Argument für semop) nicht sehen kann. Vielleicht sieht jemand anders direkt bei diesem semopAufruf ein Problem?

Wie dem auch sei, ich habe die Untersuchung fortgesetzt, um den Speicher an folgender Adresse 0xbf8f1692(als Root) zu überprüfen:

> gdb --pid 1236   
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu".
Attaching to process 1236
ptrace: Operation not permitted.
(gdb) dump memory /root/output 0xbf8f1692 0xbf9f1692 
(gdb) quit
> hexdump -C output 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

Bedeutet das, dass der semopAufruf mit einem struct sembufVerweis auf eine Reihe von Nullen erfolgt? Oder habe ich etwas falsch gemacht, um den Speicher zu ermitteln und zu sehen, was die Argumente semopsind? Gibt es verschiedene Möglichkeiten, um zu sehen, was bei diesem Aufruf passiert semop?

Weitere Informationen:

• Das Linux-System kennt weder den Befehl prctlnoch ptrace.
• Ein Verzeichnis mit dem Namen /proc/sys/kernel/yamaexistiert nicht (sieheEmpfohlene Informationen).