segfaults/etc on lots of clex blocks

[tsee]

The following variation on my thread safety test script will happily segfault (might need to tune the number iterations for your system or run a few times) even outside of any threaded environment:

use strict;
use warnings;

use C::Blocks;

for (1..500) {
  eval qq[
    clex {
      void foo$_() {}
    }
    1
  ];
}

This may be bizarre use, but it clearly shouldn't segfault.

The start of the backtrace looks like this:

#0  0x00007fdd7c931428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fdd7c93302a in __GI_abort () at abort.c:89
#2  0x00007fdd7c9737ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fdd7ca8c2e0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007fdd7c97be0a in malloc_printerr (ar_ptr=<optimized out>, ptr=<optimized out>, str=0x7fdd7ca8c3f0 "double free or corruption (out)", action=3) at malloc.c:5004
#4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3865
#5  0x00007fdd7c97f98c in __GI___libc_free (mem=<optimized out>) at malloc.c:2966
#6  0x00007fdd7bb71f29 in execute_compiler (my_perl=0x7fdd7b956360, state=0x13c7e10, data=0x7fdd742b5c70, keyword_type=2073388360) at lib/C/Blocks.xs:1157
#7  0x000003cf000003cf in ?? ()
#8  0x00007fdd7b9563d0 in ?? ()
#9  0x00007fdd7bb730c9 in strcat_printf () from /home/tsee/perl/C-Blocks/blib/arch/auto/C/Blocks/Blocks.so
#10 0xbd83489001eb90ff in ?? ()
#11 0x48297400ffffff38 in ?? ()
#12 0x008bfffffef8858b in ?? ()
#13 0xe8c78900000000be in ?? ()
#14 0x48c68948ffff0c11 in ?? ()
#15 0x00b80002a9df3d8d in ?? ()
#16 0xffff003de8000000 in ?? ()
#17 0x8b002363fe058b48 in ?? ()
#18 0x481089ffffff2895 in ?? ()

This goes on for some 20000 call stacks before gdb gives an unhelpful error message. So I suppose some recursive thing in TCC is bombing?

--Steffen

[run4flat]

Yes, I came across a similar issue in my own experiments with lots of clex blocks. It is almost surely a bug in tcc. I plan to produce a simple test script, but I'm focusing on the cache-thrashing issue first. (I've managed to boil it down to a very simple tcc-style script, so I have hopes somebody on tinycc-devel will be able to take it up.)