I have problem with debugging Qt5.4 application on win7. It gives following error by message-Box (without debug mode, the application runs without any problem):
The inferior stopped because it triggered an exception.
Stopped in thread 18 by: Exception at 0x7718c42d, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance).
call stack:
0 RaiseException KERNELBASE 0x7718c42d
1 DllGetClassObject vsfilter 0x3a6aca71
2 DirectVobSub vsfilter 0x3a64fa11
3 vsfilter 0x3a632c0b
4 DllGetClassObject vsfilter 0x3a6c90bc
5 vsfilter 0x3a636da0
6 CSTInnerUnknown::AddRef sync.cxx 225 0x753deddf
7 DllGetClassObject vsfilter 0x3a6aab2f
8 CRWLock::AcquireReaderLock rwlock_ole32.cxx 3099 0x753da471
9 DllGetClassObject vsfilter 0x3a6aab2f
10 DllGetClassObject vsfilter 0x3a6ce866
11 DllGetClassObject vsfilter 0x3a6cbd4b
12 DispatchMessageWorker USER32 0x759b77c4
13 wcscpy_s USER32 0x75a1a61d
14 _RtlUserThreadStart ntdll 0x77919f45
It might be a little bit late, but I had the same error.
See, I don't see your code, so I cant say what your problem was exactly but I can say what solved mine:
I had a Gaussian-filter of open-cv running, which was clearing my picture from noise. It had the size of 3x3. As soon as I adjusted the size to 10x10 for testing, I got the same exception.
So maybe you have also a to big filter or something. To say it exactly I would need more code example.
But anyway this maybe helps someone else!
Related
Take a look at this amazing call stack:
1 FNFolderTreeDir::refreshSubDir fnfoldertreedir.cpp 42 0x13faa3287
2 FNFolderTreeDriveRootHive::processDirLoaded fnfoldertreedriveroothive.cpp 25 0x13faa2175
3 FNFolderTreeDriveRootHive::qt_static_metacall moc_fnfoldertreedriveroothive.cpp 74 0x13faa5df5
4 QMetaObject::activate qobject.cpp 3742 0x51744922
... lots of Qt internals here ...
33 _purecall purevirt.c 58 0x7feedc2d0cc
34 FNFolderTreeNode::purge fnfoldertreenode.cpp 28 0x13fa9cf53
35 FNFolderTreeNode::~FNFolderTreeNode fnfoldertreenode.cpp 23 0x13fa9ceeb
FNFolderTreeDriveRootHive::processDirLoaded is a slot connected to the QFileSystemModel::directoryLoaded signal. So, what happened here is that my destructor was happily doing some internal cleanup when Qt interrupted it at a seemingly random point to call a slot to refresh the very object that has been reduced to the base class already. Of course, it crashed.
A couple of questions, if I may:
How is this even possible? I suspect that Qt used either QAbstractItemModel::beginRemoveColumns or endRemoveRows to dispatch the callback - I call them both in FNFolderTreeNode::purge. Should it not be doing this in main loop only?
How can I prevent this behaviour? Could try disconnecting the slot first thing in the destructor, but where is the guarantee that it will not be interrupted too?
I use libcurl for FTP works and it works fine but if left idle for some time it just crashes. Here is the backtrace which despite reading it for some time I cannot make sense of what is wrong. The trace does not show where in my functions crash originates and so am left orphan here by debugger. I use threads if that add value
Compiler is GCC 4.7 on Linux
0 0x00007fff8e09b524 addbyter /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 914
1 0x00007fff8e09a32f dprintf_formatf /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 572
2 0x00007fff8e09b5a4 curl_mvsnprintf /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 932
3 0x00007fff8e089510 Curl_failf /home/stefano/Desktop/myproject/curl-7.33.0/lib/sendf.c 152
4 0x00007fff8e07dbf4 Curl_resolv_timeout /home/stefano/Desktop/myproject/curl-7.33.0/lib/hostip.c 618
5 0x00007fff78012bf8 ??
6 0x000000c300000016 ??
7 0x00007fff8e0d3604 ??
8 0x0000000000000002 ??
9 0x00000000001b7740 ??
10 0x0000000000000000 ??
UPDATE 1
Run it again under debugger and met a crash at the line
FILE *fd;
fd = fopen(files[i].c_str(), "rb"); //<---here goes the crash!
files[i].c_str() is supposed to give const* char from wxString
The new BT is
0 0x00007fff8e08952a Curl_failf /home/stefano/Desktop/myproject/curl-7.33.0/lib/sendf.c 154
1 0x00007fff8e07dbf4 Curl_resolv_timeout /home/stefano/Desktop/myproject/curl-7.33.0/lib/hostip.c 618
2 0x00007fff780158c8 ??
3 0x00000000001b7730 ??
4 0x00007fff78009808 ??
5 0x00007fff78015e79 ??
6 0x00007fff78009808 ??
7 0x00007fff8c8a04a0 ??
8 0x00007fff8e0c84ca ftp_multi_statemach /home/stefano/Desktop/myproject/curl-7.33.0/lib/ftp.c 3113
Such error can be caused if you're using curl in non-main thread. When curl can't resolve dns entry, it sends a signal (by default) to interrupt a thread by timeout. Signals are not thread safe and can cause a crash. You should compile libcurl with --enable-threaded-resolver or with support of c-ares.
Also for me it was useful to disable signals at all
curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1)
I have this very strange problem with my code at runtime when I'm running it in parallel with mpi:
*** glibc detected *** ./QuadTreeConstruction: munmap_chunk(): invalid pointer: 0x0000000001fbf180 ***
======= Backtrace: =========
/lib/libc.so.6(+0x776d6)[0x7f38763156d6]
./QuadTreeConstruction(_ZN9__gnu_cxx13new_allocatorImE10deallocateEPmm+0x20)[0x423f04]
./QuadTreeConstruction(_ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv+0x50)[0x423e72]
./QuadTreeConstruction(_ZNSt13_Bvector_baseISaIbEED2Ev+0x1b)[0x423c79]
./QuadTreeConstruction(_ZNSt6vectorIbSaIbEED1Ev+0x18)[0x4237d2]
./QuadTreeConstruction(_Z22findLocalandGhostCellsRK8QuadTreeRK6ArrayVIiES5_iRS3_S6_+0x849)[0x41dbbd]
./QuadTreeConstruction(main+0xa32)[0x41ca49]
/lib/libc.so.6(__libc_start_main+0xfe)[0x7f38762bcd8e]
./QuadTreeConstruction[0x41b029]
My code is valgrind clean up to the some errors that are internal to mpi library (I use OpenMpi and I have seen them many times before but they have never been an issue; see http://www.open-mpi.org/faq/?category=debugging#valgrind_clean). I do not have any problem when I am running in serial.
I have been able to track down the problem to a SIGABORT system call using gdb and here is the stack when the code breaks:
0 raise raise.c 64 0x7f4bd8655ba5
1 abort abort.c 92 0x7f4bd86596b0
2 __libc_message libc_fatal.c 189 0x7f4bd868f65b
3 malloc_printerr malloc.c 6283 0x7f4bd86996d6
4 __gnu_cxx::new_allocator<unsigned long>::deallocate new_allocator.h 95 0x423f04
5 std::_Bvector_base<std::allocator<bool> >::_M_deallocate stl_bvector.h 444 0x423e72
6 std::_Bvector_base<std::allocator<bool> >::~_Bvector_base stl_bvector.h 430 0x423c79
7 std::vector<bool, std::allocator<bool> >::~vector stl_bvector.h 547 0x4237d2
8 findLocalandGhostCells mpi_partition.cpp 249 0x41dbbd
9 main mpi_partition.cpp 111 0x41ca49
This sounds like a memory corruption but I have absolutely no clue what is causing it. Basically the code breaks inside a function that looks something like this:
void findLocalandGhostCells(){
std::vector<bool> foo(fooSize,false);
// do stuff with foo; nothing crazy -- I promise
return;
}
Anyone has any idea what I should be doing now? :(
If you are quite sure that vector operation itself is correct and non-crazy, try tracing the members of your vector step by step. It's possible that some of your other operations corrupted your memory blocks of vector. For example, a memcpy that invaded memory of vector.
I noticed a large amount of page faults in my Qt application. I reproduced it by resizing a docking widget (with a widget tree of dozens of widgets underneath) for 2 seconds and traced that operation using AQTime. I get 2000 page faults for this operation. Why is that?
Using Qt 4.5.3 on Windows XP 32 bit
UPDATE: They're soft page faults
UPDATE2: I created a ui in Qt Designer with 1 combobox with 2 items in it. If I preview this, I get 200 page faults each time I click the combobox to select one of these items.
Parents
Code Type Routine Name Faults Faults with Children Hit Count
x86 qt_memfill_template<unsigned int,unsigned int> 2416 2416 5160
x86 qt_memfill<unsigned int> 2416 2416 5160
x86 qt_rectfill<unsigned int> 0 2416 5160
x86 qt_rectfill_template<unsigned int> 0 2416 63
x86 qt_rectfill_quint32 3 2419 63
x86 fillRect_normalized 1 2420 63
x86 QRasterPaintEngine::fillRect 3 2423 63
x86 QRasterPaintEngine::fillRect 1 2424 63
x86 QPainter::fillRect 1 2427 63
x86 fillRegion 0 2427 15
x86 QWidgetPrivate::paintBackground 2 2430 12
x86 QWidgetPrivate::drawWidget 0 2430 12
x86 QWidgetBackingStore::sync 2 2596 12
x86 QWidgetPrivate::syncBackingStore 4 2610 12
x86 QETWidget::translateConfigEvent 0 2479 6
x86 QtWndProc 0 2495 12
Most likely, Qt allocated a new bitmap to hold the widget's appearance, and the system satisfied this request by allocating new pages to the process. Upon the first write to these pages, a soft page fault occurs, and the actual pages are mapped into the process address space. This could potentially be avoided by caching the bitmap between repaint calls; however, when resizing, the size of the bitmap needed will change, and so this optimization no longer applies; the bitmap must be reallocated (causing soft page faults) each time the dimensions change.
Is this actually having a performance impact, though?
I have an application which makes use of winsock.
I/O part is handled on an other thread.
And I am using blocking select method for sockets.
But the point is that after 5-6 hours,my application gives 0xC00000FD exception, at the line of select function.
As far as I know, this exception occurs when there is recursion, or very large local variables. But neither of them is the case for me.
So do you have any idea why am I getting this exception?
Or any ideas to discover what actually causes exception?
many thanks
EDIT 2:
Dear All, I am very sorry but since reproducing the case takes long time, I just realized that this has not solved the problem.
Everything seems ok when stack overflow exception occurs at the line of select function.
I mean it is a server socket with a one client connected. So there is 2 socket in rset and 1 in wset. After selecting, I am checking all ready sockets and making required, read,write,accept. Timeout is 250 ms. Do you think can this be the problem? I don't want this function to be blocking so it is not null. But what will be the exact difference if I use {0,0}
An important hint is:
Same code was working without any problem, when client socket wasn't sending any data.
But when I started sending some data from client to server this problem occured.
I am sure that there is no problem with FD_SETs and FD_CLRs, I mean when client was not sending only 1(server) socket was in rset and 1(client) was in wset.
Anyway I had a look a lot of samples, but it seems that there is not a difference.
Please see local variables screenshot below(I have deleted name of executable, since it is a commercial product)
http://img192.imageshack.us/img192/1948/stackoverflow.jpg
And here is the call stack:
ntdll.dll!7c90df3a()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
mswsock.dll!71a53c9c()
ntdll.dll!7c90d26c()
mswsock.dll!71a55f9f()
mswsock.dll!71a55974()
ws2_32.dll!71ab314f()
xyz.exe!vm_socket_select(vm_socket * hds=0x04c1fb84, int nhd=1, int masks=7) Line 230 + 0x1b bytes C
xyz.exe!ND::nd_socket::SocketThreadProc() Line 173 + 0x12 bytes C++
xyz.exe!ND::nd_socket::ThreadRoutineStarter(void * u=0x07d63f90) Line 332 C++
xyz.exe!_callthreadstartex() Line 348 + 0x6 bytes C
xyz.exe!_threadstartex(void * ptd=0x011a3ce8) Line 326 + 0x5 bytes C
kernel32.dll!7c80b713()
I am waiting for any advice.
Many thanks
Have you tried stopping your program in a debugger after some time running? Then take a look at the stack it might give you a hint.
Recursion doesn't mean one of your functions call itself endlessly, it can't be more tricky and involve several layers before it comes back where it started.