Bug 914 - SIGSEGV at the end of a decoder execution
Summary: SIGSEGV at the end of a decoder execution
Status: RESOLVED DUPLICATE of bug 902
Alias: None
Product: PulseView
Classification: Unclassified
Component: Protocol decoding (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-05 14:04 CET by Gerhard Sittig
Modified: 2017-03-12 15:01 CET (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Sittig 2017-03-05 14:04:25 CET
what I did (need not reliably reproduce, reports differ in IRC and Bugzilla):
start pulseview, pick demo device, add parallel decoder, hit "run" button 
(this time I was fortunate, first attempt failed with SIGSEGV)

ran the above pulseview under gdb, got this -l 4 output and backtrace:

...
srd: Done, handled all samples (abs cur 1000000 / abs end 1000000).
srd: Freeing instance parallel-1
srd: Destroyed session 1.
[New Thread 0x7fffd96a3700 (LWP 9350)]
[New Thread 0x7fffd8d53700 (LWP 9351)]
[New Thread 0x7fffd35fe700 (LWP 9352)]
[New Thread 0x7fffc7fff700 (LWP 9353)]
[Thread 0x7fffd8d53700 (LWP 9351) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc7fff700 (LWP 9353)]
__GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
66      ../nptl/pthread_mutex_lock.c: No such file or directory.

Thread 6 (Thread 0x7fffc7fff700 (LWP 9353)):
#0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
#1  0x00007ffff598a981 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff56fa477 in Decoder_wait (self=0x7fffe41d2d68, args=0x7fffe431deb8) at type_decoder.c:606
#3  0x00007ffff193f7a9 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#4  0x00007ffff1942936 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#5  0x00007ffff1942f66 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#6  0x00007ffff18a4718 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#7  0x00007ffff188a55d in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#8  0x00007ffff18a4718 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#9  0x00007ffff1895b3f in PyObject_CallMethod () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
#10 0x00007ffff56f7682 in di_thread (data=0x7fffc8001160) at instance.c:927
#11 0x00007ffff596df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff753f184 in start_thread (arg=0x7fffc7fff700) at pthread_create.c:312
#13 0x00007ffff4c0437d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
...

the thread in question was the first and only decoder thread in the process, 
log output suggests that the decoder session got destroyed and thus the 
decoder instance should have been released, yet the thread's routine 
still executed the infinite loop in Decoder_wait(), and accessed a NULL 
mutex reference in line 606

the current libsigrokdecode implementation starts threads for decoders, 
but does not terminate those threads, sigrok-cli less probably suffers 
from this implementation artifact than pulseview since the latter is 
more flexible and executes for longer periods of time with multiple 
sessions during its lifetime
Comment 1 Uwe Hermann 2017-03-12 15:01:12 CET
This seems to be a duplicate of bug #902, marking as such.

*** This bug has been marked as a duplicate of bug 902 ***