[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