[fpc-pascal] LLVM crash

Jonas Maebe jonas at freepascal.org
Fri Aug 11 12:57:49 CEST 2023


On 10/08/2023 23:27, Benito van der Zander via fpc-pascal wrote:
> i tried to run my program under LLVM (from july fpc)  and it crashes?
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER()
> (gdb) bt
> #0 0x000000000042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER()
> #1 0x000000000041b92ain fpc_ansistr_setlength()
> #2 0x0000000000558d52in RESETBUFFER(ABUFFER=0x7fffffffd560, 
> BASECAPACITY=130) at bbutils.pas:1650
> #3 INIT(ABUFFER=0x7fffffffd560, BASECAPACITY=130, AENCODING=65001) at 
> bbutils.pas:1639
> #4 STRDECODEHTMLENTITIES(result=0x0, P=<optimized out>, L=130, 
> ENCODING=65001, FLAGS=...) at bbutils.pas:5527
> 
> anyone has seen sysgetmem crash before?

It suggests heap corruption.

> Perhaps that is exactly the kind of things ASAN was supposed to detect.

Possibly, yes.

> But with ASAN, I get an error somewhere entirely else. And I do not 
> understand it, because the function is shown as ~ 5000 lines of assembly.
> 
> How can I see the mixed code with disassemble /rm in gdb? I tried to 
> call fpc -gl, -gs and -gw, and nothing helps

On which platform? When I compile the attached tt.pp file with -gw4 
-Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I get 
the output in tt.txt. It includes line information.

You could try lldb instead of gdb, although gdb should also be able to 
handle debug information generated by LLVM.

> And there are a lot of weird ASAN calls for trivial movs. Like:
> 
> 0x00000000006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8]
> 0x00000000006f5783<+22211>: e8 18 cc d0 ff 
> call0x4023a0<__asan_report_load8 at plt>
> 0x00000000006f5788<+22216>: e8 13 cc d0 ff 
> call0x4023a0<__asan_report_load8 at plt>
> 0x00000000006f578d<+22221>: e8 0e cc d0 ff 
> call0x4023a0<__asan_report_load8 at plt>
> 0x00000000006f5792<+22226>: e8 09 cc d0 ff 
> call0x4023a0<__asan_report_load8 at plt>
> 0x00000000006f5797<+22231>: 48 89 c7 movrdi,rax
> 0x00000000006f579a<+22234>: e8 01 cc d0 ff 
> call0x4023a0<__asan_report_load8 at plt>
> 0x00000000006f579f<+22239>: 48 89 cf movrdi,rcx
> 0x00000000006f57a2<+22242>: e8 09 ca d0 ff 
> call0x4021b0<__asan_report_store8 at plt>
> 
> Are they supposed to be there?

These are generated by LLVM's own code generator, so yes.


Jonas
-------------- next part --------------
uses
  unit1;

var
  p: pbyte;
begin
  getmem(p,1);
  p[2]:=0;
end.
-------------- next part --------------
=================================================================
==12076==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000022 at pc 0x000000401383 bp 0x7ffd4259e170 sp 0x7ffd4259e168
WRITE of size 1 at 0x603000000022 thread T0
    #0 0x401382 in PASCALMAIN /home/jmaebe/fpcgit/test/tt.pp:8:3
    #1 0x4012a9 in SI_C_$$_MAIN_STUB (/home/jmaebe/fpcgit/test/tt+0x4012a9)
    #2 0x7fcfa3dd3d09 in __libc_start_main csu/../csu/libc-start.c:308:16

0x603000000022 is located 1 bytes to the right of 17-byte region [0x603000000010,0x603000000021)
allocated by thread T0 here:
    #0 0x7fcfa407f5dd in __interceptor_malloc (/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xca5dd)
    #1 0x430b6c in CMEM_$$_CGETMEM$QWORD$$POINTER (/home/jmaebe/fpcgit/test/tt+0x430b6c)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jmaebe/fpcgit/test/tt.pp:8:3 in PASCALMAIN
Shadow bytes around the buggy address:
  0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c067fff8000: fa fa 00 00[01]fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==12076==ABORTING


More information about the fpc-pascal mailing list