boost.asio : daytime server

hmm also die adresse an der die exception geworfen wird war natürlich ne adresse im programm und nicht aus der kernel32.dll. hier nochmal die message box des VS

Eine Ausnahme (erste Chance) bei 0x7c81eb33 in asio_server.exe: Microsoft C++-Ausnahme: asio::system_error an Speicherposition 0x0012ee58..

ob der jetzt vom system kommt oder von asio... aber gibts da irgendne möglichkeit die ursache des fehlers in erfahrung zu bringen??

hustbaer

Mr. N schrieb:

rudi++ schrieb:

admin rechte hab ich eh

Ausgeprägtes Sicherheitsbewusstsein.

Windows ist einfach zu lästig ohne Admin Rechte.

Artchi

Welche asio-Version benutzt du denn? system_error scheint wohl in einer älteren Version drin zu sein? In der Online-Doku ist es nicht enthalten.

boost::asio::system_exception sagt, das es es einen Systemfehler/-ausnahme repräsentiert, das asio an der Arbeit hindert. Ist jetzt nicht system_error, aber finde keine passende Doku.

hatte bisher immer 0.3.8 rc 2 verwendet, jetzt hab ich mir mal rc 3 runtergeladen. der code sieht zwar etwas anders aus aber wieder das gleiche problem. übrigens: system_exception und system_error ist dasselbe. auf der homepage sollte unten ein 0.3.7 stehen und auch dafür ist die doku. beim download der neuesten version ist auch 'ne neue doku dabei aber die klasse dient jedenfalls demselben zweck.

zum eigentlichen problem zurück: dachte zuerst es liegt an der firewall oder so, da ich die (wegen lästigen meldungen etc.) einfach mal für visual studio deaktiviert habe... hat auch keinen unterschied gemacht aber sicher isses nachher irgendsone geschichte.

hustbaer

rudi++ schrieb:

hmm also die adresse an der die exception geworfen wird war natürlich ne adresse im programm und nicht aus der kernel32.dll. hier nochmal die message box des VS

Eine Ausnahme (erste Chance) bei 0x7c81eb33 in asio_server.exe: Microsoft C++-Ausnahme: asio::system_error an Speicherposition 0x0012ee58..

ob der jetzt vom system kommt oder von asio... aber gibts da irgendne möglichkeit die ursache des fehlers in erfahrung zu bringen??

Ja, gibt es. Menu "Debug", Menupunkt "Exceptions...". Da aktivierst du das "Thrown" Hakerl bei C++ Exceptions. Dann hält er das Programm bei jedem "throw" im Debugger an. Dann guckst du einfach wo das ist und was das Problem ist.
Dann kannst du auch den Callstack verwenden um zu weiter "zurückzugehen", also zu sehen wo der Fehler ursprünglich entsteht - falls der Debugger tief verschachtelt in irgendwelchen Fehlerbehandlungsfunktionen stehen bleibt (weit weg von der Fehlerursache halt).

Wenn das immer noch nix hilft dann step es halt einfach durch, kann ja nicht SO viel Code sein bis zu dem Punkt wo's kracht.

ja der code ist nicht so umfangreich - zumindest der der main.cpp. aber es wird immer auf irgendwelche includes (asio.hpp included glaube ich schon an die 20 header und jeder davon noch zahlreiche boost header) verwiesen und zwar immer auf die funktion throw_exception in throw_exception.hpp (boost), wie zuvor beschrieben. c++ exceptions sind auch schon an...

ok jetzt hab ich noch genauere infos zum fehler: er tritt nur bei acceptor::listen auf. wenn ich also schreibe:

tcp::acceptor acceptor(io, tcp::v4());

läuft noch alles nach plan. er erstellt ja nur einen acceptor, der das ip4 protokoll verwendet. wenn ich noch einen endpoint mittels bind() hinzufüge klappt auch noch alles:

tcp::acceptor acceptor(io, tcp::v4());
tcp::endpoint ep(tcp::v4(), 13);
acceptor.bind(ep);
acceptor.listen()

hier genau wird die exception immer geworfen, dasselbe in grün wäre

tcp::acceptor(io, tcp::endpoint(tcp::v4(), 13))

