veegee has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<d1b2>
<lle_bout> Right, that's what I did just afterwards, I decided to uninstall and run from the build directory, however the manual was suggesting to install so I did - I don't think it's really a priority issue so no rush just wanted to report I may as well create a proper Github issue if you think you'll forget - as of now I have not been able to get ngscopeclient to display a proper waveform on the screen from my Rigol MSO5074, I didnt try for very long
<d1b2>
but I gotta read the manual more I guess. It kept freezing again and again when trying to 'start' and I tried to plug my probes to something that sent some Signal
bvernoux has joined #scopehal
<juh>
lle_bout: tried starting it with --debug? iirc if it doesn’t list your gpu you’re in for a hard time
<d1b2>
<azonenberg> Which transport were you using to connect to the scope?
<d1b2>
<azonenberg> you can add --trace SCPISocketTransport (or as appropriate for the selected transport) to log every command and reply sent to the scope to stdout
<d1b2>
<lle_bout> juh, @azonenberg: I think it may have been an OOM/swap thrashing issue since it got killed from OOM once, today it seems to work, I have 16GB total memory and less Firefox tabs open today. I am using 'lan' transport, my GPU is Intel Iris Plus Graphics right now. Got the first Waveform display just now.
<d1b2>
<lle_bout> Today I also used my bare hands as a signal source instead
<d1b2>
<azonenberg> Yes it does like lots of memory. Improving handling of low-memory situations (especially low GPU memory) is on the wishlist
<azonenberg>
I recently added some code to detect the amount of available CPU/GPU side memory, but it doesn't *do* anything with that data yet
<d1b2>
<lle_bout> OK! Well I also have an external thunderbolt 3 GPU but it's not plugged in now
<azonenberg>
eventually the plan is to add intelligent fallback when you dont have enough memory
<azonenberg>
e.g. reducing history depth or not allowing captures more than X points or something
<azonenberg>
or even paging old waveforms out to disk
<d1b2>
<lle_bout> Sometimes it says in logs Socket read error resource temporarily unavailable something
<d1b2>
<lle_bout> It hangs for a little while then begins working again after some sort of time-out
<d1b2>
<lle_bout> Seems to happen when I rub my oscilloscope probe a bit too vigorously maybe it's because it triggers many times in a row?
<azonenberg>
Looks to me like that's the firmware hanging. you're asking for waveform data and it's not coming back
<azonenberg>
It might be a timeout in the read where the scope responds but the waveform takes too long to come back
<azonenberg>
or the socpe might be actually locking up, idk
<d1b2>
<lle_bout> oops, I restarted and tried connecting to the scope and heap corruption, it wouldnt connect somehow, the scope was in STOP mode at the time: Connecting to SCPI device at 10.42.0.168:5555 Warning: Socket read failed (errno=11, Resource temporarily unavailable) malloc(): corrupted top size Aborted (core dumped)
<azonenberg>
Sounds like we have two separate problems then
<azonenberg>
a) driver crashes when the scope derps like this
<azonenberg>
b) scope froze
<azonenberg>
try power cycling the scope (and updating to latest firmware if you haven't already)
<d1b2>
<lle_bout> Yeah for sure those arent same problems, I'm just sending what I see, scope is latest I updated yesterday
<azonenberg>
Buggy scope firmware is the bane of our existence for this project and one of the big reasons we like working with higher end gear like pico or lecroy
<d1b2>
<lle_bout> I understand, my budget is not very big, individual here
<azonenberg>
yeah
<azonenberg>
Which is why we do our best to support the less $$$ scopes
<azonenberg>
It's just hard because the firmware teds to be buggier, and when we find a bug it often takes a long time to get it fixed, if it ever is at all
<azonenberg>
we have a lot of workarounds like e.g. rate limiting commands to siglent scopes because the firmware hangs if you send commands too fast
<azonenberg>
or wait no, it doesnt hang it just silently ignores the command :;
<azonenberg>
:p
<d1b2>
<lle_bout> My body fingers just send 50Hz it seems
<azonenberg>
If you're touching a probe with your finger, you're acting like an antenna and picking up ambient EM fields
<azonenberg>
assuming you're in a country that uses 50 Hz power there's a lot of that to be found anywhere you look :p
<d1b2>
<lle_bout> The Rigol driver needs debugging it seems
<d1b2>
<lle_bout> I'll rebuild in debug mode
<azonenberg>
So most likely what's happening wrt the crash is that it fails to acquire the waveform data
<azonenberg>
then crashes assuming it got all the data
<azonenberg>
the problem is, in most cases in this kind of a hang it's difficult or impossible to re-synchronize to the scope
<azonenberg>
and get back to a clean state
<azonenberg>
We had this problem with the Tek MSO6 driver some time ago and found a bunch of hacks to make it happen less often, and leaned on tek to fix the bugs
<azonenberg>
and i think it's decently reliable now
<azonenberg>
We do not, as a project, currently have any kind of relationship with rigol. If you find specific bugs in the firmware feel free to reach out to them yourself and beg them for a fix which may or may not come :p
<azonenberg>
failing that, your best option is just to figure out what triggers the problem and avoid doing that. Which might mean limiting intervals between commands, or max waveform depth, or not sending one particular command after another, or who knows
<d1b2>
<lle_bout> Yes don't worry, I'm not expecting you to fix anything here, for now I'll try debugging the segfault and heap memory corruption that happened which no matter what Rigol does should not happen, so I'm trying to get it to compile with the various Clang sanitizers for help.
<azonenberg>
Yeah agreed
<azonenberg>
Most likely what's happening is that a read is failing, then something else is reading garbage assuming the buffer has valid data in it. Or reading waveform data expecting a response to another command
<azonenberg>
The SCPISocketTransport constructor IIRC sets a 5 second timeout for reads
<azonenberg>
you can try increasing that temporarily and see what happens
<d1b2>
<lle_bout> I see you have cmake option for sanitizers already, so I compiled with -DSANITIZE=true
<azonenberg>
Yeah. We have a cmake option for static analysis but i dont think it's enabled for CI builds right now
<azonenberg>
because clang-analyzer took forever to run