No, vajon mibe pusztul bele a httpd leálláskor?

Mivel csak leálláskor jelentkezik a probléma, eddig nem törődtem vele, de most rábeszéltem, hogy írjon core-fájlt hátha kiderül belőle valami.

ls -l /tmp/httpdcore/
-r--r--r-- 1 www-data www-data 120188928 Dec  3 15:45 core.1289
-r--r--r-- 1 www-data www-data 123203584 Dec  3 15:45 core.1290
-r--r--r-- 1 www-data www-data 123486208 Dec  3 15:45 core.1291
-r--r--r-- 1 www-data www-data 123453440 Dec  3 15:45 core.29093

Na jó, elárulom most rögtön, szerintem úgyis mindenki erre gondolt:

(gdb) bt
#0  0x00007f885379525c in php_oci_cleanup_global_handles () from /usr/local/libexec64/apache2/libphp.so
#1  0x00007f88537953ff in zm_globals_dtor_oci () from /usr/local/libexec64/apache2/libphp.so
#2  0x00007f8853ad90e0 in ts_free_id () from /usr/local/libexec64/apache2/libphp.so
#3  0x00007f8853bc4505 in module_destructor () from /usr/local/libexec64/apache2/libphp.so
#4  0x00007f8853bb4d32 in module_destructor_zval () from /usr/local/libexec64/apache2/libphp.so
#5  0x00007f8853bdbb33 in zend_hash_graceful_reverse_destroy () from /usr/local/libexec64/apache2/libphp.so
#6  0x00007f8853bc163c in zend_destroy_modules () from /usr/local/libexec64/apache2/libphp.so
#7  0x00007f8853bb5b20 in zend_shutdown () from /usr/local/libexec64/apache2/libphp.so
#8  0x00007f8853adf1f4 in php_module_shutdown () from /usr/local/libexec64/apache2/libphp.so
#9  0x00007f8853adf1b2 in php_module_shutdown_wrapper () from /usr/local/libexec64/apache2/libphp.so
#10 0x00007f8853d7e7c1 in php_apache_child_shutdown () from /usr/local/libexec64/apache2/libphp.so
#11 0x00007f88560c7eca in run_cleanups () from /usr/local/lib64/libapr-1.so.0

Naná, hogy a PHP-be halt bele, mi másba? Sőt, azon belül is az Oracle-ba, ami szintén híresen problémamentes.
Pótkérdés: Most rögtön áruljam el, hogy ez Linux, vagy várjak meg néhány Aix-fikázó/éltető hozzászólást? Á, elárulom most.

Hozzászólások

Szerkesztve: 2021. 12. 04., szo – 20:54
(gdb) bt
#0  0x00007f3b687e925c in php_oci_cleanup_global_handles ()
    at /usr/local/src/php-8.0.11/ext/oci8/oci8.c:248
#1  0x00007f3b687e93ff in zm_globals_dtor_oci (oci_globals=0x7f3b48090f80)
    at /usr/local/src/php-8.0.11/ext/oci8/oci8.c:276

(gdb) l oci8.c:248
243      *
244      * Free global handles (if they were initialized before)
245      */
246     static void php_oci_cleanup_global_handles(void)
247     {
248             if (OCI_G(err)) {
249                     PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(err), OCI_HTYPE_ERROR));
250                     OCI_G(err) = NULL;
251             }

Persze azért lehet egyszerűsíteni (248. sor):

 if ((((zend_oci_globals *) (*((void ***) tsrm_get_ls_cache()))[((oci_globals_id)-1)])->err)) {

Örömmel látom, hogy a pthread is benne van a történetben (TSRM.c):

static pthread_key_t tls_key;
# define tsrm_tls_set(what)             pthread_setspecific(tls_key, (void*)(what))
# define tsrm_tls_get()                 pthread_getspecific(tls_key)

Megalapozatlan intuicióm azt súgja, hogy vagy jóhiszeműen felülírta a kérdéses adatterületet, vagy már a pthread_key_delete után vagyunk. Folyt. köv.

Ha hasznaltok Linuxot is az AIX mellett, akkor miert probalsz az AIXbol is Linuxot faragni? Egyre kevesbe ertem..

(amugy egyikkel sincsen alapveto bajom, de felesleges atalakitani az egyiket a masikka)

A strange game. The only winning move is not to play. How about a nice game of chess?

Megszórtam debug-kiírásokkal a kérdéses php_oci_cleanup_global_handlesfüggvényt, ez lett a meglátása:


20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck oci_globals_id=22
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck p=0xc411b0
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck q=0xc411b0
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck r=0xddd540
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck z=0xd28230
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck z->err=(nil)
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck oci_globals_id=22
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck p=0xc411b0
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck q=0xc411b0
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck r=0xddd540
20211208.091200 pid=24547 thread=7fd088548740 oci8.c:MemCheck z=(nil)
[Wed Dec 08 10:12:00.498587 2021] [core:notice] [pid 771:tid 140533617166144] AH00051: child pid 24547 exit signal Segmentation fault (1
1), possible coredump in /tmp/httpdcore

Ez mintha kétszeri hívásra utalna. Másodszorra itten áll meg:

273	    DebugLine("oci8.c:MemCheck z->err=%p\n", z->err);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-325.el7_9.x86_64 libaio-0.3.109-13.el7.x86_64 libidn2-2.3.2-1.el7.x86_64 libunistring-0.9.3-9.el7.x86_64 libxml2-2.9.1-6.el7.5.x86_64 nss-softokn-freebl-3.53.1-6.el7_9.x86_64 pcre-8.32-17.el7.x86_64 sqlite-3.7.17-8.el7_7.1.x86_64 sssd-client-1.16.5-10.el7_9.10.x86_64
(gdb) print z
$1 = (zend_oci_globals *) 0x0
Szerkesztve: 2021. 12. 11., szo – 17:12

php_oci8_int.h:

543 #define OCI_G(v) TSRMG(oci_globals_id, zend_oci_globals *, v)

TSRM.h:


159 #define TSRM_UNSHUFFLE_RSRC_ID(rsrc_id)   ((rsrc_id)-1)
160
161 #define TSRMG(id, type, element)  (TSRMG_BULK(id, type)->element)
162 #define TSRMG_BULK(id, type)      ((type) (*((void ***) tsrm_get_ls_cache()))[TSRM_UNSHUFFLE_RSRC_ID(id)])

Egyelőre ez lesz a patch-elés:

for i in ext/oci8/php_oci8_int.h ext/oci8/oci8.c; do
    if test -f "$i.saved"; then cp -p "$i.saved" "$i"
    else                        cp -p "$i" "$i.saved"
    fi
done

sed '/#ifdef ZTS/{
N;N;N;N;i\
#ifdef ZTS\
# define OCI_GLOBALS TSRMG_BULK(oci_globals_id, zend_oci_globals *)\
#else\
# define OCI_GLOBALS (&oci_globals)\
#endif\
#define OCI_G(v) (OCI_GLOBALS->v)
d
}' <ext/oci8/php_oci8_int.h.saved >ext/oci8/php_oci8_int.h

sed 's/if (OCI_G(err)) {/if (OCI_GLOBALS \&\& OCI_G(err)) {/
     s/if (OCI_G(env)) {/if (OCI_GLOBALS \&\& OCI_G(env)) {/' \
ext/oci8/oci8.c.saved >ext/oci8/oci8.c