Created attachment 624 [details] show a message instead of libusb calls with null It appears that during a scan, sr_usb_dev_inst_new is only called with NULL for devhdl. I don't see where this is set anywhere else; I get the same signal and stack trace regardless of whether it's run as root so I don't think it's a perms issue. A patch to just print a message and not try to download is attached, but I don't know if this is the right fix. I'd appreciate some advice, on where this might be set or other paths I should exercise in testing. (gdb) run Starting program: /usr/bin/sigrok-cli --scan [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7ffff6bc4700 (LWP 1227377)] sr: serial-libsp: Attempt to open serial port with invalid parameters. sr: serial-libsp: Attempt to open serial port with invalid parameters. The following devices were found: demo - Demo device with 13 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 A4 sysclk-lwla - Sysclk LWLA1034 with 34 channels: CH1 CH2 CH3 CH4 CH5 CH6 CH7 CH8 CH9 CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH17 CH18 CH19 CH20 CH21 CH22 CH23 CH24 CH25 CH26 CH27 CH28 CH29 CH30 CH31 CH32 CH33 CH34 Thread 1 "sigrok-cli" received signal SIGSEGV, Segmentation fault. ... (gdb) bt #0 0x00007ffff797c689 in do_sync_bulk_transfer (dev_handle=0x0, endpoint=endpoint@entry=4 '\004', buffer=buffer@entry=0x5555555c29d0 "", length=length@entry=48525, transferred=transferred@entry=0x7fffffffe040, timeout=timeout@entry=1000, type=2 '\002') at sync.c:177 #1 0x00007ffff797ca2f in libusb_bulk_transfer (dev_handle=<optimized out>, endpoint=endpoint@entry=4 '\004', data=data@entry=0x5555555c29d0 "", length=length@entry=48525, transferred=transferred@entry=0x7fffffffe040, timeout=timeout@entry=1000) at sync.c:281 #2 0x00007ffff7f01eba in lwla_send_bitstream (ctx=0x55555558ecf0, usb=0x5555555b62d0, name=name@entry=0x7ffff7f23c00 <bitstream_map> "sysclk-lwla1034-off.rbf") at src/hardware/sysclk-lwla/lwla.c:96 #3 0x00007ffff7f031cf in apply_fpga_config (sdi=<optimized out>) at src/hardware/sysclk-lwla/lwla1034.c:326 #4 0x00007ffff7f04212 in dev_close (sdi=<optimized out>) at src/hardware/sysclk-lwla/api.c:303 #5 0x00007ffff7e8491f in std_dev_clear_with_callback (driver=0x7ffff7f70060 <sysclk_lwla_driver_info>, clear_private=0x0) at src/std.c:449 #6 0x00007ffff7e84405 in std_cleanup (di=0x7ffff7f70060 <sysclk_lwla_driver_info>) at src/std.c:98 #7 0x00007ffff7e7fdd3 in sr_hw_cleanup_all (ctx=ctx@entry=0x55555558ecf0) at src/hwdriver.c:578 #8 0x00007ffff7e7bf6e in sr_exit (ctx=0x55555558ecf0) at src/backend.c:647 #9 0x00005555555590c5 in main (argc=<optimized out>, argv=<optimized out>) at main.c:279 Just for reference, [tim@rygel ~]$ ls -l /dev/bus/usb/004/ total 0 crw-rw-r-- 1 root root 189, 384 Apr 15 09:40 001 crw-rw-r-- 1 root root 189, 385 Apr 15 09:40 002 crw-rw-r-- 1 root root 189, 409 Apr 21 12:19 026 crw-rw-r-- 1 root root 189, 410 Apr 21 12:19 027 crw-rw-r-- 1 root root 189, 411 Apr 21 12:19 028 crw-rw-r-- 1 root root 189, 412 Apr 21 12:19 029 crw-rw-r-- 1 root root 189, 413 Apr 21 12:19 030 crw-rw-r--+ 1 root root 189, 417 Apr 23 07:39 034 [tim@rygel libsigrok]$ sigrok-cli --version sigrok-cli 0.7.1-git-4dd58271c1b Libraries and features: - libsigrok 0.5.2-git-4dd58271c1b/5:1:1 (rt: 0.5.2-git-4dd58271c1b/5:1:1). - Libs: - glib 2.64.1 (rt: 2.64.1/6401:1) - libzip 1.6.1 - libserialport 0.1.1/1:0:1 (rt: 0.1.1/1:0:1) - libusb-1.0 1.0.23.11397 API 0x01000107 - bluez 5.54 - libftdi 1.4 - Host: x86_64-pc-linux-gnu, little-endian. - SCPI backends: TCP, serial, USBTMC. - libsigrokdecode 0.5.3/6:1:2 (rt: 0.5.3/6:1:2). - Libs: - glib 2.62.3 (rt: 2.64.1/6401:1) - Python 3.8.0 / 0x30800f0 (API 1013, ABI 3) - Host: x86_64-pc-linux-gnu, little-endian. (On Arch, these are the same as the packaged versions but rebuilt to get debug symbols.)
I don't have the HW, just looked at the code. Your patch seems correct to me because apply_fpga_config() calls libusb as well, so this call must be protected by the check for a valid 'devhdl', too. I'd just think that your warning in the else branch should be a debug output. It seems normal that it is called with NULL during scan, or?