hab mich hier mal vor ner weile gemeldet, da der daytime server vom boost asio tutorial nicht läuft. da es auch weiterhin nicht geklappt hat, hab ichs dann aufgegeben (auch mit der mailing liste hats nicht geklappt). da es aber scheint, als würde es da nur bei mir probleme geben, wollte ich mal selbst schaun wo der hund begraben liegt. Also zum beispiel wer die exception asio::system_error wirft mit dem inhalt "Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist". Ich kann mir nämlich nicht im geringsten vorstellen warum hier eine solche exception geworfen wird - ich will ja nur einen acceptor erstellen und schon gar keine datei. so der code:

#include <iostream>
#include <string>
#include <ctime>
#include <asio.hpp>

using asio::ip::tcp;

int main()
{
	asio::io_service io;
	try
	{
		tcp::acceptor acc(io, tcp::endpoint(tcp::v4(), 13));
	}
	catch(std::exception& e)
	{
		std::cout<<e.what()<<std::endl;
	}
	return 0;
}

mir wurde mal geraten den "callstack nach oben zu klettern" wobei ich nicht weiß wie das gehn soll. Falls es jemandem weiterhilft: ich verwende das MS VS 2005 express.

Vielen Dank im voraus

Versuche einfach mal, einen anderen zu nutzen.

nene daran liegts nicht. alle die ich bisher versucht habe tun nicht...
da sicher nicht viele boost.asio verwenden, würde es mir vorerst auch reichen wenn mir einer erklärt wie man den callstack hochklettert

Dein Debugger kann dir nach ner exception den stack anzeigen, und die Funkionen kannst du dann "abgehen"

__CxxExceptionFilter:
0040B196 jmp dword ptr [__imp____CxxExceptionFilter (40C148h)]

damit kann ich jetzt aber leider wenig anfangen. würde mich aber freuen wenn mir da jemand weiterhelfen kann oder selbst boost.asio verwendet und mir sagen ob der fehler nur bei mir auftritt. kann ich mir aber eigentlich nicht vorstellen, da ich nur den code aus dem tutorial verwendet habe ...

Jag das mal durch den Debugger.

#include <asio.hpp>

using asio::ip::tcp;

int main()
{
	asio::io_service io;
	tcp::acceptor acc(io, tcp::endpoint(tcp::v4(), 13));
	return 0;
}

Jag das mal durch den Debugger.

ja dann landet er bei folgender funktion:

template<class E> inline void throw_exception(E const & e)
{
    throw e;
}

definiert in 'throw_exception.hpp' (ist vermutlich sogar bestandteil von boost, nicht nur von asio). verstehe aber nicht was da der unterschied ist.

Mr. N schrieb:

#include <asio.hpp>

using asio::ip::tcp;

int main()
{
	asio::io_service io;
	tcp::acceptor acc(io, tcp::endpoint(tcp::v4(), 13));
	return 0;
}

Jag das mal durch den Debugger.

ja dann landet er bei folgender funktion:

template<class E> inline void throw_exception(E const & e)
{
    throw e;
}

definiert in 'throw_exception.hpp' (ist vermutlich sogar bestandteil von boost, nicht nur von asio). verstehe aber nicht was da der unterschied ist.

Und jetzt schau, wer diese Funktion aufruft. Der Unterschied ist, dass du an der richtigen Stelle bist.

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?

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.

admin rechte hab ich eh

Ausgeprägtes Sicherheitsbewusstsein.

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

rudi++ schrieb:

admin rechte hab ich eh

Ausgeprägtes Sicherheitsbewusstsein.

Windows ist einfach zu lästig ohne Admin Rechte.

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.

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.

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.

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

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

BTW: hast du WSAStartup aufgerufen?

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.

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.

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?