[Apache] Site wordt niet goed getoond (segmentation faults)*

[Verwijderd]

Op mijn eigen PC heb ik Apache en PHP draaien om op te developen. De site die ik op mijn eigen PC heb gemaakt werkt daar prima op, maar wanneer ik deze upload naar de server gebeuren er rare dingen.

Ik heb bijvoorbeeld de pagina 'productmanager.php' op de server staan. Wanneer ik deze aanroep met b.v. id-nummer 18 toont de pagina zich zoals het hoort, maar roep ik hem aan met if 17, dan gebeurt er helemaal niets! In de access.log van Apache is niet eens terug te vinden dat de pagina met dit id is aangeroepen.

Wanneer ik "Live HTTP headers" aanzet in Firefox (plugin), dan zie ik ook niet eens dat de browser een request doet naar de server. Wanneer ik de pagina's opvraag in IE, gaat het wel goed bij nummer 18, maar bij nummer 17 komt IE terug met een DNS error. Het id nummer is echt het enige dat ik verander!

Wanneer ik in Lynx de pagina oproep met id 17 komt Lynx terug met de melding: "Alert!: Unexpected network read error; connection aborted." en bij 18 gaat het goed.

Een andere pagina: 'configuration.php' toont zich altijd maar voor 1/3. Ergens halverwege een input veld houdt de HTML code gewoon op als ik 'View Source' doe, terwijl het bestand op de server wel gewoon de complete code bevat. Dan heb ik nog een pagina 'statistics.php' die zich nooit toont. Bij alle andere pagina's die er zijn, zijn er geen problemen.

Alle HTML code staat in aparte bestanden en wordt door de php bestanden ge-include. De server draait op Debian Sarge (stable) met Apache 1.3.33 en PHP 4.3.10-15. Alle bestanden zijn leesbaar voor Apache, dus aan de toegangrechten kan het niet liggen.

Verder heb ik de php.ini en httpd.conf van mijn Windows machine (waar alles dus feilloos werkt) vergeleken met die van de server, maar ik heb niets kunnen ontdekken dat hiermee te maken kan hebben. Iemand ideeën toevallig, want ik weet het echt niet meer.

[GlowMouse]

Staat er wat in de error-log?

[Verwijderd]

Ja, daar has ik dus eerder moeten kijken

code:

[Tue Aug 23 22:40:59 2005] [notice] child pid 22511 exit signal Segmentation fault (11)

Da's vrij ernstig dus en ik heb wederom geen idee hoe dit op te moeten lossen. Een nieuwe versie van Apache zou het misschien op kunnen lossen, maar er is geen nieuwe versie van Apache in de stable branch van Debian.

Andere ideeën misschien? Kan PHP een fout veroorzaken waardoor Apache onderuit gaat?

[ Voor 8% gewijzigd door Verwijderd op 23-08-2005 22:50 ]

[NMe]

Segmentation faults met code 11 duiden meestal op hardwarefouten (is me ooit door een wijs persoon verteld), maar ik heb dit zelf ook eens gehad in Debian, zonder dat er hardware bij betrokken was. In mijn geval zat ik op een virtual dedicated server, met versie 2.6.x van de kernel, in UML (User Mode Linux). Hierbij was er een file die voor segmentation faults kon leiden in een aantal programma's, waaronder Apache. Helaas weet ik niet meer uit mijn hoofd welke file dat was, maar ik kan het wel opzoeken. Ik laat het nog wel even weten zodra ik het vind.

Overigens is dit dus zeer waarschijnlijk een configuratieprobleem, en daarom zet ik dit topic even in Non-Windows Operating Systems neer.

PW>>NOS

[ Voor 4% gewijzigd door NMe op 23-08-2005 23:33 ]

[CyBeR]

-NMe- schreef op dinsdag 23 augustus 2005 @ 23:32:
Segmentation faults met code 11 duiden meestal op hardwarefouten (is me ooit door een wijs persoon verteld), maar ik heb dit zelf ook eens gehad in Debian, zonder dat er hardware bij betrokken was. In mijn geval zat ik op een virtual dedicated server, met versie 2.6.x van de kernel, in UML (User Mode Linux). Hierbij was er een file die voor segmentation faults kon leiden in een aantal programma's, waaronder Apache. Helaas weet ik niet meer uit mijn hoofd welke file dat was, maar ik kan het wel opzoeken. Ik laat het nog wel even weten zodra ik het vind.

