On a CentOS 7 system (glibc 2.17), I ran into a crash that appears to be due to muntrace() setting a file pointer to NULL when it could still be in use. The issue still exists in the master branch.

From https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/mtrace.c;h=9064f209ec3b24c6b341a31fe8acfe98580a59ba;hb=refs/heads/master#l340

330 void
331 muntrace (void)
332 {
333   if (mallstream == NULL)
334     return;
335 
336   /* Do the reverse of what done in mtrace: first reset the hooks and
337      MALLSTREAM, and only after that write the trailer and close the
338      file.  */
339   FILE *f = mallstream;
340   mallstream = NULL;
341   __free_hook = tr_old_free_hook;
342   __malloc_hook = tr_old_malloc_hook;
343   __realloc_hook = tr_old_realloc_hook;
344   __memalign_hook = tr_old_memalign_hook;
345 
346   fprintf (f, "= End\n");
347   fclose (f);
348 }

Here, `mallstream` is being set to NULL before the old hook functions are restored, so the tracing hook functions are still in place and potentially trying to use `mallstream` (from another thread).

Nulling `mallstream` later would make this race less likely, but could presumably still be an issue if another thread were already inside one of the hook functions. I realize mtrace/muntrace are marked MT-Unsafe, so I guess this is more of a nice-to-have change than a real bug.

For reference, my backtrace was:

#0  _IO_vfprintf_internal (s=0x0, format=0x7f86d961ee9c "@ %s%s%s[%p] ", ap=ap@entry=0x7f86b06d2218)
    at vfprintf.c:1271
#1  0x00007f86d94f1827 in __fprintf (stream=<optimized out>, 
    format=format@entry=0x7f86d961ee9c "@ %s%s%s[%p] ") at fprintf.c:32
#2  0x00007f86d95242e5 in tr_where (caller=caller@entry=0x7f86d9567f9b <re_dfa_add_node+347>, 
    info=info@entry=0x7f86b06d2320) at mtrace.c:110
#3  0x00007f86d9524588 in tr_reallochook (ptr=0x7f86a96657e0, size=416, 
    caller=0x7f86d9567f9b <re_dfa_add_node+347>) at mtrace.c:220
#4  0x00007f86d9567f9b in re_dfa_add_node (dfa=0x7f86a9671f80, token=...) at regex_internal.c:1433
#5  0x00007f86d9579704 in calc_first (node=0x7f86a95fed48, extra=<optimized out>) at regcomp.c:1375
#6  postorder (fn=0x7f86d956c180 <calc_first>, extra=0x7f86a9671f80, root=<optimized out>) at regcomp.c:1226
#7  analyze (preg=<optimized out>) at regcomp.c:1180
#8  re_compile_internal (preg=preg@entry=0x7f86b06d2540, pattern=pattern@entry=0x7759d7 "^[0-9]{1,6}$", 
    length=<optimized out>, syntax=syntax@entry=242428) at regcomp.c:797
#9  0x00007f86d957aa50 in __regcomp (preg=preg@entry=0x7f86b06d2540, pattern=0x7759d7 "^[0-9]{1,6}$", 
    cflags=cflags@entry=1) at regcomp.c:499
[...snip...]