Hallo,

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?

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:

0x00000000006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x00000000006f5783<+22211>: e8 18 cc d0 ff
call0x4023a0
0x00000000006f5788<+22216>: e8 13 cc d0 ff
call0x4023a0
0x00000000006f578d<+22221>: e8 0e cc d0 ff
call0x4023a0
0x00000000006f5792<+22226>: e8 09 cc d0 ff
call0x4023a0
0x00000000006f5797<+22231>: 48 89 c7 movrdi,rax
0x00000000006f579a<+22234>: e8 01 cc d0 ff
call0x4023a0
0x00000000006f579f<+22239>: 48 89 cf movrdi,rcx
0x00000000006f57a2<+22242>: e8 09 ca d0 ff
call0x4021b0

Are they supposed to be there?

Viele Grüße,

Benito

It suggests heap corruption.

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

Possibly, yes.

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.

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

Jonas

Hi

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