Bug 829 - PulseView crashes, possibly due to obsolete/no-longer-correct stored config
Summary: PulseView crashes, possibly due to obsolete/no-longer-correct stored config
Status: RESOLVED FIXED
Alias: None
Product: PulseView
Classification: Unclassified
Component: Other (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-11 17:57 CEST by Uwe Hermann
Modified: 2017-03-08 02:23 CET (History)
2 users (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Hermann 2016-09-11 17:57:20 CEST 
There's a crash in PulseView in certain situations. Example:

 - Place the DSO-2090 firmware in the correct location.
 - Attach a DSO 2090 to USB
 - Start PV
 - DSO-2090 works
 - Close PV

Now remove the firmware from where libsigrok expects it, then

 - Start PV (which will crash now)

I'm assuming PV now remembers the DSO-2090 as being the last-used device which causes the crash (just a guess, though).

Either way, not being able to find the firmware (or any other kinds of errors) should not crash PV here, though. It should show an error message and select no device or such, instead.

Backtrace:

[New Thread 0x7fffdecea700 (LWP 18136)]
sr: [00:00.953538] hantek-dso: Unable to open device.
terminate called after throwing an instance of 'QString'

Thread 1 "pulseview" received signal SIGABRT, Aborted.
0x00007ffff3c5a198 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Thread 4 (Thread 0x7fffdecea700 (LWP 18136)):
#0  0x00007ffff3d0509d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff599c1f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff599c30c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff4b4051b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff4ae819a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff490de53 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007fffe9e4b525 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007ffff4912d78 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff6a74444 in start_thread (arg=0x7fffdecea700) at pthread_create.c:333
#9  0x00007ffff3d0e20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7fffe3fff700 (LWP 18135)):
#0  0x00007ffff3d0509d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff2dcbb3c in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x00007ffff6a74444 in start_thread (arg=0x7fffe3fff700) at pthread_create.c:333
#3  0x00007ffff3d0e20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7fffe8de4700 (LWP 18134)):
#0  0x00007ffff3d0509d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff0160340 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ffff0161f39 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007ffff7e64a79 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007ffff4912d78 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff6a74444 in start_thread (arg=0x7fffe8de4700) at pthread_create.c:333
#6  0x00007ffff3d0e20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7ffff7f44780 (LWP 18130)):
#0  0x00007ffff3c5a198 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff3c5b61a in __GI_abort () at abort.c:89
#2  0x00007ffff457504d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff4573016 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff4573061 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff45732c9 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x000000000048d16c in pv::Session::set_device (this=this@entry=0xa757f0, device=std::shared_ptr (empty) 0x0) at [...]/pulseview/pv/session.cpp:397
#7  0x000000000048f71e in pv::Session::restore_settings (this=0xa757f0, settings=...) at [...]/pulseview/pv/session.cpp:290
#8  0x000000000047c0fd in pv::MainWindow::restore_ui_settings (this=this@entry=0x7fffffffdf50) at [...]/pulseview/pv/mainwindow.cpp:350
#9  0x000000000047c470 in pv::MainWindow::MainWindow (this=0x7fffffffdf50, device_manager=..., open_file_name="", 
    open_file_format="\020\337\377\377\377\177", '\000' <repeats 18 times>, "@\232\323\364\377\177\000\000@\340~\000\000\000\000\000\320\177\200\000\000\000\000\000\000\244\214\000\000\000\000\000\060\264\214\000\000\000\000\000\002\000\000\000\000\000\000\000P\352x\000\000\000\000\000\020\371v\000\000\000\000\000\340\230\245\000\000\000\000\000\320\372v\000\000\000\000\000\000\000\243\364\377\177\000\000\000\000\000\000\000\000\000\000\020\232\245\000\000\000\000\000 \337\377\377\377\177\000\000\340]\214\000\000\000\000\000\340]\214\000\000\000\000\000\001\000\000\000\000\000\000\000=", '\000' <repeats 15 times>, "\360W\265\000\000\000\000\000\360W\265\000\000\000\000\000\360W\265\000\000\000\000\000"..., parent=<optimized out>) at [...]/pulseview/pv/mainwindow.cpp:79
#10 0x000000000046f863 in main (argc=<optimized out>, argv=<optimized out>) at [...]/pulseview/main.cpp:164
A debugging session is active.
Comment 1 Soeren Apel 2016-09-18 20:21:34 CEST 
Note to self: the set_device(device) call in restore_settings() doesn't handle exceptions thrown by set_device(). It should, so that PV can fail gracefully.
Comment 2 Uwe Hermann 2017-03-08 02:23:45 CET 
Fixed in bcd64b9b7ae8187a9519c374e2552f6a00904251, thanks!

It no longer crashes, but also doesn't show an error. That's another issue that affects various other devices as well, though (and I think there's an open bug for it already).