Re: error status 139

From: Laurette Cisneros <laurette(at)nextbus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: error status 139
Date: 2001-07-23 16:37:40
Message-ID: Pine.LNX.4.33.0107230933110.13192-100000@visor.corp.nextbus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Thanks for the help...

I am using vers. 7.1.2 of PostgreSQL on Redhat Linux 7.1 (2.4 kernel). I am running a set of external functions (in C) that are dynamincally loaded when needed (in a .so) that do some computations on rows. It works fine if I do a few rows, but crashes when done ni "batch" (a large set of rows).

My C is rusty and any help you can give is greatly appreciated.

Thannks!

Here's the stack track from the core file:
#0 0x4013275a in _IO_vfprintf (s=0x0,
format=0x4001966f "nbpointdist\n", ap=0xbfffe860)
at vfprintf.c:270
#1 0x4013c445 in fprintf (stream=0x0,
format=0x4001966f "nbpointdist\n") at fprintf.c:32
#2 0x40018e44 in nbpointdist () at eval.c:41
#3 0x40018d43 in dpath () at eval.c:41
#4 0x081463be in fmgr_oldstyle (fcinfo=0x82f8e04) at fmgr.c:448
#5 0x080d04ed in ExecMakeFunctionResult (fcache=0x82f8df0,
arguments=0x82efb08, econtext=0x82ef0e8,
isNull=0x82f12ad "", isDone=0xbfffe9a4) at execQual.c:807
#6 0x080d058e in ExecEvalFunc (funcClause=0x82efab8,
econtext=0x82ef0e8, isNull=0x82f12ad "", isDone=0xbfffe9a4)
at execQual.c:901
#7 0x080d095c in ExecEvalExpr (expression=0x82efab8,
econtext=0x82ef0e8, isNull=0x82f12ad "", isDone=0xbfffe9a4)
at execQual.c:1226
#8 0x080d0338 in ExecEvalFuncArgs (fcache=0x82f1248,
argList=0x82efaa0, econtext=0x82ef0e8) at execQual.c:614
#9 0x080d03b1 in ExecMakeFunctionResult (fcache=0x82f1248,
arguments=0x82efaa0, econtext=0x82ef0e8,
isNull=0xbfffea57 "", isDone=0xbfffea58) at execQual.c:667
#10 0x080d058e in ExecEvalFunc (funcClause=0x82efa50,
econtext=0x82ef0e8, isNull=0xbfffea57 "", isDone=0xbfffea58)
at execQual.c:901
#11 0x080d095c in ExecEvalExpr (expression=0x82efa50,
econtext=0x82ef0e8, isNull=0xbfffea57 "", isDone=0xbfffea58)
at execQual.c:1226
#12 0x080d0bfb in ExecTargetList (targetlist=0x82efb78,
nodomains=6, targettype=0x82f0c08, values=0x82f0fa0,
econtext=0x82ef0e8, isDone=0xbfffec28) at execQual.c:1547
#13 0x080d0e55 in ExecProject (projInfo=0x82f0f78,
isDone=0xbfffec28) at execQual.c:1775
#14 0x080d59fa in ExecNestLoop (node=0x82ef9b0)
at nodeNestloop.c:245
#15 0x080cf7a6 in ExecProcNode (node=0x82ef9b0, parent=0x82ef9b0)
at execProcnode.c:297
#16 0x080ceafe in ExecutePlan (estate=0x82efd60, plan=0x82ef9b0,
operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x82f10d0)
at execMain.c:974
#17 0x080ce073 in ExecutorRun (queryDesc=0x82efd48,
estate=0x82efd60, feature=3, count=0) at execMain.c:233
#18 0x0810ef73 in ProcessQuery (parsetree=0x8287840,
plan=0x82ef9b0, dest=Remote) at pquery.c:295
#19 0x0810db7b in pg_exec_query_string (
query_string=0x82866f0 "\n SELECT \n nbdist2point(p.path_points, dpath(p.path_points), s.path_position) AS nbdist2point,\n", ' ' <repeats 15 times>, "s.stop_tag, s.dir_tag, s.path_tag, \n", ' ' <repeats 15 times>, "s.path_position, s.stop_o"...,
dest=Remote, parse_context=0x826a978) at postgres.c:810
#20 0x0810eaa6 in PostgresMain (argc=4, argv=0xbfffef08,
real_argc=4, real_argv=0xbffff83c,
username=0x82585b1 "laurette") at postgres.c:1908
#21 0x080fa503 in DoBackend (port=0x8258348) at postmaster.c:2114
#22 0x080fa0ec in BackendStartup (port=0x8258348)
at postmaster.c:1897
#23 0x080f93c6 in ServerLoop () at postmaster.c:995
#24 0x080f8d93 in PostmasterMain (argc=4, argv=0xbffff83c)
at postmaster.c:685
#25 0x080dcd55 in main (argc=4, argv=0xbffff83c) at main.c:175
#26 0x400fae5e in __libc_start_main (main=0x80dcc40 <main>,
argc=4, ubp_av=0xbffff83c, init=0x807dec0 <_init>,
fini=0x81aeb7c <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>,
stack_end=0xbffff834) at ../sysdeps/generic/libc-start.c:129

On Sat, 21 Jul 2001, Tom Lane wrote:

> Laurette Cisneros <laurette(at)nextbus(dot)com> writes:
> > Any idea what status 139 indicates?
>
> SIGSEGV core dump, on most systems. Look for the backend core file
> (in $PGDATA/base/yourdb/core) and send us a gdb stack trace ...
> also, it would help to know what PG version you are running, on
> what platform, and what you were doing when the crash happened.
>
> regards, tom lane
>

--
Laurette Cisneros
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
Passenger Information Everywhere

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Laurette Cisneros 2001-07-24 00:15:58 Re: error status 139
Previous Message Gary Stainburn 2001-07-23 14:09:09 Re: Better copy/import