4. Build ohne "dynamic RTL" produziert Access violation

Build ohne "dynamic RTL" produziert Access violation

  • ?

    Hallo,
    habe ein Problem beim laufen einer Application wenn sie ohne "dynamic RTL" gebuildet wurde. Hoffe, die englische Beschreibung stoert nicht - wenn doch, kann ichs gerne nochmal in deutsch tippseln 😉

    I have a BCB6 project which runs fine in the debug environment / on the development pc (WinXP).
    But what I want is to compile a standalone .exe which runs on its own without any additional files (components, dll, ..).
    For this, as I understand, the following options in the project settings have to be untagged:
    - Packages - Build with runtime packages
    - Linker - Use dynamic RTL

    As soon as I untag the "use dynamic RTL" the following error message shows up when I run the program:
    "Access violation at address xxxxxxx. Read of address 00000000."

    By debugging into the project, I could gather the following informtation:
    This happens BEFORE the main fuction is called. (placing breakpoint at beginning of main, looking at callStack).
    When debugging, the execution stopps in ../cbuilder6/include/stl/_ios.c at the basic_ios template, which is not my code.
    The callStack lists Log::Log, which is in my code (code and callstack see below).
    It is possible to place a breakpoint in the line marked with "#1" but will not reach "#2" - the problem happens before.

    I have already tried to remove global variables from class files (found this to be the possible cause by research).
    This did not change anything.
    There are, however, files with global functions in the project.

    I am new to BCB and would very much appreciate your help.
    myme

    //*********************************************
    //*********************************** CALLSTACK
    //*********************************************

    7C812A5B C:\WINNT\system32\kernel32.dll
    004E970B ___raiseDebuggerException
    004E2100 ___DefHandler
    7C9037BF ntdll.dll
    7C90378B ntdll.dll
    7C90EAFA ntdll.dll
    004EE7E3 _STL::ios_base::ios_base
    0042D092 _STL::basic_ios<char, _STL::char_traits<char> >::basic_ios<char, _STL::char_traits<char> >(this=:0052156C)
    0042C994 _STL::basic_ofstream<char, _STL::char_traits<char> >::basic_ofstream<char, _STL::char_traits<char> >(this=:005214BC)
    0042C8B0 Log::Log(this=:005214B4)
    004168BD _STCON0_()
    004E813D __init_exit_proc
    004E8313 __startup

    //*********************************************
//************************************* log.cpp
//*********************************************
#include "log.h"
#include <string>

Log::Log()
{                        [b]//Breakpoint #1 - stopps here[/b]
  msg_counter=0;         [b]//Breakpoint #2 - does not get here[/b]
  num_of_msg=0;
  MAX_NUM_OF_MSG=10;
  messages= new string[MAX_NUM_OF_MSG];
  has_changed_since_last_read=false;
  changes_since_last_read=0;
  has_file=false;
}
.....

    //*********************************************
//************************************** _ios.c
//*********************************************
....
// Protected constructor and initialization functions. The default
// constructor creates an uninitialized basic_ios, and init() initializes
// all of the members to the values in Table 89 of the C++ standard.

