Current trunk sticks in gdb, prevents gdb debugging

Bug #956225 reported by David Mathog on 2012-03-15
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Liam P. White

Bug Description

When built in mingw current trunk (downloaded 3/15/12) will not run usefully in gdb. It starts up, then hits a bunch of errors and will not proceed past there. I built this one with "-g" added to the build.xml, so the backtrace would show a little more. Without it the first 4 steps are just hex numbers. There were absolutely no changes to the code.

C:\progs\inkscape3\inkscape>gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file inkscape.exe inkscape.dbg
Reading symbols from C:\progs\inkscape3\inkscape/inkscape.exe...(no debugging symbols found)...done.
Reading symbols from C:\progs\inkscape3\inkscape/inkscape.dbg...done.
(gdb) run C:\Temp\symbol4.svg
Starting program: C:\progs\inkscape3\inkscape/inkscape.exe C:\Temp\symbol4.svg
[New thread 3756.0x89c]
[New thread 3756.0xbb8]
[New thread 3756.0x7e4]
[New thread 3756.0x7d0]
warning: HEAP[inkscape.exe]:
warning: HEAP: Free Heap block 58e3bc0 modified at 58e3d40 after it was freed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1 0x7c96ee31 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll
#2 0x7c94af5a in ntdll!LdrFindEntryForAddress () from C:\WINDOWS\system32\ntdll.dll
#3 0x058e3bc0 in virtual thunk to Inkscape::XML::SimpleNode::next() const ()
#4 0x003f0000 in ?? ()
#5 0x058e3e18 in virtual thunk to Inkscape::XML::SimpleNode::next() const ()
#6 0x00000000 in ?? ()
(gdb) continue
Continuing.
warning: HEAP[inkscape.exe]:
warning: HEAP: Free Heap block 58e7298 modified at 58e7418 after it was freed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) continue
Continuing.
warning: HEAP[inkscape.exe]:
warning: HEAP: Free Heap block 2198998 modified at 2198b18 after it was freed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb)

and so forth.

The only way to go on is with:

(gdb) handle SIGTRAP nostop

which pretty much defeats the purpose of running in the debugger. I did that anyway, and was treated to pages of the same
heap modified after freed messages.

Note that when this same executable is run by itself there are no indications that these heap issues are taking place.

su_v (suv-lp) wrote :

Setting status to 'Confirmed' based on similar reports on the mailing list:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/38325>

Please revert the status change if the reports on the mailing list are about an unrelated issue with recent Windows builds.

tags: added: build win32
Changed in inkscape:
status: New → Confirmed
Alvin Penner (apenner) wrote :

@David,
     this has apparently been fixed in rev 11096. Could you re-test to see if this issue is still a problem?

Changed in inkscape:
status: Confirmed → Incomplete
David Mathog (mathog) wrote :

It is still broken. Downloaded trunk this morning, apparently rev 11097. Built it with no modifications whatsoever. Copied "trace.svg" into the same directory (to eliminate path issues), and...

C:\progs\inkscape3\inkscape>gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file inkscape.exe inkscape.dbg
Reading symbols from C:\progs\inkscape3\inkscape/inkscape.exe...(no debugging symbols found)...done.
Reading symbols from C:\progs\inkscape3\inkscape/inkscape.dbg...done.
(gdb) run trace.svg
Starting program: C:\progs\inkscape3\inkscape/inkscape.exe C:\Temp\trace.svg
[New thread 1496.0xb7c]
[New thread 1496.0xd0]
[New thread 1496.0xecc]
[New thread 1496.0xfb0]
warning: HEAP[inkscape.exe]:
warning: HEAP: Free Heap block 432d318 modified at 432d498 after it was freed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1 0x7c96ee31 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll
#2 0x7c94af5a in ntdll!LdrFindEntryForAddress () from C:\WINDOWS\system32\ntdll.dll
#3 0x0432d318 in ?? ()
#4 0x003f0000 in ?? ()
#5 0x0432d570 in ?? ()
#6 0x00000000 in ?? ()
(gdb)

Alvin Penner (apenner) wrote :

yes, my own experience on Windows, build 11098, is also very unpredictable. For example, using gdb I was able to load a very simple svg file using the same gdb sequence given above. However, when I then opened the Fill and Stroke dialog, I got a crash, which normally would not have happened, if I were outside of gdb.

Changed in inkscape:
status: Incomplete → Confirmed
ScislaC (scislac) wrote :

Alvin, did you get a backtrace when Inkscape crashed?

Alvin Penner (apenner) wrote :

it looks as if the gdb crash is definitely related to loading the Fill and Stroke dialog. If I was previously using the F+S dialog and then run gdb and try to load a very simple svg file then the crash occurs immediately on startup. If I was not using F+S then I can load a simple svg file with no problem. In this case the crash occurs when loading the F+S dialog.
     In either case the bt is the same:

