https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Sat, Dec 03, 2016 at 09:02:39AM +0000, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618 > > --- Comment #11 from janus at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #10) > > Others are see the failures. > > > > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00313.html > > https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00311.html > > Not sure why I don't see this. Doing a full bootstrap does not seem to help > either. > > > > I think your patch is correct, but uncovering a new latent bug. > > Does your memory allocator fill freed memory with junk? > > Not sure. How can I tell? Probably need to check the malloc manpage. FreeBSD uses jemalloc and it can be configured to aid in debugging. But, this typically causes a performance issue (as you might imagine). It is perhaps easier to use valgrind. valgrind $PATH_TO/f951 char_conversion.f90 ... Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 ==92206== Invalid read of size 8 ==92206== at 0x658EB4: resolve_fl_procedure (resolve.c:12013) ==92206== by 0x658EB4: resolve_symbol(gfc_symbol*) (resolve.c:14721) ... ==92206== Address 0x638e130 is 0 bytes inside a block of size 48 free'd ==92206== at 0x4C25DCB: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==92206== by 0x67B92B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3841) ... ==92206== Invalid read of size 4 ==92206== at 0x5F0682: gfc_is_constant_expr(gfc_expr*) (expr.c:899) ==92206== by 0x658EC1: resolve_fl_procedure (resolve.c:12013) ... ==92206== Address 0x638e1a0 is 0 bytes inside a block of size 192 free'd ==92206== at 0x4C25DCB: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==92206== by 0x67B923: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3840) > > It's kind of hard to debug this without being able to reproduce the problem > ... > I understand, and I certainly don't expect you to fix this. I think your patch is correct.
