From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: JIT causes core dump during error recovery |
Date: | 2024-06-26 18:28:33 |
Message-ID: | CAEudQAqmmjNt+iOoz02t3h3uca_ojvPhZxmHwRDM5neiBTewOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em qua., 26 de jun. de 2024 às 15:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:
> I initially ran into this while trying to reproduce the recent
> reports of trouble with LLVM 14 on ARM. However, it also reproduces
> with LLVM 17 on x86_64, and I see no reason to think it's at all
> arch-specific. I also reproduced it in back branches (only tried
> v14, but it's definitely not new in HEAD).
>
> To reproduce:
>
> 1. Build with --with-llvm
>
> 2. Create a config file containing
>
> $ cat $HOME/tmp/temp_config
> # enable jit at max
> jit_above_cost = 1
> jit_inline_above_cost = 1
> jit_optimize_above_cost = 1
>
> and do
> export TEMP_CONFIG=$HOME/tmp/temp_config
>
> 3. cd to .../src/pl/plpgsql/src/, and do "make check".
>
> It gets a SIGSEGV in plpgsql_transaction.sql's
> cursor_fail_during_commit test. The stack trace looks like
>
> (gdb) bt
> #0 __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77
> #1 0x0000000000735c58 in pq_sendstring (buf=0x7ffd80f8eeb0,
> str=0x7f77cffdf000 <error: Cannot access memory at address
> 0x7f77cffdf000>)
> at pqformat.c:197
> #2 0x00000000009ca09c in err_sendstring (buf=0x7ffd80f8eeb0,
> str=0x7f77cffdf000 <error: Cannot access memory at address
> 0x7f77cffdf000>)
> at elog.c:3449
> #3 0x00000000009ca4ba in send_message_to_frontend (edata=0xf786a0
> <errordata>)
> at elog.c:3568
> #4 0x00000000009c73a3 in EmitErrorReport () at elog.c:1715
> #5 0x00000000008987e7 in PostgresMain (dbname=<optimized out>,
> username=0x29fdb00 "postgres") at postgres.c:4378
> #6 0x0000000000893c5d in BackendMain (startup_data=<optimized out>,
> startup_data_len=<optimized out>) at backend_startup.c:105
>
> The errordata structure it's trying to print out contains
>
> (gdb) p *edata
> $1 = {elevel = 21, output_to_server = true, output_to_client = true,
> hide_stmt = false, hide_ctx = false,
> filename = 0x7f77cffdf000 <error: Cannot access memory at address
> 0x7f77cffdf000>, lineno = 843,
> funcname = 0x7f77cffdf033 <error: Cannot access memory at address
> 0x7f77cffdf033>, domain = 0xbd3baa "postgres-17",
> context_domain = 0x7f77c3343320 "plpgsql-17", sqlerrcode = 33816706,
> message = 0x29fdc20 "division by zero", detail = 0x0, detail_log = 0x0,
> hint = 0x0,
> context = 0x29fdc50 "PL/pgSQL function cursor_fail_during_commit() line
> 6 at COMMIT", backtrace = 0x0,
> message_id = 0x7f77cffdf022 <error: Cannot access memory at address
> 0x7f77cffdf022>, schema_name = 0x0, table_name = 0x0, column_name = 0x0,
> datatype_name = 0x0, constraint_name = 0x0, cursorpos = 0, internalpos =
> 0,
> internalquery = 0x0, saved_errno = 2, assoc_context = 0x29fdb20}
>
> lineno = 843 matches the expected error location in int4_div().
>
Did you mean *int4div*, right?
Since there is no reference to int4_div in *.c or *.h
best regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-06-26 18:42:23 | thread-safety: gmtime_r(), localtime_r() |
Previous Message | David E. Wheeler | 2024-06-26 18:16:05 | Re: Patch bug: Fix jsonpath .* on Arrays |