zsh: abort <tool_name>

Question

Created Dec ’22

Replies 1

Boosts 0

Views 1.8k

Participants 1

Hi,

I downloaded and ran a command line tool (on M1 Max) that natively supports Apple Silicon. I was able to run the tool several times without a problem. However, after several execution it suddenly stopped working with the following terminal output: "zsh: abort <tool_name>. I had a look at the Crash Report and it says:

 "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
  "asi" : {"libsystem_c.dylib":["stack buffer overflow"]},

First, I thought it was a code signing problem but then I would have seen SIGKILL exception. Any ideas what's wrong? Before I was trying to run another application from a docker image which could not access some of the libsystem_c libraries (not actually sure whether this was true but it said that at least similar libraries were 'corrupted' or something similar and then it suggested to move to the bin which I think I did).

Boost

Answer 1

kaubojus21 OP

Dec ’22

I also ran the command tool in the sanitized mode which produced the following output:

==16886==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016fc5a454 at pc 0x0001007609f4 bp 0x00016fc5a3c0 sp 0x00016fc59b48
WRITE of size 21 at 0x00016fc5a454 thread T0
    #0 0x1007609f0 in scanf_common(void*, int, bool, char const*, char*)+0x624 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x1c9f0)
    #1 0x100760e68 in wrap_fscanf+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x1ce68)
    #2 0x10024395c in readIniFile nii_dicom_batch.cpp:8812
    #3 0x1001a366c in main main_console.cpp:259
    #4 0x1949fbe4c  (<unknown module>)

Address 0x00016fc5a454 is located in stack of thread T0 at offset 52 in frame
    #0 0x100243780 in readIniFile nii_dicom_batch.cpp:8803

  This frame has 2 object(s):
    [32, 52) 'Setting' (line 8809) <== Memory access at offset 52 overflows this variable
    [96, 351) 'Value' (line 8809)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x1c9f0) in scanf_common(void*, int, bool, char const*, char*)+0x624
Shadow bytes around the buggy address:
  0x00702dfab430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x00702dfab480: 00 00 00 00 f1 f1 f1 f1 00 00[04]f2 f2 f2 f2 f2
  0x00702dfab490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07
  0x00702dfab4b0: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x00702dfab4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00702dfab4d0: 00 00 00 00 f1 f1 f1 f1 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
==16886==ABORTING
zsh: abort      /Users/donatas/playground/tmp/dcm2niix/console/dcm2niix

0