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 0x010a in ?? ()
#1 0x046e9cce in queryin (buf=3DCannot access
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
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
Le 30 déc. 04, à 16:05, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
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
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Ugh. That suggests it could be a compiler bug. Are you using the
latest available compiler version for your platform?
The problem is that when compiled with -O2, the pushval_morph func
address is 0x0 (in query.c).
It goes away with the
Le 28 déc. 04, à 23:36, Tom Lane a écrit :
Andrew Dunstan [EMAIL PROTECTED] writes:
This result is now seen for HEAD on buildfarm member osprey:
Yeah, I was wondering about that. It should be easy to reproduce the
failure by hand (just run the tsearch regression test and then
re-execute that
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
here is the tail of regression.diff (which indicates that the first=20
query failed):
SELECT '1'::mquery_txt;
! server closed the connection unexpectedly
! This probably means the server terminated abnormally
! before or
Le 29 déc. 04, à 18:05, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
here is the tail of regression.diff (which indicates that the first=20
query failed):
SELECT '1'::mquery_txt;
! server closed the connection unexpectedly
! This probably means the server
=?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 0x010a in ?? ()
#1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0
) at
This result is now seen for HEAD on buildfarm member osprey:
= pgsql.23138/contrib/tsearch/regression.diffs ===
*** ./expected/tsearch.out Tue Dec 28 12:05:27 2004
--- ./results/tsearch.out Tue Dec 28 19:52:47 2004
***
*** 312,322
(1 row)
SELECT
Andrew Dunstan [EMAIL PROTECTED] writes:
This result is now seen for HEAD on buildfarm member osprey:
Yeah, I was wondering about that. It should be easy to reproduce the
failure by hand (just run the tsearch regression test and then
re-execute that query) --- can we see a debugger stack trace
10 matches
Mail list logo
