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?
Related
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!
We have a standlone VC++ application and we added logging using the log4cxx0.10.0 version.
The application will initiate a thread (for some time consuming operation) and if it takes more than threshold time then the main thread will kill the thread using TerminateThread method. The child thread function also has some logging prints.Log4CXX configured with rolling file appender of 1 MB size of 5 backup copies.Logging is working fine in most of the scenarios. But in some scenarios main thread logging function call is hanging after killing the child thread and hence the entire application is in hanging state.
Subsequent instances of the application is also hanging. We took the full crash dumps of the application and analyzed using the WinDbg.
Here is the call stack of the application
**00 ntdll!NtWaitForSingleObject+0xa
01 ntdll!RtlpWaitOnCriticalSection+0xe8
02 ntdll!RtlEnterCriticalSection+0xd1
03 log4cxx!log4cxx::filter::DenyAllFilter::decide+0x194
04 log4cxx!log4cxx::helpers::synchronized::synchronized+0x31
05 log4cxx!log4cxx::Logger::callAppenders+0x81
06 log4cxx!log4cxx::Logger::forcedLog+0xe5**
07 Test!CXX_LOG(int LOG_TYPE = 0n2, char * format = 0x00000001`3f2a2ad8 "Main thread pint...")+0x463 [d:\test\saf\test.cpp # 2360]
08 test!TestFunction(int argc = 0n3, char ** argv = 0x00000001`3f2ae880, int level = 0n1)+0x586 [d:\test\saf\test.cpp # 1634]
09 test!main(int argc = 0n4, char ** argv = 0x00000000`00282920)+0x1820 [d:\test\saf\test.cpp # 2309]
0a test!__tmainCRTStartup(void)+0x13b [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c # 278]
0b kernel32!BaseThreadInitThunk+0xd
0c ntdll!RtlUserThreadStart+0x1d
and subsequent applications hangs for locking the file and call stack of the instance as follows
**ntdll!ZwLockFile+0xa
KERNELBASE!LockFileEx+0xb2
kernel32!LockFileEx+0x1b
log4cxx!log4cxx::filter::DenyAllFilter::decide+0x2a89
log4cxx!log4cxx::helpers::DatagramPacket::setData+0x559c
log4cxx!log4cxx::helpers::FileOutputStream::write+0x82
log4cxx!log4cxx::rolling::RollingFileAppenderSkeleton::getTriggeringPolicy+0x1ca
log4cxx!log4cxx::helpers::OutputStreamWriter::write+0xbe
log4cxx!log4cxx::WriterAppender::subAppend+0x7c
log4cxx!log4cxx::rolling::RollingFileAppenderSkeleton::subAppend+0xd0
log4cxx!log4cxx::WriterAppender::append+0x31
log4cxx!log4cxx::AppenderSkeleton::doAppend+0x293
log4cxx!log4cxx::helpers::AppenderAttachableImpl::appendLoopOnAppenders+0x40
log4cxx!log4cxx::Logger::callAppenders+0xa3
log4cxx!log4cxx::Logger::forcedLog+0xe5**
test!CXX_LOG(int LOG_TYPE = 0n2, char * format = 0x00000001`3f2a3868 "Starting the application")+0x463
test!main(int argc = 0n4, char ** argv = 0x00000000`00162920)+0x1806
test!__tmainCRTStartup(void)+0x13b
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x21
We have checked the function 'decide' and it has nothing to do with locking. it is just returning some constant value.I have read that LOG4CXX is thread safe. This issue is not occurring frequently and hence we didn't have the steps to reproduce in consistent way.
Is it anything needs to be addressed when we killing the child thread??
Redesign your application. TerminateThread is implicitly unsafe by its very nature because resources in use by the thread are not released. You just managed to terminate it while it was holding a lock, and now your main thread is trying to acquire that held lock. Find a different way to terminate the thread.
Here is the lock in that stack trace: https://apache.googlesource.com/log4cxx/+/e3db59080a3506f0ed23e98cbcb2be58f0b15a20/src/main/cpp/logger.cpp#93
I copied a FORTRAN IV program from a thesis, so it presumably worked at the time it was written. I compiled it with gfortran. When running, it stalls in an integration subroutine. I have tried easing off the residuals but to no avail. I am asking for help because (presuming no mistakes in code) gfortran might not like the archaic 66/IV code, and updating it is outside my abilities.
The program gets stuck by line 9, so I wonder if the DO loops are responsible. Note, lines 1 and 6 are unusual to me because ',1' has been added to the ends: e.g. =1,N,1.
I don't think it's necessary to show the FUNC subroutine called on line 5 but am happy to provide it if necessary.
If you need more detailed information I am happy to provide it.
00000001 13 DO 22 TDP=QDP,7,1
00000002 TD=TDP-1
00000003 X=X0+H0
00000004 IF(TD.EQ.QD) GOTO 15
00000005 CALL FUNC(N,DY,X,Y,J)
00000006 15 DO 21 RD=1,N,1
00000007 GOTO (120,121,122,123,124,125,126),TDP
00000008 120 RK(5*N*RD)=Y(RD)
00000009 GOTO 21
00000010 121 RK(RD)=HD*DY(RD)
00000011 H0=0.5*HD
00000012 F0=0.5*RK(RD)
00000013 GOTO 20
00000014 122 RK(N+RD)=HD*DY(RD)
00000015 F0=0.25*(RK(RD)+RK(N+RD))
00000016 GOTO 20
00000017 123 RK(2*N+RD)=HD*DY(RD)
00000018 H0=HD
00000019 F0=-RK(N+RD)+2.*RK(2*N+RD)
00000020 GOTO 20
00000021 124 RK(3*N+RD)=HD*DY(RD)
00000022 H0=0.66666666667*HD
00000023 F0=(7.*RK(RD)+10.*RK(N+RD)+RK(3*N+RD))/27.
00000024 GOTO 20
00000025 125 RK(4*N+RD)=HD*DY(RD)
00000026 H0=0.2*HD
00000027 F0=(28.*RK(RD)-125.*RK(N+RD)+546.*RK(2*N+RD)+54.*RK(3*N+RD)-
00000028 1378.*RK(4*N+RD))/625.
00000029 GOTO 20
00000030 126 RK(6*N+RD)=HD*DY(RD)
00000031 F0=0.1666666667*(RK(RD)+4.*RK(2*N+RD)+RK(3*N+RD))
00000032 X=X0+HD
00000033 ER=(-42.*RK(RD)-224.*RK(2*N+RD)-21.*RK(3*N+RD)+162.*RK(4*N+RD)
00000034 1+125.*RK(6*N+RD))/67.2
00000035 YN=RK(5*N+RD)+F0
00000036 IF(ABS(YN).LT.1E-8) YN=1
00000037 ER=ABS(ER/YN)
00000038 IF(ER.GT.G0) GOTO 115
00000039 IF(ED.GT.ER) GOTO 20
00000040 QD=-1
00000041 20 Y(RD)=RK(5*N+RD)+F0
00000042 21 CONTINUE
00000043 22 CONTINUE
It's difficult to be certain (not entirely sure your snippet exactly matches your source file) but your problem might arise from an old FORTRAN gotcha -- a 0 in column 6 is (or rather was) treated as a blank. Any other (non-blank) character in column 6 is/was treated as a continuation indicator, but not the 0.
Not all f66 compilers adhered to the convention of executing a loop at least once, but it was a common (non-portable) assumption.
Similarly, the assumption of all static variables was not a portable one, but can be implemented by adding a SAVE statement, beginning with f77. A further assumption that SAVE variables will be zero-initialized is even more non-portable, but most compilers have an option to implement that.
If an attempt is being made to resurrect old code, it is probably worth while to get it working before modernizing it incrementally so as to make it more self-documenting. The computed goto looks like a relatively sane one which could be replaced by select case, at a possible expense of optimization. Here the recent uses of the term "modernization" become contradictory.
The ,1 bits are to get the compiler to spot the errors. It is quite common to do the following
DO 10 I = 1.7
That is perfectly legal since spaces are allowed in variable names. If you wish to avoid that, then put in the extra number. The following will generate errors
DO 10 I = 1.7,1
DO 10 I = 1,7.1
DO 10 I = 1.7.1
Re the program getting struck, try puting a continuation line between labels 21 and 22. The if-goto is the same as if-not-then in the later versions of Fortran and the computed goto is the same as a select statement. You don't need to recode it: there is nothing wrong with it other than youngsters getting confused whenever they see goto. All you need to do is indent it and it becomes obvious. So what you will have is
DO 22 TDP = QDP, 7, 1
...
DO 23 RD = 1, N, 1
GOTO (...) TDP
...
GOTO 21
...
GOTO 20
...
GOTO 20
...
20 CONTINUE
Y(RD) = ...
21 CONTINUE
23 CONTINUE
22 CONTINUE
You will probably end up with far more code if you try recoding it. It will look exactly the same except that gotos have been replaced by other words. It is possible that the compiler is generating the wrong code so just help it by putting a few dummy (CONTINUE) statements.
I have notice pretty bizare bahaviour of gdb when debugging a straight block of code.
I ran gdb normally with following commands.
gdb ./exe
break main
run
next
then [enter] a few times.
What I got a as result was
35 world.generations(generations);
(gdb)
36 world.popSize(100);
(gdb)
37 world.eliteSize(5);
(gdb)
41 world.setEvaluationFnc( eval );
(gdb)
37 world.eliteSize(5);
(gdb)
39 world.pXOver(0.9);
(gdb)
38 world.pMut(0.9);
(gdb)
41 world.setEvaluationFnc( eval );
(gdb)
There is absolutely no reason to run over those lines twice. I do not understand this behaviour. The code looks as follows:
(gdb) list 39
34 SimpleGA<MySpecimen> world;
35 world.generations(generations);
36 world.popSize(100);
37 world.eliteSize(5);
38 world.pMut(0.9);
39 world.pXOver(0.9);
40
41 world.setEvaluationFnc( eval );
42
43 world.setErrorSink(stderrSink);
I am not sure if i should disregard it or there something wicked going on in my code. The app uses OpenMP and is compiled to use it. However, the info thread says there is only one thread running. Also, everything seems to give proper results, but even executed twice there should be no problems as those are mostly some plain setters.
Did anyone seen something like this or have any hints where to investigate ? I failed on my own =).
Thanks for hints,
luk32.
Most likely the compiler rearranging the code. I suppose the "new" order still works correctly?
If possible, try to debug with optimizations turned off; that increases the likelyhood of the executable staying closer to the source code.
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.