[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #8 from James Carlson --- (In reply to Vladimir Mezentsev from comment #7) > Created attachment 15433 [details] > proposed patch That patch works perfectly. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #6 from James Carlson --- Neat. I'd be more than happy to try out a patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #3 from James Carlson --- I found a clue: the application uses libtcmalloc. It seems like this recursion problem happens when that library is either ldopen'd into the address space or LD_PRELOADed in. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 --- Comment #2 from James Carlson --- First of all, your test case: % gcc -pthread t.c t.c:3:11: warning: built-in function 'calloc' declared as non-function [-Wbuiltin-declaration-mismatch] 3 | long long calloc = 0; | ^~ % ./a.out % echo $? 0 That works fine. The machine itself is running Ubuntu 22.04.4 LTS (Jammy Jellyfish). I made a clean sandbox and found no trouble at all with "-H on", so it's clearly related to something else in my environment. I'll spend some time searching. In the meantime, this can probably be closed out as "cannot reproduce" until I get to the bottom of whatever's going on. It's definitely reproducible and happens all the time in the giant proprietary C++ application I'm working on and in these tiny test programs when compiled inside that same environment, but I don't know yet how or why. Something causes collector's calloc hook to end up invoking itself. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31459] need a way to suppress the stderr message
https://sourceware.org/bugzilla/show_bug.cgi?id=31459 --- Comment #2 from James Carlson --- Excellent! I'll use that instead. In that case, please consider adding this option to the documentation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31460] New: heap tracing causes infinite recursion on calloc with multi-threaded applications
https://sourceware.org/bugzilla/show_bug.cgi?id=31460 Bug ID: 31460 Summary: heap tracing causes infinite recursion on calloc with multi-threaded applications Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: carlsonj at workingcode dot com Target Milestone: --- Created attachment 15391 --> https://sourceware.org/bugzilla/attachment.cgi?id=15391=edit Demonstrates infinite recursion with "-H on" When setting "-H on" with "gprofng collect app", starting a new thread triggers infinite recursion. The crash looks like this in gdb: #26129 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26130 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=38, value=value@entry=0x7f81e19fcac0) at ./nptl/pthread_setspecific.c:69 #26131 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26132 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26133 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=38, value=value@entry=0x7f81e19fcad0) at ./nptl/pthread_setspecific.c:69 #26134 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26135 0x7f81ed538de5 in calloc (size=32, esize=16) at heaptrace.c:447 #26136 0x7f81e7c9bbaf in ___pthread_setspecific (key=key@entry=40, value=value@entry=0x7f81e19fcae0) at ./nptl/pthread_setspecific.c:69 #26137 0x7f81ed40bff7 in __collector_tsd_get_by_key (key_index=) at tsd.c:138 #26138 0x7f81ed428bfc in __collector_ext_unwind_key_init (isPthread=isPthread@entry=1, stack=stack@entry=0x0) at unwind.c:342 #26139 0x7f81ed40552a in collector_root (cargs=) at dispatcher.c:1103 #26140 0x7f81e7c94ac3 in start_thread (arg=) at ./nptl/pthread_create.c:442 #26141 0x7f81e7d26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Attached is a simple program that demonstrates the problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31459] New: need a way to suppress the stderr message
https://sourceware.org/bugzilla/show_bug.cgi?id=31459 Bug ID: 31459 Summary: need a way to suppress the stderr message Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: carlsonj at workingcode dot com Target Milestone: --- In the old Oracle Performance Analyzer system, I could use "-O" to redirect the 'collect' output to a file. In the new "gprofng collect app" tool, "-O" now means "place the .er output here." That change in gprofng is very helpful indeed, but leaves me without a way to get rid of the stderr output (particularly the "Creating experiment directory" message), which ends up interfering with some of the automated tools I'm using. Would it be possible to bring back redirection for output from the tool itself or perhaps add a "-q" (quiet) option? -- You are receiving this mail because: You are on the CC list for the bug.
