wolfpld / tracy

Frame profiler

Home Page:https://tracy.nereid.pl/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Negative TscTime triggered assertion

IIIIIIIIll opened this issue · comments

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.

#include <iostream>
#include "tracy/public/tracy/Tracy.hpp"

int main() {
    while (true) {
        std::cout << "Hello, World!" << std::endl;
        //#1 optional sleep
        FrameMark;
    }
    return 0;
}

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 the FrameMark, it usually takes a bit longer for tracy to crash.

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.