Обсуждение: ECPG Segfaulting on EXEC SQL connect
Hello,
I'm trying to convert a series of C programs written originally using Informix ESQL to use Postgres' ECPG.
All of my test programs written from scratch seem to work ok, and I can now precompile, compile and link without error, but when I actually run the program, I get a segfault. This appears to be in the code called by EXEC SQL CONNECT... as evidenced below (output from gdb):
Program received signal SIGSEGV, Segmentation fault.
0x08053640 in error_message ()
(gdb) up
#1 0x4005b95a in _init () from /usr/lib/libpq.so.3
(gdb) up
#2 0x4005ba8f in _init () from /usr/lib/libpq.so.3
(gdb) up
#3 0x4005c35d in fe_getauthname () from /usr/lib/libpq.so.3
(gdb) up
#4 0x4005ed2d in pqPacketSend () from /usr/lib/libpq.so.3
(gdb) up
#5 0x4005c44c in PQconnectStart () from /usr/lib/libpq.so.3
(gdb) up
#6 0x4005c90a in PQsetdbLogin () from /usr/lib/libpq.so.3
(gdb) up
#7 0x4003bf7f in ECPGconnect () from /usr/lib/libecpg.so.4
(gdb) up
#8 0x0804ed15 in cgiMain () at register_customer.pgc:575
575 EXEC SQL connect to pdev_changename;
(gdb)
0x08053640 in error_message ()
(gdb) up
#1 0x4005b95a in _init () from /usr/lib/libpq.so.3
(gdb) up
#2 0x4005ba8f in _init () from /usr/lib/libpq.so.3
(gdb) up
#3 0x4005c35d in fe_getauthname () from /usr/lib/libpq.so.3
(gdb) up
#4 0x4005ed2d in pqPacketSend () from /usr/lib/libpq.so.3
(gdb) up
#5 0x4005c44c in PQconnectStart () from /usr/lib/libpq.so.3
(gdb) up
#6 0x4005c90a in PQsetdbLogin () from /usr/lib/libpq.so.3
(gdb) up
#7 0x4003bf7f in ECPGconnect () from /usr/lib/libecpg.so.4
(gdb) up
#8 0x0804ed15 in cgiMain () at register_customer.pgc:575
575 EXEC SQL connect to pdev_changename;
(gdb)
The database is called pdev_changename, and that same connect statement has worked in another test program.
I'm precompiling using
ecpg -t -C INFORMIX register_customer.pgc -o register_customer.c
and compling with
gcc -g register_customer.c <<some .o and .a files>> -o register_customer.cgi \
-I/usr/include/pgsql -I/usr/include/pgsql/informix -lecpg -lecpg_compat -L/usr/lib/pgsql
I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same thing happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1.
The ability to define variables of type "timestamp" etc. is so useful, so I really want to keep using "-C INFORMIX" if I can.
Can anyone help shed any light on this?
Thanks,
John
john(at)roundel(dot)net
On Tue, Dec 28, 2004 at 10:16:04PM -0000, John Smith wrote: > I'm trying to convert a series of C programs written originally using > Informix ESQL to use Postgres' ECPG. > ... > 575 EXEC SQL connect to pdev_changename; > ... > I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same thing > happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1. Could you please try rc3? I did fix some segfaults in the connect statement. However, I'm not sure you hit the same bug, actually I expect it to be a different one. > The ability to define variables of type "timestamp" etc. is so useful, so I > really want to keep using "-C INFORMIX" if I can. You can use the datatypes without informix mode. You just have to include the pgtypes_*.h header files yourself. > Can anyone help shed any light on this? I will try if you could send me an example to reproduce the problem. As you said it does not happen on a small self written test case. Maybe you can send me one of your source files stripped down to just connect. 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!
Hi Michael, I'll try and get a nice small pared-down source for you to play with that demonstrates the problem. Once I get that, I could certainly try rc3, although I was hoping to wait for the RPM... John. -----Original Message----- From: Michael Meskes [mailto:meskes@postgresql.org] Sent: 01 January 2005 15:08 To: John Smith Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] ECPG Segfaulting on EXEC SQL connect On Tue, Dec 28, 2004 at 10:16:04PM -0000, John Smith wrote: > I'm trying to convert a series of C programs written originally using > Informix ESQL to use Postgres' ECPG. > ... > 575 EXEC SQL connect to pdev_changename; > ... > I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same > thing happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1. Could you please try rc3? I did fix some segfaults in the connect statement. However, I'm not sure you hit the same bug, actually I expect it to be a different one. > The ability to define variables of type "timestamp" etc. is so useful, > so I really want to keep using "-C INFORMIX" if I can. You can use the datatypes without informix mode. You just have to include the pgtypes_*.h header files yourself. > Can anyone help shed any light on this? I will try if you could send me an example to reproduce the problem. As you said it does not happen on a small self written test case. Maybe you can send me one of your source files stripped down to just connect. 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 wrote the following on 01.01.2005 16:08: > On Tue, Dec 28, 2004 at 10:16:04PM -0000, John Smith wrote: > >>I'm trying to convert a series of C programs written originally using >>Informix ESQL to use Postgres' ECPG. >>... >>575 EXEC SQL connect to pdev_changename; >>... >>I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same thing >>happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1. This also happens with Postgresql 7.4. under SUSE Linux 9.1 (kernel 2.6.4-52) The last version for which embedded SQL worked well for me was 7.3. The same source which worked fine under 7.3 for many months stopped working with my switch to 7.4.2. :-( And it not only happens during connect, but also during a select. It is very difficult to debug, since often the stack is destroyed and a backtrace in gdb does not work. From what I can see it is always related to calls of malloc/free/realloc issued by libpq. -- With kind regards | Mit freundlichen Gruessen Hans-Michael Stahl Condat AG Alt-Moabit 91d | 10559 Berlin | Germany | Old Europe tel: +49.30.3949-1155 | fax: +49.30.3949-2221155 http://www.condat.de/
On Tue, Jan 18, 2005 at 05:49:05PM +0100, Hans-Michael Stahl wrote: > This also happens with Postgresql 7.4. under SUSE Linux 9.1 (kernel > 2.6.4-52) The last version for which embedded SQL worked well for me > was 7.3. The same source which worked fine under 7.3 for many months > stopped working with my switch to 7.4.2. :-( Interesting. > And it not only happens during connect, but also during a select. It is > very difficult to debug, since often the stack is destroyed and a > backtrace in gdb does not work. From what I can see it is always > related to calls of malloc/free/realloc issued by libpq. I would be happy to help debugging this. But up to now I didn't even know about this problem. Could you please send me a test case so I can reproduce this? Also did you try using 8.0? 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 wrote the following on 19.01.2005 11:16: > I would be happy to help debugging this. But up to now I didn't even > know about this problem. Could you please send me a test case so I can > reproduce this? It is from a very large production example. I have to work a bit to trim this down to a small example. I'llt try to provide an example. I now also remember that the problem *only* occurs with dynamically prepared statements with cursors, static statements with cursors work w/o problems. > Also did you try using 8.0? No, When I encountered the problem I switched back to Informix. > Go SF 49ers! What's that? > Go Rhein Fire! And that? > Use Debian GNU/Linux! I Use Gentoo and SuSE. > Use PostgreSQL! Yes, when Embedded SQL works again :-) -- With kind regards | Mit freundlichen Gruessen Hans-Michael Stahl Condat AG Alt-Moabit 91d | 10559 Berlin | Germany | Old Europe tel: +49.30.3949-1155 | fax: +49.30.3949-2221155 http://www.condat.de/
On Wed, Jan 19, 2005 at 06:07:24PM +0100, Hans-Michael Stahl wrote: > It is from a very large production example. I have to work a bit to trim > this down to a small example. I'llt try to provide an example. I now > also remember that the problem *only* occurs with dynamically prepared > statements with cursors, static statements with cursors work w/o problems. Okay, please let me know when you have a test case. I'd surely like to fix that. :-) > > Go SF 49ers! > > What's that? My favourite NFL team, that's professional american style football in the US. > > Go Rhein Fire! > > And that? My favourite and local NFLE team, that's professional (more or less) american style football in Europe. > > Use PostgreSQL! > > Yes, when Embedded SQL works again :-) Okay, let's work on that one. :-) 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!