Standard streams issues on Emscripten when using Tracy

[hugoam]

Hello ! We are trying to use Tracy inside of an Emscripten environment, and as soon as Tracy is enabled in our application we are getting some pretty obscure issues when using standard streams such as std::cout, so I'm hoping maybe you could help us shed some light on what could be happening here.

(As a note, I assumed Emscripten is probably partly supported since I found some #ifdef __EMSCRIPTEN__ here and there in the codebase, even though we encountered an issue related to an undefined tracy::Callstack usage, the rest seems to compile fine.)

So back to our issue, the errors we are getting, basically as soon as using std::cout, are the following:

Uncaught RuntimeError: operation does not support unaligned accesses
    at long std::__2::__libcpp_atomic_refcount_increment<long>(long&)
    at std::__2::__shared_count::__add_shared()
    at std::__2::locale::locale(std::__2::locale const&)
    at std::__2::ios_base::getloc() const
    at std::__2::basic_ios<char, std::__2::char_traits<char> >::widen(char) const
    at std::__2::basic_ostream<char, std::__2::char_traits<char> >& std::__2::endl<char, std::__2::char_traits<char> >(std::__2::basic_ostream<char, std::__2::char_traits<char> >&)
    at std::__2::basic_ostream<char, std::__2::char_traits<char> >::operator<<(std::__2::basic_ostream<char, std::__2::char_traits<char> >& (*)(std::__2::basic_ostream<char, std::__2::char_traits<char> >&))
    at Corrade::Utility::Debug::cleanupOnDestruction()
    at Corrade::Utility::Debug::~Debug()

I'm guessing there might be some other setup that the Corrade library that could be another part of the puzzle, but we don't have a clue yet, so I'm opening this issue in the hope that maybe this call stack will tell you more about a potential issue than it does to us, knowing the Tracy code, I hope this is okay 😅

Oh and as additional context here is the options that CMake is reporting when we built Tracy:

-- TRACY_ENABLE: ON
-- TRACY_ON_DEMAND: OFF
-- TRACY_CALLSTACK: OFF
-- TRACY_NO_CALLSTACK: OFF
-- TRACY_NO_CALLSTACK_INLINES: OFF
-- TRACY_ONLY_LOCALHOST: OFF
-- TRACY_NO_BROADCAST: OFF
-- TRACY_ONLY_IPV4: OFF
-- TRACY_NO_CODE_TRANSFER: OFF
-- TRACY_NO_CONTEXT_SWITCH: OFF
-- TRACY_NO_EXIT: OFF
-- TRACY_NO_SAMPLING: OFF
-- TRACY_NO_VERIFY: OFF
-- TRACY_NO_VSYNC_CAPTURE: OFF
-- TRACY_NO_FRAME_IMAGE: OFF
-- TRACY_NO_SYSTEM_TRACING: OFF
-- TRACY_DELAYED_INIT: OFF
-- TRACY_MANUAL_LIFETIME: OFF
-- TRACY_FIBERS: OFF
-- TRACY_NO_CRASH_HANDLER: OFF
-- TRACY_TIMER_FALLBACK: OFF

Thanks in advance

[wolfpld]

Emscripten clients are not supported.

[hugoam]

I see, thanks for the quick answer.

Out of curiosity, if we wanted to roll our own by modifying Tracy, do you think we're headed to a dead-end?
(Obviously we won't bother you for support in that case, but if you have a quick diagnostic like "don't do it, you're gonna regret it" it can still help us assess what we want to do)

[wolfpld]

I don't know. There may be certain problems to overcome, like the need to use websockets, or timing accuracy reduction which may be employed by some browsers due to spectre.

[caxapexac]

@wolfpld Which open-source profiler should we use for emscripten then?

• Chrome's built-in profiler really lacks of features

• https://github.com/google/tracing-framework is killed by google 3 years ago, doesn't work nowadays tho looked promising

• https://github.com/waywardmonkeys/emscripten-trace-collector looks ugly and doesn't have a saving ability

[caxapexac]

Any ways we can rollup an emscripten support into tracy in ~month?

[benvanik]

• https://github.com/google/tracing-framework is killed by google 3 years ago, doesn't work nowadays tho looked promising

small world :) I'm the author of tracing-framework and I've since switched to using tracy for my day-to-day work. I'm interested in capturing traces from emscripten-compiled programs but haven't got around to trying that myself yet as I've been doing mostly native stuff lately. One nice aspect of tracing-framework was minimal overheads at runtime (I originally developed it to be able to be able to run in production), but when strictly used as a developer tool I think the only potential issues with tracy will be around memory consumption and the worker requirements (if the program being traced doesn't already require them). Websockets with a local redirector script can be used to interop with a native tracy UI and if the emscripten build of the UI grows to support websocket connections you'd be able to bypass that goo. My plan (whenever I get around to needing it) is to start with the redirector so that the offline capture tool and such can be used for grabbing the traces from the browser and then tweak TracySocket.hpp/cpp to work with emscripten's sockets emulation.

Interested to see if anyone gets there before me and happy to help out :)

[cpetig]

I just started investigating tracy live-data display in the browser and have a prototype at https://github.com/cpetig/tracy which already connects but then stops - requiring a websocket redirection, e.g. by websocat --binary ws-l:0.0.0.0:8008 tcp:localhost:8086

[Tasfa]

I just started investigating tracy live-data display in the browser and have a prototype at https://github.com/cpetig/tracy which already connects but then stops - requiring a websocket redirection, e.g. by websocat --binary ws-l:0.0.0.0:8008 tcp:localhost:8086

When you use websocat to redirect, can you run tracy in the browser successfully? If not to use websocat,must i try to change the socket to websocket?

[Tasfa]

I just started investigating tracy live-data display in the browser and have a prototype at https://github.com/cpetig/tracy which already connects but then stops - requiring a websocket redirection, e.g. by websocat --binary ws-l:0.0.0.0:8008 tcp:localhost:8086

I found that you have changed some code in TracySocket.cpp from Socket to websocket? But why you say that it can be connected but then stops? Have you solved it?