PDA

View Full Version : Application throws exceptions without debugger attached



landr0id
10th January 2012, 02:01
I recently started using Qt and up until now everything's ran very smooth. When I choose to debug my application from within Qt Creator (in either release or debug configuration), it runs just fine without any exceptions. When I only run my debug build of the application, I get no exceptions as well. Then, for some odd reason when I choose to run my release build of the application I get exceptions within my code, but I'm not understanding why I would get the exceptions only without the debugger attached, and without any #ifdef directives. When I run it and manually attach the debugger I have the same issue, yet directly debugging from within Qt Creator works.

I'm debugging on Windows 7, and my .pro file is as follows:


#-------------------------------------------------
#
# Project created by QtCreator 2011-12-30T11:32:37
#
#-------------------------------------------------

QT += core gui

TARGET = Up
TEMPLATE = app


SOURCES += main.cpp\
MainForm.cpp \
AboutForm.cpp

HEADERS += MainForm.h \
AboutForm.h

FORMS += MainForm.ui \
AboutForm.ui


QMAKE_CFLAGS_RELEASE += -Zi
QMAKE_CXXFLAGS_RELEASE += -Zi -g
QMAKE_LFLAGS_RELEASE += /DEBUG /OPT:REF


win32:CONFIG(release, debug|release): LIBS += -L$$PWD/../FATX-build-release/release/ -lFATX
else:win32:CONFIG(debug, debug|release): LIBS += -L$$PWD/../FATX-build-debug/debug/ -lFATX
else:unix:!symbian: LIBS += -L$$PWD/../FATX-build-debug/ -lFATX

release{
INCLUDEPATH += $$PWD/../FATX-build-release/release
DEPENDPATH += $$PWD/../FATX-build-release/release
}
debug{
INCLUDEPATH += $$PWD/../FATX-build-debug/debug
DEPENDPATH += $$PWD/../FATX-build-debug/debug
}

win32:CONFIG(release, debug|release): PRE_TARGETDEPS += $$PWD/../FATX-build-release/release/FATX.lib
else:win32:CONFIG(debug, debug|release): PRE_TARGETDEPS += $$PWD/../FATX-build-debug/debug/FATX.lib
else:unix:!symbian: PRE_TARGETDEPS += $$PWD/../FATX-build-debug/debug/libFATX.a

RESOURCES += \
MainForm.qrc


Any help at all is greatly appreciated! Thanks.

wysota
10th January 2012, 03:12
What "exceptions" exactly do you mean? Do you just want to say that your program crashes?

landr0id
10th January 2012, 03:48
What "exceptions" exactly do you mean? Do you just want to say that your program crashes?

Yes, sorry. I said "exceptions" because at one line I'll have an exception (e.g. what appears to be double freeing an array but isn't), comment that out get another exception that shouldn't happen. Basically random behavior which causes my application to crash, yes.

I also forgot to say in the OP, but I'm compiling with MSVCC

amleto
10th January 2012, 09:27
I think you should be showing the code around your exceptions, the exact error messages, and not your pro file.

When you run with a debugger, there is probably additional memory fencing, and it sounds like this is helping your bug(s) not be seen. From what you have sound, it sounds like your crash is repeatable, so that points to something that is NOT random.

landr0id
10th January 2012, 20:31
I think you should be showing the code around your exceptions, the exact error messages, and not your pro file.

When you run with a debugger, there is probably additional memory fencing, and it sounds like this is helping your bug(s) not be seen. From what you have sound, it sounds like your crash is repeatable, so that points to something that is NOT random.

Well, here's the call stack: http://nvsx.net/i/5a304.png

Code it breaks at:


Volume* SysExt = new Volume();
Volume* SysAux = new Volume();
Volume* Cache = new Volume();
Volume* Data = new Volume();

{snip}

if (DeviceStream->ReadUInt32() == Magic)
{
ValidVolumes.push_back(SysExt);
ValidVolumes.push_back(SysAux);
ValidVolumes.push_back(Cache);
ValidVolumes.push_back(Data);
}
else
{
Cache->Size = UsbSizes::CacheNoSystem;
ValidVolumes.push_back(Cache);
ValidVolumes.push_back(Data);
} // when it breaks, it breaks at this line

My structs:

struct Volume
{
string Name;
unsigned int Magic; // Partition magic
unsigned int SerialNumber; // Partition serial number
unsigned int SectorsPerCluster; // Number of sectors per cluster
unsigned int RootDirectoryCluster; // The cluster in which the root directory is located
UINT64 DataStart;
unsigned int Clusters; // Total number of clusters in the partition
BYTE EntrySize; // Size of a chainmap entry
UINT64 Offset; // Offset of the partition
UINT64 Size; // Size of the partition
UINT64 AllocationTableSize;
UINT64 ClusterSize;
unsigned int FatEntryShift;
Folder *Root;
};

struct Folder
{
std::vector<UINT32> ClusterChain;
Dirent Dirent;
std::vector<Folder*> CachedFolders;
std::vector<File*> CachedFiles;
bool FatxEntriesRead;
std::string FullPath;
Folder* Parent;
Volume* Volume;
};

struct File
{
std::vector<UINT32> ClusterChain;
Dirent Dirent;
std::string FullPath;
Folder* Parent;
};

Edit: forgot about the exception

(ad4.c50): Access violation - code c0000005 (first chance)
s
sException at 0x77da2073, code: 0xc0000005: write access violation at: 0x1, flags=0x0 in ntdll!RtlpLowFragHeapFree
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=27a83a05 ebx=0e1c0f1b ecx=0b081bff edx=00000b08 esi=017adf8e edi=0e1c0000
eip=77da2073 esp=0012cc28 ebp=0012cc5c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
ntdll!RtlpLowFragHeapFree+0xc5:
77da2073 8930 mov dword ptr [eax],esi ds:0023:27a83a05=????????

amleto
10th January 2012, 21:26
does your software take up a lot of memory?

do you use malloc/free and new delete?

how do you use those pointers in the struct? how do you clean up? where is ownership?

wysota
10th January 2012, 22:48
Write access violation usually means you have an uninitialized pointer somewhere that you are trying to access.

ChrisW67
11th January 2012, 00:04
... and if it is actually breaking in the code you displayed then I'd be looking closely at the value and validity of the "Cache" pointer used on line 17.

landr0id
11th January 2012, 01:08
does your software take up a lot of memory?

do you use malloc/free and new delete?

how do you use those pointers in the struct? how do you clean up? where is ownership?

No, not very much memory at all. I use new and delete, yes. The pointers in the struct aren't used in the scope in which the exception is thrown -- all I do is initialize (as shown at the top of my code), then where I inserted {snip} is code where I set some of the non-pointer fields in the Volume structure (Name, Offset, Size, etc.). Ownership is within the class that this function is called and cleanup is done when the class which created the structs is closed.


Write access violation usually means you have an uninitialized pointer somewhere that you are trying to access.
That's just it though -- I'm not even referencing anything illegally. If you look at the call stack (http://nvsx.net/i/5a304.png) I posted above, it breaks on vector::_Insert_n, but the vector in which I add the items in that scope isn't even of that element type (vector type = Volume, vector type which causes the exception to be thrown: File*)


... and if it is actually breaking in the code you displayed then I'd be looking closely at the value and validity of the "Cache" pointer used on line 17.
It breaks upon exiting the scope (or after adding the element to the vector, the line is misleading). The "Cache" pointer is valid.


Like I said, everything runs fine except when manually debugging (run>attach debugger) under release configuration. What could be causing this to happen under that condition, but not when choosing to debug straight out of Qt creator?

wysota
11th January 2012, 09:56
Unless some destructor of yours causes something to insert something else to the vector, I wouldn't trust the call stack. It could be you are trying to free an already freed region of memory or something like that. Maybe in debug mode the compiler resets the pointer to zero, causing the other free to simply ignore it. These are just guesses though. You could try just recompiling the whole project to see if the problem goes away, sometimes the (incremental?) linker messes things up.