There seems to be a bug somewhere that causes a segfault upon shutting down the rigol-ds driver (tested with DS1052E). Happens with both sigrok-cli and PulseView. Happens on Linux and Windows. The driver works fine otherwise, just the shutdown has the problem. I haven't checked whether this is a more generic issue with all scpi-based drivers or not. sigrok-cli: $ sigrok-cli --scan -l 5 [...] The following devices were found: demo - Demo device with 12 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 rigol-ds - Rigol DS1102E 00.02.02.02.00 with 2 channels: CH1 CH2 sr: [00:02.610917] hwdriver: Cleaning up all drivers. Segmentation fault (core dumped) #0 0x00007f6583cb60d1 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #1 0x00007f6583cb64ef in libusb_bulk_transfer () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #2 0x00007f65851c5952 in scpi_usbtmc_bulkout (uscpi=uscpi@entry=0x557832b49bd0, msg_id=msg_id@entry=1 '\001', data=data@entry=0x557832b49960, size=<optimized out>, transfer_attributes=transfer_attributes@entry=1 '\001') at ../src/scpi/scpi_usbtmc_libusb.c:487 #3 0x00007f65851c5a0c in scpi_usbtmc_libusb_send (priv=0x557832b49bd0, command=0x557832b49960 ":KEY:LOCK DISABLE\n") at ../src/scpi/scpi_usbtmc_libusb.c:559 #4 0x00007f65851c0340 in sr_scpi_send_variadic (scpi=0x557832b57ff0, format=0x7f6585235754 ":KEY:LOCK DISABLE", args=args@entry=0x7fffa0a64318) at ../src/scpi/scpi.c:305 #5 0x00007f658520a166 in rigol_ds_config_set (sdi=0x557832b57740, format=format@entry=0x7f6585235754 ":KEY:LOCK DISABLE") at ../src/hardware/rigol-ds/protocol.c:314 #6 0x00007f658520b976 in dev_close (sdi=<optimized out>) at ../src/hardware/rigol-ds/api.c:427 #7 0x00007f65851b3c63 in std_dev_clear_with_callback (driver=0x7f658546de60 <rigol_ds_driver_info>, clear_private=0x7f658520bcf0 <clear_helper>) at ../src/std.c:459 #8 0x00007f65851b3793 in std_cleanup (di=0x7f658546de60 <rigol_ds_driver_info>) at ../src/std.c:96 #9 0x00007f65851af6fb in sr_hw_cleanup_all (ctx=ctx@entry=0x557832b39270) at ../src/hwdriver.c:560 #10 0x00007f65851abd3e in sr_exit (ctx=0x557832b39270) at ../src/backend.c:618 #11 0x00005578315855b7 in main (argc=<optimized out>, argv=<optimized out>) at ../main.c:278 PulseView: #0 0x00007fbf2f8de0d1 in () at /lib/x86_64-linux-gnu/libusb-1.0.so.0 #1 0x00007fbf2f8de4ef in libusb_bulk_transfer () at /lib/x86_64-linux-gnu/libusb-1.0.so.0 #2 0x00007fbf33745952 in scpi_usbtmc_bulkout (uscpi=uscpi@entry=0x555ab5163610, msg_id=msg_id@entry=1 '\001', data=data@entry=0x555ab514f260, size=<optimized out>, transfer_attributes=transfer_attributes@entry=1 '\001') at ../src/scpi/scpi_usbtmc_libusb.c:487 #3 0x00007fbf33745a0c in scpi_usbtmc_libusb_send (priv=0x555ab5163610, command=0x555ab514f260 ":KEY:LOCK DISABLE\n") at ../src/scpi/scpi_usbtmc_libusb.c:559 #4 0x00007fbf33740340 in sr_scpi_send_variadic (scpi=0x555ab52530e0, format=0x7fbf337b5754 ":KEY:LOCK DISABLE", args=args@entry=0x7ffec99eb848) at ../src/scpi/scpi.c:305 #5 0x00007fbf3378a166 in rigol_ds_config_set (sdi=0x555ab5253f70, format=format@entry=0x7fbf337b5754 ":KEY:LOCK DISABLE") at ../src/hardware/rigol-ds/protocol.c:314 #6 0x00007fbf3378b976 in dev_close (sdi=<optimized out>) at ../src/hardware/rigol-ds/api.c:427 #7 0x00007fbf33733c63 in std_dev_clear_with_callback (driver=0x7fbf339ede60 <rigol_ds_driver_info>, clear_private=0x7fbf3378bcf0 <clear_helper>) at ../src/std.c:459 #8 0x00007fbf33733793 in std_cleanup (di=0x7fbf339ede60 <rigol_ds_driver_info>) at ../src/std.c:96 #9 0x00007fbf3372f6fb in sr_hw_cleanup_all (ctx=ctx@entry=0x555ab4ee9540) at ../src/hwdriver.c:560 #10 0x00007fbf3372bd3e in sr_exit (ctx=0x555ab4ee9540) at ../src/backend.c:618 #11 0x00007fbf33a29d3d in sigrok::Context::~Context() (this=0x555ab4ee7ca0, __in_chrg=<optimized out>) at ../bindings/cxx/classes.cpp:193 #12 0x00007fbf33a36362 in std::default_delete<sigrok::Context>::operator()(sigrok::Context*) const (this=<optimized out>, __ptr=0x555ab4ee7ca0) at /usr/include/c++/7/bits/unique_ptr.h:78 #13 0x00007fbf33a36362 in std::_Sp_counted_deleter<sigrok::Context*, std::default_delete<sigrok::Context>, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (this=<optimized out>) at /usr/include/c++/7/bits/shared_ptr_base.h:470 #14 0x0000555ab2de3736 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (this=0x555ab4ef3730) at /usr/include/c++/7/bits/shared_ptr_base.h:154 #15 0x00007fbf3078a831 in __run_exit_handlers (status=0, listp=0x7fbf30b07718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #16 0x00007fbf3078a92a in __GI_exit (status=<optimized out>) at exit.c:139 #17 0x00007fbf30774a8e in __libc_start_main (main=0x555ab2de0cf0 <main(int, char**)>, argc=5, argv=0x7ffec99ebb28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffec99ebb18) at ../csu/libc-start.c:344 #18 0x0000555ab2de320a in _start ()
Does this always occur or only under specific circumstances?
Happens always upon sr_exit(), regardless of circumstances. For later analysis, here's a log with -fsanitize=address: AddressSanitizer:DEADLYSIGNAL ================================================================= ==34798==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7f3fc9f55bb9 bp 0x7ffe6dd0fa20 sp 0x7ffe6dd0f950 T0) ==34798==The signal is caused by a READ memory access. ==34798==Hint: address points to the zero page. #0 0x7f3fc9f55bb8 (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xbbb8) #1 0x7f3fc9f55f4e in libusb_bulk_transfer (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xbf4e) #2 0x7f3fcb9a307a in scpi_usbtmc_bulkout ../src/scpi/scpi_usbtmc_libusb.c:504 #3 0x7f3fcb9a38af in scpi_usbtmc_libusb_send ../src/scpi/scpi_usbtmc_libusb.c:576 #4 0x7f3fcb97e59f in scpi_send_variadic ../src/scpi/scpi.c:164 #5 0x7f3fcb97f9da in sr_scpi_send_variadic ../src/scpi/scpi.c:499 #6 0x7f3fcbafb47d in rigol_ds_config_set ../src/hardware/rigol-ds/protocol.c:314 #7 0x7f3fcbb023b6 in dev_close ../src/hardware/rigol-ds/api.c:476 #8 0x7f3fcb945458 in std_dev_clear_with_callback ../src/std.c:449 #9 0x7f3fcbb00ad3 in dev_clear ../src/hardware/rigol-ds/api.c:309 #10 0x7f3fcb92d8e5 in sr_dev_clear ../src/device.c:644 #11 0x7f3fcb9447fa in std_cleanup ../src/std.c:98 #12 0x7f3fcb938067 in sr_hw_cleanup_all ../src/hwdriver.c:574 #13 0x7f3fcb92b696 in sr_exit ../src/backend.c:647 #14 0x7f3fcbcf3c1c in sigrok::Context::~Context() ../bindings/cxx/classes.cpp:221 #15 0x7f3fcbcfe1f1 in std::default_delete<sigrok::Context>::operator()(sigrok::Context*) const /usr/include/c++/9/bits/unique_ptr.h:81 #16 0x7f3fcbcfe1f1 in std::default_delete<sigrok::Context>::operator()(sigrok::Context*) const /usr/include/c++/9/bits/unique_ptr.h:75 #17 0x7f3fcbcfe1f1 in std::_Sp_counted_deleter<sigrok::Context*, std::default_delete<sigrok::Context>, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() /usr/include/c++/9/bits/shared_ptr_base.h:471 #18 0x5641591f0372 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/9/bits/shared_ptr_base.h:155 #19 0x5641591ef173 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/9/bits/shared_ptr_base.h:730 #20 0x564159208a85 in std::__shared_ptr<sigrok::Context, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/9/bits/shared_ptr_base.h:1169 #21 0x564159208aa1 in std::shared_ptr<sigrok::Context>::~shared_ptr() /usr/include/c++/9/bits/shared_ptr.h:103 #22 0x7f3fca02d71f in __run_exit_handlers /build/glibc-suXNNi/glibc-2.29/stdlib/exit.c:108 #23 0x7f3fca02d859 in __GI_exit /build/glibc-suXNNi/glibc-2.29/stdlib/exit.c:139 #24 0x7f3fca017bc1 in __libc_start_main ../csu/libc-start.c:342 #25 0x5641591d3b69 in _start (/home/uwe/sr/bin/pulseview+0x479b69) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xbbb8) ==34798==ABORTING
Duplicate of bug #1275?
Fixed in 9b093606545ec3963a03a3cfac61954c62e93e10, thanks! I tested this on a Rigol DS1052E, a segfault that happened before the patch is indeed not happening anymore after the patch.