Author Topic: C::B fails to start on Windows (Rev 4407) (Read 20181 times)

Biplab · « **on:** August 24, 2007, 12:30:18 pm »

Since Rev 4407, C::B fails to start on Windows XP SP2. Running under GDB produces the following backtrace.

Quote

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)

It seems that the changes made in rev 4407 broke some thing.

Can anyone confirm this??

Best Regards,

Biplab

MortenMacFly · « **Reply #1 on:** August 24, 2007, 12:56:17 pm »

Quote from: Biplab on August 24, 2007, 12:30:18 pm

Since Rev 4407, C::B fails to start on Windows XP SP2. Running under GDB produces the following backtrace.
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)?

Biplab · « **Reply #2 on:** August 25, 2007, 06:43:16 am »

Quote from: MortenMacFly on August 24, 2007, 12:56:17 pm

No - runs fine here, both: stripped and debug version. Did you try a clean rebuild (or tried removing the PCH files before)?

Now it runs fine (even with my Unicode patch). I removed the PCH files manually here and then recompiled. Thanks for the tip.

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.

MortenMacFly · « **Reply #3 on:** August 25, 2007, 07:48:12 am »

Quote from: Biplab on August 25, 2007, 06:43:16 am

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.

MortenMacFly · « **Reply #4 on:** August 25, 2007, 09:55:02 pm »

Apologies!
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.

stahta01 · « **Reply #5 on:** August 25, 2007, 10:11:03 pm »

Thanks for confirming the issue, I have been having issues too. But, I just re-installed windows on a new Hard-Drive and was blaming the issue on that.

Tim S

thomas · « **Reply #6 on:** August 25, 2007, 10:57:29 pm »

Quote from: MortenMacFly on August 25, 2007, 09:55:02 pm

Apologies!
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.

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.

Biplab · « **Reply #7 on:** August 26, 2007, 06:35:16 am »

Quote from: thomas on August 25, 2007, 10:57:29 pm

Quote from: MortenMacFly on August 25, 2007, 09:55:02 pm
Apologies!
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.
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.

Strangely as I posted earlier it works for me on my Laptop. But my code is not exactly from SVN and it contains Unicode patch (v3+) (Thomas and Morten know this). I am totally confused why it's working in some PC and not in others ?? :? :roll:

BTW, has anyone of you tried the following patch?? A PCH header should not be included in a header file.

Code

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

MortenMacFly · « **Reply #8 on:** August 26, 2007, 10:02:21 am »

Quote from: thomas on August 25, 2007, 10:57:29 pm

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?

thomas · « **Reply #9 on:** August 26, 2007, 04:03:00 pm »

Quote from: MortenMacFly on August 26, 2007, 10:02:21 am

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).

But hey, if you think that it causes a problem, then just revert it again, I don't mind. Don't be afraid, I'll not re-revert it.

Biplab · « **Reply #10 on:** August 27, 2007, 12:20:34 pm »

Now this issue is really strange. On my PC in Lab, it fails to start. But same works on my Laptop. Both of them are unicode patched.I've tried it today by cleaning all object files, pch files. But I'm still in a fix over why it works on one PC and doesn't work on another. :?

thomas · « **Reply #11 on:** August 27, 2007, 01:13:02 pm »

Well, like I said, the modified code is not executed at all under normal conditions.

The extra code only runs if the boolean variable deleted is true. It is initialised to false in the constructor, and it can only legally become true if the Delete() function is called (which obviously is not the case, otherwise you could not build Code::Blocks prior to the re-revert, it would yield undefined symbols).

Thus, it is my assumption that the "bug" comes simply from mixing old and new components. Old code would not know about that data member and would not have a constructor that initialises it, obviously. Thus, the value would be undefined (most likely not zero) and this sure would crash.

But again... I was planning on working on this class to remove the race condition that can occur in one situation, so there was actually a way to safely abort jobs (which I thought might be a good thing). So I was starting from the previously committed version.

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...

Biplab · « **Reply #12 on:** August 27, 2007, 04:06:58 pm »

Quote from: thomas on August 27, 2007, 01:13:02 pm

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...

I did a clean-up as you suggested earlier. But the result remained same.

Honestly, I'm not in favour of a revert. If it works on one machine and doesn't work on another, then the other machine config may have some problem. I'll look into it.

MortenMacFly · « **Reply #13 on:** August 27, 2007, 05:21:47 pm »

Quote from: Biplab on August 27, 2007, 04:06:58 pm

Honestly, I'm not in favour of a revert.

Me not either.

Hence consider this:
I compiled C::B 4410 at home -> crashes always. I copied this version on my USB stick and took it to work. Guess what? Here it *works*! It's binary identical with the home version (even the wx DLL is binary the very same -> I copied that, too).

So it's really stochastic somehow. The only thing I could see was after removing contrib plugins step-by-step at home it used to work after a while. But even that was not reproducible to pinpoint a special plugin. I tried two times: The first time it worked after removing BrowseTracker, the second time it worked after removing ByoGames (alphabetical order ;-)). I could swear both are *not* the reason. :-(

With regards, Morten.

TDragon · « **Reply #14 on:** August 27, 2007, 05:27:21 pm »

In multithreaded apps, random or "stochastic" symptoms indicate multithreading problems 90% of the time.

MortenMacFly · « **Reply #15 on:** August 27, 2007, 05:34:59 pm »

Quote from: TDragon on August 27, 2007, 05:27:21 pm

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%.

TDragon · « **Reply #16 on:** August 27, 2007, 05:48:01 pm »

Quote from: MortenMacFly on August 27, 2007, 05:34:59 pm

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.

rickg22 · « **Reply #17 on:** August 27, 2007, 06:10:13 pm »

I hate to say this, Thomas - but didn't we all agree on "If it ain't broke..."?

I had reverted your code that time not only because I didn't understand it, but because it actually crashed. What I didn't understand was WHY it crashed. After I had reverted it, CB stopped crashing at certain addresses but still crashed on others. Then I fixed my code and everything was fine.

But do whatever you want, it's your code - as long as my 4291 rev plays fine, NP for me.

thomas · « **Reply #18 on:** August 27, 2007, 07:03:00 pm »

Quote from: rickg22 on June 26, 2007, 04:24:13 am

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...

But anyway, I'm through with it. I'll do the revert myself. Just don't ask me again if your code leaks and crashes.

rickg22 · « **Reply #19 on:** August 27, 2007, 11:18:29 pm »

Thanks!

thomas · « **Reply #20 on:** August 28, 2007, 01:42:36 pm »

Speaking of random crashes, both the code completion and the todo list plugin will randomly but consistently crash if the user uses any encoding other than ANSI or UTF-8. I'll leave it to you to figure out why.

MortenMacFly · « **Reply #21 on:** August 28, 2007, 01:59:25 pm »

Quote from: thomas on August 28, 2007, 01:42:36 pm

I'll leave it to you to figure out why.

Biplab and I already figured out some possible crash candidates under such circumstances... ;-)

Biplab · « **Reply #22 on:** August 28, 2007, 02:19:29 pm »

Quote from: MortenMacFly on August 28, 2007, 01:59:25 pm

Quote from: thomas on August 28, 2007, 01:42:36 pm
I'll leave it to you to figure out why.
Biplab and I already figured out some possible crash candidates under such circumstances... ;-)

And, funnily, one such instance was when I tried to run it in safe mode!!

News:

Author Topic: C::B fails to start on Windows (Rev 4407) (Read 20181 times)