Thread

a small problem with current CVS - wondering how to debug

teunis <teunis@mauve.computersupportcentre.com> — 1998-01-15T19:54:13Z

I keep getting:

Too Large Allocation Request("!(0 < (size) && (size) <=  
(0xfffffff)):size=-3 [0xfffffffd]", File: "mcxt.c", Line: 232)
!(0 < (size) && (size) <= (0xfffffff)) (0) [No such file or directory]

from a simple select:

SELECT * from provinces;

incidentally, "SELECT oid from provinces;" works...
(as does any select on one component)... but checking...
Nope - countrycode fails.  Prints out garbage (8bit garbage at that)
As do all fields after that - though they're just bad data.

For comparison, I have another database with "varchar(50), integer,
timestamp, timestamp" - and the only noncorrupted field is the first
varchar() entry.  Perhaps it's in the string-handling?

The contents of the database:
---
CREATE TABLE provinces
  (
  code		char(4),	-- ...
  name		varchar(50),	-- ...
  countrycode	char(2),	-- ...
  country	varchar(50),	-- ...

  -- creation and modification dates of this record...
  creationdate	timestamp default now(),
  modifydate	timestamp default now()
  );

INSERT INTO provinces (code, name, countrycode, country)
	VALUES ('bc','British Columbia','ca','Canada');
INSERT INTO provinces (code, name, countrycode, country)
	VALUES ('ab','Alberta',         'ca','Canada');
INSERT INTO provinces (code, name, countrycode, country)
	VALUES ('alta','Alberta',       'ca','Canada');
-- one gets tired of databases referring to "state"... so time to turn the
-- tables *grin*
INSERT INTO provinces (code, name, countrycode, country)
	VALUES ('wa', 'Washington',	'us','United States');
---

Incidentally, this worked perfectly up 'till christmas-CVS.  I had some
other problems so I upgraded... and now it core-dumps 'psql' and sends
this to the backend.

On debugging psql I found the error in "UP()", but as I don't know how to
use gdb properly I can't look any deeper (I've always preferred logfiles -
especially when working on videodriver code :)
[mayhaps psql needs better recovery code... will have to look at that
sometime]

JDBC also fails FWIW - with these messages:  (same query)
java.sql.SQLException: Error reading from backend: java.io.IOException: EOF
        at postgresql.PG_Stream.ReceiveInteger(PG_Stream.java:184)
        at postgresql.PG_Stream.ReceiveTuple(PG_Stream.java:256)
        at postgresql.Connection.ExecSQL(Connection.java:626)
        at postgresql.Statement.execute(Statement.java:259)
        at postgresql.Statement.executeQuery(Statement.java:46)
        at Mauve.Main.readProvinces(Main.java:234)
        at Mauve.Main.main(Main.java:363)
java.sql.SQLException: I/O Error: java.io.IOException: Broken pipe
        at postgresql.Connection.ExecSQL(Connection.java:583)
        at postgresql.Statement.execute(Statement.java:259)
        at postgresql.Statement.executeQuery(Statement.java:46)
        at Mauve.Main.readPaymentForms(Main.java:252)
        at Mauve.Main.main(Main.java:366)

I suspect a bug somewhere - but don't know how to find it.  Or if my
data's incorrect.... many things have changed in postgres.

Platform:
	linux 2.0.33  (got tired of being flamed for using 2.1 kernels)
	glibc-2.0.5c  (standard!  ref: redhat-5.0)
	gcc 2.7.2.1   (I also have egc-1.0 but I don't trust it yet)
	Cyrix 6x86, 40M ram, ~5G drivespace

Though it's nice to finally see large objects working *grin*.

G'day, eh? :)
	- Teunis