Another use-after-poison

[marvinborner]

Hi again! I started testing some larger terms and found another use-after-poison.

A reproduction:
repro.c.txt

I suppose it could be because some limit is reached. In this case I argue there should be a custom exception.

(optiscope is now tracked in strong-normalization-tests)

Here's a stack trace

==81604==ERROR: AddressSanitizer: use-after-poison on address 0x1326da3987a8 at pc 0x56210fdf498d bp 0x7ffe5e8e3b40 sp 0x7ffe5e8e3b30
READ of size 8 at 0x1326da3987a8 thread T0
    #0 0x56210fdf498c in follow_port optiscope/optiscope.c:903
    #1 0x56210fdf498c in weak_reduction optiscope/optiscope.c:4233
    #2 0x56210fe004fa in optiscope_algorithm optiscope/optiscope.c:4297
    #3 0x56210fdcecce in test_case optiscope/tests.c:33
    #4 0x56210fdcef83 in main /home/.../optiscopeTests2600.c:3998
    #5 0x1456db227674  (/usr/lib/libc.so.6+0x27674) (BuildId: 1d7c9b9187cec4c03a504fccc917f9af55568a53)
    #6 0x1456db227728 in __libc_start_main (/usr/lib/libc.so.6+0x27728) (BuildId: 1d7c9b9187cec4c03a504fccc917f9af55568a53)
    #7 0x56210fc2b2d4 in _start (/home/.../a.out+0xa2d4) (BuildId: e670946673aae70daaf8d6f79e899c34a8a0df23)

0x1326da3987a8 is located 9128 bytes inside of 32768-byte region [0x1326da396400,0x1326da39e400)
allocated by thread T0 here:
    #0 0x1456db720e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x56210fdd28f3 in xmalloc optiscope/optiscope.c:612

SUMMARY: AddressSanitizer: use-after-poison optiscope/optiscope.c:903 in follow_port
Shadow bytes around the buggy address:
  0x1326da398500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1326da398580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1326da398600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1326da398680: 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x1326da398700: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
=>0x1326da398780: f7 f7 f7 f7 f7[f7]f7 f7 00 00 00 00 f7 f7 f7 f7
  0x1326da398800: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x1326da398880: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x1326da398900: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x1326da398980: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x1326da398a00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==81604==ABORTING

[etiamz]

Thanks for reporting. This is again an issue with our garbage collection. Under no circumstances we should deallocate nodes from the reduction stack, because this would lead to use-after-poison immediately afterwards.

Your test should now timeout instead of crashing.

[etiamz]

(Forgot to reset PHASE_STACK when nodes go out of the stack).

[marvinborner]

Works, as per actions!