4. EAccessViolation (nur) bei Release_Build BCB2009

EAccessViolation (nur) bei Release_Build BCB2009

  • S

    Moinsn,

    wie der Titel schon sagt, erhalte ich bei einem Release_Build folgende Meldung:

    Benachrichtigung über Debugger-Exception
Im Projekt MyPrj.exe ist eine Exception der Klasse EAccessViolation mit dre Meldung 'Zugriffsverletzung' aufgetreten,

    Fertich. Nix weiter 😞

    Bei einem Debug_Build klappt alles, das Prog läuft sauber.

    Bin momentan - nach längerer Suche und noch mehr Build Versuchen mit geänderter Konfiguration - etwas gnervt, und weiß nicht mehr, wo ich noch suchen soll.

    Kennt einer diese Meldung? Was ist zu tun?

    grüssle 🙂

    0
  • B

    Das könnte irgendein uninitialisierter Zeiger sein. Im Debug-Modus werden die normalerweise mit 0 initilisiert im Release Modus aber nicht.

    0
  • A

    Versuche doch mal, ein "Debuggable Release Build" zu erstellen, also eine Build-Konfiguration wie Release, doch unter Aktivierung ausgewählter Debug-Informationen (z.B. Zeilennummern).

    0
  • S

    audacia schrieb:

    Versuche doch mal, ein "Debuggable Release Build" zu erstellen, also eine Build-Konfiguration wie Release, doch unter Aktivierung ausgewählter Debug-Informationen (z.B. Zeilennummern).

    Hab jetzt mal beim Release die Laufzeit-Packages aktiviert. Dann klappt alles.
    Wenn ich die Laufzeit-Packages deaktiviere, bleibt er in der 'dstring.h', bei:

    __fastcall AnsiStringT(const AnsiStringT& src) : AnsiStringBase(*((AnsiStringBase*)(&src))){}

    stehen.
    Also hats wohl mit AnsiStrings zu tun. Nur bei was? Erstellung? Zuweisung? Bitte nicht, denn davon gibts hier hunderte 😮

    Gibts 'ne Möglichkeit, den BCB dazu zu bewegen, die genaue Stelle, an der es passiert, zu zeigen?

    grüssle 🙂

    0
  • A

    Smitty schrieb:

    Gibts 'ne Möglichkeit, den BCB dazu zu bewegen, die genaue Stelle, an der es passiert, zu zeigen?

    Den Call-Stack 😉

    0
  • S

    audacia schrieb:

    Smitty schrieb:

    Gibts 'ne Möglichkeit, den BCB dazu zu bewegen, die genaue Stelle, an der es passiert, zu zeigen?

    Den Call-Stack 😉

    hab ich nicht. Hab nur den 'Aufruf-Stack' 😉

    Allerdings werde ich aus der Ausgabe ehrlich gesagt nicht richtig schlau:

    :7c812aeb kernel32.RaiseException + 0x52
:005c44e2 ___raiseDebuggerException + 0x1A
:005c45bc ; ___raiseDebuggerException
:7c9132a8 ntdll.RtlConvertUlongToLargeInteger + 0x6a
:7c91327a ntdll.RtlConvertUlongToLargeInteger + 0x3c
:7c91e46a ntdll.KiUserExceptionDispatcher + 0xe
:004d7375 Classes::RegisterIntegerConsts + 0x25
:005ce3bf ; __startup

    grüssle 😕

    0
  • A

    Smitty schrieb:

    Allerdings werde ich aus der Ausgabe ehrlich gesagt nicht richtig schlau:

    :7c812aeb kernel32.RaiseException + 0x52
:005c44e2 ___raiseDebuggerException + 0x1A
:005c45bc ; ___raiseDebuggerException
:7c9132a8 ntdll.RtlConvertUlongToLargeInteger + 0x6a
:7c91327a ntdll.RtlConvertUlongToLargeInteger + 0x3c
:7c91e46a ntdll.KiUserExceptionDispatcher + 0xe
:004d7375 Classes::RegisterIntegerConsts + 0x25
:005ce3bf ; __startup

    Alles ab KiUserExceptionDispatcher und aufwärts gehört zum Exception-Handling-Mechanismus. Die Funktion direkt darunter hat die Exception ausgelöst. Wenn du die CPU-Ansicht öffnest und auf den Eintrag doppelklickst, landest du etwa an der Codestelle, die für die Exception verantwortlich ist.

    Als nächstes könntest du dorthin einen Breakpoint setzen und dir ansehen, welche Parameter ungültig sind.

    Wenn du eine Kopie des Projektes so sehr kürzt, daß der Fehler noch auftritt, du sie aber hier veröffentlichen kannst, schau ich mir das gerne mal an.

    0
  • S

    audacia schrieb:

    Wenn du eine Kopie des Projektes so sehr kürzt, daß der Fehler noch auftritt, du sie aber hier veröffentlichen kannst, schau ich mir das gerne mal an.

    1000 Dank für dein Angebot, aber wird wohl nicht mehr nötig sein. Hab mich heute früh an die Kiste gesetzt, Projekt auf -> ReleaseBuild Einstellungen -> DebugInfos weg( wie schon so oft davor ) -> F9 -> funktioniert 😕 😕 😕 😃

    Dachte schon, die Heinzelmännchen wären über Nacht hier gewesen, aber die Times der Sourcefiles sagen nein 😮

    grüssle 🙂

    0
Anmelden zum Antworten