Problem with the abort build button

[Michael]

Hello,

I have a problem with the abort build button. When I press the button to stop the display of an especially long list of errors, CB stops displaying the errors, but when I release the button it re-continue to display them. Is this a possible bug?

I use CB rc2 under Windows XP SP2.

Thank you very much.

Best wishes,
Michael

[thomas]

No, it's not a bug.

The displayal of errors is done via messages which are not forwarded while you hold down the button. Also, the running process is not immediately terminated, but keeps sending output.

So it is perfectly normal to get output after releasing the button. What is really aborted is the run queue, not a running process (i.e. no more files are compiled thereafter).

[Michael]

Hello,

Ok, I understand. Thank you for your answer.

Is there may be a possibility to interrupt the run queue? It is not so funny to wait several seconds until CB has finished to display the errors, each time I try to re-build the project.

Thank you very much.

Best wishes,
Michael

[thomas]

Not without changing the source and recompiling. But that is technically possible. You get the process id from wxExecute, all you need to do is call wxThread's Kill function on that one.

I am not entirely sure if it is a good idea, though. Probably nothing happens in the case of a compiler, killing a process is generally a bad thing. I would rather wait a few seconds but be safe. For example, the SVN plugin explicitely prevents you from closing the window while a transaction is running unless you force-kill the process (if you are using CVS, this may corrupt your entire repository!).
Sure enough, the most likely thing to happen in the case of a compiler is nothing at all, the object files are overwritten next time anyway... but you never know.

[Michael]

Hello,

Yes, I agree. Killing a process is never or quite a good idea and could bring to unexpected results and problems. Ok, I will wait some seconds then.

Thank you.

Best wishes,
Michael

[mandrav]

The abort button does two things:
1) marks the end of the queue so no more commands are run and compilation stops.
2) *Tries* to kill the process. This doesn't work in windows whereas in other platforms does.

Summary: it's not a bug, it behaves as expected.

[Michael]

Hello,

Ok, I see. Thank you very much for the explanation.

Best wishes,
Michael

[Urxae]

The abort button does two things:
1) marks the end of the queue so no more commands are run and compilation stops.
2) *Tries* to kill the process. This doesn't work in windows whereas in other platforms does.

Wait, that works on non-Windows platforms? Why not on Windows? I looked at the source, and the line doing the actual work seems to be this one:

Code

ret = wxProcess::Kill(m_Pid, wxSIGTERM);

