table schema causes crash

I just tried with the CVS current and don't see a crash. I don't see
anything fancy in there at all.

---------------------------------------------------------------------------

tom@minnesota.com wrote:

7.2.3

CREATE TABLE imap_passwd (
username varchar(128) NOT NULL PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_cr varchar(128) DEFAULT '' NOT NULL,
name varchar(128) DEFAULT '' NOT NULL,
user_id int DEFAULT 65534 NOT NULL,
group_id int DEFAULT 65534 NOT NULL,
home varchar(255) DEFAULT '' NOT NULL,
maildir varchar(255) DEFAULT '' NOT NULL,
quota varchar(255) DEFAULT '' NOT NULL
);

then at the psql prompt:

\d imap_passwd

will core dump.

---
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d imap_passwd
Segmentation fault
---

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I just tried with the CVS current and don't see a crash. I don't see
anything fancy in there at all.

Works for me in 7.2.3, as well.

How about a stack trace, platform details, etc?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I just tried with the CVS current and don't see a crash. I don't see
anything fancy in there at all.

Works for me in 7.2.3, as well.

How about a stack trace, platform details, etc?

it segmentation faults but didn't core dump. postmaster is still running
though, so maybe psql segmentation fault.

# uname -a
NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002
root@ns01:/usr/s
rc/1.6/sys/arch/alpha/compile/ns01-1.6 alpha

I tried creating a test table and it suceeded w/o any problems:

create table testtable (
col_1 varchar(64) primary key,
col_2 varchar(32),
col_3 int
);

---

