Bug 206936 - devel/dmalloc: dmallocth pthread loop
Summary: devel/dmalloc: dmallocth pthread loop
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2016-02-05 00:51 UTC by heas
Modified: 2021-02-15 03:04 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (mjl)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description heas 2016-02-05 00:51:41 UTC
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
Comment 1 mjl 2016-02-05 19:42:40 UTC
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?
Comment 2 heas 2016-02-06 02:01:53 UTC
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. :/
Comment 3 Walter Schwarzenfeld freebsd_triage 2018-01-16 08:58:01 UTC
Is this still relevant, or could it be closed?
Comment 4 mjl 2018-01-16 09:03:54 UTC
(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.
Comment 5 Walter Schwarzenfeld freebsd_triage 2018-01-16 09:18:04 UTC
Added the maintainer of  gcc. Maybe, he knows to solve.
Comment 6 Alexey Dokuchaev freebsd_committer freebsd_triage 2021-01-25 03:11:26 UTC
(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?
Comment 7 mjl 2021-02-15 03:04:51 UTC
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.