4. Merkwürdiges CGI Problem

Merkwürdiges CGI Problem

  • S

    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.

    0
  • ?

    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')
    🙂

    0
  • S

    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

    0
  • L

    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.

    0
  • S

    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

    0
  • R

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

    0
  • C

    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.

    0
  • S

    -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

    0
  • R

    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.

    0
  • S

    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...

    0
  • R

    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.

    0
  • ?

    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.
    🙂

    0
  • L

    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.

    0
  • S

    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

    0
Anmelden zum Antworten