#1866 segfault at 18 ip 00007f8ea61012ee sp 00007f8e9effcac0 error 4 in libmtp.so.9.4.0[

[Anonymous]

Output from dmesg:

crash instance 1:

[ 6707.977371] show_signal_msg: 10 callbacks suppressed
[ 6707.977374] pool[8766]: segfault at 18 ip 00007f6b6a6262ee sp 00007f6b49ffaac0 error 4 in libmtp.so.9.4.0[7f6b6a618000+2a000]
[ 6707.977385] Code: d7 41 56 41 89 f6 41 55 4d 89 c5 41 54 4d 89 cc 55 48 89 fd 53 48 83 ec 18 48 8b 5f 08 89 4c 24 0c e8 96 23 ff ff 8b 4c 24 0c <48> 8b 50 18 4c 39 fa 0f 86 15 01 00 00 89 c8 89 d6 4c 01 f8 44 29

crash instance 2:

[ 8078.860713] pool[11290]: segfault at 18 ip 00007f8ea61012ee sp 00007f8e9effcac0 error 4 in libmtp.so.9.4.0[7f8ea60f3000+2a000]
[ 8078.860725] Code: d7 41 56 41 89 f6 41 55 4d 89 c5 41 54 4d 89 cc 55 48 89 fd 53 48 83 ec 18 48 8b 5f 08 89 4c 24 0c e8 96 23 ff ff 8b 4c 24 0c <48> 8b 50 18 4c 39 fa 0f 86 15 01 00 00 89 c8 89 d6 4c 01 f8 44 29

crash instance 3:

[14763.149539] pool[15025]: segfault at 18 ip 00007f4d91d832ee sp 00007f4d897f9ac0 error 4 in libmtp.so.9.4.0[7f4d91d75000+2a000]
[14763.149551] Code: d7 41 56 41 89 f6 41 55 4d 89 c5 41 54 4d 89 cc 55 48 89 fd 53 48 83 ec 18 48 8b 5f 08 89 4c 24 0c e8 96 23 ff ff 8b 4c 24 0c <48> 8b 50 18 4c 39 fa 0f 86 15 01 00 00 89 c8 89 d6 4c 01 f8 44 29

No core file was dumped as part of the crash.

Device is a SAMSUNG Galaxy S10

[Anonymous]

root@unstable:~# dpkg -l | grep libmtp
ii libmtp-common 1.1.16-2 all Media Transfer Protocol (MTP) common files
ii libmtp-dev:amd64 1.1.16-2 amd64 Media Transfer Protocol (MTP) development files
ii libmtp-runtime 1.1.16-2 amd64 Media Transfer Protocol (MTP) runtime tools
ii libmtp9:amd64 1.1.16-2 amd64 Media Transfer Protocol (MTP) library

[Anonymous]

Rhythmbox 3.4.4 error message during MTP file sync.

[crvi]

Successive MTP sync works fine on Samsung Galaxy S10 via Rhythmbox.

[Marcus Meissner]

seems to come from gvfs gphoto slave I would say.

it would be good if you could get a gdb backtrace

[crvi]

There is not core file generated as part of the crash ( not sure how this is possible, as I've configured my machine to capture all crashes ). Hence no gdb backtrace. But the following analysis points to the right code I guess.

Some analysis at debian downstream bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948588#15

[Marcus Meissner]

I added a NULL pointer check. this seems to happen if an invalid ID gets passed to the function.