Bug 206936 - devel/dmalloc: dmallocth pthread loop
Summary: devel/dmalloc: dmallocth pthread loop
Status: New
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 mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2016-02-05 00:51 UTC by heas
Modified: 2018-01-16 09:18 UTC (History)
4 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 w.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 w.schwarzenfeld freebsd_triage 2018-01-16 09:18:04 UTC
Added the maintainer of  gcc. Maybe, he knows to solve.