Sziasztok,
belefutottunk egy olyan problémába, hogy az apache2-nek (2.4.10-10+deb8u4) php7-tel (7.0.5-1~dotdeb+8.1) legalább naponta egyszer, de egyébként semmi különöshöz nem köthető időközönként meghalnak processei, ezután egy adott virtualhost csak no response hibaüzenetet ad a böngészőnek, más virtualhostok pedig elérhetőek továbbra is:
AH00051: child pid 25847 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump
AH00051: child pid 25939 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump
Ami még szintén érdekes, hogy három szerverből (dev/test/prod), csak a production-on jelentkezik a probléma, és mindhármon azonos a software környezet, a test és a prod pedig hw-ben és mindenben teljesen megegyezik.
Backtrace:
#0 zend_parse_arg_string (check_null=, dest_len=, dest=, arg=) at /usr/src/builddir/Zend/zend_API.h:1132
Debian 8.4, apache 2.4.10-10+deb8u4 (mpm_prefork), php 7.0.5-1~dotdeb+8.1, libapache2-mod-php7.
Van valami ötletetek? Köszönöm!
- 2809 megtekintés
Hozzászólások
Az access és error logban nincsenek "érdekes" bejegyzések? A prod környezet jellemzője, hogy publikus (mármint teljesen publikus, gugli által indexelt stb.) és ezért minden szar megtalálja, tehát jó eséllyel valamilyen külső hatástól dől el.
- A hozzászóláshoz be kell jelentkezni
Ma átnézem én is, a fejlesztők próbálták összepárosítani a log bejegyzéseket, de azt mondták nem köthető össze semmivel.
Arra nincs tipped hogy gdb-vel hogyan lehetne jobban szűkíteni hogy legalább megkapjuk mihez köthető a probléma?
- A hozzászóláshoz be kell jelentkezni
Elsőre nézd át a logot. A gdb-re nincs bővebb tippem, abból a trükkös lekérést nehéz lesz kihámozni.
- A hozzászóláshoz be kell jelentkezni
Nekem annyi, hogy valahogy egy unserialize olyan paramétert kap amitől befordul. :P
PHP_FUNCTION(unserialize)
{
....
if (zend_parse_parameters(ZEND_NUM_ARGS(), "s|a", &buf, &buf_len, &options) == FAILURE) {
- A hozzászóláshoz be kell jelentkezni
php5 esetén a buf_len típusa int, php7 esetén size_t. A gond az, hogy little endian CPU esetén hibás típusú paraméterrel is működhet (latszólag) helyesen.
- A hozzászóláshoz be kell jelentkezni
A log-ban az egyik ilyen eseményhez találtam egy GET-et, de ha meghívom az URL-t hibamentesen lefut.
Viszont azóta tovább debugoltam, és az egyik backtrace-nél találtam egy ilyet:
#5 0x00007fb82fd5b2be in zif_unserialize (execute_data=, return_value=0x7fb82ca136d0) at /usr/src/builddir/ext/standard/var.c:1011
buf = 0x18 error: Cannot access memory at address 0x18
buf_len = 140428999473152
p = 0x7fb82ca135c0 "\200r\305!\270\177"
var_hash = 0x7fb8306eb16e
options = 0x0
classes = 0x0
class_hash = 0x0
#46 0x00007fb82feb17ea in php_handler (r=) at /usr/src/builddir/sapi/apache2handler/sapi_apache2.c:678
zfd = {handle = {fd = 749064192, fp = 0x7fb82ca5d000, stream = {handle = 0x7fb82ca5d000, isatty = 0, mmap = {len = 481, pos = 0, map = 0x0,
buf = 0x7fb82cc3c000 error: Cannot access memory at address 0x7fb82cc3c000, old_handle = 0x0, old_closer = 0x0},
reader = 0x7fb82fdd3d60 <_php_stream_read>, fsizer = 0x7fb82fdbabc0
, closer = 0x7fb82fdbaba0
}},
filename = 0x7fb82cc55f00 "/var/www/vhost/index.php", opened_path = 0x0, type = ZEND_HANDLE_MAPPED, free_filename = 0 '\000'}
__orig_bailout = 0x0
__bailout = {{__jmpbuf = {140429001838704, -2125854719023403101, 140429001838704, 140737294386292, 140429001884304, 1, 2125868924265803683,
2093942599942385571}, __mask_was_saved = 0, __saved_mask = {__val = {0, 18446744073709551615, 5560396222692464128, 240, 140429001822248,
140737294385760, 140429001822248, 140429001842432, 140737294385924, 140429001836232, 0, 140429125077424, 5560396222692464128, 140429001836392,
140429001843632, 140429001838704}}}}
ctx = 0x7fb82cc565f0
conf =
brigade = 0x7fb82cc57290
bucket =
rv =
parent_req = 0x0
- A hozzászóláshoz be kell jelentkezni
Most nézem hogy a bejegyzésből kiszedte a Drupal az error: Cannot access memory at address 0x7fb82cc3c000 részeket.
buf = 0x18 error: Cannot access memory at address 0x18
buf = 0x7fb82cc3c000 error: Cannot access memory at address 0x7fb82cc3c000, old_handle = 0x0, old_closer = 0x0},
Szerkesztettem az előző hozzászólást is
- A hozzászóláshoz be kell jelentkezni
Nincs grsec vagy más ilyen szigorított eljárásos történet a kernelbe patkolva?
- A hozzászóláshoz be kell jelentkezni
Nincs grsec, és semmi más sem.
- A hozzászóláshoz be kell jelentkezni
SELinux, AppArmor és ilyesmik? dmesg-ben nem látszik semmi csak a sig11?
- A hozzászóláshoz be kell jelentkezni
Ez így még kevés lesz, mert nem tudni a php valóban merre járt (és ez alapján lehet környezeti bug, pl.: valami beleszemetelt a stackbe, vagy php bug is, vagy még legalább 20 indokot tudok)
Ezt még nézd át: https://bugs.php.net/bugs-generating-backtrace.php
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Valami tutira beleszemetelt, vagy az unserialize jó hosszú stringet kapott. :)
buf_len = 140428999473152
- A hozzászóláshoz be kell jelentkezni
Igen igen, ritkán szokott szükség lenni egy 127TB méretű bufferre:D De ettől még nem biztos hogy valami beleszemetelt, bőven lehet még egy integer underflow. Ezért lenne tudni hogy merre járt a php és mit csinált :)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
offtopic+
"Cannot access memory at address 0x18" Mindegy, hogy 127TB, ha már a 24. bájtot sem tudja olvasni.
offtopic-
- A hozzászóláshoz be kell jelentkezni
A kettő azért szorosan összefügghet, ráadásként a 24. bájtot ne is akarja olvasni mert nem egészséges;)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Ha logolod az adatbázis műveleteket, mi az utolsó, ami után ez történik?
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
Esetleg multithread-dal megy az Apache? Talán a multiprocess stabilabb lenne.
A 0x18 mint cím arra utalhat, hogy valaki elnézett egy NULL-pointert
struct foo *p= malloc (sizeof *p);
/* no check for p==NULL here */
dosomething (&p->member);
- A hozzászóláshoz be kell jelentkezni
Köszönöm szépen mindenkinek az ötletelést, segítséget. Nagyon úgy néz ki hogy az APCu kikapcsolása után megszűnt a processek meghalása. Azt sajnos nem tudom hogy mi az oka hogy három szerverből kettőn nem jelentkezett a hiba.
- A hozzászóláshoz be kell jelentkezni