Heap-use-after-free on double include

[XVilka]

If you put 2 lines at the beginning of file, then shebang:

(define *include-dirs* (cons "/home/user/ol" *include-dirs*))
(define *include-dirs* (cons "/home/user/ol" *include-dirs*))
#/usr/bin/ol

/home/user/ol/ol main.scm
=================================================================
==19329==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f0b12733288 at pc 0x00000040949f bp 0x7ffdb74a7160 sp 0x7ffdb74a7150
READ of size 8 at 0x7f0b12733288 thread T0
    #0 0x40949e in runtime src/olvm.c:2187
    #1 0x41e3e2 in OL_eval src/olvm.c:4458
    #2 0x41d828 in main src/olvm.c:4296
    #3 0x7f0b1c21e400 in __libc_start_main (/lib64/libc.so.6+0x20400)
    #4 0x402139 in _start (/home/user/ol/ol+0x402139)

0x7f0b12733288 is located 17414792 bytes inside of 17475456-byte region [0x7f0b11697800,0x7f0b12741f80)
freed by thread T0 here:
    #0 0x7f0b1c88f210 in realloc (/lib64/libasan.so.3+0xc7210)
    #1 0x4026cd in adjust_heap src/olvm.c:1073
    #2 0x40300b in gc src/olvm.c:1273
    #3 0x4030eb in gc src/olvm.c:1284
    #4 0x404a89 in OL__gc src/olvm.c:1557
    #5 0x4092cc in runtime src/olvm.c:2177
    #6 0x41e3e2 in OL_eval src/olvm.c:4458
    #7 0x41d828 in main src/olvm.c:4296
    #8 0x7f0b1c21e400 in __libc_start_main (/lib64/libc.so.6+0x20400)

previously allocated by thread T0 here:
    #0 0x7f0b1c88f210 in realloc (/lib64/libasan.so.3+0xc7210)
    #1 0x4026cd in adjust_heap src/olvm.c:1073
    #2 0x40300b in gc src/olvm.c:1273
    #3 0x4030eb in gc src/olvm.c:1284
    #4 0x404a89 in OL__gc src/olvm.c:1557
    #5 0x405cfd in runtime src/olvm.c:1754
    #6 0x41e3e2 in OL_eval src/olvm.c:4458
    #7 0x41d828 in main src/olvm.c:4296
    #8 0x7f0b1c21e400 in __libc_start_main (/lib64/libc.so.6+0x20400)

SUMMARY: AddressSanitizer: heap-use-after-free src/olvm.c:2187 in runtime
Shadow bytes around the buggy address:
  0x0fe1e24de600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de640: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0fe1e24de650: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de660: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de670: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de680: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de690: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe1e24de6a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==19329==ABORTING

Of course it's invalid syntax, but at least it shouldn't corrupt the memory, imho

[yuriy-chumak]

Can't reproduce under win64 and linux-arm-x32. Maybe already fixed in some commit.

[yuriy-chumak]

No more reproducible:

#:~/tmp$ ol fail2 
This makes no sense:  (expected n) 
  >>>  #/usr/bin/ol  <<<