On the DR-TES flight computer, I can reproduce crashes with the following steps:
1) delete .dastard directory
2) start dastard
3) connect to ABACO (UDP) source (with 32 channels in this case but I don't know that matters)
4) turn on a auto trigger with delay 0 (for 1 channel)
5) after a short time, dastard crashes with error message below
6) restart dastard
7) connect to ABACO (UDP) source
8) after a short time, dastard crashes. Same error message, just different goroutine number
I then tried the same above steps, but with all 32 channels for the auto trigger. This time dastard starts to allocate huge amounts of memory after step 4.
If, after step 3, I set the record length to a non-zero value, I don't get the crash. Similarly, if I edit the config.yaml file to make nsamples nonzero, I don't get the crash.
I'm not using dastardcommander for these tests, I'm using my own script to command dastard, that I'm writig for dr-tes. I'll attach that script.
Specifically, I run it like:
drtes.py udp 191.168.14.100 # to connect to UDP
drtes.py start_noise 1 # to start auto trigger
Error message:
This is DASTARD version 0.3.4pre2 (git commit 4521992)
Logging problems to /root/.dastard/logs/problems.log
Logging client updates to /root/.dastard/logs/updates.log
2024/08/23 13:49:37 Dastard config file: /root/.dastard/config.yaml
2024/08/23 13:49:52 New client connection established
2024/08/23 13:49:52 Starting data source named ABACOSOURCE
Sample rate for chan [4096-4127] 46875 /sec determined from 198 packets: Δt=0.050432 sec, Δserial=197, and 12.000 samp/packet
2024/08/23 13:50:52 New client connection established
2024/08/23 13:50:59 New client connection established
Panic! internal buffersChan full, len 100, capacity 100
panic: internal buffersChan full, len 100, capacity 100
goroutine 14 [running]:
github.com/usnistgov/dastard.(*AbacoSource).readerMainLoop(0xc0000e1188)
/dastard/abaco.go:1071 +0xdf7
created by github.com/usnistgov/dastard.(*AbacoSource).StartRun in goroutine 11
/dastard/abaco.go:951 +0xd6
This was dastard 0.3.4pre2 (git commit 4521992)
On the DR-TES flight computer, I can reproduce crashes with the following steps:
1) delete
.dastard
directory 2) start dastard 3) connect to ABACO (UDP) source (with 32 channels in this case but I don't know that matters) 4) turn on a auto trigger with delay 0 (for 1 channel) 5) after a short time, dastard crashes with error message below 6) restart dastard 7) connect to ABACO (UDP) source 8) after a short time, dastard crashes. Same error message, just different goroutine numberI then tried the same above steps, but with all 32 channels for the auto trigger. This time dastard starts to allocate huge amounts of memory after step 4.
If, after step 3, I set the record length to a non-zero value, I don't get the crash. Similarly, if I edit the
config.yaml
file to makensamples
nonzero, I don't get the crash.I'm not using
dastardcommander
for these tests, I'm using my own script to command dastard, that I'm writig for dr-tes. I'll attach that script.Specifically, I run it like:
Error message:
drcom.txt