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@plt>
0x00000000006f5788<+22216>: e8 13 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f578d<+22221>: e8 0e cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f5792<+22226>: e8 09 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f5797<+22231>: 48 89 c7 movrdi,rax
0x00000000006f579a<+22234>: e8 01 cc d0 ff
call0x4023a0<__asan_report_load8@plt>
0x00000000006f579f<+22239>: 48 89 cf movrdi,rcx
0x00000000006f57a2<+22242>: e8 09 ca d0 ff
call0x4021b0<__asan_report_store8@plt>
Are they supposed to be there?
These are generated by LLVM's own code generator, so yes.
Jonas
uses
unit1;
var
p: pbyte;
begin
getmem(p,1);
p[2]:=0;
end.
=================================================================
==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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
