Skip site navigation (1) Skip section navigation (2)

Re: buildfarm NetBSD/m68k tsearch regression failure

From: Rémi Zara <remi_zara(at)mac(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buildfarm NetBSD/m68k tsearch regression failure
Date: 2004-12-30 10:57:02
Message-ID: 8BBB8085-5A51-11D9-9EA6-003065B81B34@mac.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Le 29 déc. 04, à 23:38, Tom Lane a écrit :

> =?ISO-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)com> 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/

In response to

Responses

pgsql-hackers by date

Next:From: Hans-Jürgen SchönigDate: 2004-12-30 12:44:36
Subject: Implementing RESET CONNECTION ...
Previous:From: Michael MeskesDate: 2004-12-30 09:39:50
Subject: Re: ECPG CONNECT TO DEFAULT segfault

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group