#976 "Currently compiling. Stop compilations and exit?" - replying Yes causes a hang.

[Paul A Bristow]

Start CB (on windows 10)

Create a new project, hello world perhaps, and run it, but

Don't close the run window!

Then
Close CB and you get a CB Pop box asking if you want to stop compiling.

Answer Yes

CB window is now greyed out and hangs.
If you try to close by clicking X, it says codeblock IDE has stopped responding.

Choosing 'Close the program' option send a report to Microsoft :-(

I suspected that this problem is Windows-specific, but apparently not.

Workaround is simplE: - "Don't answer Yes!"

Answer "No" and close the run window properly first (when prompts you to save workspace etc).

But CB should not do this (it didn't before I believe).

http://forums.codeblocks.org/index.php/topic,23952.0/topicseen.html

[Paul A Bristow]

Thanks for confirmation :-)

https://sourceforge.net/p/codeblocks/tickets/976/

[bluehazzard]

I can confirm this bug.
Will look into it

[bluehazzard]

After hitting yes in the confirmation dialog the function CompilerGCC::KillProcess() is called. There

ret = wxProcess::Kill(p.PID, wxSIGKILL, wxKILL_CHILDREN);

is called.
Then codeblocks whaits in sdk\pluginmanager.cpp:1554

while(compiler->IsRunning())

CompilerGCC::IsRunning() checks with CompilerGCC::IsProcessRunning() if a process is running and this function checks if

if (p.pProcess)
     return true;

is null.

p.Process is set to null in PipedProcess::OnTerminate.

But according https://docs.wxwidgets.org/trunk/classwx_process.html#aa378b7e705c9191431cad51a81581836
OnTerminate is never called if the process is terminated with wxProcess::Kill, so the pointer p.pProcess is never set to nullptr and this leads to a never ending loop...

Does someone knows more about this?

Attached is a patch that fixes this.

[Paul A Bristow]

I’m not sure how to apply this patch to my setup (and worried to see that it appears to be GCC specific whereas this behaviour is found with Clang too).

If you want me to test this patch, please tell a novice patcher if and how to do it.

(Meanwhile I have stopped being naughty and close things down properly 😉 so I can wait for the next CodeBlocks release.)

Thanks for looking into this trickier-than-it-appeared buglet.

[Teodor Petrov]

@bluehazzard Check if this statement is true for both wx 3.0 and 3.1.

[bluehazzard]

@fuscated The commit with this note is 12 years old. This Note is present in wx3.0 and wx3.1, but not wx2.8
The commit that introduced the note https://github.com/wxWidgets/wxWidgets/commit/ca5016d4ddae7f9a2d72a16326e9339f8d3e8748

I could not find any changelog in the porting document from wx2.8 to wx3.0, so i am not sure what is going on...

@Paul A Bristow You have to download the sourceode of codeblocks, apply the patch on the code and compile codeblocks for yourself. It is not an easy task...

[Paul A Bristow]

Hmm - sounds more trouble than I need - there are too many of my own bugs to fix!
I think I'll wait untilt he next release. But thanks for tackling this buglet.

[Teodor Petrov]

@bluehazzard Good. Now you have to test at least windows and linux. We don't want to introduce another regression as the one introduced for stopping the compilation (the one which switched from sigterm to sigkill and broke stuff, I'll have to fix it someday, but my time working on c::b is quite limitted these days).

[bluehazzard]

About what regression are you talking?
The problem, that compilation is terminated hard and leaves invalid files behind?
Or is there a other problem i am not aware of?

[Teodor Petrov]

Yes, this one. It is pretty terrible bug actually.

[bluehazzard]

I agree...
I think we need a two step process here:
1) First press of the stop button calls TERMINATE -> send a terminate to the process, clear the compiling queue. Maybe change the symbol of the toolbar button to something else. This will allow the compiler to finish its work, and stop the compilation queue.
2) Second press of the stop button sends a KILL signal to the process and terminates the process hard. This will allow us to hard terminate a stuck program/compilation if the user wants so...

[Teodor Petrov]

This is not the place to discuss this actually.

I have no opinion yet, because I'm not sure what the actual problem is. At the moment I'm concentrated on other parts. But I'll tackle this someday.

I suppose we'll have to use separate solutions for separate OSes or even toolchains.

[bluehazzard]

I can reproduce this bug on linux mint 19 with trunk codeblocks...
the patch proposed from me, leads to a crash on linux. Currently i do not know if it is a side effect, or if i hit a secondary bug....

[Paul A Bristow]

Well if it is tricky to fix properly, how about just removing the 'Yes' button? This means that the user HAS to shut down 'properly' - what he should have done in the first place!

For a bonus, tell the user how to do it properly in the popup box (close the run window).

[bluehazzard]

Ok, i tested this on a new linux wm and the crash is gone...
can someone test this patch?

[Paul A Bristow]

Thanks for working on this. I'm a Windows 10 user, so I'm not sure how to test this patch (and not using CodeBlocks just now - reverted to Visual Studio and even VS Intellisense is choking on my input ;-( ).

[bluehazzard]

The question was more directed to other devs that use linux.
Thank your for reporting the bug, and sticking around, responding to messages, i appreciate that a lot!

[bluehazzard]

I have tested on linux and windows and can not reproduce this bug, so i have committed this patch
Fixed in r12292.
Thank you for reporting.