Open IIIIIIIIll opened 3 months ago
What CPU do you have? Is it a multi-socket machine?
No, it's just a commerial level laptop with an amd R7 4800u
That doesn't make much sense. TSC readings should be monotonic. On my 7950, the time between FrameMark
calls is about 1 microsecond due to the cost of std::cout
, and that's far beyond the granularity of TSC readings on AMD, which is 10 ns.
You can compile with TRACY_TIMER_FALLBACK
to rely on CLOCK_MONOTONIC_RAW
readings instead of TSC.
I recompiled with the flag and the negative values are gone. But the assertion is still failing as fd->frames.back().start
now is just greater than time
. Good news is I can now get ~10s or ~40mil frames stable traces. I have also observerd another crash site on TracyWorker.cpp:6596
where m_sysTimePlot->data.back().time.Val()
is greater than time
too. Will try other machines to see if it is something wrong with my device...
I tried on a 5800x and it runs without any issue. If you want to investigate more into the problem I'm happy to help. Otherwise feel free to close it. Thank you.
Using v0.10 on Ubuntu 20.04 Crash site is
tracy/server/TracyWorker.cpp:5031
with this line of code :assert( fd->frames.empty() || fd->frames.back().start <= time );
Reproducible with the following code snippet.
I tried to inspect the issue with gdb and found somehow the call to get
time
on line 5030 (const auto time = TscTime( ev.time );
) gives negative result. Interestingly when I added a sleep before theFrameMark
, it usually takes a bit longer for tracy to crash.