Le 29 déc. 04, à 23:38, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit :Backtracing the core dump from that crash would do fine.
Here you go
(gdb) bt
#0 0x0100000a in ?? ()
#1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0
) at query.c:543
#2 0x046e9e44 in mqtxt_in (fcinfo=3D0xffffb688) at query.c:620
#3 0x0019d790 in OidFunctionCall3 (functionId=3D61367, arg1=3D2762304,=20=
arg2=3D0, arg3=3D4294967295) at fmgr.c:1408
#4 0x00091298 in stringTypeDatum (tp=3D0x2a26e9, string=3D0x2a2640 "1",=20=
atttypmod=3D-1) at parse_type.c:338
Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area.
You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate.
The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2)
regards,
Rémi Zara
-- Rémi Zara http://www.remi-zara.net/
smime.p7s
Description: S/MIME cryptographic signature