der macht all das auf einmal. der system_error wird übrigens bei fast allen acceptor ctoren und funktionen geworfen, aber woran kann es liegen wenn ein listen (z.b. auch wenn mans mit winsock "von hand" macht) scheitert??

Mr. N

NAME
       listen - listen for connections on a socket

SYNOPSIS
       #include <sys/socket.h>

       int listen(int sockfd, int backlog);

ERRORS
       EADDRINUSE
              Another socket is already listening on the same port.

       EBADF  The argument sockfd is not a valid descriptor.

       ENOTSOCK
              The argument sockfd is not a socket.

       EOPNOTSUPP
              The socket is not of a type that supports the listen() operation.

Die möglichen Fehler werden unter Windows ähnlich sein.

@ Mr.N: Danke für die Info! aber es scheint mir als kommt keiner der möglichen gründe in Frage. da müsste asio schon massive fehler haben, wenn es am socket liegen würde und den port wechseln hab ich schon versucht. das problem is sicher n ganz anderes wenn da nur ich probleme mit hab.

hustbaer

Oh Mann, ich verstehe echt nicht warum du immer noch rumrätst. Guck dir doch einfach an was der Returncode von listen() ist. Oder kannst du deinen Debugger nicht bedienen? In dem Fall musst du halt fragen oder gucken ob du Tutorials für den Debugger findest - allerdings muss ich sagen der MSVC Debugger ist das einfachste wo gibt.

BTW: hast du WSAStartup aufgerufen?

hustbaer schrieb:

Oh Mann, ich verstehe echt nicht warum du immer noch rumrätst.

hmmm... hast du nen besseren vorschlag ?

hustbaer schrieb:

Guck dir doch einfach an was der Returncode von listen() ist

hab ich doch schon des öfteren und auch schonmal hier gepostet.

hustbaer schrieb:

Oder kannst du deinen Debugger nicht bedienen? In dem Fall musst du halt fragen oder gucken ob du Tutorials für den Debugger findest - allerdings muss ich sagen der MSVC Debugger ist das einfachste wo gibt.

das was du mir bisher geschrieben hast hab ich doch geschnallt aber es geht hier nicht um winsock sondern um eine netzwerk library. Wie soll ich denn da an die Funktionen im object file kommen?

hustbaer schrieb:

BTW: hast du WSAStartup aufgerufen?

der code ist plattformunabhängig. ein WSAStartup kommt außerdem in keinem Tutorialcode vor.

also gut: mein debugger findet probleme bei 2 membern des asio::io_service objekts io was essentiell für asio ist

io.impl_ Fehler: "io.impl_" ist nicht vorhanden.
(*io.service_registry_).owner_ Fehler: "*io.service_registry_.owner_" ist nicht vorhanden.

kann dir leider nur nicht sagen wie sich das auswirkt, werde aber noch die duko etwas studieren.

hustbaer

Oh Mann, du machst das echt kompliziert.

Also. *Welchen* Errorcode liefert denn ::listen() zurück? Also nicht die ASIO Version sondern einfach das globale ::listen() vom alten WinSock.

Könnte es sein dass es vielleicht EADDRINUSE ist?
Könnte es sein dass Port 13 schon belegt ist?
Hast du es mit einem anderen Port probiert?

hustbaer schrieb:

Also. *Welchen* Errorcode liefert denn ::listen() zurück? Also nicht die ASIO Version sondern einfach das globale ::listen() vom alten WinSock.

ich kenn das schon aber datt gibts da nicht. glaub mir dieses listen is so verschachtelt, schon allein asio.hpp bindet 54 weitere asio header ein, die wieder andere und zusätzlich noch boost header! das versteckt alle plattforspeziefischen funktionen. es gibt also _keine_ winapi funktion, die ich aufrufen muss und keine von der ich nen rückgabewert erhalte.

hustbaer schrieb:

Könnte es sein dass es vielleicht EADDRINUSE ist?

kein schimmer was das ist
aber meine winsock proggies gehen noch

hustbaer schrieb:

Könnte es sein dass Port 13 schon belegt ist?

theoretisch ja. aber ich hab schon etliche andere probiert und da tut sich auch nix.

The-Kenny

Dann such dir ::listen() halt nicht aus asio heraus, sondern schreib einfach selber ein mini-testprogramm *ohne* asio.

