Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Negative TscTime triggered assertion #758

Open
IIIIIIIIll opened this issue Mar 23, 2024 · 5 comments
Open

Negative TscTime triggered assertion #758

IIIIIIIIll opened this issue Mar 23, 2024 · 5 comments

Comments

@IIIIIIIIll
Copy link

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.

@wolfpld
Copy link
Owner

wolfpld commented Mar 23, 2024

What CPU do you have? Is it a multi-socket machine?

@IIIIIIIIll
Copy link
Author

No, it's just a commerial level laptop with an amd R7 4800u

@wolfpld
Copy link
Owner

wolfpld commented Mar 23, 2024

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.

@IIIIIIIIll
Copy link
Author

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...

@IIIIIIIIll
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants