[C/C++/Qt/VS] R6025 Error / Heapcrash

cwriter

Erfahrenes Mitglied
Hallo Welt

Ich bin auf eines dieser merkwürdigen Probleme gestossen, die erst auftreten, wenn man das Programm ohne angehängten Debugger ausführt: Dann nämlich haut mir die Visual C++ 2013 Runtime den Fehler R6025 um die Ohren: Pure Virtual Function Call
Ein bisschen geärgert hat mich das schon, doch ich las auf der msdn-page, dass man ganz einfach die Funktion int _purecall() überschreiben könne. Das habe ich gemacht, geändert hat es nix.
Also einfach mal das Programm ohne Debugger gestartet und dann erst den Debugger drangeklatscht: Zeile des Fehlers gefunden, der allerdings kein Pure Virtual Call Error sein kann, sondern allerhöchstens ein Memory Leak.
Seltsam, dachte ich, doch irgendwie könnte ich das ja schon finden. Tja. Leider nutze ich Qt 5, welches mir als Error in der cmd folgende Nachricht liefert:
Code:
QGraphicsScene::sendEvent: item 0x3a17e38's scene (0x3a523e0) is different from
this scene (0xfbee08)
Bei der abstürzenden Zeile handelt es sich um ein QGraphicsScene::addItem(QGraphicsItem* item) call.

Nun: Wie kann ich den Fehler finden? Es kann sich nicht um ein Nullpointerproblem handeln, da explizit darauf geprüft wird. Dass das Item eine andere Scene hat, ist eigentlich unmöglich, da im ganzen Programm nur eine Scene existiert.
Wie gesagt ist der Erfolg der Operation massgeblich davon abhängig, ob mit angehängtem Debugger ausgeführt wird oder nicht. Das würde auf uninitialized variables hinweisen, doch diese Möglichkeit habe ich mehrfach überprüft.
Den Code würde ich gerne anhängen, er ist allerdings so umfangreich, dass ich mal davon absehe.

Gruss
cwriter
 
Hi,

wenn es nicht-initialisierte Variablen nicht sein können, tippe ich auf Über-/Unterlauf eines Puffers. Bei Variablen auf dem Stack wird das noch recht einfach zu finden sein. Viele Compiler bieten einen Stack-Protector an. Damit würde ich anfangen.

EDIT: Habe gerade gelesen, dass bei MSVC die Stack-Protection standard-mäßig an ist. Nur wenn /GS- als Compiler-Flag gesetzt wird, wird die Protection deaktiviert. Müsste dann also schon mutwillig passieren. Dann scheitet das aus. Bleibt noch Heap-Over- /Underflow.
 
Zuletzt bearbeitet:
Hallo

Danke für die schnelle Antwort. Ich konnte nicht so schnell antworten, da ich zuerst meine Inline-ASM-Eskapaden für die Problemursache hielt. Antwort: Sind sie nicht. Vielleicht waren sie aber der Grund für den Absturz des Doktor Memory. Ich werde ihn morgen wieder auf Visite schicken.

Da das Programm mehrere Allokationen pro Sekunde ausführt, weiss ich allerdings nicht, warum das Programm ausgerechnet bei einer Qt-Funktion abstürzt (die relativ selten ausgeführt wird).

Könnte es daran liegen, dass Qt auf msvc2012 basiert, aber in einem msvc2013-Programm genutzt wird?

Gruss
cwriter
 
Aus Übersichtsgründen mache ich mal einen Doppelpost:
Auch beim Dr. Memory crasht das Programm fröhlich vor sich hin:
Code:
<Application D:\Users\cwriter\Dropbox\Maturarbeit\Segno\MainWindow - Drawing_WRON
G!\MainWindow\MainWindow.exe (10016).  Platform exception at PC 0x7106a186.  Ple
ase report this.  Program aborted.
0xc0000005 0x00000000 0x7106a186 0x7106a186 0x00000001 0x00000000
Base: 0x71000000
Registers: eax=0x710d4888 ebx=0x00000000 ecx=0x00000075 edx=0x00000001
        esi=0x1a65ef0c edi=0x1a65ef0c esp=0x1821edc0 ebp=0x00000000
        eflags=0x00010246
version 4.2.2635, custom build
-no_dynamic_options -disasm_mask 8 -logdir 'C:\Users\cwriter\AppData\Roaming\Dr.
Memory\dynamorio' -client_lib 'D:\Program Files (x86)\Dr. Memory\bin\release\drm
emorylib.dll;0;-logdir `C:\Users\cwriter\AppData\Roaming\Dr. Memory` -symcache_di
r `C:\Users\cwriter\AppData\Roaming\Dr. Memory\symcache` -lib_blacklist C:\WINDOW
S*.d**** -resfile 10016 ' -code_api -probe_api -stack_size 56K ->
Titel des Fensters: DynamoRIO Notice: [Programmpfad].

