stack overflow with preexisting --hashfile=foo

[matthiaskrgr]

./duperemove -rh .  --hashfile=foo --lookup-extents=yes 
=================================================================
==10122==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc1cec8838 at pc 0x7f6cc0b24987 bp 0x7ffc1cec8550 sp 0x7ffc1cec7cf8
WRITE of size 9 at 0x7ffc1cec8838 thread T0
    #0 0x7f6cc0b24986 in strcpy (/lib64/libasan.so.3+0x91986)
    #1 0x41b2c9 in get_config_text /home/matthias/vcs/github/duperemove/dbfile.c:539
    #2 0x41b2c9 in __dbfile_get_config /home/matthias/vcs/github/duperemove/dbfile.c:577
    #3 0x41c5d9 in dbfile_get_config /home/matthias/vcs/github/duperemove/dbfile.c:630
    #4 0x405d19 in create_update_hashfile /home/matthias/vcs/github/duperemove/duperemove.c:563
    #5 0x405d19 in main /home/matthias/vcs/github/duperemove/duperemove.c:688
    #6 0x7f6cbfe02730 in __libc_start_main (/lib64/libc.so.6+0x20730)
    #7 0x406d28 in _start (/home/matthias/vcs/github/duperemove/duperemove+0x406d28)

Address 0x7ffc1cec8838 is located in stack of thread T0 at offset 168 in frame
    #0 0x40530f in main /home/matthias/vcs/github/duperemove/duperemove.c:643

  This frame has 7 object(s):
    [32, 36) 'dbfile_is_new'
    [96, 100) 'db_blocksize'
    [160, 168) 'db_hash_type' <== Memory access at offset 168 overflows this variable
    [224, 232) 'dev'
    [288, 296) 'fsid'
    [352, 368) 'res'
    [416, 456) 'dups_tree'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.3+0x91986) in strcpy
Shadow bytes around the buggy address:
  0x1000039d10b0: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2
  0x1000039d10c0: 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
  0x1000039d10d0: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x1000039d10e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000039d10f0: 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4
=>0x1000039d1100: f4 f4 f2 f2 f2 f2 00[f4]f4 f4 f2 f2 f2 f2 00 f4
  0x1000039d1110: f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00
  0x1000039d1120: f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3
  0x1000039d1130: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000039d1140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000039d1150: 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
  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
==10122==ABORTING

@ b39ac5588369bd369ccbffda6b5f90f7b03f828e

[matthiaskrgr]

Or is this related to these memory statistics?

[markfasheh]

Nope that looks like a legit crash but I didn't reproduce based on your command here. Let me take a look at the code, that stack is helpfull

[markfasheh]

Actually I can reproduce now (had to make clean)

[matthiaskrgr]

It actually seems to be realted to --hashfile. I can only reproduce when the specified already exists (run with --hashfile=foo twice)

[markfasheh]

Yeah it's the strcpy in get_config_text, if you update from master it should be fixed. Thanks for reporting this it would've been a nightmare to find later. I think I'll add a debug target to the Makefile.

[markfasheh]

Never mind we already have one I just forgot to use it :/