My freshly built simulator is crashing instantly after startup. I managed to debug the process and traced it back to this line:
secs = -1 which causes the crash.
I’m building and running using MinGW.
My freshly built simulator is crashing instantly after startup. I managed to debug the process and traced it back to this line:
secs = -1 which causes the crash.
I’m building and running using MinGW.
What are the values of ticks
and poweron_sec_since_epoch
before the exception?
Yeah, I’m also curious how this is happening. The simulator calls ticks_to_fattime(0)
early on (I think when mounting the virtual assets FAT volume), so for secs
to be -1, then poweron_sec_since_epoch
would also need to be -1.
Could you try putting a printf before the line you highlighted (that is, at the top of the ticks_to_fattime function), like this:
printf("poweron_sec_since_epoch = %lld, size=%zu\n", poweron_sec_since_epoch, sizeof(poweron_sec_since_epoch));
And see what values you get? time_t
and some stdlib time functions are left open to the implementation so there might be something different happening with mingw. I’ve run the simulator on mingw in the past but our CI just tests if it compiles. I won’t have access to a mingw machine until Monday.
I was poking around in the mingw source and found that std::time_t
is typedeffed from __time32_t
which is typedeffed from long
ticks = 0, size=4
poweron_sec_since_epoch = -1, size=8
Ah.. ok, so probably mktime is not working on mingw, since poweron_sec_since_epoch is set only once:
static time_t poweron_sec_since_epoch = mktime_(&default_poweron_tm);
Does make tests
report a failed test when run from the firmware/
dir?
I just ran the tests on the windows/mingw machine with our github workflow, and it passed the time_convert tests. So if make tests
fails on your machine we can try to bisect the difference.
Also, if you just want to get the simulator working for now, you could change the highlighted line to:
// time_t secs = (time_t)(ticks / 1000) + poweron_sec_since_epoch;
time_t secs = 0;
and it’ll work fine (in the simulator, the only place this is used is in the assets volume, and timestamps aren’t relevant there anyways)
Seems not to.
===============================================================================
tests/time_convert_tests.cc:33:
TEST CASE: fattime<->ticks
tests/time_convert_tests.cc:48: ERROR: CHECK( ticks == elapsedtm ) is NOT correct!
values: CHECK( 0 == 12610000 )
tests/time_convert_tests.cc:51: ERROR: CHECK( ft.date == ft2.date ) is NOT correct!
values: CHECK( 10305 == 5121 )
tests/time_convert_tests.cc:52: ERROR: CHECK( ft.time == ft2.time ) is NOT correct!
values: CHECK( 9157 == 2100 )
===============================================================================
tests/time_convert_tests.cc:55:
TEST CASE: tick -> ft -> tick
tests/time_convert_tests.cc:64: ERROR: CHECK( ticks_ms == ticks_ms2 ) is NOT correct!
values: CHECK( 1240000 == 0 )
Thanks, I already did that, so no hurry on this issue.
Cool, so tests are failing, at least that’s consistent. What version of gcc are you using to compile the simulator?
gcc version 15.1.0 (Rev4, Built by MSYS2 project)