4. Studio 7.1: EXE schmiert ab, bevor die main erreicht wird

Studio 7.1: EXE schmiert ab, bevor die main erreicht wird

  • ?

    Hallo,

    ich habe hier ein ziemlich umfangreiches c++ Projekt. Die generierte EXE schmiert beim Debuggen (und auch beim Ausführen) ab, bevor die main-Methode erreicht wurde. Deshalb kann ich es auch nicht debuggen. Es erscheint ein Pop-Up mit der Meldung "Unhandled exception at 0x7c901230 in ias.exe: User breakpoint.". Hat jemand einen Ahnung, was das sein könnte, oder wie ich das Problem am Besten angehen kann?

    Eine Anmerkung noch: Ich benötige viele Bibliotheken, von denen eine mit einigen anderen "doppelt definierte Symbole" erzeugt. Leider kann ich auf die Bibliothek nicht verzichten und habe es deshalb mit force gelinkt.

    Für Hilfe bin ich dankbar! 🙂

    0
  • D

    höchstwahrscheinlich gibt es Probleme mit Release- und Debug-CRT

    0
  • J

    Vermutlich hast Du irgendwo im Konstruktor ein Problem, welcher in einer statisches/globalen Instanz drin ist...
    Wenn der Fehler auftritt kannst Du nicht "Wiederholen" drücken?

    0
  • ?

    Danke für die Antworten! Ich komme an den Code leider erst am Dienstag wieder ran.

    Die Debug- und Release-Versionen habe ich schon getrennt, also jeweils die entsprechenden Bibliotheken benutzt.

    Die Sache mit dem wiederholden muss ich noch testen, weiß allerdings nicht, was das ändert. Meinst Du, ich soll es machen, damit ich sehen kann, wo ich gerade bin? Also nach der Fehlermeldung beendet sich der Prozess nicht, sonder steht nur. Ich kann dann auf Continue oder Break klicken, wobei das Programm mit Continue auch nicht weiter durchläuft. Jedenfalls befindet sich das Programm zu dem Zeitpunkt in irgendeiner String-Klasse, genau kann ich das Dienstag nochmal sagen.

    Was vielleicht auch noch interessant ist: Das Projekt war früher mal ein Visual Studio 6-Projekt. Es benutzt OpenIdeas(eine Corba-Geschichte) und ich musste es mal an eine neue OpenIdeas-Version anpassen. In dem Zuge habe ich daraus auch ein Visual-Studio 7.1-Projekt gemacht, was sich ohne force Linken ließ und problemlos lief. Jemand anders hat das Ding mit der alten OpenIdeas-Version und Studio-6 weiterentwickelt. Jetzt habe ich seine Ereiterungen in mein neues Studio 7.1-Projekt übernommen. Kann das Problem auch daher kommen? Aber eigentlich binde ich keine Bibliotheken ein, die speziell für Studio 6 sind.

    0
  • J

    Wenn Du auf "break" dückst, dann solltest Du es doch debuggen können, oder?

    0
  • ?

    Jochen Kalmbach schrieb:

    Wenn Du auf "break" dückst, dann solltest Du es doch debuggen können, oder?

    Wenn das Programm abschmiert, ist es in der "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring". "xstring" hat dabei keine Dateiendung. Genau bleibt er da drin hängen:

    void _Eos(size_type _Newsize)
		{	// set new length and null terminator
		_Traits::assign(_Myptr()[_Mysize = _Newsize], _Elem());
		}

    Wenn ich dann auf Break klicke und den Debugger benutze, komme ich durch Assembler-Code und nach ein paar Schritten erscheint ein PopUp mit der Meldung:

    Debug Assertion Failed!
    Program: die exe...
    File: dbgheap.c
    Lien 1132

    Expression _CrtIsValidHeapPointer(pUserDate)
    ...

    Und dieses Popup erscheint immer wieder, egal, ob ich auf "ignorieren", oder "wiederholen" klicke.

    0
  • J

    Du solltest im Callstack schauen, woher der Fehler kommt...

    0
  • ?

    Danke für den Tip!
    Im Callstack steht folgendes, was mich aber leider nicht viel weiter bringt. Bringt es Dich auf eine Idee?

    ntdll.dll!7c901230() 	
ntdll.dll!7c96c943() 	
ntdll.dll!7c96cd80() 	
ntdll.dll!7c960af8() 	
ias.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Eos(unsigned int _Newsize=22872064)  Line 1475 + 0x22	C++
kernel32.dll!7c85e9cf() 	
msvcr71d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x016f6f88)  Line 1807	C
msvcr71d.dll!_free_dbg_lk(void * pUserData=0x016f6f88, int nBlockUse=1)  Line 1132 + 0x9	C
msvcr71d.dll!_free_dbg(void * pUserData=0x016f6f88, int nBlockUse=1)  Line 1070 + 0xd	C
msvcr71d.dll!operator delete(void * pUserData=0x016f6f88)  Line 54 + 0x10	C++
msvcp71d.dll!std::allocator<char>::deallocate(char * _Ptr=0x016f6f88, unsigned int __formal=64)  Line 138 + 0x9	C++
msvcp71d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Tidy(bool _Built=true, unsigned int _Newsize=0)  Line 1519	C++
msvcp71d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >()  Line 458	C++
ias.exe!jace::JClassImpl::JClassImpl()  Line 96 + 0xcc	
ias.exe!jace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem::staticGetJavaJniClass()  Line 104 + 0x3d	C++
ias.exe!jace::JEnlister<jace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem>::getClass()  Line 96	C++
ias.exe!jace::helper::enlist()  Line 278 + 0xd	
ias.exe!jace::JEnlister<jace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem>::JEnlister<jace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem>()  Line 42 + 0x9	C++
ias.exe!$E3()  Line 112 + 0x13	C++
ias.exe!_initterm(void (void)* * pfbegin=0x0059105c, void (void)* * pfend=0x005910c0)  Line 600	C
ias.exe!_cinit(int initFloatingPrecision=1)  Line 215 + 0xf	C
ias.exe!mainCRTStartup()  Line 229 + 0x7	C
kernel32.dll!7c816fd7() 	
ntdll.dll!7c915b4f()
    0
  • Mod

    Ist doch nicht schwer zu lesen.

    Die CRT startet:
    1. ias.exe!mainCRTStartup() Line 229 + 0x7 C
    2. ias.exe!_cinit(int initFloatingPrecision=1) Line 215 + 0xf C

    Nun kommt das Initialisieren der statischen (globalen) Variablen)

    3. ias.exe!$E3() Line 112 + 0x13 C++
    4. ias.exe!_initterm(void (void)* * pfbegin=0x0059105c, void (void)* * pfend=0x005910c0) Line 600 C

    Nun und in diesem Namespace/Objekt/Initializer knallt es
    5. jace::JEnlisterjace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem::JEnlisterjace::proxy::COM::metaphasetech::tasks::ids::ops::openness::OIETeamItem() Line 42 + 0x9 C++

    Irgendwie wird hier in der Klasse jace::JClassImpl::JClassImpl() ein std::string freigegeben und zu diesem Zeitpunkt ist der entsprechende Heap an dieser Stelle kaputt...
    msvcr71d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x016f6f88) Line 1807 C

    0
  • B

    @Martin: krass.. wie machst du das nur, ich versteh gar nichts:)

    0
Anmelden zum Antworten