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]

[mdelfede]

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

What about another alertbox asking if you REALLY want to kill the process, and only on windoze compilations ?
So, for example, stop the log output at first, then prompt an alertbox asking if you want to kill the process too, with little explanation of risks.
Another possibility would be to put what to do in environment options, so user can choose if he wants the normal behaviour, the 'stop output' behaviour or the 'kill it' one.

Ciao

Max

[mandrav]

This conversation is pointless.
What's slow, is the error messages that are regex-parsed and scrolling fast. Thomas' patch disables them, so abort time will be instant in most cases.

We won't add "Just Another Configuration Option" just for the heck of it. It just doesn't make sense...

[tiwag]

Hi thomas,
it makes the following difference

with CB rev_2801 i had to wait until all warnings got catched ... 8 minutes !!!

Code

-------------- Build: Debug in wx_console ---------------
mingw32-g++.exe -W -pipe -mthreads -include wx_pch.h -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -DUSE_PCH -g  -Id:\wx263\include -Id:\wx263\lib\gcc_dll\mswu -Id:\wx263\contrib\include -ID:\MinGW\include  -c wx_pch.h -o wx_pch.h.gch\Debug_wx_pch.h.gch
In file included from d:/wx263/include/wx/string.h:55,
                 from d:/wx263/include/wx/memory.h:20,
                 from d:/wx263/include/wx/object.h:25,
                 from d:/wx263/include/wx/wx.h:16,
                 from d:/wx263/include/wx/wxprec.h:54,
                 from ./wx_pch.h:9,
                 from <command line>:7:
d:/wx263/include/wx/buffer.h:96: warning: inline function 'wxCharBuffer::wxCharBuffer(const char*)' is declared as dllimport: attribute ignored.
d:/wx263/include/wx/buffer.h:96: warning: inline function 'wxCharBuffer::wxCharBuffer(const char*)' is declared as dllimport: attribute ignored.
...
Process terminated with status 0 (8 minutes, 12 seconds)
0 errors, 4490 warnings

with your patch applied i got  39 sec. ....  much better !!!!

Code

-------------- Build: Debug in wx_console ---------------
mingw32-g++.exe -W -pipe -mthreads -include wx_pch.h -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -DUSE_PCH -g  -Id:\wx263\include -Id:\wx263\lib\gcc_dll\mswu -Id:\wx263\contrib\include -ID:\MinGW\include  -c wx_pch.h -o wx_pch.h.gch\Debug_wx_pch.h.gch
In file included from d:/wx263/include/wx/string.h:55,
                 from d:/wx263/include/wx/memory.h:20,
                 from d:/wx263/include/wx/object.h:25,
                 from d:/wx263/include/wx/wx.h:16,
                 from d:/wx263/include/wx/wxprec.h:54,
                 from ./wx_pch.h:9,
                 from <command line>:7:
d:/wx263/include/wx/buffer.h:96: warning: inline function 'wxCharBuffer::wxCharBuffer(const char*)' is declared as dllimport: attribute ignored.
d:/wx263/include/wx/buffer.h:96: warning: inline function 'wxCharBuffer::wxCharBuffer(const char*)' is declared as dllimport: attribute ignored.
...
Aborting process 0...
Process terminated with status 0 (0 minutes, 39 seconds)
0 errors, 436 warnings

thanks thomas, fine improvement !

[mandrav]

tiwag, you could also add the -Wfatal-errors which will stop on the very first error.

[tiwag]

tiwag, you could also add the -Wfatal-errors which will stop on the very first error.

i know this,

the reason why i posted all that stuff was,
that when you erroneously started a compilation with the wrong options,
you had to wait long (in my case 8 minutes) without possibility to abort the process.
this is now corrected with thomas' patch

thanks all
tiwag

[thomas]

Never mind that patch... I've modified the PipedProcess class to suck everything proper, this avoids all the data being piped through the message queue again (committed already). This should now be at least twice as fast.

[tiwag]

one little "cosmetic" change would be fine ...

we should display the "Aborting process ..." before discarding all further messages from the pipeline,
so that the user knows that the Abort-button is processed actually.

Code

Be patient!
This process will be aborted soon...

[tiwag]

under windoze, the

Code

wxProcess::Kill(m_Pid[i], wxSIGTERM);

obviously does nothing and does not return, until the signalled process finishes normally.

Therefore it is necessary under windoze, to send the Buildlog message before wxProcess::Kill() is called.

i did a test with the following patch and it works under windoze ok.

plugins\compilergcc\compilergcc.cpp:2273...

Code

int CompilerGCC::KillProcess()
{
    ResetBuildState();
    m_RunAfterCompile = false;
    if (!IsProcessRunning())
        return 0;
    wxKillError ret = wxKILL_OK;

    m_CommandQueue.Clear();

    for (size_t i = 0; i < m_ParallelProcessCount; ++i)
    {
        if (!m_Processes[i])
            continue;

    #ifdef __WXMSW__
        Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Aborting process %d ... Be patient!"), i);
    #endif // __WXMSW__

        // Close input pipe
        m_Processes[i]->CloseOutput();
        ((PipedProcess*) m_Processes[i])->ForfeitStreams();

        ret = wxProcess::Kill(m_Pid[i], wxSIGTERM);

    #ifndef __WXMSW__
        if(ret != wxKILL_OK)
        {
            // No need to tell the user about the errors - just keep him waiting.
            Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Aborting process %d ..."), i);
        }
        else switch (ret)
        {
//            case wxKILL_ACCESS_DENIED: cbMessageBox(_("Access denied")); break;
//            case wxKILL_NO_PROCESS: cbMessageBox(_("No process")); break;
//            case wxKILL_BAD_SIGNAL: cbMessageBox(_("Bad signal")); break;
//            case wxKILL_ERROR: cbMessageBox(_("Unspecified error")); break;
            case wxKILL_OK:
            default: break;//Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Process killed..."));
        }
    #endif // __WXMSW__
    }
    return ret;
}

how does this work under linux ?
is the linux case necessary or could it be thrown completely ?
and maybe simplified to

Code

int CompilerGCC::KillProcess()
{
    ResetBuildState();
    m_RunAfterCompile = false;
    if (!IsProcessRunning())
        return 0;
    wxKillError ret = wxKILL_OK;

    m_CommandQueue.Clear();

    for (size_t i = 0; i < m_ParallelProcessCount; ++i)
    {
        if (!m_Processes[i])
            continue;

    #ifdef __WXMSW__
        Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Aborting process %d ... Be patient!"), i);
    #else
        Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Aborting process %d ..."), i);
    #endif // __WXMSW__

        // Close input pipe
        m_Processes[i]->CloseOutput();
        ((PipedProcess*) m_Processes[i])->ForfeitStreams();

        ret = wxProcess::Kill(m_Pid[i], wxSIGTERM);
    }
    return ret;
}

[tiwag]

@Yiannis & Pecan - any comments ?

the actual svn version needs to be updated anyways,
because actually there is no message displayed when one presses the Abort button
and then it can take a long while under windoze OS until gcc returns ... ... zzz ... ... zz ... ... z ... ...

i tested the above versions with windows and it works ok there,
i'm not shure with linux and MAC OS X ...

[mandrav]

Forgot about this. I 'll run some tests and if it works ok...

[Pecan]

I'll have to test next week. I'm currently too far away from my MAC box.