C:\InkscapeBZR\inkscape>gdb inkscape
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) symbol-file inkscape.dbg
Reading symbols from C:\InkscapeBZR\inkscape/inkscape.dbg...done.
(gdb) run \windows\temp\junk.svg
Starting program: C:\InkscapeBZR\inkscape/inkscape.exe \windows\temp\junk.svg
[New thread 2780.0xf9c]
[New thread 2780.0xe40]
[New thread 2780.0xd5c]
warning: HEAP[inkscape.exe]:
warning: HEAP: Free Heap block 44b2cd0 modified at 44b2e50 after it was freed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c90120f in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1 0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#2 0x7c94b0aa in ntdll!LdrFindEntryForAddress ()
   from C:\WINDOWS\system32\ntdll.dll
#3 0x044b2cd0 in ?? ()
#4 0x003f0000 in ?? ()
#5 0x044b2f28 in ?? ()
#6 0x00000000 in ?? ()
(gdb)

Alvin Penner (apenner) wrote :

when running in gdb, opening the Layers dialog or the Path Effects dialog, or the Filter Editor dialog does not cause a problem, only the Fill and Stroke generates a crash

David Mathog (mathog) wrote :

Since valgrind isn't an option in mingw I gave Dr. Memory a try. With both Trunk and Inkscape 0.48.2 it catches a ton of memory errors and exits before the first window even opens. Here is the first thing it sees (wrong) in 0.48.2

Error #1: UNINITIALIZED READ: reading register al
# 0 libglib-2.0-0.dll!g_array_sized_new
# 1 libglib-2.0-0.dll!g_array_new
# 2 libglib-2.0-0.dll!g_static_private_set
# 3 libglib-2.0-0.dll!g_get_charset
# 4 libglib-2.0-0.dll!g_locale_from_utf8
# 5 libglib-2.0-0.dll!g_win32_locale_filename_from_utf8
# 6 inkscape.exe!? +0x0 (0x004050ab <inkscape.exe+0x50ab>)
# 7 inkscape.exe!? +0x0 (0x004010db <inkscape.exe+0x10db>)
# 8 inkscape.exe!? +0x0 (0x00401158 <inkscape.exe+0x1158>)
# 9 KERNEL32.dll!RegisterWaitForInputIdle
Note: @0:00:14.891 in thread 3616
Note: instruction: test %al %al

As you can see it isn't able to figure out where in inkscape.exe the problem was, but presumably compiling it with -g
would fix that. In this case there the g_win32_locale_filename_from_utf8 is only ever called from main.cpp and script.cpp, my guess is that one of those is with a NULL name passed in.

Later on some of the errors become quite mysterious - this one is in the same thread (they all were) but doesn't list inkscape.exe at all.

Error #8: UNINITIALIZED READ: reading 0x0022fa98-0x0022fa9c 4 byte(s)
# 0 ADVAPI32.dll!RegDeleteValueW +0xf5 (0x77ddeee6 <ADVAPI32.dll+0xeee6>)
# 1 WS2_32.dll!WSCEnumProtocols +0xa63 (0x71ab85c5 <WS2_32.dll+0x85c5>)
# 2 WS2_32.dll!WSCEnumProtocols +0x9a1 (0x71ab8503 <WS2_32.dll+0x8503>)
# 3 WS2_32.dll!WSCEnumProtocols +0x839 (0x71ab839b <WS2_32.dll+0x839b>)
# 4 WS2_32.dll!WSCEnumProtocols +0x75b (0x71ab82bd <WS2_32.dll+0x82bd>)
# 5 WS2_32.dll!WSCEnumProtocols +0x43d (0x71ab7f9f <WS2_32.dll+0x7f9f>)
# 6 WS2_32.dll!WSCEnumProtocols +0x34d (0x71ab7eaf <WS2_32.dll+0x7eaf>)
# 7 libgio-2.0-0.dll!_g_networking_init
# 8 libgio-2.0-0.dll!g_inet_address_get_type
# 9 libgiomm-2.4-1.dll!ZN3Gio9wrap_initEv
#10 libgiomm-2.4-1.dll!ZN3Gio4initEv
#11 libgtkmm-2.4-1.dll!ZN3Gtk4Main20init_gtkmm_internalsEv
Note: @0:00:21.562 in thread 3016
Note: instruction: cmp %ecx (%eax)

Anyway, if any of these messages are real then this tool may be helpful in finding the memory problems under windows.

Liam P. White (liampwhite) wrote :

There is a comment in src/widgets/stroke-marker-selector.cpp that shows the cause of this, but I haven't found any way to fix it yet.

// TODO: this causes SIGTRAP on Windows

(just hit Ctrl+F and look for 'SIGTRAP')

Liam P. White (liampwhite) wrote :

Also note that running with default prefs kills the issue on startup but happens again as soon as Fill&Stroke is opened.

Liam P. White (liampwhite) wrote :

Reproduced on x86_64 linux with valgrind. bt full attached.

On Windows 7, I temporarily made use of a feature of the kernel called "page heap" to debug. You can find the Application Verifier here: http://msdn.microsoft.com/en-us/library/ms220948(v=vs.90).aspx

