Boost assertions closes the debugger

[ThundThund]

That seems to be what I want to get  

EDIT: See image in previous page.

[zabzonk]

I have just tried this with the latest debugger nightly, on Windows 7, and even simple  stuff like this (no Boost):

    assert( 1 == 0 );

or the even simpler:

    abort();

is not being caught in the debugger.

OTOH, stuff like this;

    int * p = 0;
    * p = 42;

is caught, and the correct stack-frame and location is displayed. Using this fact, one can write this fix/hack:

    #define BOOST_ENABLE_ASSERT_HANDLER
    #include <boost/assert.hpp>
     using namespace std;

    namespace boost
    {
        void assertion_failed(char const * expr, char const * function, char const * file, long line) {
            *(int *)0 = 42;
        }
    }


    void f() {
            BOOST_ASSERT( 1 == 0 );
    }

    void g() {
       f();
    }

    int main() {
        g();
    }

which will give you the call stack for assert that failed.

[oBFusCATed]

Neil please use code tags!
OK, so abort detection is not working on windows and this is a bug.
Can you provide the full debugger's debug log?
See the debugger options how to enable this log.

[ThundThund]

Do you mean this?

Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 2732
Program exited with code 03.
Debugger finished with status 0

[oBFusCATed]

No, this is the normal log, the debugger's debug log is not visible by default and should be explicitly enabled.

[zabzonk]

Attached is the debugger log for this program:

Code

#include <cstdlib>
using namespace std;

void f() {
   abort();
}

void g() {
	f();
}

int main() {
	g();
}

[oBFusCATed]

Hm, it looks like the debugger is not catching the call to abort. Pretty strange.

[ThundThund]

So are you going to send it as a Bug? If so, please paste here the reference to it, so I can track its progress.

Many thanks to you two for your interest, your time and your wisdom

[oBFusCATed]

I don't know if i'm going to report it to gdb/mingw guys, first I need to check it.
Unfortunately, this won't happen soon.
But I've added it to my todo, so it won't be forgotten.

[ThundThund]

Ok, that's reasonable. The point is that I would like to be notified when this is solved (whenever).
Well, I guess I will have to ask in the forum in the future.

Thanks again.

[zabzonk]

@ThundThund

It's a "feature" of the Windows implementation of the GDB debugger, and nothing to do with CB, so I wouldn't wait around here for a fix. The Windows version of GDB seems incapable of handling raise(SIGABRT), which is what is happening underneath all this. And I wouldn't expect this to be fixed any time soon, if ever.

Basically, GDB is a piss-poor debugger on Windows, and nothing the CB devs can do will alter that. Personally, I very, very rarely use a debugger of any sort, but if I did I would use Visual C++, which has an outstanding debugger.

[oBFusCATed]

I'll post a message in this thread, if I can fix it.

[oBFusCATed]

It's a "feature" of the Windows implementation of the GDB debugger...

Are you 100% sure, could it be that the mingw standard lib is broken. Or there is a setting which should be enabled.

[zabzonk]

No, I'm not 100% sure. I have run some tests using command line GDB,  and I have done some googling which failed to come up with any magic settings. SIGABRT is caught by default on Linux, and is definitely not caught by default on Windows. I've tried using the "handle" command to change how the signal is handled in GDB, but that seems to make no difference. This really wants input from a GDB-on-Windows expert.

I am 100% sure that GDB is a poor Windows debugger, however. Particularly compared with the one that comes with VC++.

[oBFusCATed]

I am 100% sure that GDB is a poor Windows debugger, however. Particularly compared with the one that comes with VC++.

This can be said for almost any other debugger, because VStudio's debugger is close to the best debugger.
And on windows it is the native one and gdb doesn't use the MS's symbols, but the GNU symbols format, so most of the time GDB is working without symbols.
BTW there are no signals on windows, as far as I know.