Also versuchte ich es mir dem CRT-Debug-Dingens: http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

Hier definiere ich zwar _CRTDBG_MAP_ALLOC in der main.cpp-Datei, doch das nützt nix: Die Zeilennummern/Dateinamen werden nicht dargestellt.
Wenn ich das _CRTDBG_MAP_ALLOC in die main.h-Datei schmeisse, kriege ich einen Haufen Fehler:
Und zwar _alle_ in den Qt-Dateien wie z.B. qlist.h.
Also mal schnell am Ende der Datei eingefügt, doch dann kriege ich das ganze wieder ohne Dateinamen:
Code:
Detected memory leaks!
Dumping objects ->
{851} normal block at 0x02304AA8, 8 bytes long.
 Data: <     L0 > F0 85 1C 00 B8 4C 30 02 
{850} normal block at 0x022FF140, 8 bytes long.
 Data: <     G0 > F0 85 1C 00 98 47 30 02 
{849} normal block at 0x022FEC00, 8 bytes long.
 Data: <      / > F0 85 1C 00 10 EE 2F 02 
{848} normal block at 0x022FE740, 8 bytes long.
 Data: <      / > F0 85 1C 00 E8 E7 2F 02 
{847} normal block at 0x02304670, 24 bytes long.
 Data: <,     /         > 2C 86 1C 00 C0 E2 2F 02 08 87 1C 00 00 00 CD CD 
{846} normal block at 0x02304258, 8 bytes long.
 Data: <  ,   / > 18 EB 2C 02 F0 F6 2F 02 
{834} normal block at 0x022FFBA0, 10 bytes long.
 Data: <NoteInput > 4E 6F 74 65 49 6E 70 75 74 00 
{833} normal block at 0x022FFA68, 8 bytes long.
 Data: <      / > F0 85 1C 00 B0 FA 2F 02
Einzig NoteInput könnte stimmen, aber ohne Zeilennummern ist das sch...lecht.

Wie kriege ich Qt dazu, mit dem Rumbocken aufzuhören?

Gruss
cwriter
 
Zuletzt bearbeitet:
vielleicht sind hier einige sinnvolle Lösungsansätze dabei ?
https://www.google.de/#q=R6025

Ist das eine Frage oder eine Aussage?
Ich habe schon nach einer Lösung gesucht, bevor ich hier gefragt habe.
Bei R6025 als Suchterm ist das Problem, dass auch Userlevel-Probleme dabei sind, die mir nix helfen.
Da Qt sehr stark auf Virtual Functions setzt, halte ich das für die wahrscheinlichste Problemursache. Nur wird sich der Fehler wohl von meinem Programm in die Qt-DLLs fortpflanzen, doch solange Qt so doof war, eine eigene Funktion "realloc" zu nennen, welche dann überschrieben wird, kann ich den Fehler nicht finden.

Und das ist das eigentliche Problem.
Gruss
cwriter
 
Ok, ok, ich nehme die Hälfte zurück:
- Der in der MSDN beschriebene Weg funktioniert durchaus, allerdings nur eingeschränkt: Wenn jede einzelne Codedatei die Anweisung
C:
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#ifndef DBG_NEW
#define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
#define new DBG_NEW
#endif
#endif  // _DEBUG
bekommt.
Dafür nimmt es die Löschvorgänge, die Qt übernimmt, nicht wahr (so z.B. QGraphicsScene::clear()).
- Das mit den uninitialisierten Variabeln: Nunja. Uninitialisiert waren sie nicht.
C:
char* mem = initialize();
if(mem == NULL)
{
    //Error
}
if(aConditionIsNotMet(mem))
{
    
    char* mem2 = initialize2();
    //Errorhandling
    if(anotherConditionIsNotMet(mem2))
    {
         free(mem2);
         mem2 = NULL;
         char* mem2 = initialize3();    //Error: Scoping
         mem2 = initialize3();
         //Errorhandling
    }
    mem = mem2;
}
War wohl gerade ziemlich beduselt, als ich das so sorgfältig kopiert habe. *schäm*
(Das ist umgeformter Code, im eigentlichen Code würde Qt dann so ein NULL-Objekt zur Scene hinzufügen -> Function pointer operation of NULL-object -> pure virtual function call...

Was ich nicht zurücknehme, ist , dass Dr. Memory eine hübsche Bruchlandung hinlegt.
Aber das ist mir jetzt auch egal :D

Vielen Dank für die Bemühungen!
cwriter
 

Neue Beiträge

Zurück