¿Cómo depurar una falla de semop?

Question

Usando Linux se ejecuta 2.6.30-gentoo-r4un sistema de código muy complejo (con 4.4.9-pl0-gentoo y 5.2.10-pl0-gentoo), que ocasionalmente se topa con un problema de bloqueo de semáforo. phpLa llamada a la phpfunción sem_acquirese bloquea, lo que finalmente provoca que el sistema falle.

Sin embargo, este semáforo en cuestión no parece estar bloqueado por otro phpproceso, lo que me llevó a investigar más a fondo. Pude identificar el phpproceso en cuestión y llegar al stracemismo, lo que lleva al semáforo de bloqueo:

....
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 ...>

Este resultado en particular semop(0, 0xbf8f1692, 1)no me es de mucha ayuda, ya que no puedo ver el contenido de struct sembuf(segundo argumento de semop). ¿Quizás alguien más ve un problema directamente con esta semopllamada?

De todos modos, continué la investigación para verificar la memoria en la dirección 0xbf8f1692(como root):

> 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

¿Significa esto que semopse llama apuntando struct sembufa un montón de ceros? ¿O hice algo mal para averiguar la memoria y ver cuáles semopson los argumentos? ¿Hay diferentes formas de ver lo que sucede en esa semopllamada?

Información adicional:

• El sistema Linux no conoce el comando prctlni ptrace.
• Un directorio llamado /proc/sys/kernel/yamano existe (verinformación sugerida).