Closed samkirkham closed 3 years ago
ok good to know. Would you have an example file you could send me for me to test? By that I mean somethinkg like an .Rdata
file containing the 49+ track AsspDataObj file? That would save me having to create a mock one from scratch...
thanks! Sure, see below - the object inside is just called 'ado' (and has 112 tracks). https://www.dropbox.com/s/ui708kf3nel9ai6/assp_example.RData?dl=0
Perfect! Thanks :-)
Found the issue: https://github.com/IPS-LMU/wrassp/blob/1411e0d4995d1f14b2c6f991e7b8194d9d8598ee/src/assp/headers.c#L2776 because C doesn't have variable size char arrays it was just assumed (as so often in the history of computing) by the libassp author that headers will never be larger thatn 1kB in size... would be an easy fix for the SSFF file just to say double or x10 that or something (already tried it and if fixes your issue). But that assumption is also used for various other formats throughout the lib and I don't know if it is worth it TBH. Do you think you'd benefit from larger SSFF file header sizes in the future (i.e. more tracks in a single file)?
Ok, thanks a lot! If changing this breaks assumptions made elsewhere then I would suggest not bothering with it. I only raised this as my default approach was to write fewer files to disk, thereby having more tracks in each file. However, I've subsequently re-written my function to write a single file per sensor (i.e. only ~20 tracks per file), so it is possible to sidestep this issue via a perfectly reasonable alternative. Happy for you to close if you think appropriate. Thanks again!
I'll see if I can't at least catch the error somehow... crashing the entire R session isn't great behaviour on our end ;-)
now catching error in C-lib. Will leave the max size at 1KB as the error says what the limit is.
write.AsspDataObj() causes R to crash when the AsspDataObj contains more than 48 tracks. Objects are binary SSFF format containing EMA sensor data in REAL32 track format. Tested on R 4.0.5; wrassp 1.0.0; Mac OS 11.2.3.
The ‘In Memory Assp Data object’ is returned for the higher track counts (i.e. 112 tracks), so it appears that writing to file is causing the crash. A 48 track object writes, but a 49 track object crashes for the same operation. Different combinations of 48 tracks work fine, so it seems to be the track count rather than anything in the data.
This is not a critical problem as I can write multiple SSFF files instead of one big one, but raising it an issue in case there are known limits on track numbers or header size.
possibly related to issue #32 re: header size?