On 25-4-2012 21:14, mathog wrote:
On 25-Apr-2012 12:01, Johan Engelen wrote:
On 25-4-2012 20:34, mathog wrote:
except that is NOT what I see on bt. What I see is always something like this:
(gdb) bt #0 0x7c912669 in stricmp () from C:\WINDOWS\system32\ntdll.dll #1 0x7c911649 in ntdll!RtlInitializeHandleTable () from C:\WINDOWS\system32\ntdll.dll #2 0x7c91911f in ntdll!RtlRealPredecessor () from C:\WINDOWS\system32\ntdll.dll #3 0x044bc000 in ?? () #4 0x00016000 in ?? () #5 0x000000f7 in ?? () #6 0x7c912482 in stricmp () from C:\WINDOWS\system32\ntdll.dll #7 0x77c2c3c9 in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll #8 0x003f0000 in ?? () #9 0x00000000 in ?? () (gdb)
I think your gdb already shows the names of the methods :-) You are seeing the effects of a nasty crash, perhaps in a library somewhere.
I rarely see crashes that are not in libraries - they get passed invalid arguments and blow up later. That would be fine if it was at least possible to trace back to whatever handed them the bogus values. In the worst possible case, shouldn't it at least have _one_ inkscape method or function listed in the backtrace, for instance "main" in the lowest position?
If the stack gets corrupted, alas... :(
What may help you in this case is putting "g_message" lines in the code, to see how far execution progresses and where it stops.
-Johan