Debugging a crash on return from graphics open()? call?
Working on putting libUEMF's wmf support into inkscape in branch lp988601. Replicated the emf-inout/emf-print files in /src/extension/internal as wmf-inout/wmf-print, modified these to use WMF pieces instead of EMF, and cleaned up the collisions (some globals had been used originally). Got it all to compile cleanly.
Problem is, it is blowing up on the "return doc" from
SPDocument * Wmf::open( Inkscape::Extension::Input * /*mod*/, const gchar *uri ) {
the "doc" has been created, and near as I can tell it is kosher. At least the SVG text fed in here:
SPDocument *doc = SPDocument::createNewDocFromMem(d.outsvg->c_str(), strlen(d.outsvg->c_str()), TRUE);
was OK (can be cut/paste into a separate SVG file, and it loads fine). The doc pointer is nonzero. Print statements work all the way down to:
std::cout << "DEBUG Wmf::open post myMetaFileProc 3" <<std::endl; return doc; }
Tried running it in gdb and after the crash
Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it.
did a bt, which showed:
[New Thread 0xb5f21b40 (LWP 14365)]
Program received signal SIGSEGV, Segmentation fault. 0x01380110 in g_mutex_lock@...2945... () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (gdb) bt #0 0x01380110 in g_mutex_lock@...2945... () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #1 0x0139713f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #2 0x0139f2dc in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #3 0x0139f453 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #4 0x00abd2da in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 #5 0x00ab8d3b in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 #6 0x013871ec in g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #7 0x01385484 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #8 0x013970c0 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #9 0x0139f2dc in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 #10 0x00000000 in ?? ()
Not very useful.
How does one debug this sort of thing? I will try valgrind next (which is a real last resort for Inkscape, since it takes 10 minutes run that way, and there are scads of error problems reported, which tends to swamp the issue). But gdb sure wasn't very helpful!
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 12-Feb-2013 13:02, mathog wrote:
I will try valgrind next
Also not terribly useful, except that it shows no memory errors within the code I am working on. The last DEBUG line is immediately before the return. Where would this return to? Maybe I can put some print lines in the calling routines, assuming that it isn't some stack corruption issue in the return itself.
Anyway, it was run like this:
export _INKSCAPE_GC=disable valgrind --leak-check=full --show-reachable=yes >/tmp/vg.log 2&1 head -700 /tmp/vg.log >/tmp/vg700.log
That small file is attached. All of the "DEBUG" lines are within my code, and there is no valgrind output mixed in with it. The errors at the front are common:
__wcslen_sse2 (ignore these, some issue with Ubuntu and valgrind) libfontconfig messages (these always appear)
The information after the last DEBUG tells me little, perhaps it means more to one of you.
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
This is a tough one.
In a control run, which used the same inkscape binary, but only opened a small SVG file and then immediately exited, valgrind had the same output (other than relocation offsets) for the first 262 lines, the first of my DEBUG lines is at line 263. In other words, none of the error messages before my print statements are unusual. There were no valgrind messages within the print statements, they only came on or after a return to calling code.
I am quickly running out of straws to grasp!
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Found and fixed it, although I am still not quite sure what was going on.
In the original EMF version there was this structure in emf-inout.cpp:
typedef struct emf_callback_data { ... } EMF_CALLBACK_DATA, *PEMF_CALLBACK_DATA;
In the wmf-inout this was moved into the header file and became
typedef struct emf_callback_data { <--- note the "e", should have been "w" ... //(slightly different innards) } WMF_CALLBACK_DATA, *PWMF_CALLBACK_DATA;
Removing the "emf_callback_data", or changing it to "wmf_callback_data" resolved the issue. Odd though that there were no valgrind warnings associated with this.
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
participants (1)
-
mathog