Summary: | Pulseview crashes when using two PWM decoders | ||
---|---|---|---|
Product: | PulseView | Reporter: | Baruch Even <baruch> |
Component: | Other | Assignee: | Nobody <nobody> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | joel, uwe |
Priority: | Normal | ||
Version: | unreleased development snapshot | ||
Target Milestone: | PulseView 0.3.0 | ||
Hardware: | x86 | ||
OS: | Linux |
Description
Baruch Even
2015-02-18 12:21:42 CET
Another core when I tried to start recording with two PWM decoders: #0 0x00007f909441e46b in PyObject_SetAttr () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #1 0x00007f909455d585 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #2 0x00007f9094562843 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #3 0x00007f90944e2629 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #4 0x00007f9094474ea8 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #5 0x00007f909459abad in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #6 0x00007f9094474ea8 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #7 0x00007f90944753f4 in PyObject_CallMethod () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 #8 0x00007f90949de0be in srd_inst_decode (di=0x7f9084781d80, start_samplenum=start_samplenum@entry=0, end_samplenum=end_samplenum@entry=12288, inbuf=inbuf@entry=0x7f907e09ee20 '\365' <repeats 199 times>, <incomplete sequence \365>..., inbuflen=inbuflen@entry=4096) at instance.c:610 #9 0x00007f90949dbf3c in srd_session_send (sess=<optimized out>, start_samplenum=0, end_samplenum=12288, inbuf=0x7f907e09ee20 '\365' <repeats 199 times>, <incomplete sequence \365>..., inbuflen=4096) at session.c:247 #10 0x0000000000499710 in pv::data::DecoderStack::decode_data (this=this@entry=0x16b73f0, sample_count=sample_count@entry=12288, unit_size=unit_size@entry=1, session=0x7f9084793b20) at /home/baruch/proj/sigrok/pulseview/pv/data/decoderstack.cpp:316 #11 0x000000000049a099 in pv::data::DecoderStack::decode_proc (this=0x16b73f0) at /home/baruch/proj/sigrok/pulseview/pv/data/decoderstack.cpp:381 #12 0x00007f9094144970 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #13 0x00007f9096ef80a4 in start_thread (arg=0x7f907e0a0700) at pthread_create.c:309 #14 0x00007f90938b404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 bt full of the second crash: #0 0x00007f909441e46b in PyObject_SetAttr () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #1 0x00007f909455d585 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #2 0x00007f9094562843 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #3 0x00007f90944e2629 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #4 0x00007f9094474ea8 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #5 0x00007f909459abad in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #6 0x00007f9094474ea8 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #7 0x00007f90944753f4 in PyObject_CallMethod () from /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 No symbol table info available. #8 0x00007f90949de0be in srd_inst_decode (di=0x7f9084781d80, start_samplenum=start_samplenum@entry=0, end_samplenum=end_samplenum@entry=12288, inbuf=inbuf@entry=0x7f907e09ee20 '\365' <repeats 199 times>, <incomplete sequence \365>..., inbuflen=inbuflen@entry=4096) at instance.c:610 py_res = <optimized out> logic = 0x7f907ce43770 #9 0x00007f90949dbf3c in srd_session_send (sess=<optimized out>, start_samplenum=0, end_samplenum=12288, inbuf=0x7f907e09ee20 '\365' <repeats 199 times>, <incomplete sequence \365>..., inbuflen=4096) at session.c:247 d = 0x7f908400d050 ret = <optimized out> #10 0x0000000000499710 in pv::data::DecoderStack::decode_data (this=this@entry=0x16b73f0, sample_count=sample_count@entry=12288, unit_size=unit_size@entry=1, session=0x7f9084793b20) at /home/baruch/proj/sigrok/pulseview/pv/data/decoderstack.cpp:316 decode_lock = {_M_device = @0x6e20c0} i = 0 chunk = '\365' <repeats 4095 times>... chunk_sample_count = 4096 #11 0x000000000049a099 in pv::data::DecoderStack::decode_proc (this=0x16b73f0) at /home/baruch/proj/sigrok/pulseview/pv/data/decoderstack.cpp:381 sample_count = {<boost::optional_detail::optional_base<long>> = {<boost::optional_detail::optional_tag> = {<No data fields>}, m_initialized = true, m_storage = {dummy_ = {data = "\000\060\000\000\000\000\000", aligner_ = {<No data fields>}}}}, <No data fields>} session = 0x7f9084793b20 prev_di = <optimized out> unit_size = 1 ---Type <return> to continue, or q <return> to quit--- #12 0x00007f9094144970 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 No symbol table info available. #13 0x00007f9096ef80a4 in start_thread (arg=0x7f907e0a0700) at pthread_create.c:309 __res = <optimized out> pd = 0x7f907e0a0700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140258566604544, -6048740080364248326, 0, 23045904, 18, 140258566604544, 5993854469987148538, 5994189050437870330}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #14 0x00007f90938b404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. This is probably an issue with not being able to run multiple libsigrokdecode engines concurrently! This does look like a dup of #181 and you have a few backtraces that may help here. Running two decoders at the same time is currently not easily supportable. I think PulseView has/had a mechanism to avoid running multiple PDs at the same time, maybe that needs some (re)fixing. Long-term we do want to support this use-case of course, but it's nontrivial; for now avoiding multiple concurrently running PDs in frontends is the safe thing. |