Open stormalf opened 2 months ago
it was caused by incorrect extended assembly generated by chibicc that causes a segmentation fault :
0x000000000147addd in pg_atomic_compare_exchange_u32_impl () at ../../../../src/include/port/atomics/arch-x86.h:171 171 asm volatile( (gdb) bt
at ../../../../src/include/port/atomics/arch-x86.h:171
New segmentation fault after fixing the issue with atomic compare exchange : Thread 5.1 "postgres" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7c7fb80 (LWP 532639)] 0x0000000000000000 in ?? () (gdb) bt
the issue was in pg_stat.c compiled by chibicc the pointer function defined in a struct is always null. Compiling the same program pg_stat.c with gcc, the function pointer in a struct has a valid address!
After investigation the root cause was the offsetof management by chibicc that was not correct. With help of chatgpt, rewritten the builtin_offsetof parsing to manage all the case we can find in postgres. Will be solved in 1.0.23.
postgres execution failed with segmentation fault and sometimes --auth requires a value. Not sure yet, what is this segmentation fault and why when retrying with gdb instead of segmentation fault we receive FATAL --auth requires a value bucket: 162 sshift: 8 hashvalue: 2696752290 segment_num: 0 hashp->dsize: 256 hashp->dir: 0x33e53c8 1===bucket=162,Segmentation fault child process exited with exit code 139 2024-08-22 09:24:21.464 GMT [269657] FATAL: --auth requires a value [Inferior 3 (process 269657) exited with code 01] (gdb) no idea for now about the root cause: 0x00007ffff7ce1887 in __GI___libc_write (fd=4, buf=0x584020, nbytes=155) at ../sysdeps/unix/sysv/linux/write.c:26 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directory. (gdb) bt
0 0x00007ffff7ce1887 in __GI___libc_write (fd=4, buf=0x584020, nbytes=155)
1 0x00007ffff7c57eed in _IO_new_file_write (f=0x478d10, data=0x584020, n=155) at ./libio/fileops.c:1180
2 0x00007ffff7c599e1 in new_do_write (to_do=155,
fp=0x478d10) at ./libio/libioP.h:947
3 _IO_new_do_write (to_do=155,
fp=0x478d10) at ./libio/fileops.c:425
4 _IO_new_do_write (fp=0x478d10,
to_do=155) at ./libio/fileops.c:422
5 0x00007ffff7c574d8 in _IO_new_file_sync (fp=0x478d10) at ./libio/fileops.c:798
6 0x00007ffff7c4c1aa in GIIO_fflush (fp=0x478d10) at ./libio/libioP.h:947
7 0x0000000000410f12 in bootstrap_template1 () at initdb.c:331
8 0x0000000000409764 in initialize_data_directory () at initdb.c:3029
9 0x0000000000407bb8 in main () at initdb.c:3430
Perhaps a builtin function that doesn't work as expected ?