Merkwürdiges CGI Problem



  • Hallo werte Community,

    ich habe ein merkwürdiges Problem mit einem unserer CGI Webservices, bin am Ende meiner Ideen angelangt und brauche dringend eure Hilfe.

    Es ist in C geschrieben und lief eigentlich wunderbar. Bei uns in der Firmenumgebung läuft es nach wie vor, jedoch beim Kunden gibt es einen Fehler 500: Premature End Of Script headers.

    Nun habe ich schon zwei Tage mit der Problemlösung verbracht und viel danach gegoogled und alls mögliche probiert, jedoch treibt mich der Fehler in den Wahnsinn.

    Zunächst konnte ich den Fehler bei uns nicht einmal reproduzieren. Irgenwann habe ich dann mit provuzierten Fehlerausgaben (perror) und filedescriptoren (STDERR_FILENO) herumgespielt (geschlossen, umgeleitet, etc.), worauf hin ich auch irgenwann diesen 500er vom Server quittiert bekam.

    Toll dachte ich, da hab ich die Lösung. Doch nach rekonstruktion des alten Quellcode und neuem kompilieren lief auch diese Binary (und auch andere definitv früher lauffähige Kompilate) nichtmehr; mit dem selben Fehler.

    Dann habe ich weiter mit den Filedescriptoren herumgespiet und irgendwann, lief der Service dann bei uns wieder. Die Binarys hab ich zum Kunden geschickt, aber sie laufen dort auch nicht. Sogar der Code in der ursprünglichen Form (der anfangs lief, dann irgendwann nichtmehr) läuft jetzt wieder.

    Ich kann mir nicht erklären, was da die Ursache ist... Frust.

    Wie kann es sein, dass ein und der selbe Code mal läuft und mal nicht? Und warum läuft er hier vor Ort, aber beim Kunden nicht (selbe Zielplattform: Solaris 10)?

    Server und Dienste habe ich mehrfach restartet (der Kunde auch).

    Der Fehler deutet ja darauf hin, dass vor der Ausgabe der HTTP Header, irgendwas anderes ausgegeben wird. Aber was???

    Ich habe den Service testweise mal auf ein Minimum reduziert:

    int main (int argc, char **argv)
    {
    	printf("Content-Type: text/html\n\n");
    	printf("test");
    	return 0;
    }
    

    Auch dieses Codeschnippselchen lief dann nichtmehr. Nach Spielerei mit den Filedescriptoren, bekam ich es aber wieder zum laufen.

    Kann es irgendwas mit Ausgaben zu tun haben, die in irgend einem Puffer hängengeblieben sind? Aber welche Puffer ist nach einem Reboot des Servers noch immer gefüllt?!

    Habt ihr eine Idee? Eine Info, wie man sowas debuggen kann, wäre auch schon hilfreich.

    Noch ein paar Infos zur Platform:

    Solaris 10
    Apache 2.0.59
    Compiler gcc 3.4.6

    Für eure Antworten bedanke ich mich jetzt schon

    viele Grüsse
    Michael



  • Wenn du das Programm normal ausführst klappt es aber? Dateirechte stimmen auch? Wird das Programm überhaupt gestartet oder quittiert der Apache sofort mit einem 500?



  • Hallo,

    ./meincgi.cgi

    Ausgabe: Ungültige Anweisung (core dumped)

    (Da ich gdb momentan nicht zum laufen bekomme, kann ich den dump nicht auswerten, daran arbeite ich aber momentan)

    Wenn ich es im Browser parameterlos aufrufe, bekomme ich direkt die 500. Ich denke es wird auch garnicht gestartet, weil ich zu debug Zwecken direkt am Anfang eine logausgabe mache, die nicht erscheint.



  • soUrcerer schrieb:

    printf("Content-Type: text/html\n\n");
    

    versuch mal so: "Content-Type: text/html\r\n\r\n"
    und dann: schalte die pufferung ab (geht glaub ich mit 'setvbuf')
    🙂



  • also, das mit "\r\n\r\n" ist nur ne formsache... denke nicht das es daran liegt, weil der code ja so schon funktioniert hat. Ausserdem läuft es auf einem Unix Server, bei dem "\n\n" reichen sollte.

    Die Sache mit dem Buffer (setvbuf) ist interessant, das werd ich mal probieren.

    Danke



  • soUrcerer schrieb:

    ./meincgi.cgi

    Ausgabe: Ungültige Anweisung (core dumped)

    Das sagt doch so ziemlich alles, oder?
    Wenn das Programm standalone vor der Ausgabe der Header abstürzt, wird es sich im Webserver nicht anders verhalten. Damit ist die Ursache des HTTP 500 doch eindeutig isoliert. Damit brauchen wir jetzt nicht im Nebel rumstochern, indem wir an der Pufferung schrauben oder die Zeilenenden verdrehen, es ist nun einzig und allein die Ursache des Coredumps zu finden.



  • Unser Apache dumped leider nicht,

    wie kann ich dem das denn beibringen?!
    [edit]
    ein testweise ins httpd.conf eingefügtes
    CoreDumpDirectory /tmp (auch /tmp/ versucht)
    funzt leider nicht
    [/edit]

    Leider habe ich dem kunden keine debug version (gcc -g) geschickt und der bt vom kunden-core sagt nur:

    #0 0x000653e8 in ?? ()

    Auch ärgerlich ... alle meine Kompilate laufen (bei uns) wieder, daher kann ich keinen coredump einer debug version machen und so bekomme ich auch nur bt´s ala

    #0 0x000XXXXX in ?? ()

    ...

    aber ich hab dem kunden eine debug version geschickt und warte nun auf die dumps.

    Ich bin auch nicht sehr erfahren mit gdb ... welche infos kann ich aus so einem dump denn noch herausbekommen (und wie), wenn kein debug kompilat verwendet wurde?

    Gruss
    Michael



  • Das scheint ein fundamentaleres Problem zu sein. Hast du vielleicht einen kaputten Compiler installiert? Probier es vielleicht mal mit einer anderen Version.



  • Dieser Thread wurde von Moderator/in rüdiger aus dem Forum ANSI C in das Forum Linux/Unix verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • -bash-3.00# gcc -v
    Reading specs from /usr/local/lib/../lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
    Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
    Thread model: posix
    gcc version 3.4.6

    Uff, na das will ich mal nicht hoffen, dass der Compiler schrott ist ...

    ich hab die binarys von sunfreeware.com eingespielt. Unter solaris ist das immer so eine sache mit dem installieren 🙂

    aber in letzter Konsequenz werde ich auc das probieren.

    Leider bekomme ich erst montag wieder Feedback vom Kunden. Bis dahin kann ich nur spekulieren.

    Danke, und gruss

    Michael



  • Ansonsten kann es natürlich auch daran liegen, dass der Kunde ein (etwas) anderes System hat oder bei dem etwas kaputt ist.

    Im Zweifelsfall schick ihm mal eine statisch kompilierte Version (-static beim kompilieren angeben). Damit kann man schon viele Fehler ausschließen.



  • Hallo rüdiger,

    die Kompilate sind statisch gelinkt. Bei dem Kunden sind unsere binaries auch schon gelaufen. Seit dem letzten Release gibt es jedoch diesen Fehler und nun laufen dort auch die binaries, die vorher gelaufen sind, nicht mehr.

    Das ist ja das kuriose.

    Ein Defekt ... hm ... ist natürlich nicht aus zu schliessen, aber doch sehr unwarscheinlich. Solaris Systeme (auf SPARC) gelten als sehr robust und es laufen noch viele andere Dienste darauf, die Problemlos arbeiten. Aber ich kann den Admin bitten, dies zu prüfen; Ein Strohhalm ist es allemal.

    Ich hoffe stark auf die Geschichte mit dem setvbuf. Das Feedback bekomm ich aber erst am Montag. Ansonsten bekomm ich einen coredump von einer Debug version, was auch Aufschluss geben könnte.

    Was ich auch noch machen werde, ist die Apache Version vom Kunden und unsere gleich zu ziehen. Mit möglichst hoher Versionsnummer. Vielleicht is es ein Bug im Apache...



  • Ein Bug im Apache wird es nicht sein. Sonst könntest du das Programm ja auf der Konsole ohne Probleme ausführen. Irgend was muss das Binary oder die Laufzeitumgebung kaputt gemacht haben.



  • LordJaxom schrieb:

    Damit brauchen wir jetzt nicht im Nebel rumstochern, indem wir an der Pufferung schrauben...

    die ursprüngliche fehlerbeschreibung deutet darauf hin, dass reste im buffer den http-header zersemmeln.
    🙂



  • Stimmt, aber zu dem Zeitpunkt wurde bereits gezeigt, dass auf der Konsole auch ein Absturz passiert. Reste im Buffer wären allerdings wirklich ein Apache-Problem (was garantiert schon jemandem aufgefallen wäre 🤡, da ja CGIs für jeden Request neu gestartet werden.



  • ES LÄUFT!!

    Hallo liebe Gemeinde,
    endlich ist es vollbracht, es läuft wieder!

    Zunächst sah es so aus, als ob ein simpler Konfigurationsfehler vorlag, denn die neueste Version brach auch mit dem 500er ab. Ich hätte den Admin am liebsten in Stücke gerissen, konnte mich aber gerade noch beherrschen.

    Aber nach reflektieren des heutigen Testlaufs, glaube ich, dass nicht der Konfigurationsfehler, sondern doch das Abschalten der Puffer mittels setvbuf den Erfolg gebracht hat, denn:

    Beim heutigen Testen ist eine konkrete Fehlermeldung in das (eigens umgeleitete) Errorlog gelaufen, die auf einen String Zuweisungsfehler (durch fehlerhafte Konfiguration) hingewiesen hat, den ich sofort finden und beheben konnte.

    Mir ist jedoch bekannt, dass der Admin die Errorlogs des Apache immer überwacht hat; und normalerweise laufen Fehlermeldungen, die das CGI ausspuckt, in dieses Errorlog rein. Dort waren aber vorher kein zu finden. Jetzt jedoch gab es eine Fehlermeldung ... Ein Zeichen dafür, dass das CGI jetzt korrekt gestartet wurde.

    Ich werde der Sache nochmal genauer auf den Grund gehen, aber mein Gefühl sagt mir, dass es das Abschalten der Puffer war, was den Erfolg gebracht hat. Der Konfigfehler wäre anhand der Fehlermeldung sehr schnell auffindbar gewesen. Aber ohne Fehlermeldung .........

    Nun ja, sobald ich mehr weiss, werde ich euch hier nochmal informieren.

    Bis dahin bedanke ich mich nochmal ganz herzlich für eure Hilfe!!! Schön dass man nicht allein da steht.

    Viele Grüsse
    Michael


Anmelden zum Antworten