Dear Maintainer,

Inkscape crashes, recently causing Thunar to crash _too_.
The crash happens when many undo and redo actions are performed consecutively.
At first, I thought it was a one-time bug so I tried using the bpo. Once again, under the same conditions, Inkscape crashed. Finally, I tried using the 1.0 AppImage (to test "sterile"  and see if this was Debian-specific or Inkscape in general). The result is the same. Since it wasn't a "world-ender" bug, I went back to using the native Debian bpo and decided to just save a lot (side-note: auto-save and recovery still occasionally fails).

Earlier tonight, something serious happened; it crashed all instances of Thunar. Clearly this bug seems to be worse than I thought -- apologies for not reporting it sooner. Sadly, this bug is not absolutely reproducible. It has only happened a few times, always under the same conditions though.
It may be related to other similar bugs involving memory access errors. I have noticed only complex SVGs do this (memory/cache?).
The errors (see below) point to the problem being Inkscape-specific (the core lib), so it's very concerning that there's this "domino effect".

Here's the relevant dmesg outputs:
inkscape[18142]: segfault at 148 ip 00007efbfefec5db sp 00007ffbffff9620 error 4 in libinkscape_base.so[7efbfe58a000+bb0000]
traps: inkscape[28062] general protection fault ip:7efbfeed39a1 sp:7ffbffff8520 error:0 in libinkscape_base.so[7efbfe58a000+bb0000]

If I have time, I'll try running Inkscape and Thunar from two consoles and try to reproduce the error. Hopefully it'll shed some light on it. Hopefully still, I won't need to.

Regards,
Jason

Since you tried the AppImage and reproduced with that as well, could you
consider filing a bug report upstream directly at
https://gitlab.com/inkscape/inbox ?


Also, I'm uploading now 1.0-5 to backports, if you could see whether
that also triggers this crash it would be useful (1.0-2 disable a bunch
of asserts that might or might not be relevant).

Likewise, if you can get a stacktrace it usually helps nailing down where
the bug is.

Hello Jason,
one small additional note. The dmesg lines you provided would have been
followed by lines "Code:". With that line it would be possible to
find at least the current instruction and source code line when the
executables are from the debian archive and the package version is
known. So please do not strip these lines away.

Kind regards,
Bernhard

Hello Jason,
thanks for the information, just some notes before.
You might want to  use reply all, otherwise the answer
might get through unnoticed.
And for some reason your email did not convert sufficiently
to plain text for some reason, so it appears kind of
short at https://bugs.debian.org/968756 .

This line points to function below.

But proper backtraces might still be needed to be able to find the reason.
You probably could install systemd-coredump - then minimal backtrace
should be visible in 'journalctl -e' after a chrash.
Plus a core would be generated for later inspection.

And if Thunar crashes too, are there also a segfault line?

Kind regards,
Bernhard



        (gdb) info b
        Num     Type           Disp Enb Address            What
        2       breakpoint     keep y   0x00007ffff78e55db in Avoid::Router::processTransaction() at /usr/include/c++/8/bits/stl_list.h:1063

        (gdb) disassemble Avoid::Router::processTransaction
        Dump of assembler code for function Avoid::Router::processTransaction():
           0x00007ffff78e55d0 <+0>:     push   %rbx
           0x00007ffff78e55d1 <+1>:     lea    0x148(%rdi),%rax
           0x00007ffff78e55d8 <+8>:     mov    %rdi,%rbx
    -->    0x00007ffff78e55db <+11>:    cmp    %rax,0x148(%rdi)
           0x00007ffff78e55e2 <+18>:    je     0x7ffff78e5620 <Avoid::Router::processTransaction()+80>
           0x00007ffff78e55e4 <+20>:    cmpb   $0x0,0x139(%rbx)
        ...

benutzer@debian:~$ cat -n /usr/include/c++/8/bits/stl_list.h | grep 1063 -B7 -A2
  1056
  1057        // [23.2.2.2] capacity
  1058        /**
  1059         *  Returns true if the %list is empty.  (Thus begin() would equal
  1060         *  end().)
  1061         */
  1062        bool
  1063        empty() const _GLIBCXX_NOEXCEPT
  1064        { return this->_M_impl._M_node._M_next == &this->_M_impl._M_node; }
  1065



640 bool Router::processTransaction(void)
641 {
642     // If SimpleRouting, then don't update here.
643     if ((actionList.empty() && (m_hyperedge_rerouter.count() == 0) &&
644          (m_settings_changes == false)) || SimpleRouting)
645     {

https://gitlab.com/inkscape/inkscape/-/blob/INKSCAPE_1_0/src/3rdparty/adaptagrams/libavoid/router.cpp#L643

Hello Jason,

I assume you updated inkscape to current version 1.0-5~bpo10+1 ?

The above part of your backtrace would translate to this
when debug symbols are installed.

(gdb) bt
#0  0x00007f5ab0050204 in _gtk_gesture_get_pointer_emulating_sequence () at ../../../../gtk/gtkgesture.c:1811
#1  0x00007f5ab01d6a53 in _gtk_widget_get_emulating_sequence () at ../../../../gtk/gtkwidget.c:4183
#2  0x00007f5ab01d6b11 in _gtk_widget_set_sequence_state_internal () at ../../../../gtk/gtkwidget.c:4245
#3  0x00007f5ab01d6ff1 in event_controller_sequence_state_changed () at ../../../../gtk/gtkwidget.c:17330
#4  0x00007f5aae1208ee in ffi_call_unix64 () from /lib/x86_64-linux-gnu/libffi.so.6
...

The instruction at this address originates from following location
and tries to read memory from the address the variable "data->event"
points to. The data variable is retrieved before by g_hash_table_iter_next.

https://sources.debian.org/src/gtk+3.0/3.24.5-1/gtk/gtkgesture.c/#L1811

Also this location is quite different from what the original segfault
lines in the first message was showing for the previous bpo version.


Unfortunately I guess this will not be sufficient for the maintainer
to find out the problem or create a fix.

If you receive such crashes multiple times, are the backtraces always
different? If yes you might consider to check for memory faults.

Also running inkscape through "valgrind --undef-value-errors=no inkscape"
might reveal something, but might be too slow to work long enough with it,
if there are no exact steps known to reproduce it.

Also you might add the debug symbols to your system to generate
backtraces with more information, like described here:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Kind regards,
Bernhard

-- 
Greetings From Mr.Musa Abudu

 I have a Mutual/Beneficial Business Project that would be beneficial
to you. I only have two questions to ask of you, if you are
interested.

 1. Can you handle this project?
 2. Can I give you this trust?

 Please note that the deal requires high level of maturity, honesty
and secrecy. This will involve moving some money from my office, on
trust to your hands or bank account. Also note that i will do
everything to make sure that the money is moved as a purely legitimate
fund, so you will not be exposed to any risk.

 I request for your full co-operation. I will give you details and
procedure when I receive your reply, to commence this transaction, I
require you to immediately indicate your interest by a return reply. I
will be waiting for your response in a timely manner.


 Best Regard,
 Mr.Musa Abudu

 NOTE: If you received this message in your SPAM/JUNK folder, that is
because of the restrictions implemented by your Internet Service
Provider, treat it genuinely.