[PHP] segmentation fault (11) tijdens het uitvoeren van code

[sschalkwijk]

Hallo allemaal,

Ik ben bezig met het schrijven van mijn eigen framework in PHP. Gister heb ik mijn database class herschreven van Mysqli naar PDO en vervolgens alle classes die daar gebruik van maken aangepast.

Als ik alle classes onafhankelijk test is er geen enkel probleem. Echter wanneer ik meerdere classes in een keer aanroep krijg ik de volgende fout in Google Chrome:

Error code: ERR_EMPTY_RESPONSE

In Safari, Opera en Firefox krijg ik gewoon een lege pagina terug.

Ik werk op OSX 10.9 zonder MAMP maar met de standaard geconfigureerde apache. Daarbij gebruikte ik een zelf gecompileerde versie van PHP 5.5.6 en MariaDB 5.6. Na het terugdraaien van de PHP update naar 5.5.6 en het gebruik maken van OSX zijn eigen PHP (5.4.17). bestaat het probleem nog steeds. Omdat ik aan het ontwikkelen ben staat error reporting aan.

Vervolgens ben ik gaan kijken in mijn apache logs waar ik de volgende melding zag.

[notice] child pid XXXX exit signal Segmentation fault (11)

Daarna heb ik dezelfde code op mijn webserver gezet. Deze draait onder CentOs 6.4 met PHP 5.3.3 en Mysql 5.5. Hier liep ik tegen dezelfde problemen aan en in Apache heb ik wederom een Segmentation fault

[notice] child pid XXXX exit signal Segmentation fault (11)

Na het meerdere malen toevoegen van een die() in mijn code kan ik geen specifieke regel aanwijzen waar de code op stukloopt. Door het willekeurig uitzetten van ongeveer 50 regels code door er commentaar regels van te maken wordt ook de volledige code uitgevoerd. Deze regels kan ik echt overal in het script uitzetten.

Voor de zekerheid heb ik ook nog geprobeerd om te runnen vanuit de command line met het volgende resultaat op OSX:

$ php index.php
 Segmentation fault: 11

En op CentOs:

# php index.php
 Segmentation fault

Is er iemand die mij op weg kan helpen om dit probleem op te lossen?

[kwaakvaak_v2]

ik gok dat er ergens in je script door php een bepaald stukje geheugen word aangevraagd wat niet bestaat. In combinatie met mysqli heb ik dit soort geneuzel wel eens gehad met de mysql client op een 127.0.0.1:3306, omgezet naar een socket verbinding en het probleem was weg.

Kan in principe van alles in je script zijn, kan ook iets lulligs zijn als het benaderen van een variable die niet ge-initialiseerd was tot aan een samenloop van rare omstandigheden die er voor zorgen dat je de segfault krijgt.

(segfault: "A segmentation fault (often shortened to segfault), bus error, or access violation is generally an attempt to access memory that the CPU cannot physically address. ")

[Kalentum]

Je kan zien wat (mogelijk) deze segfault veroorzaakt met behulp van strace (Linux) of dtruss (Mac OSX)

BV:

code:

# Mac:
$ sudo dtruss php index.php
# Linux:
$ strace php index.php

[ Voor 7% gewijzigd door Kalentum op 16-12-2013 09:52 ]

[storeman]

Ik ken de melding, ik heb het gehad door de combinatie van APC en Zend Server. De opcode cache was toen volgens mij de boosdoener.

[sschalkwijk]

rutgerw schreef op maandag 16 december 2013 @ 09:51:
Je kan zien wat (mogelijk) deze segfault veroorzaakt met behulp van strace (Linux) of dtruss (Mac OSX)

BV:

code:

# Mac:
$ sudo dtruss php index.php
# Linux:
$ strace php index.php

strace op Linux leverde het volgende op (laatste regels)