I walked the stack after getting a crash in Visual Studio, manually entering addresses into gdb running simultaneously.
I found that the stack frames from valgrind and the trap from the verifier core on Windows were essentially identical after the first few frames.

#0 ntdll.dll!RtlpBreakPointHeap()
...
#7 libsigc-2.0-0.dll!6aa01b04() {sigc::signal_base::~signal_base() + 79 in section .text of ./libsigc-2.0-0.dll}
#8 inkscape.exe!eff708() {sigc::signal1<void, SPObject*, sigc::nil>::~signal1() + 24 in section .text of inkscape.exe}
Line 2739 of "c:/devlibs64/include/sigc++-2.0/sigc++/signal.h" [ class signal1
  : public signal_base {...}; ] (inherited, non-virtual destructor)
#9 inkscape.exe!0xef51cc { sigc::signal<void, SPObject*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::~signal()+12 }
#10 inkscape.exe!0x938885 { SPObject::~SPObject()+259 }
Line 147 of "src/sp-object.cpp" [ } ] (destructor tail)
#11 inkscape.exe!0x91193A { SPItem::~SPItem()+92 }
Line 130 of "src/sp-item.cpp" [ } ] (destructor tail)
#12 inkscape.exe!0x91BC97 { SPLPEItem::~SPLPEItem()+12 }
Line 68 of "src/sp-lpe-item.cpp" [ } ] (destructor tail)
#13 inkscape.exe!0x951E1E { SPShape::~SPShape()+167 } ibid
#14 inkscape.exe!0x9443F6 { SPPath::~SPPath()+56 } ibid
#15 inkscape.exe!0x944420 { SPPath::~SPPath()+12 } ibid
#16 inkscape.exe!0x938e00 { sp_object_unref(SPObject*, SPObject*)+225 }
Line 235 of "src/sp-object.cpp"
#17 inkscape.exe!0x93A0A1 { SPObject::detach(SPObject*)+310 }
Line 581 of "src/sp-object.cpp"
#18 inkscape.exe!0x93A3DC { SPObject::release()+42 }
Line 637 of "src/sp-object.cpp"
#19 inkscape.exe!0x912FD5 { SPItem::release()+191 }
Line 442 of "src/sp-item.cpp"
#20 inkscape.exe!0x91beaa { SPLPEItem::release()+385 }
Line 101 of "src/sp-lpe-item.cpp"
#21 inkscape.exe!0x9092DD { SPGroup::release()+57 }
#22 inkscape.exe!0x87A970 { SPMarker::release()+85 }
Line 105 of "src/marker.cpp"
#23 inkscape.exe!0x93AD60 { SPObject::releaseReferences()+170 }
Line 776 of "src/sp-object.cpp"
#24 inkscape.exe!0x939FEA { SPObject::detach(SPObject*)+131 }
Line 558 of "src/sp-object.cpp"
#25 inkscape.exe!0x93A426 { SPObject::remove_child(Inkscape::XML::Node*)+43 }
Line 639 of "src/sp-object.cpp"
#26 inkscape.exe!0x93af94 { SPObject::repr_child_removed(Inkscape::XML::Node*, Inkscape::XML::Node*, Inkscape::XML::Node*, void*)+32 }

... I won't bore you with these. See attached for the full thing.

tags: added: win64
Liam P. White (liampwhite) wrote :

Hello. Can someone test if this still occurs with recent trunk after applying this patch?

=== modified file 'src/style.cpp'
--- src/style.cpp 2014-06-10 09:29:58 +0000
+++ src/style.cpp 2014-07-28 16:38:56 +0000
@@ -227,11 +227,6 @@
         document = document_in;
     }

- new (&release_connection) sigc::connection();
- new (&filter_modified_connection) sigc::connection();
- new (&fill_ps_modified_connection) sigc::connection();
- new (&stroke_ps_modified_connection) sigc::connection();
-
     // 'font' shorthand requires access to included properties.
     font.setStylePointer( this );

@@ -431,7 +426,6 @@

     // Remove connections
     release_connection.disconnect();
- release_connection.~connection();

     // The following shoud be moved into SPIPaint and SPIFilter
     if (fill.value.href) {
@@ -446,12 +440,7 @@
         filter_modified_connection.disconnect();
     }

- filter_modified_connection.~connection();
- fill_ps_modified_connection.~connection();
- stroke_ps_modified_connection.~connection();
-
     _properties.clear();
- //_propmap.clear();

     // std::cout << "SPStyle::~SPstyle(): Exit\n" << std::endl;
 }

Liam P. White (liampwhite) wrote :

Confirmed that the patch works (thanks Johan). Fix committed in lp:inkscape r13474.

Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → Liam P. White (inkscapebrony)
su_v (suv-lp) on 2014-07-29
Changed in inkscape:
milestone: none → 0.91
su_v (suv-lp) on 2014-07-29
Changed in inkscape:
importance: Undecided → Medium
Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers