Hilfe bzgl. Interpretation stacktrace

Hallo zusammen,

ich habe nachfolgenden Stacktrace aber ich tu mir schwer festzustellen wo es kracht und vor allem warum.

Kann mir bitte Jemand sagen wie ich sukzessive den Fehlerherd bestimmen kann?

Problem ist "string iterator not dereferencable"

msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x00d34240, const wchar_t * file=0x00d34298, unsigned int line=112)  Line 24	C++
 	soo-cpp-server.exe!std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> >::operator*()  Line 112 + 0x14 bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::buffer_debug_check<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >::operator()()  Line 526	C++
 	soo-cpp-server.exe!boost::detail::function::void_function_obj_invoker0<boost::asio::detail::buffer_debug_check<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,void>::invoke(boost::detail::function::function_buffer & function_obj_ptr={...})  Line 154	C++
 	soo-cpp-server.exe!boost::function0<void>::operator()()  Line 760 + 0x16 bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::buffer_cast_helper(const boost::asio::const_buffer & b={...})  Line 270	C++
 	soo-cpp-server.exe!boost::asio::buffer_cast<void const *>(const boost::asio::const_buffer & b={...})  Line 428 + 0x9 bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::buffer_sequence_adapter<boost::asio::const_buffer,boost::asio::const_buffers_1>::validate(const boost::asio::const_buffers_1 & buffer_sequence={...})  Line 237 + 0x9 bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::win_iocp_socket_send_op<boost::asio::const_buffers_1,boost::_bi::bind_t<void,boost::_mfi::mf2<void,soo::TcpConnection,boost::system::error_code const &,unsigned int>,boost::_bi::list3<boost::_bi::value<boost::shared_ptr<soo::TcpConnection> >,boost::arg<1>,boost::arg<2> > > >::do_complete(boost::asio::detail::win_iocp_io_service * owner=0x030eac70, boost::asio::detail::win_iocp_operation * base=0x03101120, boost::system::error_code ec={...}, unsigned int bytes_transferred=11)  Line 67 + 0xc bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::win_iocp_operation::complete(boost::asio::detail::win_iocp_io_service & owner={...}, const boost::system::error_code & ec={...}, unsigned int bytes_transferred=11)  Line 44 + 0x20 bytes	C++
 	soo-cpp-server.exe!boost::asio::detail::win_iocp_io_service::do_one(bool block=true, boost::system::error_code & ec={...})  Line 399	C++
 	soo-cpp-server.exe!boost::asio::detail::win_iocp_io_service::run(boost::system::error_code & ec={...})  Line 161 + 0xe bytes	C++
 	soo-cpp-server.exe!boost::asio::io_service::run()  Line 57 + 0xf bytes	C++
 	soo-cpp-server.exe!soo::FhemAdapter::runIoService()  Line 181	C++
 	soo-cpp-server.exe!boost::_mfi::mf0<void,soo::FhemAdapter>::operator()(soo::FhemAdapter * p=0x030ea5d0)  Line 49 + 0xc bytes	C++
 	soo-cpp-server.exe!boost::_bi::list1<boost::_bi::value<soo::FhemAdapter *> >::operator()<boost::_mfi::mf0<void,soo::FhemAdapter>,boost::_bi::list0>(boost::_bi::type<void> __formal={...}, boost::_mfi::mf0<void,soo::FhemAdapter> & f={...}, boost::_bi::list0 & a={...}, boost::_bi::type<void> __formal={...})  Line 254	C++
 	soo-cpp-server.exe!boost::_bi::bind_t<void,boost::_mfi::mf0<void,soo::FhemAdapter>,boost::_bi::list1<boost::_bi::value<soo::FhemAdapter *> > >::operator()()  Line 21	C++
 	soo-cpp-server.exe!boost::detail::thread_data<boost::_bi::bind_t<void,boost::_mfi::mf0<void,soo::FhemAdapter>,boost::_bi::list1<boost::_bi::value<soo::FhemAdapter *> > > >::run()  Line 62	C++
>	soo-cpp-server.exe!boost::`anonymous namespace'::thread_start_function(void * param=0x00820390)  Line 177	C++
 	msvcr90d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
 	msvcr90d.dll!_threadstartex(void * ptd=0x030e9aa8)  Line 331	C

Danke an Alle die ein paar Tipps haben

314159265358979

soo-cpp-server.exe!soo::FhemAdapter::runIoService() Line 181 C++

Irgendwo dort wird wohl der Fehler liegen.

314159265358979 schrieb:

soo-cpp-server.exe!soo::FhemAdapter::runIoService() Line 181 C++

Irgendwo dort wird wohl der Fehler liegen.

so einfach ist nicht denn

void FhemAdapter::runIoService() 
	{
		while(!isGoingShutdown) {
			try {
				ioService->run();
				break; // run() exited normally
			}
			catch (exception& e) {
				// Deal with exception as appropriate.
				std::cerr << boost::diagnostic_information(e) << endl;
				//std::cout << e.what();
			}
		}
	} //line 181

314159265358979

Vielleicht entsteht der Fehler auch schon viel früher und macht sich erst hier bemerkbar. Am besten bemühst du wohl deinen Debugger.

SeppJ

Die Zeile 181 ist auch keine Zeile, die nichts täte. Es ist das Ende eines Scopes, in C++ ein sehr mächtiges Konstrukt. Anscheinend geht da in einem Destruktor etwas schief.

SeppJ schrieb:

Die Zeile 181 ist auch keine Zeile, die nichts täte. Es ist das Ende eines Scopes, in C++ ein sehr mächtiges Konstrukt. Anscheinend geht da in einem Destruktor etwas schief.

Ja, aber

{//Hier beginnt der Scope

        while(!isGoingShutdown) 
        {//Anderer Scope
            try 
            {
                ioService->run();
                break;
            }
            catch (exception& e) 
            {
                std::cerr << boost::diagnostic_information(e) << endl;
            }
        }

    }//Hier endet er, es gibt in diesem local scope keine lokalen Variablen, weswegen hier auch kein Destruktor aufgerufen werden kann

Was du meinst, ist, das am Ende eines Scopes immer erst einige Operationen durchgeführt werden, bevor fortgefahren wird, wobei sich in diesem spezifischen Kontext die Frage stellt was das wohl sein könnte.
Könnte es auch sein, dass der Stack-zeiger beschädigt ist, oder so etwas ähnliches?

SeppJ

Hacker schrieb:

//Hier endet er, es gibt in diesem local scope keine lokalen Variablen, weswegen hier auch kein Destruktor aufgerufen werden kann

Von der Art der Fragestellung her gehe ich mal stillschweigend davon aus, dass der Threadersteller uns nicht alles relevante gezeigt hat. Wir müssen ihm hier schließlich alles aus der Nase ziehen. Man sollte jedenfalls davon ausgehen, dass der Debugger erst einmal recht hat. Damit er nicht Recht hat, muss das Programm schon ziemlich zerschossen sein. Ich wollte nur erklären, wie ein Absturz bei einer schließenden Klammer auftreten kann.

Was du meinst, ist, das am Ende eines Scopes immer erst einige Operationen durchgeführt werden, bevor fortgefahren wird, wobei sich in diesem spezifischen Kontext die Frage stellt was das wohl sein könnte.
Könnte es auch sein, dass der Stack-zeiger beschädigt ist, oder so etwas ähnliches?

Das kann natürlich auch sein. Bei einem Absturz ist erfahrungsgemäß vorher schon ordentlich was schiefgegangen. Stack-corruption ist da ein typisches Problem.