Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 516.0x374]
0x619bcdcd in BackgroundThread::Entry (this=0x1e87524)
at C:/DevTools/CBSource/src/include/backgroundthread.h:170
170 delete job;
Current language: auto; currently c++
(gdb) bt full
#0 0x619bcdcd in BackgroundThread::Entry (this=0x1e87524)
at C:/DevTools/CBSource/src/include/backgroundthread.h:170
job = (AbstractJob *) 0x1e8e050
#1 0x6ccff82b in wxmsw28u_gcc_cb!_ZN11wxSemaphore7TryWaitEv ()
from C:\DevTools\CBSource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#2 0x6ccff93d in wxmsw28u_gcc_cb!_ZN11wxSemaphore7TryWaitEv ()
from C:\DevTools\CBSource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#3 0x77c3a3b0 in msvcrt!_endthreadex () from C:\WINDOWS\system32\msvcrt.dll
No symbol table info available.
#4 0x01e87524 in ?? ()
No symbol table info available.
#5 0x7c90ee18 in strchr () from C:\WINDOWS\system32\ntdll.dll
No symbol table info available.
#6 0x7c96d8a8 in ntdll!RtlpNtMakeTemporaryKey ()
from C:\WINDOWS\system32\ntdll.dll
No symbol table info available.
#7 0x01e878d8 in ?? ()
No symbol table info available.
#8 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Since Rev 4407, C::B fails to start on Windows XP SP2. Running under GDB produces the following backtrace.No - runs fine here, both: stripped and debug version. Did you try a clean rebuild (or tried removing the PCH files before)?
Can anyone confirm this??
No - runs fine here, both: stripped and debug version. Did you try a clean rebuild (or tried removing the PCH files before)?
But, as we had discussed, this issue was present in my Lab's PC. I'll try there again on Monday by cleaning the PCH files manually and then rebuilding it.What could have happened: In case you copied the modified header file from the VM it may have had a date older then the PCH file. In that case the PCH file isn't re-compiled and thus points to a wrong interface. You might simple load/save the modified header files in question so that GCC will re-compiled the SDK PCH itself.
Apologies!It's funny how code which is not used at all should cause a crash, but alright... I'm not going to revert-revert again, that's it for me then.
I have completely re-compiled C::B from scratch (for various reasons). That means removed all object, libs and PCH files before. The new version (4410) crashes immediately on startup. The crash-log points to BackgoundThread, too. I have manually reverted 4407 (the revert of Thomas) and now it's working again.
So Thomas: In case you read this: We are two now having real issues after the revert of yours.
With regards, Morten.
Apologies!It's funny how code which is not used at all should cause a crash, but alright... I'm not going to revert-revert again, that's it for me then.
I have completely re-compiled C::B from scratch (for various reasons). That means removed all object, libs and PCH files before. The new version (4410) crashes immediately on startup. The crash-log points to BackgoundThread, too. I have manually reverted 4407 (the revert of Thomas) and now it's working again.
So Thomas: In case you read this: We are two now having real issues after the revert of yours.
With regards, Morten.
Index: src/include/backgroundthread.h
===================================================================
--- src/include/backgroundthread.h (revision 4410)
+++ src/include/backgroundthread.h (working copy)
@@ -1,7 +1,7 @@
#ifndef BACKGROUNDTHREAD_H
#define BACKGROUNDTHREAD_H
-#include "sdk_precomp.h"
+//#include "sdk_precomp.h"
#include "safedelete.h"
#undef new
It's funny how code which is not used at all should cause a crash, but alright... I'm not going to revert-revert again, that's it for me then.Well... why does the crash log point to this then?! Very strange...!? :shock:
Maybe you could tell us for what reason exactly you reverted whatever you reverted?The reason is simple: Rick reverted my code because he did not understand it. The extra code was meant to provide a way to cancel jobs in a mostly safe way (mostly, because if you delete from two different threads, a race condition can occur). As no code currently calls Delete(), I don't see how it could affect anything, to be honest (unless you mix pre-4110 plugins with a post-4110 application, or something like that).
However, if this causes so much trouble, then just screw it... revert the modifications, and leave it :)
We'll not have the ability to abort jobs then, but so what...
Honestly, I'm not in favour of a revert.Me not either.
In multithreaded apps, random or "stochastic" symptoms indicate multithreading problems 90% of the time.Maybe, but this would not explain why it crashes at home 100% and here at work 0%.
Maybe, but this would not explain why it crashes at home 100% and here at work 0%.Certainly it could -- your home PC might be moving fast enough to (for example) slip into a race condition before a semaphore in another thread gets signaled; or it might be slow enough that (for example) a thread that's waiting for data mistakenly decides to act on it before it's received it. The work PC, on the other hand, follows the expected path because it's not too fast or not too slow.
I've tried to analyze the Abstractjob code, but it's too complicated for me to understand the program flow. I don't even know if the ORIGINAL code is correct! :?You know, Rick... the original code worked fine for 10 months before that... :)
I'll leave it to you to figure out why.Biplab and I already figured out some possible crash candidates under such circumstances... ;-)
I'll leave it to you to figure out why.Biplab and I already figured out some possible crash candidates under such circumstances... ;-)