(gdb) run Starting program: /home/karlp/.local/bin/pulseview Missing separate debuginfos, use: dnf debuginfo-install glibc-2.22-16.fc23.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffde3d8700 (LWP 7672)] sr: saleae-logic16: Failed to init device. sr: saleae-logic16: Failed to init device. [New Thread 0x7fffd9a40700 (LWP 7676)] [New Thread 0x7fffd9216700 (LWP 7678)] [Thread 0x7fffd9216700 (LWP 7678) exited] [New Thread 0x7fffd9216700 (LWP 7684)] [Thread 0x7fffd9216700 (LWP 7684) exited] [New Thread 0x7fffd9216700 (LWP 7685)] [Thread 0x7fffd9216700 (LWP 7685) exited] [New Thread 0x7fffd9216700 (LWP 7686)] [Thread 0x7fffd9216700 (LWP 7686) exited] [New Thread 0x7fffd9216700 (LWP 7687)] [Thread 0x7fffd9216700 (LWP 7687) exited] [New Thread 0x7fffd9216700 (LWP 7697)] [Thread 0x7fffd9216700 (LWP 7697) exited] [New Thread 0x7fffd9216700 (LWP 7698)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd9216700 (LWP 7698)] 0x00007ffff595435f in soft_trigger_logic_check (stl=0x7fffcc0182d0, buf=0x7fffcc002e00 "\003", len=len@entry=81920, pre_trigger_samples=pre_trigger_samples@entry=0x7fffd921597c) at src/soft-trigger.c:166 166 if (!stage->matches) No backtrace, at this point my display was locked up, I had to ctrl-alt-f3 to get to a new terminal to kill stuff to try and regain control. Steps to reproduce: Set falling edge trigger on two channels. Start capture. Notice that it's not an OR of the triggers, but an AND. Click on one channel to turn it's trigger of, and select the "dot" to turn it's trigger off. (While acquisition still running) The "failed to init" line items are incorrect, this is the mcupro version that doesn't need bitstream inits.
*** Bug 846 has been marked as a duplicate of this bug. ***
Just noting that this still happens with current builds too
This makes logic16 compatible devices *very* hard to use, as if you forget to check that the capture definitely isn't running before switching trigger, you lose all your data.
The straightforward out of this is to simply disallow changing the trigger settings while an acquisition is "running" state. When in "waiting for trigger" state and no data has been captured yet, it's feasible to stop the session, reconfigure the trigger and restart it. Otherwise, changing triggers would be disallowed in that state as well. Allowing triggers to be changed during a running acquisition is possible with soft triggers but once a hardware device with built-in triggers is involved, this may not be supported and yield unexpected results. That's why I think the straightforward approach is also the least complex one.
Fixed in f02b6a98dc19c0c076760239e6a394fb370a24ef, thanks!