Обсуждение: BUG #1440: ecpg seg faults
The following bug has been logged online:
Bug reference: 1440
Logged by: Edmund Bacon
Email address: ebacon@onesystem.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
On Mon, Jan 24, 2005 at 06:50:48PM +0000, Edmund Bacon wrote: > 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 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/
On Mon, Jan 24, 2005 at 12:08:36PM -0700, Michael Fuhr wrote: > 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. 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/
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: >On Mon, Jan 24, 2005 at 12:08:36PM -0700, Michael Fuhr wrote: > > > >>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. >> >> > >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. > > > -- Edmund Bacon <ebacon@onesystem.com>
Edmund Bacon <ebacon@onesystem.com> writes:
> According to the backtrace, it appears to be dieing in malloc.
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
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@onesystem.com> writes: > > >>According to the backtrace, it appears to be dieing in malloc. >> >> > >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 > > -- Edmund Bacon <ebacon@onesystem.com>
Edmund Bacon <ebacon@onesystem.com> writes:
> njamd says:
> NJAMD/free: Double free of address 0x41454ff4
> #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
OK, here's where I defer to Michael Meskes to actually fix it ;-)
regards, tom lane
On Mon, Jan 24, 2005 at 03:24:13PM -0500, Tom Lane wrote: > Edmund Bacon <ebacon@onesystem.com> writes: > > njamd says: > > NJAMD/free: Double free of address 0x41454ff4 > > > #4 0x40021e87 in free () from /usr/lib/libnjamd.so > > OK, here's where I defer to Michael Meskes to actually fix it ;-) 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@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Tue, Jan 25, 2005 at 01:52:33PM +0100, Michael Meskes wrote: > Thanks for the report and the analysis. I just committed a fixe. It > should work correctly now. 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/
Michael Fuhr <mike@fuhr.org> writes:
> On Tue, Jan 25, 2005 at 01:52:33PM +0100, Michael Meskes wrote:
>> Thanks for the report and the analysis. I just committed a fixe. It
>> should work correctly now.
> Where all did you commit the fix? Just HEAD? Shouldn't it also
> be committed to REL8_0_STABLE, etc., as well?
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
On Tue, Jan 25, 2005 at 12:18:38PM -0500, Tom Lane wrote: > > Where all did you commit the fix? Just HEAD? Shouldn't it also > > be committed to REL8_0_STABLE, etc., as well? Yes, you are right of course. I was in a hurry to fix this before going on a business trip without internet connectivity and simply forgot this. > 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. I take it you took care of this Tom. Thanks a lot. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Tue, Jan 25, 2005 at 12:18:38PM -0500, Tom Lane wrote:
>> 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.
> I take it you took care of this Tom. Thanks a lot.
I put it into 8.0, since that was just a quick copy, but I did not risk
touching older versions. If you like you can make back-patches for 7.*.
regards, tom lane
On Mon, Jan 31, 2005 at 11:21:31AM -0500, Tom Lane wrote: > I put it into 8.0, since that was just a quick copy, but I did not risk > touching older versions. If you like you can make back-patches for 7.*. It appears that 7.4 does not segfault. Maybe it does not free this memory at all . But I'd prefer to keep it that way and not risk a bigger problem. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!