Re: [lmi] Segfault in lmi with wx-2.9.5

[Vadim Zeitlin]

On Fri, 12 Jul 2013 19:36:09 +0000 Greg Chicares <address@hidden> wrote:

GC> A segfault occurred while I was randomly pounding on a fresh
GC> lmi build. I haven't been able to reproduce it yet. The DrMingw
GC> JIT debugger caught it and issued the report below; can you
GC> make any sense of it?
GC> 
GC> Usually DrMingw gives a backtrace; here it did not.
GC> 
GC> 80000003 seems to be a breakpoint, but I don't remember coding
GC> INT 3 anywhere. That would be opcode 0xCC; perhaps execution
GC> jumped into a data area that happened to contain that opcode?

 If you were using MSVC, this would have been quite likely as it
intentionally initializes the otherwise uninitialized variables with this
value, but I am not aware of MinGW doing anything like this and the special
values used by Win32 heap manager itself don't include 0xCC (it uses
0xBAADF00D for uninitialized memory and 0xFEEEFEEE for the already freed
memory).

 But wait, actually it looks that the breakpoint exception was triggered by
another thread while trying to handle the real exception that happened in
the (presumably) main thread. At least this is how I interpret the values
of dwFirstChance below:

GC> DEBUG_EVENT:
GC>     dwDebugEventCode = EXCEPTION_DEBUG_EVENT
GC>     dwProcessId = 274
GC>     dwThreadId = 1D4C
GC>     ExceptionCode = 80000003
GC>     ExceptionFlags = 0
GC>     ExceptionAddress = 7C90120E
GC>     dwFirstChance = 1
GC> DEBUG_EVENT:
GC>     dwDebugEventCode = EXCEPTION_DEBUG_EVENT
GC>     dwProcessId = 274
GC>     dwThreadId = F10
GC>     ExceptionCode = C0000005
GC>     ExceptionFlags = 0
GC>     ExceptionAddress = 3DAD2AA
GC>     dwFirstChance = 0

So actually I think the second exception was the original one and the first
one was generated by DrMinGW itself while attempting to handle it.


GC> The ensuing C0000005 is of course a segfault. Using 'addr2line',
GC> I can't decode the address for either "ExceptionCode", or for
GC> the other "AddrPC" in the call stack:
GC>   addr2line --exe=./lmi_wx_shared.exe 03DAD2AA
GC>   addr2line --exe=./lmi_wx_shared.exe 7C90120E
GC>   addr2line --exe=./lmi_wx_shared.exe 2E00225A
GC> all return "??:0", even though lmi was built with '-ggdb'.
GC> Is there anything else I can do with this debug report?

 Unfortunately I don't know, debugging with MinGW under Windows is really
difficult, at least compared to Microsoft tools... Perhaps you could load
it into gdb and use "disassemble *0x3DAD2AA" in it?

VZ