The following bug has been logged online:

Bug reference: 1440
Logged by: Edmund Bacon
Email address: ebacon (AT) onesystem (DOT) com
PostgreSQL version: 8.0.0
Operating system: Linux Redhat 9 Pentium-4
Description: ecpg seg faults
Details:

I have here a shortish source file that produces a seg-fault from ecpg.

$ ecpg --version
ecpg (PostgreSQL 8.0.0) 3.2.0
$ cat test_bad.pgc
#include <string.h>

EXEC SQL INCLUDE sqlca;

typedef
struct ideal_fc {
int upc;
char code[7];
doube usage_x;
int used;
} IDEAL_FOOD_COST;

void save_ideal_adv(char *bus_date, IDEAL_FOOD_COST *Ideal, int session_id)
{
int i, j;

EXEC SQL TYPE SQL_IDEAL IS
struct sql_ideal {
int ph_id;
double quantity;
char code[8];
};


EXEC SQL BEGIN DECLARE SECTION;
SQL_IDEAL sql_Ideal;
char *sql_date;
EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT prod_hist_id, quantity, code
INTO :sql_Ideal
FROM product_history
JOIN products USING(upc)
WHERE trans_key = -2 AND date(date) = date(:sql_date)
ORDER BY code;
}

void insert_ideal(char *date, IDEAL_FOOD_COST *fc, int session_id)
{
EXEC SQL BEGIN DECLARE SECTION;
int upx;
double qty;
char *dt = date;
int sess_id = session_id;
EXEC SQL END DECLARE SECTION;


EXEC SQL
INSERT INTO product_history(date, upc, session_id, quantity,
trans_key)
VALUES(:dt, :upx, :sess_id, :qty, -2);

}
$ ecpg test_bad.pgc
Segmentation fault (core dumped)
$

Note that the following source file, which differs only in the order of the
functions passes ecpg without error.


$ cat test_good.pgc
#include <string.h>

EXEC SQL INCLUDE sqlca;

typedef
struct ideal_fc {
int upc;
char code[7];
doube usage_x;
int used;
} IDEAL_FOOD_COST;


void insert_ideal(char *date, IDEAL_FOOD_COST *fc, int session_id)
{
EXEC SQL BEGIN DECLARE SECTION;
int upx;
double qty;
char *dt = date;
int sess_id = session_id;
EXEC SQL END DECLARE SECTION;


EXEC SQL
INSERT INTO product_history(date, upc, session_id, quantity,
trans_key)
VALUES(:dt, :upx, :sess_id, :qty, -2);

}

void save_ideal_adv(char *bus_date, IDEAL_FOOD_COST *Ideal, int session_id)
{
int i, j;

EXEC SQL TYPE SQL_IDEAL IS
struct sql_ideal {
int ph_id;
double quantity;
char code[8];
};


EXEC SQL BEGIN DECLARE SECTION;

SQL_IDEAL sql_Ideal;

char *sql_date;
/*int phist_id;
double qty;
int SESSION_ID; */

EXEC SQL END DECLARE SECTION;

EXEC SQL SELECT prod_hist_id, quantity, code
INTO :sql_Ideal
FROM product_history
JOIN products USING(upc)
WHERE trans_key = -2 AND date(date) = date(:sql_date)
ORDER BY code;
}
$ ecpg test_good.pgc
$ echo $?
0


Both source files pass with ecpg v 3.1.1 (Posgtresql 7.4.2) on RedHat Linux
9 (x86), and (interstingly) withe ecpg v 3.2.0 (Postgres 8.0.) under HPUX
11i - ia64

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Mon, Jan 24, 2005 at 06:50:48PM +0000, Edmund Bacon wrote:

On both FreeBSD 4.11-STABLE and Solaris 9, ecpg 3.2.0 (8.0.0) runs
against both files without dumping core. On Solaris it's silent,
but on FreeBSD both files cause the following message:

ecpg in free(): warning: chunk is already free

If you have a core dump then maybe you can do a backtrace and see
where that's happening.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

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

http://archives.postgresql.org

On Mon, Jan 24, 2005 at 12:08:36PM -0700, Michael Fuhr wrote:

This assumes, perhaps prematurely, that the free() problem is causing
the core dump on your platform. In any case, a backtrace should
help track down the problem.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

According to the backtrace, it appears to be dieing in malloc.

(gdb) bt
#0 0x40149f9c in _int_malloc () from /lib/i686/libc.so.6
#1 0x40149201 in malloc () from /lib/i686/libc.so.6
#2 0x080547c3 in mm_alloc (size=3) at type.c:13
#3 0x080493a0 in make_str (str=0x4020c400 "\001") at preproc.y:129
#4 0x0804f629 in yyparse () at preproc.y:4899
#5 0x08055db0 in main (argc=2, argv=0xbfffdb94) at ecpg.c:424
#6 0x400eba67 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

Michael Fuhr wrote:

--
Edmund Bacon <ebacon (AT) onesystem (DOT) com>


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Edmund Bacon <ebacon (AT) onesystem (DOT) com> writes:
That's consistent with the idea that the multiple free is the source of
trouble --- multiple free() could corrupt malloc's private data
structures to the point of causing a crash in a later malloc call.

The least painful way of locating the problem would be to relink ecpg
with a debugging malloc package, which could tell you exactly where the
bad free() call is. You'd probably want to rebuild with --enable-debug
too.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

You know, I should have been able to think of that:

njamd says:

(gdb) set env LD_PRELOAD=libnjamd.so
(gdb) set env NJAMD_CHK_FREE=error
(gdb) r test_bad.pgc
Starting program:
/var/lib/pgsql/src/postgresql-8.0.0/src/interfaces/ecpg/preproc/ecpg
test_bad.pgc
NJAMD/free: Double free of address 0x41454ff4

Program received signal SIGSEGV, Segmentation fault.
0x4010a671 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4010a671 in kill () from /lib/i686/libc.so.6
#1 0x4010a405 in raise () from /lib/i686/libc.so.6
#2 0x4001f867 in __nj_underflow_free () from /usr/lib/libnjamd.so
#3 0x4001fe93 in __nj_overflow_free () from /usr/lib/libnjamd.so
#4 0x40021e87 in free () from /usr/lib/libnjamd.so
#5 0x0805755f in remove_typedefs (brace_level=1073902784) at variable.c:271
#6 0x08049e02 in yyparse () at preproc.y:610
#7 0x08055db0 in main (argc=2, argv=0xbfffe254) at ecpg.c:424
#8 0x400f7a67 in __libc_start_main () from /lib/i686/libc.so.6


Tom Lane wrote:

--
Edmund Bacon <ebacon (AT) onesystem (DOT) com>


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Edmund Bacon <ebacon (AT) onesystem (DOT) com> writes:
OK, here's where I defer to Michael Meskes to actually fix it ;-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Mon, Jan 24, 2005 at 03:24:13PM -0500, Tom Lane wrote:
Thanks for the report and the analysis. I just committed a fixe. It
should work correctly now.

As you probably expected the memory was free'ed twice.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes (AT) jabber (DOT) org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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

http://archives.postgresql.org

On Tue, Jan 25, 2005 at 01:52:33PM +0100, Michael Meskes wrote:

Where all did you commit the fix? Just HEAD? Shouldn't it also
be committed to REL8_0_STABLE, etc., as well?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
Yes, it should definitely go into 8.0 branch, and probably also 7.4
branch if you are sure that the patch applies there. Keep in mind
there will be releases pretty soon because of the LOAD privilege issue.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org