[Bug gprofng/30360] [gprofng collect] Seg. Fault when application uses std::thread

[vladimir.mezentsev at oracle dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30360

Vladimir Mezentsev <vladimir.mezentsev at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Vladimir Mezentsev <vladimir.mezentsev at oracle dot com> 
---
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example,

% nm -D /lib64/gprofng/libgp-collector.so  | grep thread_create@ | sort
000000000004b420 T pthread_create@GLIBC_2.34
000000000004b490 T pthread_create@GLIBC_2.17
000000000004b500 T pthread_create@GLIBC_2.2.5
000000000004b570 T pthread_create@GLIBC_2.1
000000000004b5e0 T pthread_create@GLIBC_2.0

Our library does not set the default version for symbols.
This is correct because we don't know which libC will be used.

gcc and g++ links differently the version symbols when the default version is
not set.
c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using our
pthread_create@GLIBC_2.0 by default.

The current implementation of the interposed functions is:
  If we are in our pthread_create@GLIBC_<NN>,
  we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call the
same function from libC.
In the test above, pthread_create@GLIBC_2.0 is not in the current libC.

We need to call the default pthread_create from libC.
I want to prepare this fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.