According to the wxProcess::Kill documentation, "wxSIGNONE, wxSIGKILL and wxSIGTERM have the same meaning under both Unix and Windows".
So the question becomes: is this because of wxWidgets or because of C::B?
The only thing I could see that's possibly wrong with that line is that wxKILL_CHILDREN isn't passed as the third (flags) parameter. MinGW and normal GCC (and possibly other compilers, I wouldn't know) spawn child processes to do the actual work of compiling, so I would expect that parameter to be appropriate.
[later]I tried, that doesn't make it work either.[/later]

Summary: it's not a bug, it behaves as expected.

I beg to differ. Knowing it not to work doesn't mean it isn't still a bug when it doesn't . Besides, as this thread shows some people expect it to actually work (As did I the first time I pushed the Big Red Button^TM).

[mandrav]

Summary: it's not a bug, it behaves as expected.

I beg to differ. Knowing it not to work doesn't mean it isn't still a bug when it doesn't . Besides, as this thread shows some people expect it to actually work (As did I the first time I pushed the Big Red Button^TM).

"As expected" as in "as expected based on platform-related limitations"...
Although if you think you can make it kill the process under windows, feel free to share with us

[Michael]

Hello,

Now that I remember, sometime ago I have developed a kind of remote control that allows to start/stop external applications (e.g., server, player, etc.). To stop the create process, I used for some of them I used the flag wxSIGTERM and for the other the flag wxSIGKILL (the flag wxSIGTERM did not work as I wished). This worked under Windows XP SP2 and wxWidgets 2.6.1 and 2.6.2. The remote control has been developed under VS Studio C++ .NET 2003.

Best wishes,
Michael

[thomas]

I beg to differ. Knowing it not to work doesn't mean it isn't still a bug when it doesn't . Besides, as this thread shows some people expect it to actually work (As did I the first time I pushed the Big Red Button^TM).

It works, and it is no bug. What Code::Blocks does is perfectly correct and legal. It is just that SIGTERM (or signals in general) does not exist on Windows.
So what the abort button effectively does is stop the run queue, thus no more processes are launched. Everything works as it should, really.

According to

The wxWidgets documentation is rubbish, bluntly said. It often makes claims which are not in concordance with reality. For example, the documentation encourages to use wxMilliSleep instead of usleep(3) because it is MT safe. What wxMilliSleep really does is multiply by 1000 and call the platform-dependent usleep, Sleep, or nanosleep function. In my humble opinion, a multiply does not greatly increase thread safety.

The issue with wxKill is similar. While it really sends signals on Unix, what wxKill does on Windows is this:
- If signal is SIGKILL, it calls TerminateProcess
- If signal is SIGNONE, the function returns immediately
- If signal is *anything* except the two above, it posts WM_QUIT to any windows it can find

You could argue that WM_QUIT kind of simulates a SIGTERM for Windows programs, but that is really not the case. SIGTERM is meant to say "please go away, gracefully", and an application is not even required to actually follow it.
WM_QUIT just ends the message loop, and the program exits without much opportunity for cleanup.
Using WM_CLOSE instead would be an improvement at least insofar as the program is not just knocked out of its message loop, but it would of course still not work for non-GUI programs.

Edit: typo

[Michael]

Hello,

Sorry, but why you say that "It is just that SIGTERM (or signals in general) does not exist on Windows."?

After the wxWidgets doc:

int wxKill(long pid, int sig = wxSIGTERM, wxKillError *rc = NULL, int flags = 0)

wxSIGNONE, wxSIGKILL and wxSIGTERM have the same meaning under both Unix and Windows but all the other signals are equivalent to wxSIGTERM under Windows.

Thank you very much.

Best wishes,
Michael

[mandrav]

What he 's saying is that when things don't work as expected, take a peek in the code. Don't always rely on the documentation...

[thomas]

If you look at src/msw/utils/utils.cpp  (abbreviated):

int wxKill(long pid, wxSignal sig, wxKillError *krc, int flags)
{
...
    HANDLE hProcess = ::OpenProcess(SYNCHRONIZE | PROCESS_TERMINATE |
                                                     PROCESS_QUERY_INFORMATION, FALSE, (DWORD) pid);
    if ( hProcess == NULL )
    {
...
        return -1;
    }

    bool ok = true;
    switch ( sig )
    {
        case wxSIGKILL:
            // kill the process forcefully returning -1 as error code
            if ( !::TerminateProcess(hProcess, (UINT)-1) )
            {
                wxLogSysError(_("Failed to kill process %d"), pid);

                if ( krc )
                {
                    // this is not supposed to happen if we could open the
                    // process
                    *krc = wxKILL_ERROR;
                }

                ok = false;
            }
            break;

        case wxSIGNONE:
            // do nothing, we just want to test for process existence
            break;

        default:
            // any other signal means "terminate"
            {
                wxFindByPidParams params;
                params.pid = (DWORD)pid;

...
                if ( !::EnumWindows(wxEnumFindByPidProc, (LPARAM)&params) )
                {
                    // did we find any window?
                    if ( params.hwnd )
                    {
...
                        if ( !::PostMessage(params.hwnd, WM_QUIT, 0, 0) )
                        {
                            wxLogLastError(_T("PostMessage(WM_QUIT)"));
                        }
                    }
...
                }
                else // no windows for this PID
                {
...
                    ok = false;
                }
            }
    }
...

    ::CloseHandle(hProcess);
...
}
You see that what the documentation tells you differs from what actually happens.

[Michael]

Hello,

Yes, I see. Thank you very much for the explanation.

Best wishes,
Michael