Fun-Soft - Programmierforum

Autor

Thread - Seiten: > 1 <

000
22.01.2008, 00:37 Uhr
banshee

hallo,

ich bekomme in folgendem Code einen Debug Assertion Error in Visual C++:

C++:

int s;
FILE *file;

// permit incoming connections on socket
s = (int)accept(sock, NULL, NULL);

if(s == SOCKET_ERROR)
{
    fprintf(logfile, "socket doesn't accept incoming connections!\n");
    return 1;
}

file = fdopen(s, "r+");    // hier tritt die Assertion auf
process(file);
fclose(file);

Als assertion wird folgende Zeile angegeben:

(filedes >= 0) && (unsigned)filedes < (unsigned)_nhandle)

Da mir das allerdings rein gar nichts sagt, habe ich keine Ahnung, wie ich den Fehler beheben kann. Wenn ich das ganze mit gcc auf Konsole kompiliere, klappt es.
Gibt es vielleicht irgendeine Möglichkeit, diese Debug Assertions auszuschalten?

Dieser Post wurde am 22.01.2008 um 00:38 Uhr von banshee editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

001
22.01.2008, 08:28 Uhr
0xdeadbeef
Gott
(Operator)

Debug-Assertions, wie der Name suggeriert, kommen nur in Debug-Code. Wenn das Makro NDEBUG definiert ist, oder in diesem Fall, wenn die Nicht-Debug-Runtime gelinkt wird, ist das nicht mit drin.

Allerdings solltest du wirklich mal in die Windows-Dokumentation zu sockets und fdopen kucken, debug assertions zu ignorieren ist in aller Regel eine äußerst ungesunde Idee. Es sieht mir danach aus, als erwarte fdopen in der Windows-Bibliothek einen tatsächlichen Datei-Deskriptor, jedenfalls ist der Deskriptor, den du ihm gibst, außerhalb des für Windows-fdopen akzeptablen Bereichs.

Was ziemlich merkwürdig ist, denn die in POSIX definierte fdopen-Funktion hat damit keinerlei Probleme - deswegen frisst gcc das auch anstandslos. Aber so ist das mit Microsoft und Industriestandards. Man könnte ja kompatibel sein.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

002
22.01.2008, 11:34 Uhr
banshee

Jo, ich muss meine Aufgaben auch immer auf Linux testieren, hab zu Hause aber Windows + Visual C++. Ich schreib jedes Programm also eigentlich gleich zweimal...

Das Problem hier ist nur, dass mein gcc komplett am rumspinnen ist. Zb. schreib ich in meine main Funktion einfach zwei printf-Anweisungen und die zweite gibt er nicht mehr auf dem Bildschirm aus. Ich müsste das also irgendwie mal Debuggen und auch so ist es immer mühsam den Code per Hand über Konsole zu kompilieren.

Und sämtlichen Code, den ich im Internet über Webserver gefunden hab, benutzen entweder das fdopen (oder _fdopen, was aber die gleiche Assertion schmeißt) oder eine read() Methode, die in der sys/types.h drin ist und die ich unter Windows auch nicht habe.

Zum Kotzen einfach nur

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

003
22.01.2008, 12:15 Uhr
0xdeadbeef
Gott
(Operator)

Das mit dem printf ist keine Spinnerei. Schreib hinter die printf-Anweisung ein

C++:

fflush(stdout);

...das flusth den Ausgabestream und die Ausgabe wird sofort sichtbar. Sinnvoller wäre es natürlich, einen Debugger zu benutzen (z.B. gdb in Verbindung mit ddd, oder valgrind in Verbindung mit kcachegrind).

Ansonsten funktionieren sockets unter Windows etwas anders als unter Linux, zum Beispiel muss die Socket-Bibliothek da erst initialisiert werden oder so, und es gibt auch sonst ein paar feine Unterschiede zur BSD-Socket-Bibliothek, auf der der ganze Kram fußt. Mit POSIX hat's Windows auch nicht so, deswegen wundert es mich eigentlich nicht, dass die fdopen-Funktion da rumspinnt und du read nicht kriegst - vielleicht nennen die das _read oder so.

Übrigens befindet read sich laut POSIX in <unistd.h>. Mag sein, dass sie der gcc in sys/types.h deklariert und die dann von unistd.h aus einbindet, aber korrekt, wenn man read benutzen will, ist trotzdem, <unistd.h> einzubinden. Die Windows allerdings ebenfalls nicht haben dürfte.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

004
22.01.2008, 15:57 Uhr
banshee

Also ich denke der Fehler lag da eher darin, dass ich einen kompletten Buffer von 1024 Zeichen ausgegeben habe und die Konsole dahinter zuende war oder sowas. Ich hab mir dann einfach mit einem logfile beholfen, was sowieso übersichtlicher sein dürfte.

Ich bin gerade dabei mir mit ecplipse und cdt einen Debugger für gcc einzurichten, aber mit Visual C++ in GNU C zu programmieren ist in der Tat hässlich

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: > 1 < [ C / C++ (ANSI-Standard) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: