Hi Gerhard,
Many thanks for the response!
The previous implementation was flawed in the case of analog-only
data. Total absence of logic data resulted in a division by zero.
This got fixed in libsigrok 2cb4204c6f31. Will be part of the
next nightly build.
Fantastic - that explains it, thanks so much!
I just got the latest nightlies; apparently they are built with:
https://sigrok.org/jenkins/job/libsigrok/208/
... which builds revision 6bee394dee, which contains 2cb4204; so I now got
PulseView 0.5.0-git-d8cdab7 - and sigrok-cli 0.8.0-git-0e2f95c (which is the
same revision I've had in the OP, but built against libsigrok 6bee394dee).
And, I can happilly confirm, that this new PulseView succesfully opens the
stereo.vcd referred in the OP of this thread; and likewise sigrok-cli
successfully converts the .vcd into .sr!
Note that this .vcd file has a line like `$scope module
libsigrok $end` or similar, which will cause sigrok to print
this, if you try loading that .vcd file:
sr: input/vcd: Skipping scope with application's package name:
libsigrok
... so, I had to change that line to `$scope module top $end`.
Out of curiousity: Why do you _have_ to change that line? IIUC
the message does not show up by default, only at manually raised
log levels. Where it's shown for information, but is far from
fatal or anything to worry about.
Ah, yes - sorry about that, I should have clarified.
Well, at that point, I tried using sigrok-cli to convert the .vcd to .sr - but
the .sr file did not get generated.
So, when I saw that message, I interpreted the "Skipping scope" part of the message quite literally - I
thought that maybe sigrok, if it encounters a scope in the .vcd with the name 'libsigrok', it completely skips
processing the data contained that scope; and given that I did not otherwise get any other error message, it made sense
to me at the time. Of course, I thought: why would a scope data be ignored just because the scope is called
"libsigrok" - but I thought, maybe it's just some if/then that was intended to be a debugging check, but
leaked into production code. So, I thought, if I rename the scope, then I wouldn't trigger this part of the code that
"ignores" the data from a scope called "libsigrok", and then I would force the data to be processed
- but of course, since the problem was something completely different, this did not help.
However, if I then start a new PulseView session (PulseView
0.5.0-git-9d307c6, libsigrok 0.6.0-git-d7df9dc/4:0:0 (rt:
0.6.0-git-d7df9dc/4:0:0) on Windows 10), and I try importing
this stereo.vcd, then PulseView just shuts down, without any
error messages.
Out of interest: Did your platform not show the SIGFPE or similar
error cause that I got here when I tried?
Nope, it did not.
I usually work in a MSYS2 bash shell under Windows 10. On the other hand, as
far as I know, also sigrok/PulseView for Windows is built under a MSYS2 system
- but I doubt the MSYS2 I have installed, is exactly the same as the MSYS2 that
builds sigrok/PulseView.
So, I like it very much, that since the MSYS2 bash "knows" about stdout/stderr, I can get
messages printed from protocol decoders etc., if I start pulseview.exe in MSYS2 bash. Then again,
there's my MSYS2, calling Windows executable, which then refers to libraries etc built by a (likely
different) MSYS2 - so, I guess, it is maybe not very surprising that a signal might get
"lost"?
Then again, when I posted the OP, I used a command line which I often use, with
redirect to capture the messages output by PulseView to a file; that is:
$ "C:\Program Files (x86)\sigrok\PulseView\pulseview.exe" >
/tmp/pulseview-messages.log
So, I thought, maybe that "ate" any SIGFPE error message? But I just tried this
now, with the same version referred in the OP:
$ "C:\Program Files (x86)\sigrok\PulseView-0.5.0-git-9d307c6\pulseview.exe"
$
... and inside I start new session, import the .vcd, the program shuts down -
and there are no messages (and all of the messages from sigrok-cli were
reported in the OP, there was no SIGFPE reported there).
However, I repeated the same procedure running under `gdb` - and here SIGFPE is
visible:
```
$ gdb --args "C:\Program Files
(x86)\sigrok\PulseView-0.5.0-git-9d307c6\pulseview.exe"
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from C:\Program Files
(x86)\sigrok\PulseView-0.5.0-git-9d307c6\pulseview.exe...
(No debugging symbols found in C:\Program Files
(x86)\sigrok\PulseView-0.5.0-git-9d307c6\pulseview.exe)
(gdb) set pagination off
(gdb) r
Starting program: /c/Program Files
(x86)/sigrok/PulseView-0.5.0-git-9d307c6/pulseview.exe
[New Thread 6800.0x2094]
[New Thread 6800.0x3734]
[New Thread 6800.0x67c]
[New Thread 6800.0x3120]
[New Thread 6800.0x2380]
warning:
warning: AllK required contiguous memory = 534200 (64bit)
warning: 8 HotK Handles: HandleSize 2112 PoolSize 16912 (bytes)
warning: 64 LstK Handles: HandleSize 64 PoolSize 4112 (bytes)
warning: 1024 LstInfoK Handles: HandleSize 64 PoolSize 65552 (bytes)
warning: 64 UsbK Handles: HandleSize 96 PoolSize 6160 (bytes)
warning: 32 DevK Handles: HandleSize 112 PoolSize 3600 (bytes)
warning: 4096 OvlK Handles: HandleSize 104 PoolSize 426000 (bytes)
warning: 64 OvlPoolK Handles: HandleSize 96 PoolSize 6160 (bytes)
warning: 32 StmK Handles: HandleSize 176 PoolSize 5648 (bytes)
warning:
warning: Dynamically allocated as needed:
warning: KLST_DEVINFO = 2596 bytes each
[New Thread 6800.0x1de0]
[New Thread 6800.0x337c]
[New Thread 6800.0x3610]
[New Thread 6800.0x1d10]
[New Thread 6800.0x1630]
[New Thread 6800.0x7c8]
[New Thread 6800.0x20e8]
[New Thread 6800.0x2600]
[Thread 6800.0x2600 exited with code 0]
[New Thread 6800.0x226c]
[New Thread 6800.0x1fc4]
[New Thread 6800.0x77c]
[New Thread 6800.0x181c]
warning:
onecore\com\combase\dcomrem\security.cxx(3057)\combase.dll!00007FFF86115C5C:
(caller: 00007FFF70FB80AE) ReturnHr(1) tid(181c) 80010117 Call context cannot
be accessed after call completed.
[New Thread 6800.0xbc0]
[New Thread 6800.0x241c]
[New Thread 6800.0x21e0]
[New Thread 6800.0x332c]
[Thread 6800.0x21e0 exited with code 0]
[New Thread 6800.0x3fc4]
[New Thread 6800.0x2198]
[New Thread 6800.0x6ec]
[New Thread 6800.0x2e98]
[New Thread 6800.0x3c94]
[New Thread 6800.0x1c54]
[New Thread 6800.0x1f18]
[New Thread 6800.0x1574]
[New Thread 6800.0x2c90]
[Thread 6800.0x1574 exited with code 0]
[Thread 6800.0x7c8 exited with code 0]
Thread 1 received signal SIGFPE, Arithmetic exception.
0x00000000009ec95f in ?? ()
(gdb) q
A debugging session is active.
Inferior 1 [process 6800] will be killed.
Quit anyway? (y or n) y
```
However, with the new nightly PulseView, when I do the same procedure
(importing stereo.vcd in a new session, which here succeeds), then I get usual
messages printed in the terminal (again, the below is for PulseView
0.5.0-git-d8cdab7 with libsigrok 0.6.0-git-6bee394):
```
$ "C:\Program Files (x86)\sigrok\PulseView\pulseview.exe"
"Note for device developers: Ignoring device configuration capability 'Continuous
sampling' as it is missing GET and/or SET"
"Note for device developers: Ignoring device configuration capability 'Trigger
matches' as it is missing GET and/or SET"
"Note for device developers: Ignoring device configuration capability 'Continuous
sampling' as it is missing GET and/or SET"
"Note for device developers: Ignoring device configuration capability 'Trigger
matches' as it is missing GET and/or SET"
"Querying config key samplerate is not allowed"
sr: input/vcd: Suspiciously low overall change rate (total min TS delta 226).
sr: input/vcd: Suggest to downsample, value like 100.
Acquisition took 0.35 s
```
And for completeness, here is the log of new nightly sigrok-cli converting the
same stereo.vcd to .sr:
```
$ "C:\Program Files (x86)\sigrok\sigrok-cli\sigrok-cli.exe" -l 3 -i stereo.vcd
-o stereoB.sr
cli: Received SR_DF_HEADER.
cli: Received SR_DF_META.
cli: Got samplerate 10000000 Hz.
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (1048576 samples).
cli: Received SR_DF_ANALOG (562816 samples).
cli: Received SR_DF_ANALOG (562816 samples).
sr: input/vcd: Suspiciously low overall change rate (total min TS delta 226).
sr: input/vcd: Suggest to downsample, value like 100.
cli: Received SR_DF_END.
$ ls -la stereoB.sr
-rw-r--r-- 1 user None 469K Oct 23 14:45 stereoB.sr
```
Thanks again - great to see this working,
Best regards!
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
