Thread: BUG #1815: ECPGdebug causes crash on Windows XP
The following bug has been logged online:
Bug reference: 1815
Logged by: joshua masiko
Email address: joshua_masiko@yahoo.com
PostgreSQL version: 8.0.3
Operating system: Windows XP SP2
Description: ECPGdebug causes crash on Windows XP
Details:
/* Processed by ecpg (4.0.1) */
/* These include files are added by the preprocessor */
#include <ecpgtype.h>
#include <ecpglib.h>
#include <ecpgerrno.h>
#include <sqlca.h>
/* End of automatic include section */
#line 1 "main.pgc"
#include <stdio.h>
int main(int argc,char **argv)
{
ECPGdebug(1,stderr);
return 0;
}
Running the above program results in a reproducible crash on Windows XP
Environment
Windows XP SP2
Visual Studio SP5
Postgresql 8.0.3
Any ideas??
Make sure the lib directory is in the PATH.
I tested it in MinGW.
$ ecpg main.pgc
$ gcc main.c -I../include -L../lib -lecpg
$ export PATH=$PATH:"/c/Program Files/PostgreSQL/8.0/lib"
$ ./a.exe
[1772]: ECPGdebug: set to 1
""joshua masiko"" <joshua_masiko@yahoo.com> wrote
news:20050809194027.A1C76F0B08@svr2.postgresql.org...
>
> The following bug has been logged online:
>
> Bug reference: 1815
> Logged by: joshua masiko
> Email address: joshua_masiko@yahoo.com
> PostgreSQL version: 8.0.3
> Operating system: Windows XP SP2
> Description: ECPGdebug causes crash on Windows XP
> Details:
>
> /* Processed by ecpg (4.0.1) */
> /* These include files are added by the preprocessor */
> #include <ecpgtype.h>
> #include <ecpglib.h>
> #include <ecpgerrno.h>
> #include <sqlca.h>
> /* End of automatic include section */
> #line 1 "main.pgc"
> #include <stdio.h>
>
> int main(int argc,char **argv)
> {
> ECPGdebug(1,stderr);
> return 0;
> }
>
> Running the above program results in a reproducible crash on Windows XP
>
> Environment
> Windows XP SP2
> Visual Studio SP5
> Postgresql 8.0.3
>
> Any ideas??
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
crash in this case means I get the popup that says
<progname> has encountered errors and needs to close
when I click the debug button this is the call stack
that shows up in the Visual Studio debugger
ntdll.dll!7c918fea()
ntdll.dll!7c9106eb()
ntdll.dll!7c90104b()
msvcrt.dll!77c3b90d()
msvcrt.dll!77c420e7()
libecpg.dll!6d0c7471()
> ecpgtest.exe!main(int argc=1, char * *
argv=0x003c0d10) Line 5 + 0xc C
ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C
kernel32.dll!7c816d4f()
kernel32.dll!7c8399f3()
The offending line in ecpgtest.pgc is
ECPGdebug(1,stderr);
I get the same result even if I use a file handle
obtained by using fopen
--- William ZHANG <uniware@zedware.org> wrote:
>
> "Bruce Momjian" <pgman@candle.pha.pa.us>
> wrote:200508130244.j7D2iJE03191@candle.pha.pa.us...
> > William ZHANG wrote:
> > > Make sure the lib directory is in the PATH.
> > > I tested it in MinGW.
> > >
> > > $ ecpg main.pgc
> > > $ gcc main.c -I../include -L../lib -lecpg
> > > $ export PATH=$PATH:"/c/Program
> Files/PostgreSQL/8.0/lib"
> > > $ ./a.exe
> > > [1772]: ECPGdebug: set to 1
> >
> >
> > Ah, interesting. Why would it crash if the lib
> directory is not in the
> > path? Because it can't load the library?
>
> Maybe I misunderstood the word 'crash'. If I forgot
> to put the lib
> directory,
> it will make Windows popup a GUI warning window.
>
> joshua masiko: Can you give more information?
>
>
>
>
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Yes. It is reproducible. But it works well in MinGW. Is there sth. wrong with the import library lib\ms\libecpg.lib or lib\libecpg.dll? "Joshua Masiko" <joshua_masiko@yahoo.com> wrote:20050813145453.48119.qmail@web33903.mail.mud.yahoo.com... > > ntdll.dll!7c918fea() > ntdll.dll!7c9106eb() > ntdll.dll!7c90104b() > msvcrt.dll!77c3b90d() > msvcrt.dll!77c420e7() > libecpg.dll!6d0c7471() >> ecpgtest.exe!main(int argc=1, char * * > argv=0x003c0d10) Line 5 + 0xc C > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > kernel32.dll!7c816d4f() > kernel32.dll!7c8399f3() > > > The offending line in ecpgtest.pgc is > > ECPGdebug(1,stderr); > > I get the same result even if I use a file handle > obtained by using fopen
On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote: > Yes. It is reproducible. But it works well in MinGW. > Is there sth. wrong with the import library lib\ms\libecpg.lib or > lib\libecpg.dll? > > "Joshua Masiko" <joshua_masiko@yahoo.com> > wrote:20050813145453.48119.qmail@web33903.mail.mud.yahoo.com... > > > > ntdll.dll!7c918fea() > > ntdll.dll!7c9106eb() > > ntdll.dll!7c90104b() > > msvcrt.dll!77c3b90d() > > msvcrt.dll!77c420e7() > > libecpg.dll!6d0c7471() > >> ecpgtest.exe!main(int argc=1, char * * > > argv=0x003c0d10) Line 5 + 0xc C > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > > kernel32.dll!7c816d4f() > > kernel32.dll!7c8399f3() > > > > > > The offending line in ecpgtest.pgc is > > > > ECPGdebug(1,stderr); > > > > I get the same result even if I use a file handle > > obtained by using fopen Could someone with access to a Windows system have a look at this? I do not have one atm. In particular I'd like to know whether it makes a difference if your compiled ecpg with threading enabled or not. After all without threading the function called does not much, just changing two variables and logging the change. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Ah, I have found the cause of the crash, and added documentation about
the cause:
On Win32, if the <application>ecpg</> libraries and application are
compiled with different flags, this function call will crash the
application because the internal representation of the <literal>FILE</>
pointers differ.
While such a mismatch is a problem on all platforms, it is more common
on Win32 where the FILE structure changes for debug, for example.
---------------------------------------------------------------------------
Michael Meskes wrote:
> On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote:
> > Yes. It is reproducible. But it works well in MinGW.
> > Is there sth. wrong with the import library lib\ms\libecpg.lib or
> > lib\libecpg.dll?
> >
> > "Joshua Masiko" <joshua_masiko@yahoo.com>
> > wrote:20050813145453.48119.qmail@web33903.mail.mud.yahoo.com...
> > >
> > > ntdll.dll!7c918fea()
> > > ntdll.dll!7c9106eb()
> > > ntdll.dll!7c90104b()
> > > msvcrt.dll!77c3b90d()
> > > msvcrt.dll!77c420e7()
> > > libecpg.dll!6d0c7471()
> > >> ecpgtest.exe!main(int argc=1, char * *
> > > argv=0x003c0d10) Line 5 + 0xc C
> > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C
> > > kernel32.dll!7c816d4f()
> > > kernel32.dll!7c8399f3()
> > >
> > >
> > > The offending line in ecpgtest.pgc is
> > >
> > > ECPGdebug(1,stderr);
> > >
> > > I get the same result even if I use a file handle
> > > obtained by using fopen
>
> Could someone with access to a Windows system have a look at this? I do
> not have one atm. In particular I'd like to know whether it makes a
> difference if your compiled ecpg with threading enabled or not. After
> all without threading the function called does not much, just changing
> two variables and logging the change.
>
> Michael
> --
> Michael Meskes
> Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
> Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
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
I remember that I have posted the answer to pgsql.bugs, but now it can only be found here: http://www.talkaboutdatabases.com/group/pgsql.bugs/messages/2346.html Do not know what's wrong with the mail list or my mails. "Bruce Momjian" <pgman@candle.pha.pa.us> wrote > > Ah, I have found the cause of the crash, and added documentation about > the cause: > > On Win32, if the <application>ecpg</> libraries and application are > compiled with different flags, this function call will crash the > application because the internal representation of the <literal>FILE</> > pointers differ. > > While such a mismatch is a problem on all platforms, it is more common > on Win32 where the FILE structure changes for debug, for example. > > -------------------------------------------------------------------------- - > > Michael Meskes wrote: > > On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote: > > > Yes. It is reproducible. But it works well in MinGW. > > > Is there sth. wrong with the import library lib\ms\libecpg.lib or > > > lib\libecpg.dll? > > > > > > "Joshua Masiko" <joshua_masiko@yahoo.com> > > > wrote:20050813145453.48119.qmail@web33903.mail.mud.yahoo.com... > > > > > > > > ntdll.dll!7c918fea() > > > > ntdll.dll!7c9106eb() > > > > ntdll.dll!7c90104b() > > > > msvcrt.dll!77c3b90d() > > > > msvcrt.dll!77c420e7() > > > > libecpg.dll!6d0c7471() > > > >> ecpgtest.exe!main(int argc=1, char * * > > > > argv=0x003c0d10) Line 5 + 0xc C > > > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > > > > kernel32.dll!7c816d4f() > > > > kernel32.dll!7c8399f3() > > > > > > > > > > > > The offending line in ecpgtest.pgc is > > > > > > > > ECPGdebug(1,stderr); > > > > > > > > I get the same result even if I use a file handle > > > > obtained by using fopen > > > > Could someone with access to a Windows system have a look at this? I do > > not have one atm. In particular I'd like to know whether it makes a > > difference if your compiled ecpg with threading enabled or not. After > > all without threading the function called does not much, just changing > > two variables and logging the change. > > > > Michael > > -- > > Michael Meskes > > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org > > Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > > > -- > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend >
Thanks, I have added an additional sentence to that section outlining the specific items that should match --- patch attached. --------------------------------------------------------------------------- William ZHANG wrote: > I remember that I have posted the answer to pgsql.bugs, > but now it can only be found here: > > http://www.talkaboutdatabases.com/group/pgsql.bugs/messages/2346.html > > Do not know what's wrong with the mail list or my mails. > > "Bruce Momjian" <pgman@candle.pha.pa.us> wrote > > > > Ah, I have found the cause of the crash, and added documentation about > > the cause: > > > > On Win32, if the <application>ecpg</> libraries and application are > > compiled with different flags, this function call will crash the > > application because the internal representation of the <literal>FILE</> > > pointers differ. > > > > While such a mismatch is a problem on all platforms, it is more common > > on Win32 where the FILE structure changes for debug, for example. > > > > -------------------------------------------------------------------------- > - > > > > Michael Meskes wrote: > > > On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote: > > > > Yes. It is reproducible. But it works well in MinGW. > > > > Is there sth. wrong with the import library lib\ms\libecpg.lib or > > > > lib\libecpg.dll? > > > > > > > > "Joshua Masiko" <joshua_masiko@yahoo.com> > > > > wrote:20050813145453.48119.qmail@web33903.mail.mud.yahoo.com... > > > > > > > > > > ntdll.dll!7c918fea() > > > > > ntdll.dll!7c9106eb() > > > > > ntdll.dll!7c90104b() > > > > > msvcrt.dll!77c3b90d() > > > > > msvcrt.dll!77c420e7() > > > > > libecpg.dll!6d0c7471() > > > > >> ecpgtest.exe!main(int argc=1, char * * > > > > > argv=0x003c0d10) Line 5 + 0xc C > > > > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > > > > > kernel32.dll!7c816d4f() > > > > > kernel32.dll!7c8399f3() > > > > > > > > > > > > > > > The offending line in ecpgtest.pgc is > > > > > > > > > > ECPGdebug(1,stderr); > > > > > > > > > > I get the same result even if I use a file handle > > > > > obtained by using fopen > > > > > > Could someone with access to a Windows system have a look at this? I do > > > not have one atm. In particular I'd like to know whether it makes a > > > difference if your compiled ecpg with threading enabled or not. After > > > all without threading the function called does not much, just changing > > > two variables and logging the change. > > > > > > Michael > > > -- > > > Michael Meskes > > > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot > (De|Com|Net|Org) > > > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org > > > Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 2: Don't 'kill -9' the postmaster > > > > > > > -- > > 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 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: explain analyze is your friend > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- 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 Index: doc/src/sgml/ecpg.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v retrieving revision 1.67 diff -c -c -r1.67 ecpg.sgml *** doc/src/sgml/ecpg.sgml 25 Sep 2005 03:12:13 -0000 1.67 --- doc/src/sgml/ecpg.sgml 13 Oct 2005 17:45:12 -0000 *************** *** 1612,1618 **** On Win32, if the <application>ecpg</> libraries and an application are compiled with different flags, this function call will crash the application because the internal representation of the ! <literal>FILE</> pointers differ. </para> </note> </listitem> --- 1612,1620 ---- On Win32, if the <application>ecpg</> libraries and an application are compiled with different flags, this function call will crash the application because the internal representation of the ! <literal>FILE</> pointers differ. Specifically, ! threading/non-threading, release/debug, and static/dynamic flags should ! be the same for the library and all applications using that library. </para> </note> </listitem> Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.191 diff -c -c -r1.191 libpq.sgml *** doc/src/sgml/libpq.sgml 25 Sep 2005 03:12:13 -0000 1.191 --- doc/src/sgml/libpq.sgml 13 Oct 2005 17:45:15 -0000 *************** *** 3520,3526 **** On Win32, if the <application>libpq</> library and an application are compiled with different flags, this function call will crash the application because the internal representation of the <literal>FILE</> ! pointers differ. </para> </note> </listitem> --- 3520,3528 ---- On Win32, if the <application>libpq</> library and an application are compiled with different flags, this function call will crash the application because the internal representation of the <literal>FILE</> ! pointers differ. Specifically, threading/non-threading, release/debug, and ! static/dynamic flags should be the same for the library and all applications ! using that library. </para> </note> </listitem>