AddressSanitizer reports an error when calling cr_plugin_close

[danielytics]

When running my codebase with ASan, I noticed that it complained about CR. So I reran the code from #60 and the same thing happens. The code is unchanged from what I posted in #60, the only change is I compiled like this:

clang++ -fPIC -Icr -fsanitize=address -c test.cpp -o test.o
clang++ -shared -fsanitize=address test.o -o test.so
clang++ -Icr -fsanitize=address -c main.cpp -o main.o
clang++ -ldl -fsanitize=address main.o -o main

I'm unsure if its a false positive due to how CR messes with setjmp/longjmp and crash protection or if there's a real bug.

The ASan report is below:

=================================================================
==2496617==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f123c9e61e1 at pc 0x000000496967 bp 0x7ffe9df6e3e0 sp 0x7ffe9df6dba8
READ of size 96 at 0x7f123c9e61e1 thread T0
    #0 0x496966 in __asan_memcpy (/home/dan/code/cr_test/main+0x496966)
    #1 0x4ceaa7 in cr_plugin_sections_store(cr_plugin&) (/home/dan/code/cr_test/main+0x4ceaa7)
    #2 0x4cb20c in cr_plugin_unload(cr_plugin&, bool, bool) (/home/dan/code/cr_test/main+0x4cb20c)
    #3 0x4cae0e in cr_plugin_close (/home/dan/code/cr_test/main+0x4cae0e)
    #4 0x4cbacb in main (/home/dan/code/cr_test/main+0x4cbacb)
    #5 0x7f123f57ccb1 in __libc_start_main csu/../csu/libc-start.c:314:16
    #6 0x41d49d in _start (/home/dan/code/cr_test/main+0x41d49d)

0x7f123c9e61e1 is located 0 bytes to the right of global variable 'std::__ioinit' defined in '/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/iostream:74:25' (0x7f123c9e61e0) of size 1
  'std::__ioinit' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/dan/code/cr_test/main+0x496966) in __asan_memcpy
Shadow bytes around the buggy address:
  0x0fe2c7934be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
  0x0fe2c7934c10: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0fe2c7934c20: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x0fe2c7934c30: f9 f9 f9 f9 f9 f9 00 00 00 00 00 00[01]f9 f9 f9
  0x0fe2c7934c40: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe2c7934c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  Shadow gap:              cc
==2496617==ABORTING

[fungos]

Thanks again for reporting! This looks interesting, I'll try to look at it sometime in the future, I'm having trouble finding time to do any personal project work recently, but I certainly hope to look at all your issues.

[danielytics]

Thanks. There's no rush, none of my issues are blocking me, so whenever you get time is ok. I also meant to do a git-bisect on one of the other issues, but have also not had the time yet, so I totally understand.