User forums > Using Code::Blocks

How does Run abort work

<< < (3/4) > >>

oBFusCATed:
The next step is to inspect what wxKill does on windows:)
So look at the code of wxwidgets.

tigerbeard:
I did not find out the difference, as I have no info about what taskmanager and taskkill are doing. But I found the cause of the problem. Its the line wxLogMessage("hello"); somewhere where it is called from MainFrames dtor.

I think its quite interesting. It can be reproduced in the minimal sample by just adding a destructor to MyFrame() with that line.
The program works fine and can be killed by task manager. But it stops when aborted by C::B.  (Win7, WX V2.9.3, GCC)

The interesting question for me would be how to debug that behaviour using the standard C::B toolset. I could not step into the problem as it triggers after wxApp is destructed, Dr.MinGW shows garbage. I am looking for a better method tracking stuff like that than taking apart the whole project bit by bit until almost nothing is left. Hopefully C::B and gcc can do more that I am aware off?

Tiger


Cheers
Hans

oBFusCATed:
You can probably use a second instance of codeblocks and do debug -> attach from it.
Then hit the abort button in the first instance.

tigerbeard:

--- Quote from: oBFusCATed on April 05, 2016, 10:02:06 am ---You can probably use a second instance of codeblocks and do debug -> attach from it.
Then hit the abort button in the first instance.

--- End quote ---

That was what I did. I had tried to describe it in that post. Sorry that it was not clear.


--- Quote from: tigerbeard on April 03, 2016, 01:06:55 am ---Finally I found a way to get the debugger working with that scenario.
I just run two instances of CodeBlocks with the same project. The one starts the application.
The other attaches the debugger to the running process.

Works really nice.

--- End quote ---

The problem ist that while debugging is possible, I found no way with the debugger (probably
better: its integration in C::B) to get to that point where it crashes. I believe there is a very
high chance that this is due to my inability to effectively work with C::B's debugger integration.

I gave that short example to reproduce the crash hoping I could learn from more experienced
codeblocks users how to the the debugging tools in Codeblocks better than I do today. I would
be relieved to lean that this kind of crash only is debuggable with GDB by working manually with
its command line. That would be well out of scope for me, then.

So this is not meant to be a post about how I lean GDB, but rather what can I do with the integrated
gdb in code blocks. I think its very rare that a crash is reproducable by just a single line added in a wxMinmal
sample, so I though I'd use that opportunity to lean something.

Cheers
Tiger

oBFusCATed:
Do you have catching of exception enabled in the debugger settings.
If it crashes because of the way cb is killing the app then the debugger should catch it.

If the bug disappears when the debugger is attached to the app then you have either a timing/threading related bug or uninitialized memory/use-after-free bug.

Navigation

[0] Message Index

[#] Next page

[*] Previous page