authtest=# create table testtable (
authtest(# col_1 varchar(64) primary key,
col_2 varchar(32),
col_3 int
);col_1 varchar(64) primary key,
authtest(# col_2 varchar(32),
authtest(# col_3 int
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'testtable_pkey' for table '
testtable'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'testtable_pkey' for table '
testtable'
CREATE
authtest=# \d testtable
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+--------------
col_1 | character varying(64) | col_3 int
col_2 | character varying(32) | \d testtable
col_3 | integer | testtable
Primary key: testtable_pkey

authtest=#

---
*** NOTE \d worked above for testtable ****

then i tried creating the other table that caused it to crash again:

---

authtest=# CREATE TABLE imap_passwd (
authtest(# username varchar(128) NOT NULL PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_clear varchar(128) DEFAULT '' NOT NULL,
real_name varchar(128) DEFAULT '' username
varchar(
128) NOT NULL PRIMARY KEY,
authtest(# pw_crypt varchar(128) DEFAULT '' NOT NULL,
authtest(# pw_clear varchar(128) DEFAULT '' NOT NULL,
authtest(# real_name varchar(128) DEFAULT '' NOT NULL,
authtest(# user_id int NOT NULL,
authtest(# group_id int NOT NULL,
authtest(# home varchar(255) DEFAULT '' NOT NULL,
authtest(# maildir varchar(255) DEFAULT '' NOT NULL,
authtest(# quota varchar(255) DEFAULT '' NOT NULL
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d testtable
DEBUG: pq_recvbuf: unexpected EOF on client connection
Segmentation fault
$ psql authtest
Welcome to psql, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

authtest=# \d testtable
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+-----------
col_1 | character varying(64) | Primary key: testtable_pkey

*** NOTE THE OTHER MISSING COLUMNS ***

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

authtest=# drop table imap_passwd;
DROP
authtest=# \d testtable;
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+-----------
col_1 | character varying(64) | Primary key: testtable_pkey

authtest=# drop table testtable;
DROP

----

as you can see the creation of table imap_passwd causes psql to
segmentation fault and causes the odd effect of '\d' command.

<tom@minnesota.com> writes:

# uname -a
NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002
root@ns01:/usr/src/1.6/sys/arch/alpha/compile/ns01-1.6 alpha

Alpha, huh? I wonder if there's some 64-bit problem in psql?

But still, you haven't given us anywhere near enough information to find
the problem. I think you'll have to either get in there with a debugger
yourself, or let someone have a temporary account on your machine to
study the problem.

regards, tom lane

<tom@minnesota.com> writes:

# uname -a
NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002
root@ns01:/usr/src/1.6/sys/arch/alpha/compile/ns01-1.6 alpha

Alpha, huh? I wonder if there's some 64-bit problem in psql?

unless something changed in psql from 7.2 to 7.2.3 that could cause
64-bit. I didn't come across this problem in 7.2. If it was a table
creation problem, why didn't the creation of testtable segmentation fault?

But still, you haven't given us anywhere near enough information to find
the problem. I think you'll have to either get in there with a debugger
yourself, or let someone have a temporary account on your machine to
study the problem.

I haven't much experience in using the debugger, but if you tell me how I
can send you the results. If all else fail, what type of access do you
need?

But still, you haven't given us anywhere near enough information to
find the problem. I think you'll have to either get in there with a
debugger yourself, or let someone have a temporary account on your
machine to study the problem.

I attached gdb to a running pid of psql. After I do:

\d imap_passwd

There are thousands of these lines in gdb:

...
#14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14136 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14137 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14138 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
...

pressing <return> and it keeps going and going...

<tom@minnesota.com> writes:

There are thousands of these lines in gdb:
#14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so

I'd say the thing is already hosed at this point --- can you dig
down to the bottom of the call stack and see what's under the infinite
recursion?

regards, tom lane

<tom@minnesota.com> writes:

There are thousands of these lines in gdb:
#14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so

I'd say the thing is already hosed at this point --- can you dig
down to the bottom of the call stack and see what's under the infinite
recursion?

(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text ()
#2 0x120012ea8 in printTable ()
#3 0x120015a94 in describeTableDetails ()
#4 0x1200041f0 in exec_command ()
#5 0x120003a50 in HandleSlashCmds ()
#6 0x12000bb8c in MainLoop ()
#7 0x12000d974 in main ()
#8 0x1200036a4 in __start ()
#9 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#10 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#11 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
#12 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
[...]

<tom@minnesota.com> writes:

(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text ()
#2 0x120012ea8 in printTable ()
#3 0x120015a94 in describeTableDetails ()
#4 0x1200041f0 in exec_command ()
#5 0x120003a50 in HandleSlashCmds ()
#6 0x12000bb8c in MainLoop ()
#7 0x12000d974 in main ()

Hmm.  Evidently a null (or invalid) pointer is getting passed to
strlen(), but it's hard to say more without a symbolic backtrace
--- for which you'll need to recompile psql with debug symbols.

We've found a number of bugs in print_aligned_text() in the past, but
the only post-7.2 fixes I see in the logs have to do with zero-column
tables; it seems unlikely that \d is triggering those bugs. Possibly
you've found something new.

regards, tom lane

[...]

Hmm.  Evidently a null (or invalid) pointer is getting passed to
strlen(), but it's hard to say more without a symbolic backtrace
--- for which you'll need to recompile psql with debug symbols.

[...]

I recompiled psql with debug.

---
Program received signal SIGSEGV, Segmentation fault.
0x160275d84 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text (
title=0x120036580 "Table \"imap_passwd\"", headers=0x1fffff510,
cells=0x120036100, footers=0x12003a460, opt_align=0x120020d16 "llll",
opt_barebones=0 '\000', opt_border=1, fout=0x160293568) at print.c:280
#2 0x120012ea8 in printTable (title=0x120036580 "Table \"imap_passwd\"",
headers=0x1fffff510, cells=0x120036100, footers=0x12003a460,
align=0x120020d16 "llll", opt=0x1fffff4e8, fout=0x160293568)
at print.c:1123
#3 0x120015a94 in describeTableDetails (name=0x120020cc4 "Primary key",
desc=0 '\000') at describe.c:914
#4 0x1200041f0 in exec_command (cmd=0x12003a430 "d",
options_string=0x12003a432 "imap_passwd", continue_parse=0x1fffff6e0,
query_buf=0x1200389e0) at command.c:347
#5 0x120003a50 in HandleSlashCmds (line=0x12003a3b1 "d imap_passwd",
query_buf=0x1200389e0, end_of_cmd=0x1fffff750) at command.c:135
#6 0x12000bb8c in MainLoop (source=0x1602934d0) at mainloop.c:467
#7 0x12000d974 in main (argc=1613313248, argv=0x12001ea33) at startup.c:305
(gdb)

Let me ask --- if you execute \a, then \d in psql, does it display OK?
How about \x and then \d?

---------------------------------------------------------------------------

tom@minnesota.com wrote:

[...]

Hmm.  Evidently a null (or invalid) pointer is getting passed to
strlen(), but it's hard to say more without a symbolic backtrace
--- for which you'll need to recompile psql with debug symbols.

[...]

I recompiled psql with debug.

---
Program received signal SIGSEGV, Segmentation fault.
0x160275d84 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text (
title=0x120036580 "Table \"imap_passwd\"", headers=0x1fffff510,
cells=0x120036100, footers=0x12003a460, opt_align=0x120020d16 "llll",
opt_barebones=0 '\000', opt_border=1, fout=0x160293568) at print.c:280
#2 0x120012ea8 in printTable (title=0x120036580 "Table \"imap_passwd\"",
headers=0x1fffff510, cells=0x120036100, footers=0x12003a460,
align=0x120020d16 "llll", opt=0x1fffff4e8, fout=0x160293568)
at print.c:1123
#3 0x120015a94 in describeTableDetails (name=0x120020cc4 "Primary key",
desc=0 '\000') at describe.c:914
#4 0x1200041f0 in exec_command (cmd=0x12003a430 "d",
options_string=0x12003a432 "imap_passwd", continue_parse=0x1fffff6e0,
query_buf=0x1200389e0) at command.c:347
#5 0x120003a50 in HandleSlashCmds (line=0x12003a3b1 "d imap_passwd",
query_buf=0x1200389e0, end_of_cmd=0x1fffff750) at command.c:135
#6 0x12000bb8c in MainLoop (source=0x1602934d0) at mainloop.c:467
#7 0x12000d974 in main (argc=1613313248, argv=0x12001ea33) at startup.c:305
(gdb)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Let me ask --- if you execute \a, then \d in psql, does it display OK?
How about \x and then \d?

I created the table as described earlier, it segmentation fault. I ran
psql again, then:

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

*** NOTE: it only shows the first column and none of the other columns ***

authtest=# \a
Output format is unaligned.
authtest=# \a
Output format is aligned.
authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

authtest=# \a
Output format is unaligned.
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
username|character varying(128)|Primary key: imap_passwd_pkey
authtest=# \x
Expanded display is on.
authtest=# \d imap_passwd
Table "imap_passwd"

Column|username
Type|character varying(128)

Primary key: imap_passwd_pkey
authtest=# \x
Expanded display is off.
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
username|character varying(128)|Primary key: imap_passwd_pkey

authtest=# drop table imap_passwd;
DROP
authtest=# CREATE TABLE imap_passwd (
authtest(# username varchar(128) PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_clear varchar(128) DEFAULT '' NOT NULL,
real_name varchar(128) DEFAULT '' NOT NULL,
user_id int DEFAULT '65534' NOT NULL,
group_id int DEFAULT '65534' NOT N username
varcha
r(128) PRIMARY KEY,
authtest(# pw_crypt varchar(128) DEFAULT '' NOT NULL,
authtest(# pw_clear varchar(128) DEFAULT '' NOT NULL,
authtest(# real_name varchar(128) DEFAULT '' NOT NULL,
authtest(# user_id int DEFAULT '65534' NOT NULL,
authtest(# group_id int DEFAULT '65534' NOT NULL,
authtest(# home varchar(255) DEFAULT '' NOT NULL,
authtest(# maildir varchar(255) DEFAULT '' NOT NULL,
authtest(# quota varchar(255) DEFAULT '' NOT NULL
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
Segmentation fault

***
NOTE: it only crashes when \d imap_passwd AFTER fresh new create of
imap_passwd
***

---------------------------------------------------------------------------

Let me ask --- if you execute \a, then \d in psql, does it display OK?
How about \x and then \d?

I created the table as described earlier, it segmentation fault. I ran
psql again, then:

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

*** NOTE: it only shows the first column and none of the other columns
***

[...]

After doing more \d on various tables, it finally core dumped on the psql
binary with debug symbols:

This GDB was configured as "alpha-unknown-netbsd"...
Core was generated by `psql'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Reading symbols from /usr/local/lib/libpq.so.2...done.
Loaded symbols for /usr/local/lib/libpq.so.2
Reading symbols from /usr/lib/libz.so.0...done.
Loaded symbols for /usr/lib/libz.so.0
Reading symbols from /usr/lib/libcrypt.so.0...done.
Loaded symbols for /usr/lib/libcrypt.so.0
Reading symbols from /usr/lib/libresolv.so.1...done.
Loaded symbols for /usr/lib/libresolv.so.1
Reading symbols from /usr/lib/libm.so.0...done.
Loaded symbols for /usr/lib/libm.so.0
Reading symbols from /usr/lib/libutil.so.6...done.
Loaded symbols for /usr/lib/libutil.so.6
Reading symbols from /usr/lib/libedit.so.2...done.
Loaded symbols for /usr/lib/libedit.so.2
Reading symbols from /usr/lib/libcurses.so.5...done.
Loaded symbols for /usr/lib/libcurses.so.5
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text (title=0x120015a94 "\002", headers=0xc,
cells=0x12003a550, footers=0x0, opt_align=0x120020cc4 "Primary key",
opt_barebones=1 '\001', opt_border=0, fout=0x12003a540) at print.c:280

<tom@minnesota.com> writes:

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

*** NOTE: it only shows the first column and none of the other columns ***

What I find even more suspicious is that the "Primary key" footer shows
up in the table data area. Looking at print_aligned_text, this seems to
suggest that cells[2] must be NULL --- you would get this kind of
mistake if the number of non-null cells[] entries is not a multiple of
the number of non-null headers[] entries. But I surely do not see how
describeTableDetails would be setting that cell to null --- it does

cells[i * cols + 2] = xmalloc(128 + 128);

and xmalloc() will exit() rather than return null.

regards, tom lane

<tom@minnesota.com> writes:

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

*** NOTE: it only shows the first column and none of the other columns
***

What I find even more suspicious is that the "Primary key" footer shows
up in the table data area. Looking at print_aligned_text, this seems to

[...]

\d on any table shows only the first column:

authtest=# \d country
Table "country"
Column | Type | Modifiers
------------+---------+-----------
country_id | integer | Primary key: country_pkey

authtest=# \d auth_address
Table "auth_address"
Column | Type | Modifiers
------------+---------+-----------
address_id | integer | Primary key: auth_address_pkey
Unique keys: auth_address_user_id_key
Triggers: RI_ConstraintTrigger_9306303,
RI_ConstraintTrigger_9306352,
RI_ConstraintTrigger_9306354

authtest=# \d auth_email
Table "auth_email"
Column | Type | Modifiers
----------+---------+-----------
email_id | integer | Primary key: auth_email_pkey
Unique keys: auth_email_em_idx,
auth_email_ev_idx,
auth_email_user_id_key
Triggers: RI_ConstraintTrigger_9324514

---

All of the above table came from the same db. However, when I connect to a
different database, things are normal again:

authtest=# \c transition
You are now connected to database transition.
transition=# \d t_blocks
Table "t_blocks"
Column | Type | Modifiers
--------------+--------------------------+-----------
rid | character varying(16) | atthasdef
display | character(1) | �
heading | character varying(48) |
content | text | ter(1)
url | character varying(96) |
type | smallint |
birthstamp | timestamp with time zone | pgsql
timestamp | timestamp with time zone | l
showmain | character(1) | �
hits | integer |
cache | integer |
pagecomments | character(1) |
orderid | smallint | zone
Primary key: t_blocks_pkey

---
But note the Modifiers column. There are some very odd values in there.

Could it be related to the fact that in 7.2 and earlier, didn't use the flag:

--enable-multibyte

I only started using --enable-multibyte in 7.2.3.

On Fri, 20 Dec 2002, Tom Lane wrote:

<tom@minnesota.com> writes:

authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey

*** NOTE: it only shows the first column and none of the other columns ***

What I find even more suspicious is that the "Primary key" footer shows
up in the table data area. Looking at print_aligned_text, this seems to
suggest that cells[2] must be NULL --- you would get this kind of
mistake if the number of non-null cells[] entries is not a multiple of
the number of non-null headers[] entries. But I surely do not see how
describeTableDetails would be setting that cell to null --- it does

cells[i * cols + 2] = xmalloc(128 + 128);

and xmalloc() will exit() rather than return null.

This is sounding more and more like a machine with bad memory or a bad
hard drive.

<tom@minnesota.com> writes:

Could it be related to the fact that in 7.2 and earlier, didn't use the flag:
--enable-multibyte
I only started using --enable-multibyte in 7.2.3.

Oh? Are you sure you've been consistent about using --enable-multibyte?

I am suddenly wondering about the possible consequences of psql compiled
with multibyte used with a libpq.so compiled without, or vice versa.

I don't believe that we'd see these consequences for psql and backend
not compiled the same way; those combinations are reasonably well
tested. I'm less sure about psql-to-libpq.so incompatibilities, though.

regards, tom lane

<tom@minnesota.com> writes:

Could it be related to the fact that in 7.2 and earlier, didn't use
the flag: --enable-multibyte
I only started using --enable-multibyte in 7.2.3.

Oh? Are you sure you've been consistent about using --enable-multibyte?

I'm pretty sure. All installtions from 7.2 and before didn't have
--enable-multibyte, while 7.2.3 has it configured with that option.

I am suddenly wondering about the possible consequences of psql compiled
with multibyte used with a libpq.so compiled without, or vice versa.

the pgsql i used with debug has --enable-multibyte, as well as libpg.so.

While studying this I noticed a number of potential buffer overruns in
the 7.2.3 version of describeTableDetails(). They were mostly fixed
already in 7.3, and I just committed a fix for one more. However,
I do not believe that any of these overruns could have occurred in the
example you give, so there's still something fishy going on. On the
whole, I'd still bet that it's a 64-bit-platform issue. But where?
Good luck digging...

regards, tom lane