template <class _CharT, class _Traits>
basic_ios<_CharT, _Traits>::basic_ios()
  : ios_base(),                             [b]//stopps here (arrow)[/b]
    _M_fill(_STLP_NULL_CHAR_INIT(_CharT)), _M_streambuf(0), _M_tied_ostream(0)
{}
....
    0
  • S

    Hi,

    "Access violation at address xxxxxxx. Read of address 00000000."

    zeigt den Leseversuch in einem nicht initialisierten Speicherbereich.
    Liegt normalerweise an einem nicht initialisierten Pointer (evtl. Klasseninstanz nicht gebildet?).
    Es ist nicht anzunehmen, das std:io in diesem Bereich einen Fehler hat,
    normalerweise verwirrst du den Debugger, indem du ihn mit einem solchen Pointer arbeiten lässt.

    Das es im Debugmode läuft (mit RTL), aber nicht ohne, ist etwas, das ich auch schon kennen lernen durfte.
    Es liegt wahrscheinlich daran, das der Arbeitsspeicher anders organisiert wird, der Fehler mit dem nicht initialisierten Zeiger ist dann (manchmal) nicht sofort offensichtlich.
    Hast du einmal Codeguard eingeschaltet?

    <edit: sch... Fremdwörter>

    0
  • ?

    Hi SilentSurfer,
    danke für den Hinweis mit Codeguard - hatte ihn nicht eingeschaltet.
    Werd mich mal mit Codeguard beschaeftigen und schaun was sich rausfinden laesst. 🙂

    0
  • ?

    Hab mir Codeguard angesehen und ihn eingeschaltet.
    Leider tritt der Fehler schon auf bevor Codeguard etwas findet.

    Mit verwendeten RTL (Programm lauft laenger) werden Fehler im Code gefunden ..
    allerdings auch erst zu einem spaeteren Zeitpunkt
    (sobald Buttons gedrueckt werden, etc..).

    So wie ich das verstanden habe, muesste Codeguard nicht initialiserte Pointer finden?
    Wie kann sich ein nicht initialisierter Pointer zum Zeitpunkt des Programmstartes
    VOR aufruf der Main() bereits auswirken?

    ..hm.. wie gehe ich jetzt am besten vor um herauszufinden, was nicht stimmt? *gruebelgruebel*

    0
  • S

    Hi,
    Grundsätzlich kann die Codeguard auch nur Fehler anzeigen, wenn er gestartet ist.
    Dein Fehler scheint schon beim erstellen einiger Objekte aufzutreten.

    Leider habe ich nicht viel von deinem Quellcode gesehen, aber lass mich mal ein bisschen raten:
    Es sieht aus, als ob der Fehler in einer Log Klasse entsteht, die du geschrieben hast.
    Ein Objekt dieser Logklasse erstellst du bestimmt. (im Konstruktor der Form?)

    Greift vielleicht eine andere Klasse die du erstellst auf eine Logfunktion zu, bevor es ein Objekt der Log Klasse gibt?

    0
  • S

    Noch als Tip:
    Vor Main werden einige Objekte gebildet,
    also mal in den Konstruktoren deiner Klassen nachschauen, was da so passiert

    0
  • ?

    Danke, ich werde das überprüfen..

    0
  • D

    hm... hatte bis eben das Gleiche Problem und hab ewig gesucht.

    Er ist mir abgeschmiert, wenn ein globaler ofstream im Programm ist oder in einer Klasse, würde ich mal kontrollieren, wenn Problem nicht schon erledigt.
    Finde ich jetzt zwar seltsam, aber naja.

    0
  • ?

    dreaddy schrieb:

    hm... hatte bis eben das Gleiche Problem und hab ewig gesucht.

    Er ist mir abgeschmiert, wenn ein globaler ofstream im Programm ist oder in einer Klasse, würde ich mal kontrollieren, wenn Problem nicht schon erledigt.
    Finde ich jetzt zwar seltsam, aber naja.

    Ich kann nich so gut Deutsch scheiben, darum schreibe ich auf Englisch:
    I had the same problem as the topic-starter. When I removed 'dynamic RTL' from the linker options I got a access-violation at address 0, but when compiling with dynamic RTL there was no problem.
    I had a global ofstream for debugging, I removed it and now my program works again. Thanks for you help.

    0
  • B

    Das Problem tritt bei mir dann auf, wenn ich Projekt habe, welches mehrere Libs mit einbindet und die in unterschiedlichen Modi compiliert worden sind (mit und ohne dynamisch RTL). Wichtig ist hier, dass alle im Projekt verwendeteten Bibliotheken die gleichen Einstellungen nutzen.

    0
Anmelden zum Antworten