Edit:
http://beej.us/guide/bgnet/output/html/multipage/syscalls.html#listen

ja das funtzt doch...

hustbaer

Also ich weiss nicht was das Problem ist.
Ich habe den "asynchronous daytime tcp server" aus dem Tutorial ausprobiert, und bei mir geht das 1A.

Mit der ASIO 0.3.7 wohlgemerkt, die 0.3.8rc3 geht bei mir nicht (die "error" Klasse ist irgendwie nicht brauchbar, die lässt sich nicht auslesen und das "if (!error)" im "daytime server tutorial" lässt sich nicht compilieren.

Mit der 0.3.7 aber wie gesagt: keine Probleme und der Server läuft auch schön brav.

Der ::select Aufruf ist bei der 0.3.7 übrigens in socket_ops.hpp, Zeile 120. Wirklich nicht schwer zu finden wenn man mit dem Debugger durchsteppt.

----

Bitte berschreib doch einfach mal welche Libraries (boost, asio) du runtergeladen hast, also genaue Version etc. Und hast du die asio wie beschrieben ins boost Verzeichnis reinkopiert? Stimmen die include Pfade?
Und wieso kannst du die ASIO einfach über "asio.hpp" includieren und im Namespace ::asio ansprechen? Bei mir ist das immernoch <boost/asio.hpp> und Namespace boost::asio.

Ich schätze mal du dürftest da irgendwas beim Einbinden der Library gröber falsch gemacht haben...

hustbaer schrieb:

Also ich weiss nicht was das Problem ist.
Ich habe den "asynchronous daytime tcp server" aus dem Tutorial ausprobiert, und bei mir geht das 1A.
Mit der ASIO 0.3.7 wohlgemerkt, die 0.3.8rc3 geht bei mir nicht (die "error" Klasse ist irgendwie nicht brauchbar, die lässt sich nicht auslesen und das "if (!error)" im "daytime server tutorial" lässt sich nicht compilieren.
Mit der 0.3.7 aber wie gesagt: keine Probleme und der Server läuft auch schön brav.
Der ::select Aufruf ist bei der 0.3.7 übrigens in socket_ops.hpp, Zeile 120. Wirklich nicht schwer zu finden wenn man mit dem Debugger durchsteppt.

Vielen Dank erstmal, dass du dir die Mühe gemacht hast, es selbst auszuprobiern. verstehe nur nicht ganz wie du auf select kommst, bzw. warum du vermutest, dass genau dort was schief läuft. jedoch läuft bei mir jetzt wiederum die error klasse

hustbaer schrieb:

Bitte berschreib doch einfach mal welche Libraries (boost, asio) du runtergeladen hast, also genaue Version etc.

boost dürfte 1.33.1 sein und asio ist eben die neueste, also .3.8 rc3.

hustbaer schrieb:

Und hast du die asio wie beschrieben ins boost Verzeichnis reinkopiert? Stimmen die include Pfade?

jo passt alles.

hustbaer schrieb:

Und wieso kannst du die ASIO einfach über "asio.hpp" includieren und im Namespace ::asio ansprechen? Bei mir ist das immernoch <boost/asio.hpp> und Namespace boost::asio.

alles tutorialcode. also wenn man die pfade entsprechend gesetzt hat geht das so. außerdem steht zu beginn fast jeden bsps

using asio::ip::tcp;

werde jetzt aber auch mal auf 0.3.7 umsteigen ggf auch auf boost 1.34.0 und auch äußere sachen wie firewall für bestimmte programme oder internetoptionen checken... nur komisch eben, dass normale Winsock programme laufen

probier deine exe doch mal bei freunden aus

hustbaer schrieb:

Mit der 0.3.7 aber wie gesagt: keine Probleme und der Server läuft auch schön brav.

hätte nicht gedacht, dass ich das nochmal sagen werd, aber: ES LÄUFT
:p

Recht herzlichen Dank für den Tip und auch an alle anderen, die sich an dem Thread beteiligt haben!

Scheint wohl noch kleinere Probleme mit den rcs zu geben (zumindes untern windows mit ms compiler) aber die .3.7-er version läuft jetzt auch einwandfrei