boost.asio : daytime server

kernel32.dll!7c81eb33()
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für kernel32.dll]
kernel32.dll!7c81eb33()
msvcr80d.dll!10243990()
[Übergang von Verwaltet zu Systemeigen]

asio_server.exe!boost::throw_exceptionasio::system\_error(asio::system_error& e = {...}) Zeile 40 C++

ein pfeil an der seite zeigt auf die obere zeile, ein weitere auf die untere des kommentars. der obere ist vermutlich die funktion, die dann die eigentliche funktion aufruft, die schließlich die exception wirft. aber kann jemand was damit anfangen? position 7c81eb33 in der kernel32.dll. aber welche funtkion befindet sich dort?

LordJaxom

Ports < 1024 sind IMHO privilegiert und nur dem Administrator zugänglich (unter Windows IMHO, unter UNIX ganz sicher). Ist vielleicht das das Problem?

Artchi

system_error sollte schon sehr deutlich machen, das es sich nicht um ein boost.asio-Problem handelt, sondern um ein Problem/Grund im oder aus dem System.

LordJaxom schrieb:

Ports < 1024 sind IMHO privilegiert und nur dem Administrator zugänglich (unter Windows IMHO, unter UNIX ganz sicher). Ist vielleicht das das Problem?

normalerweise nicht. werds nochmal probieren aber ich hab auch schon ports darüber versucht und admin rechte hab ich eh

Artchi schrieb:

system_error sollte schon sehr deutlich machen, das es sich nicht um ein boost.asio-Problem handelt, sondern um ein Problem/Grund im oder aus dem System.

hab mich nur gewundert, weils asio::system_error heisst. bin mir nicht sicher ob das soo arg viel mit windows zu tun hat.

Mr. N

rudi++ schrieb:

admin rechte hab ich eh

Ausgeprägtes Sicherheitsbewusstsein.

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