socket(PF_FILE, SOCK_STREAM, 0)         = 4
fcntl(4, F_SETFL, O_RDONLY)             = 0
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(4, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"}, 110) = 0
fcntl(4, F_SETFL, O_RDWR)               = 0
setsockopt(4, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
setsockopt(4, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
setsockopt(4, SOL_IP, IP_TOS, [8], 4)   = -1 EOPNOTSUPP (Operation not supported)
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=4, events=POLLIN}], 1, 30000) = 1 ([{fd=4, revents=POLLIN}])
read(4, "4\0\0\0\n5.1.69\0007\352\1\0007}5.(xKK\0\377\367\10\2\0\0\0"..., 16384) = 56
stat("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644, st_size=18267, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY) = 5
read(5, "<?xml version='1.0' encoding=\"ut"..., 18267) = 18267
close(5)                                = 0
write(4, "Y\0\0\1\215\242\3\0\0\0\0@\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 93) = 93
read(4, "\7\0\0\2\0\0\0\2\0\0\0", 16384) = 11
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(4, "\17\0\0\0\3SET NAMES utf8", 19) = 19
read(4, "\7\0\0\1\0\0\0\2\0\0\0", 16384) = 11
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(4, "<\0\0\0\3SELECT username FROM users "..., 64) = 64
read(4, "\1\0\0\1\1C\0\0\2\3def\23wbc_sergeschalkwij"..., 16384) = 94
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(4, "=\0\0\0\3SELECT mail FROM users WHER"..., 65) = 65
read(4, "\1\0\0\1\1;\0\0\2\3def\23wbc_sergeschalkwij"..., 16384) = 86
brk(0x1b73000)                          = 0x1b73000
open("/dev/urandom", O_RDONLY)          = 5
read(5, "\3640\312{\345\356\214\37\0\213\207\254\222{IT\205\314\24\302/\31", 22) = 22
close(5)                                = 0
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(4, "\1\0\0\0\16", 5)              = 5
read(4, "\7\0\0\1\0\0\0\2\0\0\0", 16384) = 11
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(4, "H\0\0\0\3SELECT salt FROM users WHER"..., 76) = 76
read(4, "\1\0\0\1\1;\0\0\2\3def\23wbc_sergeschalkwij"..., 16384) = 86
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

Ik heb gekopieerd wat volgens mij de laatste database connectie is voor de Segmentation fault. Het lijkt me fout te gaan bij een SELECT statement.

Dat komt overheen met dit stukje code:

PHP:

// Generate a random & unique salt;
    do
    {   
        $this->salt = md5(mcrypt_create_iv(22, MCRYPT_DEV_URANDOM));
        $db = new Db();
        $db->select("users", array("salt"));
        $db->where("salt", $this->salt, "=");
        $result = $db->run();
                    
        if($result->rowCount() >= 1)
        {
            $badsalt = true;
        }
        else
        {
            $badsalt = false;
            break;
        }
    }
    while($badsalt === true);

De query die hier als output komt is als volgt (via var_dump):

private 'sql' => string 'SELECT salt FROM users WHERE salt = :salt;' (length=42)
private 'bind' =>
array (size=1)
':salt' => string 'ad53fb9c47eccf86d08e3cdd0a31e653' (length=32)

Edit:

kwaakvaak_v2 schreef op maandag 16 december 2013 @ 08:59:
ik gok dat er ergens in je script door php een bepaald stukje geheugen word aangevraagd wat niet bestaat. In combinatie met mysqli heb ik dit soort geneuzel wel eens gehad met de mysql client op een 127.0.0.1:3306, omgezet naar een socket verbinding en het probleem was weg.

Kan in principe van alles in je script zijn, kan ook iets lulligs zijn als het benaderen van een variable die niet ge-initialiseerd was tot aan een samenloop van rare omstandigheden die er voor zorgen dat je de segfault krijgt.

(segfault: "A segmentation fault (often shortened to segfault), bus error, or access violation is generally an attempt to access memory that the CPU cannot physically address. ")

Omzetten naar socket verbinding lost het probleem voor mij jammer genoeg niet op.

[ Voor 10% gewijzigd door sschalkwijk op 16-12-2013 10:36 . Reden: Extra reactie toegevoegd ]

[Kalentum]

Ik ken je DB-class niet dus nu moet je zelf debuggen. Die query ziet er niet bepaald spannend uit ofzo. Maar ik heb ook wel eens rare dingen gehad met een database query die niet goed ging met PDO maar wel met de 'native' functies (in mijn geval PostgreSQL).

- Zit de fout inderdaad in dit stukje code?
- Als je ipv je eigen class de PDO class gebruikt op die plek, werkt het dan wel?

[sschalkwijk]

rutgerw schreef op maandag 16 december 2013 @ 10:44:
Ik ken je DB-class niet dus nu moet je zelf debuggen. Die query ziet er niet bepaald spannend uit ofzo. Maar ik heb ook wel eens rare dingen gehad met een database query die niet goed ging met PDO maar wel met de 'native' functies (in mijn geval PostgreSQL).

- Zit de fout inderdaad in dit stukje code?
- Als je ipv je eigen class de PDO class gebruikt op die plek, werkt het dan wel?

Bedankt voor de tip het werkt inderdaad als ik de PDO class gebruik inplaats van mijn eigen class.

Na even wat verder debuggen zijn de opties die ik instel voor PDO de oorzaak:

PHP:

$options = array(
            parent::ATTR_PERSISTENT => true,
            parent::ATTR_ERRMODE => parent::ERRMODE_EXCEPTION
        );

Gebruik nu enkel nog de ATTR_ERRMODE.

Bedankt iedereen!