Re: [fpc-pascal] LLVM crash
Hi 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. Ubuntu 22.04, LLVM 13 Nothing helps. only some units are affected Actually, now I see the warnings during compilation Assembling xquery mismatched subprogram between llvm.dbg.addr variable and !dbg attachment inlinable function call in a function with debug info must have a !dbg location invoke void @"\01XQUERY$_$IXQVALUE_$__$$_$finalize$IXQVALUE"(%typ.XQUERY.IXQValue* %reg.1_200) to label %.Lj9768 unwind label %.Lj9743 . call void @llvm.dbg.addr(metadata %typ.SYSTEM.TRTLCriticalSection* %tmp.1, metadata !48637, metadata !DIExpression()), !dbg !48773 label %0 void ()* @"\01XQUERY_$$_finalize$" !48637 = !DILocalVariable(name: "_zero_$SYSTEM_$$_TRTLCRITICALSECTION", scope: !48635, file: !3, line: 10567, type: !1260) !48635 = distinct !DISubprogram(name: "XQUERY_$$_init$", scope: !3, file: !3, line: 3506, type: !7606, scopeLine: 10504, spFlags: DISPFlagDefinition, unit: !2) !48773 = !DILocation(line: 10570, column: 1, scope: !48772) !48772 = distinct !DISubprogram(name: "XQUERY_$$_finalize$", scope: !3, file: !3, line: 10570, type: !7606, scopeLine: 10570, spFlags: DISPFlagDefinition, unit: !2) warning: ignoring invalid debug info in /home/theo/lib/fpc/x86_64-linux/xquery.ll The first appears to be caused by my managed operator patch Then there is the default issue https://gitlab.com/freepascal.org/fpc/source/-/issues/40395 (and you have fixed it while I was still writing this mail) Then this: https://gitlab.com/freepascal.org/fpc/source/-/issues/40280 is causing a stack corruption https://gitlab.com/freepascal.org/fpc/source/-/issues/40392 is causing a heap corruption Cheers, Benito On 11.08.23 12:57, Jonas Maebe via fpc-pascal wrote: 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. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() #1 0x0041b92ain fpc_ansistr_setlength() #2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, BASECAPACITY=130) at bbutils.pas:1650 #3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at bbutils.pas:1639 #4 STRDECODEHTMLENTITIES(result=0x0, P=, 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: 0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x006f5783<+22211>: e8 18 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5788<+22216>: e8 13 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f578d<+1>: e8 0e cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5792<+6>: e8 09 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5797<+22231>: 48 89 c7 movrdi,rax 0x006f579a<+22234>: e8 01 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f579f<+22239>: 48 89 cf movrdi,rcx 0x006f57a2<+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 ___ fpc-pascal maillist -fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LLVM crash
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. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() #1 0x0041b92ain fpc_ansistr_setlength() #2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, BASECAPACITY=130) at bbutils.pas:1650 #3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at bbutils.pas:1639 #4 STRDECODEHTMLENTITIES(result=0x0, P=, 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: 0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x006f5783<+22211>: e8 18 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5788<+22216>: e8 13 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f578d<+1>: e8 0e cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5792<+6>: e8 09 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5797<+22231>: 48 89 c7 movrdi,rax 0x006f579a<+22234>: e8 01 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f579f<+22239>: 48 89 cf movrdi,rcx 0x006f57a2<+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 0x60300022 at pc 0x00401383 bp 0x7ffd4259e170 sp 0x7ffd4259e168 WRITE of size 1 at 0x60300022 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 0x60300022 is located 1 bytes to the right of 17-byte region [0x60300010,0x60300021) 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
[fpc-pascal] LLVM crash
Hallo, i tried to run my program under LLVM (from july fpc) and it crashes? Program received signal SIGSEGV, Segmentation fault. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() #1 0x0041b92ain fpc_ansistr_setlength() #2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, BASECAPACITY=130) at bbutils.pas:1650 #3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at bbutils.pas:1639 #4 STRDECODEHTMLENTITIES(result=0x0, P=, L=130, ENCODING=65001, FLAGS=...) at bbutils.pas:5527 anyone has seen sysgetmem crash before? Perhaps that is exactly the kind of things ASAN was supposed to detect. 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 And there are a lot of weird ASAN calls for trivial movs. Like: 0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x006f5783<+22211>: e8 18 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5788<+22216>: e8 13 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f578d<+1>: e8 0e cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5792<+6>: e8 09 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5797<+22231>: 48 89 c7 movrdi,rax 0x006f579a<+22234>: e8 01 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f579f<+22239>: 48 89 cf movrdi,rcx 0x006f57a2<+22242>: e8 09 ca d0 ff call0x4021b0<__asan_report_store8@plt> Are they supposed to be there? Viele Grüße, Benito ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
