Внутренняя ошибка inkscape будет закрыт

#0  0x00007ffff0c0f446 in strlen () at /usr/lib/libc.so.6
#1  0x0000000000663b05 in  ()
#2  0x000000000065ffa3 in  ()
#3  0x00000000006618bc in  ()
#4  0x000000000065b4b4 in  ()
#5  0x000000000067214e in  ()
#6  0x000000000065f2b2 in  ()
#7  0x000000000066dd8c in  ()
#8  0x0000000000668a2e in  ()
#9  0x00007ffff78178b4 in Gtk::Dialog_Class::response_callback(_GtkDialog*, int) () at /usr/lib/libgtkmm-2.4.so.1
#10 0x00007ffff203df75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff205037d in  () at /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff2058bcc in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#13 0x00007ffff2058faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff203df75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff204ff82 in  () at /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff2058bcc in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff2058faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff6925025 in  () at /usr/lib/libgtk-x11-2.0.so.0
#19 0x00007ffff203df75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff204f95c in  () at /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff2058bcc in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff2058faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff6923f89 in  () at /usr/lib/libgtk-x11-2.0.so.0
#24 0x00007ffff69c97ac in  () at /usr/lib/libgtk-x11-2.0.so.0
#25 0x00007ffff203df75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#26 0x00007ffff205037d in  () at /usr/lib/libgobject-2.0.so.0
#27 0x00007ffff205866f in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#28 0x00007ffff2058faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#29 0x00007ffff6ae18cc in  () at /usr/lib/libgtk-x11-2.0.so.0
#30 0x00007ffff69c7f74 in gtk_propagate_event () at /usr/lib/libgtk-x11-2.0.so.0
#31 0x00007ffff69c832b in gtk_main_do_event () at /usr/lib/libgtk-x11-2.0.so.0
#32 0x00007ffff663f46c in  () at /usr/lib/libgdk-x11-2.0.so.0
#33 0x00007ffff1d65587 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#34 0x00007ffff1d657f0 in  () at /usr/lib/libglib-2.0.so.0
#35 0x00007ffff1d65b12 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#36 0x00007ffff69c73a7 in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
#37 0x00000000004738ca in  ()
#38 0x00007ffff0baf291 in __libc_start_main () at /usr/lib/libc.so.6
#39 0x000000000046fe5a in  ()

I you get any resource that you can point to with which I would be able to debug the whole thing, it could be great.

thanks for the report!
It leaves me pretty clueless… is there an older version that works for you? If so, we have a starting point for searching the change that broke it.

Would it also crash when you save a dump file instead of sending to the device?

Oh, I can crash inkscape like this:
rm ~/.config/inkscape; inkscape star.svg
-> Extensions -> Export -> Send to Silhouette … -> Advanced -> Dummy device -> Apply

I had rare crashes before. Maybe that was exactly when running for the first time. Once the ~/.config/inkscape folder is populated, everyhting works smooth.

I have tested other things with no more luck :

• Removing my .config/inkscape folder and retrying: failure,
• Using pip2 to install pyusb instead of pacman -S python2-pyusb: same failure.
• Send to dummy device: idem.
• Try with older versions of Inkscape: failure mostly because older versions cannot be installed on my Arch version due to library incompatibilities,
• Try with older versions of extension: failure too.

I heavily suspect something very specific to my own config. Really don’t know where does it come from though. Have you any pointer so that I could debug the thing by myself?

Cool. The information I harvest from this is:

• When you can crash with the dummy device, then usb code is not the issue.
• Removing .config/inkscape may provoke a possibly unrelated crash (the one I had in mind above). Beware.
• Maybe it is still related to the crash I had in mind, and it just triggers differently and ‘more reliably’ for you

Next step for me would be to find the exact line in the python code that causes the crash.
If that is a library call, we would try other version of that library, or recompile it with full debug symbols, ….

A way to find that line is to sprinkle the extension code with a number of print() statements.

I have made some investigation:

• Using inkex.debug or print in the python script has no effect, the bug seems to happen before calling the script,
• Setting #!/usr/bin/env python2 instead of #!/usr/bin/env python as header has no effect,
• Substituting the python script of another extension to the one called from the inx file has no effect,
• Calling the script from the command line directly without any arguments works perfectly and prints the debug messages.

I suspect that the call made by the inx dialog to the script passes to much arguments and trigger this bug. It would explain the segmentation fault.

Again, it’s just supposition as I am not versed in Python. I will now try to debug Inkscape itself and the call from the dialog to the python script of the extension to spot the exact place where I think it happens.

Great work! That narrows down the issue.

Next idea from my side: strip down the inx file to do less. And to generate less parameters. This would confirm or falsify your theory of too much arguments being the cause.

Maybe its locale / encoding related?

Possibly it are not too much parameters, but a specific type of
parameter triggers the problem. So the proposal from Jürgen is good to
narrow down the problem.

I have started to comment parts of the inx to see if it changed something. It instantly got rid of the bug. But the strangest thing is that uncommenting the param, I now still get a working extension, no more bug! Unexplainable!

In the current state, I can thus no more investigate the bug…

I don’t really get an explanation for this. Perhaps Inkscape has a mechanism to store last entered value for a param and pass this value by default if unchanged in the dialog. By commenting part of the inx, it invalidates this cache. I really don’t know…

I thus close the bug as it is mysteriously resolved.

I cannot even open inkscape and get the very same message