Overigens is dit dus zeer waarschijnlijk een configuratieprobleem, en daarom zet ik dit topic even in Non-Windows Operating Systems neer.

PW>>NOS

Wel. D'r is niet zoiets als een segmentation fault met code 11. Het programma krijgt een SIGSEGV. Dat is een Segmentation Violation. Die krijgt 'ie door als nummer: 11. Een segfault is dus code 11

Verder betekent het dat het programma een stuk geheugen heeft getracht te accessen waar het geen toegang to had. De oorzaak daartoe kan inderdaad in de hardware zitten. Brak geheugen leidt vaak tot random segfaults en bus errors. Het kan ook gewoon brak geprogrammeerd zijn. Maar aangezien we het over apache hebben en apache zich inmiddels best stabiel bewezen heeft zullen we daar niet van uitgaan.

Dus: gooi je geheugen eens door een memory tester. Memtest86 werkt vrij aardig. Laat dat eens een nachtje draaien en zie of er errors tevoorschijn komen.

[Verwijderd]

Gezien het feit dat hij met 'nummer 18' wel altijd werkt, en met 'nummer 17' niet, lijkt het mij eerder dat er domweg een fout in de code van de bewuste pagina zit.

Verder betekent het dat het programma een stuk geheugen heeft getracht te accessen waar het geen toegang to had.

Dit kan bv. ook voorkomen als men een pointer gebruikt welke niet verwijst naar een object etc. Oftewel, de klassieke access violation.

Als de server verder wel stabiel draait, zou ik het NIET in de hardware zoeken, maar in de code van de bewuste pagina.

[Verwijderd]

De server draait inderdaad stabiel en er treden nergens anders fouten op (in andere sites op dezelfde server). Het zijn dus alleen de specifieke pagina's die ik in de OP beschreef. Ik zal eens gaan debuggen via Zend Studio Server, misschien dat dat iets oplevert. Ik laat het even weten als ik zover ben.

Andere suggesties zijn meer dan welkom natuurlijk!

[Verwijderd]

Je kunt 'ns proberen te kijken wat Apache probeert te doen vlak voordat 'ie segfault door het proces in foreground modus te volgen met strace:

code:

 # strace -f -F ./httpd -F

[Verwijderd]

Ik heb m gevonden!

Via de Zend Server debugger ben ik erachter gekomen dat het fout ging tijdens het aanroepen van number_format(), deze gaf ik 4 argumenten mee, waarvan de laatste twee het decimaalteken en het groeperingsteken zijn (respectievelijk , en .). Tenminste, dit had het moeten zijn.

Die komma en punt haalde ik uit de array die je krijgt wanneer je localeconv() aanroept. Helaas voor mij vulde localeconv() deze twee waarden niet en zo kwam de functie-aanroep er dus (b.v.) als volgt uit te zien: number_format(123, 2, , ,);

Lijkt me duidelijk dat dit niet helemaal de bedoeling is en dat PHP daardoor onderuit ging op mijn Debian server. Op mijn Windows machine ging het goed, maar of dat nu aan PHP lag, of aan het feit dat localeconv() hier wel de punt en de komma invulde weet ik niet.

Hopelijk heeft iemand hier nog iets aan in de toekomst!

[ Voor 0% gewijzigd door Verwijderd op 25-08-2005 19:05 . Reden: Ik zie net dat localeconv() wel de punt en komma invult :) ]

[Verwijderd]

Verwijderd schreef op donderdag 25 augustus 2005 @ 18:45:
Ik heb m gevonden!

Da's mooi

Ook mooi dat je het resultaat hier meldt, dat zouden meer mensen moeten doen.

Het leek mij ook sterk dat het een hardwareprobleem was.

[smokalot]

dit is een bug in php, aangezien een script taal nooit een segfault mag geven door onjuiste code (eigenlijk mag sowieso geen enkel programma een segfault geven )

wellicht ook daar reporten?

[Verwijderd]

smokalot schreef op donderdag 25 augustus 2005 @ 19:18:
dit is een bug in php, aangezien een script taal nooit een segfault mag geven door onjuiste code (eigenlijk mag sowieso geen enkel programma een segfault geven )

wellicht ook daar reporten?

Lukt me niet om de code samen te vatten en weer de segfault te krijgen, dus daar zie ik maar vanaf...