=?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
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 alre
=?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 backtr
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:
> 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
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 te
=?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
> ! bef
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 que
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 trac
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
10 matches
Mail list logo
