Thread: Server process exited with status 139 (meaning?)

Server process exited with status 139 (meaning?)

From

Ed Loehr

Date:

23 June 2000, 17:11:24

I have a query crashing the backend and leaving this message in the
server log...

What does exit status 139 mean?  Better still would be a pointer to some
documentation for error codes if such beast exists...

Regards,
Ed Loehr

Re: Server process exited with status 139 (meaning?)

From

Peter Eisentraut

Date:

25 June 2000, 00:03:49

Ed Loehr writes:

> I have a query crashing the backend and leaving this message in the
> server log...
> What does exit status 139 mean?

The backend terminated because of a segmentation fault (note 139 = 128 +
11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
query.

> Better still would be a pointer to some documentation for error codes
> if such beast exists...

See wait(2). Of course we could also make the error message more
expressive.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: Server process exited with status 139 (meaning?)

From

Ed Loehr

Date:

26 June 2000, 03:05:45

Peter Eisentraut wrote:
> 
> Ed Loehr writes:
> 
> > I have a query crashing the backend and leaving this message in the
> > server log...
> > What does exit status 139 mean?
> 
> The backend terminated because of a segmentation fault (note 139 = 128 +
> 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> query.

I don't need help on this as I found workable queries for my purposes,
but here is a simplified core-dumper (7.0beta3) for posterity...

Regards,
Ed Loehr

DROP TABLE foo;
CREATE TABLE foo (d date);
CREATE UNIQUE INDEX date_uidx ON foo(d);
CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
INSERT INTO foo (d) VALUES ('17-Jun-1995');
INSERT INTO foo (d) VALUES ('18-Jun-1995');
INSERT INTO foo (d) VALUES ('19-Jun-1995');
DROP TABLE bar;
DROP SEQUENCE bar_id_seq;
CREATE TABLE bar (   id SERIAL,    start_time DATETIME,   duration FLOAT
);
INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);
DROP TABLE baz;
DROP SEQUENCE baz_id_seq;
CREATE TABLE baz (   id SERIAL,    bar_id DATETIME,   duration FLOAT
);
INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;       
SELECT f.d, r.start_time::date, r.duration AS "r_dur",      z.duration AS "z_dur", f.d,      (r.start_time - '1
day'::interval)::dateAS "leave",      (r.start_time + (z.duration||' days')::interval)::date AS "return"
 
FROM foo f, activity r, activity_hr_need z
WHERE r.id = 2 AND z.activity_id = 2 AND (f.d = (r.start_time - '1 day'::interval)::date    OR f.d = (r.start_time +
(z.duration||'days')::interval));

Re: Server process exited with status 139 (meaning?)

From

Ed Loehr

Date:

26 June 2000, 03:51:58

Ed Loehr wrote:
> 
> Peter Eisentraut wrote:
> >
> > Ed Loehr writes:
> >
> > > I have a query crashing the backend and leaving this message in the
> > > server log...
> > > What does exit status 139 mean?
> >
> > The backend terminated because of a segmentation fault (note 139 = 128 +
> > 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> > query.
> 
> I don't need help on this as I found workable queries for my purposes,
> but here is a simplified core-dumper (7.0beta3) for posterity...

Oops.  A few typos in my last post.  Correction below (still
segfaulting):

DROP TABLE foo;
CREATE TABLE foo (d date);
CREATE UNIQUE INDEX date_uidx ON foo(d);
CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
INSERT INTO foo (d) VALUES ('17-Jun-1995');
INSERT INTO foo (d) VALUES ('18-Jun-1995');
INSERT INTO foo (d) VALUES ('19-Jun-1995');

DROP TABLE bar;
DROP SEQUENCE bar_id_seq;
CREATE TABLE bar (   id SERIAL,    start_time DATETIME,   duration FLOAT
);
INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);

DROP TABLE baz;
DROP SEQUENCE baz_id_seq;
CREATE TABLE baz (   id SERIAL,    bar_id DATETIME,   duration FLOAT
);
INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;       
-- Here's the offending query...
SELECT f.d, r.start_time::date, r.duration AS "r_dur",      z.duration AS "z_dur", f.d,      (r.start_time - '1
day'::interval)::dateAS "leave",      (r.start_time + (z.duration||' days')::interval)::date AS "return"
 
FROM foo f, bar r, baz z
WHERE r.id = 2 AND z.bar_id = 2 AND (f.d = (r.start_time - '1 day'::interval)::date    OR f.d = (r.start_time +
(z.duration||'days')::interval));

Re: Server process exited with status 139 (meaning?)

From

Tom Lane

Date:

26 June 2000, 03:57:51

Ed Loehr <eloehr@austin.rr.com> writes:
> I don't need help on this as I found workable queries for my purposes,
> but here is a simplified core-dumper (7.0beta3) for posterity...

This doesn't come close to doing anything as-is, but even reading
between the lines ("activity"=>"bar" etc) and deleting references
to missing fields, I can't get a crash.  Possibly a bug fixed since
beta3?
        regards, tom lane

Re: Server process exited with status 139 (meaning?)

From

Ed Loehr

Date:

26 June 2000, 04:02:49

Ed Loehr wrote:
> 
> > > > I have a query crashing the backend and leaving this message in the
> > > > server log...
> > > > What does exit status 139 mean?
> > >
> > > The backend terminated because of a segmentation fault (note 139 = 128 +
> > > 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> > > query.
> >
> > I don't need help on this as I found workable queries for my purposes,
> > but here is a simplified core-dumper (7.0beta3) for posterity...
> 
> Oops.  A few typos in my last post.  Correction below (still
> segfaulting):
> 
> DROP TABLE foo;
> CREATE TABLE foo (d date);
> CREATE UNIQUE INDEX date_uidx ON foo(d);
> CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
> INSERT INTO foo (d) VALUES ('17-Jun-1995');
> INSERT INTO foo (d) VALUES ('18-Jun-1995');
> INSERT INTO foo (d) VALUES ('19-Jun-1995');
> 
> DROP TABLE bar;
> DROP SEQUENCE bar_id_seq;
> CREATE TABLE bar (
>     id SERIAL,
>     start_time DATETIME,
>     duration FLOAT
> );
> INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
> INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
> INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);
> 
> DROP TABLE baz;
> DROP SEQUENCE baz_id_seq;
> CREATE TABLE baz (
>     id SERIAL,
>     bar_id DATETIME,            ^^^^^^^^^

One more typo:  'bar_id' should be of type INTEGER (and the crash
remains).

Regards,
Ed Loehr

>     duration FLOAT
> );
> INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;
> 
> -- Here's the offending query...
> SELECT f.d, r.start_time::date, r.duration AS "r_dur",
>        z.duration AS "z_dur", f.d,
>        (r.start_time - '1 day'::interval)::date AS "leave",
>        (r.start_time + (z.duration||' days')::interval)::date AS "return"
> FROM foo f, bar r, baz z
> WHERE r.id = 2
>   AND z.bar_id = 2
>   AND (f.d = (r.start_time - '1 day'::interval)::date
>     OR f.d = (r.start_time + (z.duration||' days')::interval));

Re: Server process exited with status 139 (meaning?)

From

Ed Loehr

Date:

26 June 2000, 04:20:28

Tom Lane wrote:
> 
> Ed Loehr <eloehr@austin.rr.com> writes:
> > I don't need help on this as I found workable queries for my purposes,
> > but here is a simplified core-dumper (7.0beta3) for posterity...
> 
> This doesn't come close to doing anything as-is, but even reading
> between the lines ("activity"=>"bar" etc) and deleting references
> to missing fields, I can't get a crash.  Possibly a bug fixed since
> beta3?

I'll assume you tried my latest typo-free version on an HP box after
posting this and got the same results (i.e., nothing).  Maybe someone
else would care to verify on a Linux box?  I'm on RH 6.2 with dual
PIII's...

Regards,
Ed Loehr

Re: Server process exited with status 139 (meaning?)

From

Thomas Lockhart

Date:

26 June 2000, 04:29:08

> I'll assume you tried my latest typo-free version on an HP box after
> posting this and got the same results (i.e., nothing).  Maybe someone
> else would care to verify on a Linux box?  I'm on RH 6.2 with dual
> PIII's...

I see the latest being formally rejected down in the Executor. So
something is better than in the beta, but the plan being generated is
not quite right apparently.
               - Thomas

Re: Server process exited with status 139 (meaning?)

From

Tom Lane

Date:

26 June 2000, 05:51:55

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I see the latest being formally rejected down in the Executor. So
> something is better than in the beta, but the plan being generated is
> not quite right apparently.

No sign of a problem here (using current sources).  Exactly which of
Ed's versions did you see a problem with, and what did you see exactly?
        regards, tom lane

Re: Server process exited with status 139 (meaning?)

From

Andrew McMillan

Date:

26 June 2000, 10:51:58

Ed Loehr wrote:
> > > I don't need help on this as I found workable queries for my purposes,
> > > but here is a simplified core-dumper (7.0beta3) for posterity...
> >

test=# -- Here's the offending query...
test=# SELECT f.d, r.start_time::date, r.duration AS "r_dur",
test-#        z.duration AS "z_dur", f.d,
test-#        (r.start_time - '1 day'::interval)::date AS "leave",
test-#        (r.start_time + (z.duration||' days')::interval)::date AS
"return"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2
test-#   AND z.bar_id = 2
test-#   AND (f.d = (r.start_time - '1 day'::interval)::date 
test(#     OR f.d = (r.start_time + (z.duration||' days')::interval));    d      |  ?column?  | r_dur | z_dur |     d
  |   leave    |  
 
return   
------------+------------+-------+-------+------------+------------+------------1995-06-17 | 1995-06-18 |     3 |     3
|1995-06-17 | 1995-06-17 |
 
1995-06-21
(1 row)

test=# 
test=# explain SELECT f.d, r.start_time::date, r.duration AS "r_dur",
test-#        z.duration AS "z_dur", f.d,
test-#        (r.start_time - '1 day'::interval)::date AS "leave",
test-#        (r.start_time + (z.duration||' days')::interval)::date AS
"return"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2
test-#   AND z.bar_id = 2
test-#   AND (f.d = (r.start_time - '1 day'::interval)::date 
test(#     OR f.d = (r.start_time + (z.duration||' days')::interval));
NOTICE:  QUERY PLAN:

Nested Loop  (cost=0.00..5354.86 rows=1990 width=28) ->  Nested Loop  (cost=0.00..104.86 rows=100 width=24)       ->
SeqScan on baz z  (cost=0.00..22.50 rows=10 width=8)       ->  Index Scan using bar_id_key on bar r  (cost=0.00..8.14
 
rows=10 width=16) ->  Seq Scan on foo f  (cost=0.00..20.00 rows=1000 width=4)

EXPLAIN
test=# select version();                           version                            
---------------------------------------------------------------PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc
2.95.2
(1 row)


Works fine on my Debian 'woody' system on my laptop.


Also, looking at your other query:

test=#         
test=# -- Here's the offending query...
test=# SELECT f.d, r.start_time::date, r.duration AS "r_dur", z.duration
AS
test-# "z_dur"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2 
test-#   AND z.bar_id = 2
test-#   AND f.d = (r.start_time - '1 day'::interval)::date ;d | ?column? | r_dur | z_dur 
---+----------+-------+-------
(0 rows)

so no problem there either.  Looks like you should get a trade-in on
that beta3 :-)

Cheers,            Andrew.
-- 
_____________________________________________________________________           Andrew McMillan, e-mail:
Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267