Hallo,
ich hab da ein merkwürdiges Problem. Ich entwickle derzeit auf einem SuSE mit PHP 5.1.2.
Hier funktioniert mein Script tadellos und es gibt keine Probleme.
Nun hab ich einen Snapshot des derzeitigen Standes auf meinem Server (Debian mit Apache 2.2 und PHP 5.1.6) installiert und bekomme solche Fehlermeldungen (und nix funzt):
Integer overflow in memory_limit check detected
*** glibc detected *** corrupted double-linked list: 0x0862b348 ***
*** glibc detected *** corrupted double-linked list: 0x0852cf70 ***
*** glibc detected *** free(): invalid next size (fast): 0x08648730 ***
[Wed Nov 22 22:09:43 2006] [notice] child pid 17269 exit signal Aborted (6)
[Wed Nov 22 22:09:43 2006] [notice] child pid 17290 exit signal Aborted (6)
[Wed Nov 22 22:09:43 2006] [notice] child pid 17336 exit signal Aborted (6)
*** glibc detected *** double free or corruption (!prev): 0x0862bd40 ***
[Wed Nov 22 22:09:54 2006] [notice] child pid 17341 exit signal Aborted (6)
Ich hab aktuell nicht wirklich eine Idee, woran das liegen kann, sieht aber irgendwie nach einem PHP-Bug aus, oder?
Code kann man unter oh-trac.tobyf.de/browser/frontend/tags/snapshot-22.11.06 einsehen, auch wenns wohl nicht viel helfen wird. Ich habe auch noch nicht genau lokalisiert, wo der Fehler exakt auftritt. Ich spiele viel mit Serialisierung in Sessions und so, aber wie gesagt, auf dem Develsystem rennt das alles problemlos.
Vielleicht kann mir ja hier jemand Tipps geben? Danke schonmal!
PHP stirbt...
gepostet vor 17 Jahre, 7 Monate von Toby
gepostet vor 17 Jahre, 7 Monate von TheUndeadable
Garantiert ein (PHP?)-Problem.
Egal was du schreibst: Es darf nie passieren, dass dein Interpreter hart abschmiert.
Es stellt sich die Frage, ob PHP der schuldige ist, ob der Apache der schuldige ist oder ob du ein Threading-Problem hast.
PHP ist AFAIK unter bestimmten Umständen nicht threadsafe (zumindest unter Windows). Und da sind Serialisierungen besonders interessant.
Egal was du schreibst: Es darf nie passieren, dass dein Interpreter hart abschmiert.
Es stellt sich die Frage, ob PHP der schuldige ist, ob der Apache der schuldige ist oder ob du ein Threading-Problem hast.
PHP ist AFAIK unter bestimmten Umständen nicht threadsafe (zumindest unter Windows). Und da sind Serialisierungen besonders interessant.
gepostet vor 17 Jahre, 7 Monate von exception
Original von Toby
Hallo,
ich hab da ein merkwürdiges Problem. Ich entwickle derzeit auf einem SuSE mit PHP 5.1.2.
Hier funktioniert mein Script tadellos und es gibt keine Probleme.
Nun hab ich einen Snapshot des derzeitigen Standes auf meinem Server (Debian mit Apache 2.2 und PHP 5.1.6) installiert und bekomme solche Fehlermeldungen (und nix funzt):
Integer overflow in memory_limit check detected
*** glibc detected *** corrupted double-linked list: 0x0862b348 ***
*** glibc detected *** corrupted double-linked list: 0x0852cf70 ***
*** glibc detected *** free(): invalid next size (fast): 0x08648730 ***
[Wed Nov 22 22:09:43 2006] [notice] child pid 17269 exit signal Aborted (6)
[Wed Nov 22 22:09:43 2006] [notice] child pid 17290 exit signal Aborted (6)
[Wed Nov 22 22:09:43 2006] [notice] child pid 17336 exit signal Aborted (6)
*** glibc detected *** double free or corruption (!prev): 0x0862bd40 ***
[Wed Nov 22 22:09:54 2006] [notice] child pid 17341 exit signal Aborted (6)
Ich hab aktuell nicht wirklich eine Idee, woran das liegen kann, sieht aber irgendwie nach einem PHP-Bug aus, oder?
Code kann man unter oh-trac.tobyf.de/browser/frontend/tags/snapshot-22.11.06 einsehen, auch wenns wohl nicht viel helfen wird. Ich habe auch noch nicht genau lokalisiert, wo der Fehler exakt auftritt. Ich spiele viel mit Serialisierung in Sessions und so, aber wie gesagt, auf dem Develsystem rennt das alles problemlos.
Vielleicht kann mir ja hier jemand Tipps geben? Danke schonmal!
Keine wirklich schöne Lösung, aber versuch doch einfach mal php5.2. Vielleicht wurde der Fehler dort ja behoben.
Wenn der Fehler aber immer noch auftritt, versuche ein möglichst kurzes PHP-Script zu schreiben, mit dem der Fehler reproduziert werden kann. Dieses kannst du dann im PHP-Bugtracker melden
gepostet vor 17 Jahre, 7 Monate von Agmemon
gepostet vor 17 Jahre, 7 Monate von Toby
Danke Agmemon, den Bugreport hatte ich auch schon gefunden.
Problem ist, das ich ein 32Bit-System habe. Denke daher nicht, das das damit zusammenhängt.
Aber ich werde mal versuchen, ob ein Versionswechsel was bringt.
Wie kann ich auf Debian ein Downgrade machen? Ich würds gerne erstmal mit PHP 5.1.2 ausprobieren, bevor ich auf PHP 5.2 gehe.
Problem ist, das ich ein 32Bit-System habe. Denke daher nicht, das das damit zusammenhängt.
Aber ich werde mal versuchen, ob ein Versionswechsel was bringt.
Wie kann ich auf Debian ein Downgrade machen? Ich würds gerne erstmal mit PHP 5.1.2 ausprobieren, bevor ich auf PHP 5.2 gehe.
gepostet vor 17 Jahre, 7 Monate von mifritscher
Versuch erstmal folgendes:
Konfiguriere apache so, dass es nur 1-2 childs macht.
nehme gdb und attache an alle childs.
Führe dein Script auf.
Einer der Childs wird dann crashen, gebe im entsprechenden gdb-Fenster bt ein. Mit etwas Glück hast du die Stelle wo es kracht.
Ich tippe ja auf ein php-Modul...
Wenn du gdb nicht anschmeißen willst:
Sind allephp-Module auf den neuesten Stand und für deine aktuelle php-Version kompiliert? Schmeiß mal alles Unnötiges raus, fürs Testen auch eventuelle Bytecodecacher/Optimierer ala apc, ea und Co.
Gerade letztere crashen gerne mal...
Konfiguriere apache so, dass es nur 1-2 childs macht.
nehme gdb und attache an alle childs.
Führe dein Script auf.
Einer der Childs wird dann crashen, gebe im entsprechenden gdb-Fenster bt ein. Mit etwas Glück hast du die Stelle wo es kracht.
Ich tippe ja auf ein php-Modul...
Wenn du gdb nicht anschmeißen willst:
Sind allephp-Module auf den neuesten Stand und für deine aktuelle php-Version kompiliert? Schmeiß mal alles Unnötiges raus, fürs Testen auch eventuelle Bytecodecacher/Optimierer ala apc, ea und Co.
Gerade letztere crashen gerne mal...
gepostet vor 17 Jahre, 7 Monate von Toby
Danke für die Tipps, ich habs wohl mittlerweile herausgefunden (gibt zwar noch andere Probleme, aber es crasht nicht mehr).
Das Problem lag an dieser statischen Funktion:
public static function &ReadFile($filename,$path = '')
{
//if we are in DEBUG-Mode, we want to read everything out of the DB...
if (DEBUG)
return false;
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include (CACHEDIR . $path. $filename . '.cache.php');
return $$filename;
}
return false;
}
Mir war eingefallen, das ich auf dem Server meinen Debugmodus ausgeschaltet hatte, damits performanter wird und eben der Cache genutzt wird (der Cache besteht einfach aus php-files mit Arrays drin, ich cache statische Werte, die nur aus Bequemlichkeit in der DB gehalten werden).
Wie man sehen kann, wird im Debugmodus der Cache nicht genutzt.
Ich habe also den Debug wieder eingeschaltet und die Crashes waren weg. Da eine der Hauptunterscheidungen des Debugmodus eben die Nutzung des Caches ist, lag der Verdacht nahe, da mal rumzufummeln.
Mittlerweile habe ich den Code so umgeschrieben:
public static function &ReadFile($filename,$path = '')
{
//if we are in DEBUG-Mode, we want to read everything out of the DB...
if (DEBUG)
return false;
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include_once (CACHEDIR . $path. $filename . '.cache.php');
$helper = $$filename;
return $helper;
}
return false;
}
Debug ist wieder aus und keine Crashes... irgendwie blöd, oder?
Es muss aber irgendwo am Zusammenspiel mit dem übrigen Code stehen, denn die Klasse alleine funktioniert tadellos...
Ergo bin ich eigentlich so schlau wie vorher und kann den Fehler nicht einfach so reproduzieren. Ich schau mal, ob ich evt. doch rausfinden kann, woran es lag und mach dann bei PHP nen Bugbericht...
Zum Testen&Spielen.
define('CACHEDIR','.');
Cache::WriteFile('teststore',array('1','2','3'));
print_r(Cache::ReadFile('teststore'));
class Cache
{
/**
* read cache-file
* @access public
*
* @param string filename a filename, without file extension
*
* @return array/boolean
*/
public static function &ReadFile($filename,$path = '')
{
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include (CACHEDIR . $path. $filename . '.cache.php');
return $$filename;
}
return false;
}
/**
* write an array to a file
* @access public
*
* @param string filename a filename, without file extension
* @param array valuearray an array with data to store in the file
*
* @return boolean
*/
public static function WriteFile($filename,$valuearray,$path = '')
{
if (!is_array($valuearray))
return false;
if (!is_string($filename))
return false;
if (!is_string($path) || strpos($path, "..") !== false)
return false;
if ($path != '')
$path .= '/';
if (file_exists(CACHEDIR) && is_writable(CACHEDIR))
{
$config_string = " $config_string .= '$'.$filename . " = \n" . var_export($valuearray, true) . ";\n?>";
if (file_put_contents(CACHEDIR . $path . $filename.'.cache.php', $config_string, LOCK_EX))
return true;
}
return false;
}
}
?>
Das Problem lag an dieser statischen Funktion:
public static function &ReadFile($filename,$path = '')
{
//if we are in DEBUG-Mode, we want to read everything out of the DB...
if (DEBUG)
return false;
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include (CACHEDIR . $path. $filename . '.cache.php');
return $$filename;
}
return false;
}
Mir war eingefallen, das ich auf dem Server meinen Debugmodus ausgeschaltet hatte, damits performanter wird und eben der Cache genutzt wird (der Cache besteht einfach aus php-files mit Arrays drin, ich cache statische Werte, die nur aus Bequemlichkeit in der DB gehalten werden).
Wie man sehen kann, wird im Debugmodus der Cache nicht genutzt.
Ich habe also den Debug wieder eingeschaltet und die Crashes waren weg. Da eine der Hauptunterscheidungen des Debugmodus eben die Nutzung des Caches ist, lag der Verdacht nahe, da mal rumzufummeln.
Mittlerweile habe ich den Code so umgeschrieben:
public static function &ReadFile($filename,$path = '')
{
//if we are in DEBUG-Mode, we want to read everything out of the DB...
if (DEBUG)
return false;
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include_once (CACHEDIR . $path. $filename . '.cache.php');
$helper = $$filename;
return $helper;
}
return false;
}
Debug ist wieder aus und keine Crashes... irgendwie blöd, oder?
Es muss aber irgendwo am Zusammenspiel mit dem übrigen Code stehen, denn die Klasse alleine funktioniert tadellos...
Ergo bin ich eigentlich so schlau wie vorher und kann den Fehler nicht einfach so reproduzieren. Ich schau mal, ob ich evt. doch rausfinden kann, woran es lag und mach dann bei PHP nen Bugbericht...
Zum Testen&Spielen.
define('CACHEDIR','.');
Cache::WriteFile('teststore',array('1','2','3'));
print_r(Cache::ReadFile('teststore'));
class Cache
{
/**
* read cache-file
* @access public
*
* @param string filename a filename, without file extension
*
* @return array/boolean
*/
public static function &ReadFile($filename,$path = '')
{
if ($path != '')
$path .= '/';
if (is_readable(CACHEDIR . $path. $filename.'.cache.php'))
{
include (CACHEDIR . $path. $filename . '.cache.php');
return $$filename;
}
return false;
}
/**
* write an array to a file
* @access public
*
* @param string filename a filename, without file extension
* @param array valuearray an array with data to store in the file
*
* @return boolean
*/
public static function WriteFile($filename,$valuearray,$path = '')
{
if (!is_array($valuearray))
return false;
if (!is_string($filename))
return false;
if (!is_string($path) || strpos($path, "..") !== false)
return false;
if ($path != '')
$path .= '/';
if (file_exists(CACHEDIR) && is_writable(CACHEDIR))
{
$config_string = " $config_string .= '$'.$filename . " = \n" . var_export($valuearray, true) . ";\n?>";
if (file_put_contents(CACHEDIR . $path . $filename.'.cache.php', $config_string, LOCK_EX))
return true;
}
return false;
}
}
?>
gepostet vor 17 Jahre, 7 Monate von Toby
Weitere Tests sagen mir, das es evt. eher am Include liegt... Ein Include_Once scheint den zu verhindern, das der Fehler auftritt? Aber wieso, wenn die Funktion beendet wird, wird der Include doch eh aufgehoben, oder? Von daher sollte ich doch in Funktionen includen was ich will und wie oft ich es will?!
Edit: Zu früh gefreut, es treten noch immer sporadisch Crashes auf... *hmpf*
Edit: Zu früh gefreut, es treten noch immer sporadisch Crashes auf... *hmpf*
gepostet vor 17 Jahre, 7 Monate von exception
Original von Toby
Ergo bin ich eigentlich so schlau wie vorher und kann den Fehler nicht einfach so reproduzieren. Ich schau mal, ob ich evt. doch rausfinden kann, woran es lag und mach dann bei PHP nen Bugbericht...
Teste es zunächst aber mit der aktuellen PHP 5.2-Version. PHP 5.1 wird nicht mehr unterstützt.
gepostet vor 17 Jahre, 7 Monate von Nuky
Hab mal gelesen dass das beenden von Funktionen nicht alle Inhalte wieder free't - kann jetzt aber auch grad c und php mischen, da ich grad beides gleichzeitig mache..
Kann dir eig. hauptsächlich alles gute wünschen..
Kann dir eig. hauptsächlich alles gute wünschen..
gepostet vor 17 Jahre, 7 Monate von Toby
Ich habs jetzt soweit gefixt, das das wieder rennt.
Die Crashes nach meinem obigen Fix kann ich nicht nachvollziehen, noch wiederholen, evt. hab ich mich da aber auch verschaut.
Das andere Problem war ein fehlender View in der DB, der irgendwie nicht richtig abgefangen wurde und in den Logs nicht auftauchte.
Egal, die Demo rennt wieder und ich bin glücklich.
Ich werd aber evt. doch mal schauen, ob der Orginalcode unter PHP 5.2 nicht crasht... mal gucken.
Danke an alle Helfer hier!
Die Crashes nach meinem obigen Fix kann ich nicht nachvollziehen, noch wiederholen, evt. hab ich mich da aber auch verschaut.
Das andere Problem war ein fehlender View in der DB, der irgendwie nicht richtig abgefangen wurde und in den Logs nicht auftauchte.
Egal, die Demo rennt wieder und ich bin glücklich.
Ich werd aber evt. doch mal schauen, ob der Orginalcode unter PHP 5.2 nicht crasht... mal gucken.
Danke an alle Helfer hier!