wolfpld
QNX 7 Client found but connection never established
Hey Im trying to profile some C++ applications on QNX 7. I was able to cross compile my application with TracyClient.cpp in the sources and tracy/public in my includes directory. I had to make some small modifications to TracySystem.cpp to support QNX as an OS (just returning the kernel thread identifier via gettid()).
When I run my application on a target PC and then try to connect to that client from my host machine via the GUI, it hangs forever. The server is able to detect the client. I am able to ssh onto the target PC, and I've checked wireshark and I have some TCP packets being sent on the right IP + port.
I am able to build this application for Ubuntu and profile it. Any ideas for why this may be failing on QNX?
I am using Tracy 0.10 for the client and server.
Please submit any fixes you have as PRs. As for the hangup you are experiencing, you are most likely on your own, as the first person to try to run this new platform.
Please submit any fixes you have as PRs.
Yeah once I have something actually working on QNX I will be opening a PR up :)
As for the hangup you are experiencing, you are most likely on your own
Do you have any hunches or tips for where to start investigating this? Did anyone else experience this kind of behavior after adding a new platform?
I have experience with using tracy on a QNX 7.0 target. The required changes are quite minor but happy to save you some effort @maspe36. Beyond that patch I did not do any special configuration and can confirm that at least the instrumentation profiling worked seamlessly when capturing data on a Linux machine over the network. Haven't tried cross-compiling the headless capture tool for QNX, but if you keep running into issues, that could be another avenue to at least confirm functionality if you have a sufficiently capable QNX target?
@wolfpld are you interested in adding QNX support given that it's quite a niche platform and will be hard for anyone without a QNX license to maintain?
Hey! Not to hijack this PR or anything (I'm not a tracy developer) but I do work with QNX a bit & I was wondering what about tracy is appealing to each of you as a QNX developer? @michaeldleslie @maspe36
@dylanleclair momentics has a lot of the same feature set for tracing, but locks you in to only being able to use that on QNX. What if you want to also perform tracing with the same codebase in a non-QNX environment?
Additionally, in large organizations with limited QNX licenses, you face situations where only a few people even have the ability to learn how to use momentics. We often have applications that need to run on multiple platforms so a profiler that works on all of our supported platforms is more useful, even if it has fewer features than a profiler that only works on one platform.
Facing same issue. Run example of fiber.
-
test on Linux : Client TracyProfiler.cpp Profiler::SendData will be called several times after client connected with front end(profiler HMI) and everything seems fine.
-
test on QNX aarch64: TracyProfiler.cpp SendData is never called. Server discovered client by “ interface-ip xx.xx.xx.255”. static tracy_force_inline void EnterFiber is called. static tracy_force_inline void LeaveFiber() is called. HMI: waiting for connection…
Any tips on this? thanks
TL;DR: Try building or running with TRACY_ONLY_IPV4 as a workaround.
@maspe36's issue, which we ended up debugging offline, was something I'd also run into in my own setup: there was no usable IPv6 connection from the machine running the client to the machine running the server. We worked around this that by using the TRACY_ONLY_IPV4 define, but at that time we never root-caused.
Given your comment above that the server discovered the client via an IPv4 UDP broadcast, you must have a working IPv4 connection? So, seems that your issue is similar. Either use that TRACY_ONLY_IPV4 define as a workaround or provide an IPv6 connection.
As far as actually fixing it, looked into it briefly and I think I found the relevant snippet:
bool ListenSocket::Listen( uint16_t port, int backlog )
{
assert( m_sock == -1 );
struct addrinfo* res = nullptr;
#if !defined TRACY_ONLY_IPV4 && !defined TRACY_ONLY_LOCALHOST
const char* onlyIPv4 = GetEnvVar( "TRACY_ONLY_IPV4" );
if( !onlyIPv4 || onlyIPv4[0] != '1' )
{
m_sock = addrinfo_and_socket_for_family( port, AF_INET6, &res );
}
#endif
if (m_sock == -1)
{
// IPV6 protocol may not be available/is disabled. Try to create a socket
// with the IPV4 protocol
m_sock = addrinfo_and_socket_for_family( port, AF_INET, &res );
if( m_sock == -1 ) return false;
}
#if defined _WIN32
unsigned long val = 0;
setsockopt( m_sock, IPPROTO_IPV6, IPV6_V6ONLY, (const char*)&val, sizeof( val ) );
#elif defined BSD
int val = 0;
setsockopt( m_sock, IPPROTO_IPV6, IPV6_V6ONLY, (const char*)&val, sizeof( val ) );
val = 1;
setsockopt( m_sock, SOL_SOCKET, SO_REUSEADDR, &val, sizeof( val ) );
#else
int val = 1;
setsockopt( m_sock, SOL_SOCKET, SO_REUSEADDR, &val, sizeof( val ) );
#endif
if( bind( m_sock, res->ai_addr, res->ai_addrlen ) == -1 ) { freeaddrinfo( res ); Close(); return false; }
if( listen( m_sock, backlog ) == -1 ) { freeaddrinfo( res ); Close(); return false; }
freeaddrinfo( res );
return true;
}
Based on all of our experiences, I'd guess that QNX defaults to IPV6_V6ONLY enabled, and to make the socket dual-stack, we need to add some QNX-specific calls like we can are present for Windows & BSD. I'll test a fix when I have a QNX system available.
HI, Rebuild with TRACY_ONLY_IPV4 works, connection established by HMI and stay on view of drawing plots.
But HMI crashed after the first time “TracyProfiler.cpp SendData is called” , no matter “debug or release” build of HMI.(data succeed arrived HMI and run into analyzing part when crashing)
I haven’t had that issue, everything has just worked for me otherwise (though my target is x64).
It’ll be hard to debug that without more specific information about where in the profiler the crash occurs. Can run under debugger or look at the backtrace of the debug build’s coredump to see?
Does the headless capture utility also crash at runtime, or does it successfully write data? If the latter, can the data be converted to text via the CSV export tool?
HI： commit c4863d4324d0c8503f80f222d6a7b7d5f22aa597 (HEAD -> master, origin/master, origin/HEAD)
[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff6c13700 (LWP 13198)] [New Thread 0x7ffff6412700 (LWP 13199)] [New Thread 0x7ffff5c11700 (LWP 13200)] [Thread 0x7ffff5c11700 (LWP 13200) exited] [New Thread 0x7ffff4870700 (LWP 13201)] [New Thread 0x7fffee474700 (LWP 13202)] [New Thread 0x7ffff5c11700 (LWP 13206)] [New Thread 0x7fffe1649700 (LWP 13207)] [New Thread 0x7fffe0e48700 (LWP 13220)] [Thread 0x7fffe1649700 (LWP 13207) exited] [Thread 0x7ffff5c11700 (LWP 13206) exited] [Thread 0x7fffe0e48700 (LWP 13220) exited] [New Thread 0x7fffe0e48700 (LWP 13221)] [New Thread 0x7ffff5c11700 (LWP 13222)] [Thread 0x7ffff6412700 (LWP 13199) exited] [New Thread 0x7fffe1649700 (LWP 13263)] [Thread 0x7ffff5c11700 (LWP 13222) exited] [Thread 0x7fffe0e48700 (LWP 13221) exited] [Thread 0x7fffe1649700 (LWP 13263) exited] [New Thread 0x7fffe1649700 (LWP 13264)] [New Thread 0x7fffe0e48700 (LWP 13265)] [New Thread 0x7ffff5c11700 (LWP 13275)] [Thread 0x7fffe1649700 (LWP 13264) exited] [Thread 0x7fffe0e48700 (LWP 13265) exited] [Thread 0x7ffff5c11700 (LWP 13275) exited] [New Thread 0x7ffff5c11700 (LWP 13278)] [New Thread 0x7fffe1649700 (LWP 13279)] [New Thread 0x7fffe0e48700 (LWP 13289)] [Thread 0x7fffe1649700 (LWP 13279) exited] [Thread 0x7ffff5c11700 (LWP 13278) exited] [Thread 0x7fffe0e48700 (LWP 13289) exited] [New Thread 0x7fffe0e48700 (LWP 13292)] [New Thread 0x7ffff5c11700 (LWP 13293)]
Thread 19 "Tracy Worker" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe0e48700 (LWP 13292)] 0x00000000009808a0 in tracy::Worker::ProcessFiberLeave (this=0x20b1f80, ev=...) at ../../../server/TracyWorker.cpp:6902 6902 if( !td->fiber ) (gdb) bt #0 0x00000000009808a0 in tracy::Worker::ProcessFiberLeave (this=0x20b1f80, ev=...) at ../../../server/TracyWorker.cpp:6902 #1 tracy::Worker::Process (this=0x20b1f80, ev=...) at ../../../server/TracyWorker.cpp:4683 #2 tracy::Worker::DispatchProcess (this=0x20b1f80, ev=..., ptr=@0x7fffe0e33358: 0x2109fd2 "9\002") at ../../../server/TracyWorker.cpp:3250 #3 tracy::Worker::Exec (this=0x20b1f80) at ../../../server/TracyWorker.cpp:2786 #4 0x00000000009acae2 in tracy::Worker::Worker(char const*, unsigned short)::$_0::operator()() const (this=0x20a0c08) at ../../../server/TracyWorker.cpp:302 #5 0x00000000009aca9d in std::__invoke_impl<void, tracy::Worker::Worker(char const*, unsigned short)::$_0>(std::__invoke_other, tracy::Worker::Worker(char const*, unsigned short)::$_0&&) (__f=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/invoke.h:60 #6 0x00000000009aca2d in std::__invoke<tracy::Worker::Worker(char const*, unsigned short)::$_0>(tracy::Worker::Worker(char const*, unsigned short)::$_0&&) ( __fn=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/invoke.h:95 #7 0x00000000009aca05 in std::thread::_Invoker<std::tuple<tracy::Worker::Worker(char const*, unsigned short)::$_0> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0x20a0c08) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/thread:244 #8 0x00000000009ac9d5 in std::thread::_Invoker<std::tuple<tracy::Worker::Worker(char const*, unsigned short)::$_0> >::operator()() (this=0x20a0c08) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/thread:251 #9 0x00000000009ac8be in std::thread::_State_impl<std::thread::_Invoker<std::tuple<tracy::Worker::Worker(char const*, unsigned short)::$_0> > >::_M_run() ( this=0x20a0c00) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/thread:195 #10 0x00007ffff7478df4 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #11 0x00007ffff7635609 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #12 0x00007ffff7165163 in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb)
client works fine on QNX aarch64. server crash.
Need help, Thanks