Bug 206936
| Summary: | devel/dmalloc: dmallocth pthread loop | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | heas |
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> |
| Status: | Open --- | ||
| Severity: | Affects Only Me | CC: | arved, danfe, gerald, mjl, w.schwarzenfeld |
| Priority: | --- | Keywords: | needs-qa |
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(mjl) |
| Hardware: | Any | ||
| OS: | Any | ||
I have never used dmallocth before, sorry. I can reproduce your crash on amd64. But if I add -dmalloc to the cc command (i used cc rather than gcc) then the program runs fine. Do you need to link against both? Have you contacted upstream about the bug? Hi. No, -ldmalloc is not required. I believe they provide all the same symbols, just one with locking and one without. And, if I add -ldmalloc after -ldmallocth, it still dumps core. And, no, I have not contacted the author. I do not know if it is a dmalloc bug or something related to the port (or fbsd). Have to start somewhere. :/ Is this still relevant, or could it be closed? (In reply to w.schwarzenfeld from comment #3) I was able to reproduce the bug. It is relevant but I don't understand enough about the internals of freebsd to fix. Added the maintainer of gcc. Maybe, he knows to solve. (In reply to mjl from comment #4) > I was able to reproduce the bug. Looks like you've recently submitted port update PR (bug #252124), is this particular problem fixed in the new version? Apologies for taking so long to reply. The update does not fix it. However, I did go and look at the docs: https://dmalloc.com/docs/dmalloc.html#Using-With-Threads I was able to have the conftest program in this report exit cleanly with -o 2. with -o 1, it core dumped. I believe the default is 0 (line 221 of env.c). I could look at adjusting the default but it could be the case that this introduces other problems. My recommendation is that this bug be closed. |
I've not attempted to debug this, but this did work at point - its been a while since I've needed dmalloc. Linking the following program from a configure script with -ldmallocth results in a segfault when it blows-out its stack space. The problem appears to be completely in the start-up; using ktrace, it never reaches the first line of main(). ISTR observing this in a much earlier version of dmalloc on solaris and it was a problem with dmalloc repeatedly trying to re-initialize itself. This is fbsd 10.2-p12 with the latest dmalloc from binary pkgs (or source). # include <stdlib.h> # include <unistd.h> #include <stdio.h> #include <string.h> #include <openssl/opensslv.h> #define DATA "conftest.sslincver" #include <dmalloc.h> int main(void) { FILE *fd; int rc; fd = fopen(DATA,"w"); if (fd == NULL) exit(1); if ((rc = fprintf(fd ,"%lx (%s)\n", (long)OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT)) <0) exit(1); exit(0); } gcc -o conftest -pthread -pthread -D_REENTRANT -D_THREAD_SAFE -DINET6 -I/usr/local/include -pthread -L/usr/local/lib -g conftest.c -lpthread -lutil -ldmallocth -lssl -lz -lcrypto test.c Core was generated by `conftest'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /usr/local/lib/libdmallocth.so.1...(no debugging symbols fo und)...done. Loaded symbols for /usr/local/lib/libdmallocth.so.1 Reading symbols from /usr/lib/libssl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.7 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.7 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800c62b5a in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 [New LWP 101621] (gdb) whe #0 0x0000000800c62b5a in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #1 0x0000000800c6387b in calloc () from /usr/local/lib/libdmallocth.so.1 #2 0x000000080082f0fa in pthread_kill () from /lib/libthr.so.3 #3 0x00000008008302d3 in pthread_timedjoin_np () from /lib/libthr.so.3 #4 0x000000080082d4ca in pthread_mutex_lock () from /lib/libthr.so.3 #5 0x0000000800c62944 in dmalloc_shutdown () from /usr/local/lib/libdmallocth.so.1 #6 0x0000000800c62e51 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #7 0x0000000800c62b82 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #8 0x0000000800c6387b in calloc () from /usr/local/lib/libdmallocth.so.1 #9 0x000000080082f0fa in pthread_kill () from /lib/libthr.so.3 #10 0x00000008008302d3 in pthread_timedjoin_np () from /lib/libthr.so.3 #11 0x000000080082d4ca in pthread_mutex_lock () from /lib/libthr.so.3 #12 0x0000000800c62944 in dmalloc_shutdown () from /usr/local/lib/libdmallocth.so.1 #13 0x0000000800c62e51 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #14 0x0000000800c62b82 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #15 0x0000000800c6387b in calloc () from /usr/local/lib/libdmallocth.so.1 #16 0x000000080082f0fa in pthread_kill () from /lib/libthr.so.3 #17 0x00000008008302d3 in pthread_timedjoin_np () from /lib/libthr.so.3 #18 0x000000080082d4ca in pthread_mutex_lock () from /lib/libthr.so.3 #19 0x0000000800c62944 in dmalloc_shutdown () from /usr/local/lib/libdmallocth.so.1 #20 0x0000000800c62e51 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 #21 0x0000000800c62b82 in dmalloc_malloc () from /usr/local/lib/libdmallocth.so.1 .... thousands of loops