Aborting compilation seems to be broken

[tiwag]

in one of my last projects i started a compilation of a wxWidgets precompiled header file
with the "-W" compiler warnings option,

which leads to millions of warnings of type
"inline function ... is declared as dllimport: attribute ignored"

when i press the Abort button, a message "Aborting process 0..." appears in the build dialogue,
but it isn't aborting  :shock:

you can test it with the attached project

OS WinXP,
wxMSW-2.6.3-p2, unicode, shared library,
gcc 3.4.4

[attachment deleted by admin]

[Ceniza]

I'mn't sure but it seems abort just stops executing new tasks and not killing the current ones, which would explain that behavior.

[mandrav]

Exactly. This is known windows behaviour. Most kill-signals are ignored on that platform and there's not much we can do about it.
In linux though it aborts just fine.

[tiwag]

ok that explains it

but how does ProcessExplorer kill them ?
with this tool i'm able to kill the process without problems,
maybe we can use the same method ... ?

[MortenMacFly]

but how does ProcessExplorer kill them ?

AFAIK using a specific WinAPI method not encapsulated within wxWidgets. This is very Windows specific and certainly not cross-platform compatible... but does that matter?

[thomas]

ok that explains it

but how does ProcessExplorer kill them ?
with this tool i'm able to kill the process without problems,
maybe we can use the same method ... ?

We can kill it, no problem. But we don't want to.

What we do is we send the process SIGTERM. Under Linux, every decent program understands this as a kick in the rear with the demand to get lost as soon as possible, albeit in a gentle manner.

Under Windows, nothing happens if you send SIGTERM. It is simply not implemented.

What ProcessExplorer does (in Posix terms) is SIGKILL, which we do not want to use because it just kills the process in an uncontrolled manner. Even though it probably works, sigkilling a program is not nice. You don't really know what happens, files may stay locked or be left in an inconsistent state, memory may not be freed, anything...


EDIT:
For completeness, it should be mentioned that wxWidgets implements a workaround for Windows by sending a WM_CLOSE notification. This implements a SIGTERM-like graceful shutdown behaviour for GUI apps. However, this only works if the application has a window, and gcc obviously doesn't.

[kagerato]

EDIT:
For completeness, it should be mentioned that wxWidgets implements a workaround for Windows by sending a WM_CLOSE notification. This implements a SIGTERM-like graceful shutdown behaviour for GUI apps. However, this only works if the application has a window, and gcc obviously doesn't.

For applications running within a console instance (cmd.exe, generally), there is a mechanism for shutting down as the console itself is destroyed.  See "More on Process Termination".  I don't believe this is pertinent in CodeBlocks' case, though.  Do you allocate a console at any point, or merely invoke the applications directly?  It appears to be the latter, so far as I can tell.

[tiwag]

@thomas
it's nice trying to be gentle, but under Windoze it's quite useless ...

when you start for example a compilation of a wx pch erroneously with warning option "-W"
you get thousands of warnings and it lasts ages until it completes.

the only way is to kill the process ( btw. i never got any locked files or any problems with unfreed memory or a corrupted heap or whatever )

i see now the reasons for this behaviour and think it is better done with an external tool
and not necessary to be implemented into CodeBlocks Abort code.

thanks for the infos

[Ceniza]

Windows should take care of unlocking files and freeing memory if a process is killed... at least any recent version should do that.

It's completely ugly sending a SIGKILL (or any other mechanism to achieve the same goal) but I wouldn't mind

[tiwag]

... but I wouldn't mind

me too

[thomas]

when you start for example a compilation of a wx pch erroneously with warning option "-W"
you get thousands of warnings and it lasts ages until it completes.

What if we stop adding any more stdout data to the log window after the user has hit "abort"? We will still have to read a few megabytes from the pipe (or else the process will hang after filling the 4k pipe buffer), but we will save significant CPU time not sending it through a regex and not writing it all to the log window and drawing the text that you don't want to read anyway on screen. This might indeed turn "ages" into "a second or two", and you could just wait for gcc to exit cleanly.

Windows should take care of unlocking files and freeing memory if a process is killed

Should... but you never know what actually happens. Personally, I have never seen anything go wrong killing a process, but you really don't know what happens if you just take away a process' timeslice and unmap its pages.
I could think of quite a few scenarios like object files or precompiled headers being written to disk half-way, when the user presses "abort" for whatever reason. Even if most of these conditions can be fixed by doing a clean rebuild at worst, they should not be "normal operation" (and there may be worse consequences that you cannot foresee).

[takeshimiya]

... but I wouldn't mind

me too

Neither do I

I guess most are just pressing CTRL-ALT-DEL to kill and completely destroy the process, commiting a violent assassination.
A "Nice SIGTERM" is not what it's in the mind at that moment.

But if anyone is completely opposed to SIGKILLING, it will have to be made an option then.

[tiwag]

... if we stop adding any more stdout data to the log window after the user has hit "abort"? ...

extension :

1st press of Abort button:  disable output logging

if the Abort button is pressed subsequently later on (let's say more than 2 times in one second) :  kill the process

[takeshimiya]

... if we stop adding any more stdout data to the log window after the user has hit "abort"? ...

extension :

1st press of Abort button:  disable output logging

if the Abort button is pressed subsequently later on (let's say more than 2 times in one second) :  kill the process

A good solution if you know it beforehand, but a bit user-unfriendly/non-intuitive if you don't.
So new users would mean new posts about "Aborting compilation seems to be broken".

Look,
If anyone considers SIGKILLING in Windows something risky, I don't, because it's what I do by hand anyways.
So either an creating an option, or directly making it the default behaviour, will alivianate the Windows inability to SIGTERM.

[thomas]

Tiwag, try if this makes it any better for you (for me it seems to work, although not as good as I expected).
One might cut the line even further upstream (before a million events are being sent), that might actually be better... will look if I get that done.

[attachment deleted by admin]