Stack overflow when too many similar images are present

[Fuuzetsu]

The similar image database only is able to hold up to 16 images

struct similar_image_db {
	struct similar_image *img_db[16];
	unsigned short size;
};

			/* Add it to our database of similar images */
			sim_db->img_db[sim_db->size] = image;
			sim_db->size++;

Simplest hack is just

	while (index != NULL && sim_db->size < 16) {

but perhaps it should be dynamically sized?

=================================================================
==28618==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffc378 at pc 0x00000040befd bp 0x7fffffffc0a0 sp 0x7fffffffc098
WRITE of size 8 at 0x7fffffffc378 thread T0
    #0 0x40befc in populate_sim_db /home/shana/programming/ruiji/src/parser.c:291
    #1 0x4022e1 in main /home/shana/programming/ruiji/src/ruiji.c:202
    #2 0x7f60ceb4352f in __libc_start_main (/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libc.so.6+0x2052f)
    #3 0x402949 in _start (/home/shana/programming/ruiji/src/ruiji+0x402949)

Address 0x7fffffffc378 is located in stack of thread T0 at offset 328 in frame
    #0 0x4020cf in main /home/shana/programming/ruiji/src/ruiji.c:159

  This frame has 3 object(s):
    [32, 34) 'user_input'
    [96, 136) 'cmd_args'
    [192, 328) 'sim_db' <== Memory access at offset 328 overflows this variable
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 /home/shana/programming/ruiji/src/parser.c:291 populate_sim_db
Shadow bytes around the buggy address:
  0x10007fff7810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10007fff7820: f1 f1 02 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2
  0x10007fff7830: f2 f2 04 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10007fff7840: 00 00 00 00 00 00 f1 f1 f1 f1 02 f4 f4 f4 f2 f2
  0x10007fff7850: f2 f2 00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00
=>0x10007fff7860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f4]
  0x10007fff7870: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x10007fff7880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff78a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff78b0: 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
==28618==ABORTING
[Inferior 1 (process 28618) exited with code 01]
(gdb) q

id:000000,sig:06,src:000016+000018,op:splice,rep:2.txt

[kamiyaa]

Thanks!

Yes, I should've had it dynamically sized, but I got lazy during the beginning.
Will fix.

[kamiyaa]

Fixed with c04bec6.
I will leave this open for 24hrs just in case.

[Fuuzetsu]

Feel free to just close, I'm happy to reopen if needed.

By the way, did you consider just using a linked list instead? I don't see anything justifying the need for explicit size tracking and random access; it removes the need for realloc and book keeping completely. Just a suggestion.

[kamiyaa]

Size tracking is mostly quality of life so I don't have to explicitly find the size at some point when I check if the user picked a valid option.

I don't really see any reason not to use a linked list, so I'll probably add it.

[kamiyaa]

d87f363