Thread: Looking for someone with MinGW
Could anyone with a MinGW system please run the ecpg regression suite including tcp checks for the current CVS HEAD for me? Just run "make checktcp" in src/interfaces/ecpg and afterwards send me the file .../ecpg/test/results/connect-test1.stderr. There is a special expected file for MinGW which is outdated, so don't be surprised if the regression tests fail. Alternatively you could check in the file as .../ecpg/test/expected/connect-test1-minGW32.stderr. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Hello, Michael Meskes <meskes@postgresql.org> wrote: > Could anyone with a MinGW system please run the ecpg regression suite including > tcp checks for the current CVS HEAD for me? I ran the test but got a segfault. I hope it can help you. $ make checktcp NO_LOCALE=on ============== running regression test queries ============== ... test connect/test1 ... source FAILED (test process was terminated by exception 0xC0000005) ============== shutting down postmaster ============== $ uname MINGW32_NT-5.1 $ gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Attachment
Hello, > > Could anyone with a MinGW system please run the ecpg regression suite including > > tcp checks for the current CVS HEAD for me? > > I ran the test but got a segfault. > I hope it can help you. Not really I'm afraid. Is there any way you could send me a backtrace? I guess this has to be debugged so we find out what's going wrong. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote: > Hello, > > >>> Could anyone with a MinGW system please run the ecpg regression suite including >>> tcp checks for the current CVS HEAD for me? >>> >> I ran the test but got a segfault. >> I hope it can help you. >> > > Not really I'm afraid. > > Is there any way you could send me a backtrace? I guess this has to be debugged > so we find out what's going wrong. > > > See below cheers andrew test1.exe caused an Access Violation at location 76becb8b in module msvcrt.dll Reading from location 00000000. Registers: eax=0022fd14 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=0085c64c eip=76becb8b esp=0022f4ac ebp=0022f898 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 Call stack: 76BECB8B msvcrt.dll:76BECB8B strlen 6D0CAF60 libecpg.dll:6D0CAF60 pg_vfprintf snprintf.c:224 int pg_vfprintf( FILE * stream = &{ char * _ptr = 0x00852f70, int _cnt = 0, char * _base = 0x00852f70, int _flag = 10, int _file = 2, int _charbuf = 0, int _bufsiz = 4096, char * _tmpfname= 0x00000000 }, const char * fmt = &'[', va_list args = "" ) ... target.stream = stream; target.nchars = 0;> if (dopr(&target, fmt, args)) { errno = EINVAL;/* bad format*/ ... 6D0C8FA2 libecpg.dll:6D0C8FA2 ecpg_log misc.c:275 void ecpg_log( const char * format = &'e' ) ... /* dump out internal sqlca variables */> if (ecpg_internal_regression_mode) fprintf(debugstream, "[NO_PID]:sqlca: code: %ld, state: %s\n", sqlca->sqlcode, sqlca->sqlstate); ... 6D0C7B3E libecpg.dll:6D0C7B3E ecpg_finish connect.c:149 static void ecpg_finish( struct connection * act = ) ... ecpg_log("ecpg_finish: connection %s closed\n", act->name); > for (cache = act->cache_head; cache; ptr = cache,cache = cache->next, ecpg_free(ptr)); ecpg_free(act->name); ecpg_free(act); ... 6D0C89D1 libecpg.dll:6D0C89D1 ECPGdisconnect connect.c:582 char ECPGdisconnect( int lineno = 39, const char * connection_name = &'C' ) ... } else> ecpg_finish(con); } ... 00401495 test1.exe:00401495 main test1.pgc:42 int main( ) ... strcpy(pw, "connectpw");> strcpy(db, "tcp:postgresql://localhost/connectdb"); exec sql connect to :db userconnectuser using :pw; exec sql disconnect; ... 004011E7 test1.exe:004011E7 00401238 test1.exe:00401238 76CD4911 kernel32.dll:76CD4911 BaseThreadInitThunk 777DE4B6 ntdll.dll:777DE4B6 RtlInitializeExceptionChain 777DE489 ntdll.dll:777DE489 RtlInitializeExceptionChain
On Sun, Dec 14, 2008 at 11:36:21AM -0500, Andrew Dunstan wrote: > See below > ... Thanks. The backtrace is kind of strange, but I might have found it. Could you please update from CVS and re-run? Thanks again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote: > On Sun, Dec 14, 2008 at 11:36:21AM -0500, Andrew Dunstan wrote: > >> See below >> ... >> > > Thanks. The backtrace is kind of strange, but I might have found it. Could you > please update from CVS and re-run? > > > same result ;-( cheers andrew
Andrew Dunstan <andrew@dunslane.net> wrote: > > Thanks. The backtrace is kind of strange, but I might have found it. > > Could you please update from CVS and re-run? > > same result ;-( Hi, I found the cause. Segfault comes from the following lines. [ecpg/test/connect/test1.pgc] exec sql connect to tcp:postgresql://localhost/ user connectdb; exec sql disconnect; -> ECPGdisconnect() -> ecpg_finish() -> ecpg_log("ecpg_finish: connection %s closed\n", act->name); <HERE> -> vfprintf(debugstream, fmt, ap); Actual error occurs in vfprintf() because act->name can be NULL. sprintf(..., "%s", NULL) could work on some platform (the result is '(null)'), but it crashes on Windows (msvcrt). We need to avoid passing NULLs as arguments to "%s" format for printf families. The attached patch fixes the segfault. Regression tests can finish successfully but there is still a difference. The diff seems to be trivial and come from error message changes. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Attachment
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > Hi, I found the cause. > ... > Actual error occurs in vfprintf() because act->name can be NULL. > sprintf(..., "%s", NULL) could work on some platform (the result is '(null)'), > but it crashes on Windows (msvcrt). We need to avoid passing NULLs as > arguments to "%s" format for printf families. Hmm, Windows is hardly the only platform where that would crash. I'm surprised we don't have more buildfarm members complaining about this. regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: >> Hi, I found the cause. >> ... >> Actual error occurs in vfprintf() because act->name can be NULL. >> sprintf(..., "%s", NULL) could work on some platform (the result is '(null)'), >> but it crashes on Windows (msvcrt). We need to avoid passing NULLs as >> arguments to "%s" format for printf families. > > Hmm, Windows is hardly the only platform where that would crash. > I'm surprised we don't have more buildfarm members complaining about > this. Actually I thought the behaviour of spitting out "(null)" was unique to glibc. Don't we have plenty of BSD and other implementations? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
Tom Lane wrote: > ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > >> Hi, I found the cause. >> ... >> Actual error occurs in vfprintf() because act->name can be NULL. >> sprintf(..., "%s", NULL) could work on some platform (the result is '(null)'), >> but it crashes on Windows (msvcrt). We need to avoid passing NULLs as >> arguments to "%s" format for printf families. >> > > Hmm, Windows is hardly the only platform where that would crash. > I'm surprised we don't have more buildfarm members complaining about > this. > > This test is not run by the buildfarm. It's not part of ecpg's "installcheck" suite. cheers andrew
On Wed, Dec 17, 2008 at 07:40:20AM -0500, Andrew Dunstan wrote: > This test is not run by the buildfarm. It's not part of ecpg's > "installcheck" suite. I was under the impression that at least some members do run it. What else is the test good for? Back when it was implemented it was taken out of "make check" because it requires a tcp connection, so you have to run "make checktcp" instead. But if noone runs this, we could drop it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
On Wed, Dec 17, 2008 at 12:09:01PM +0900, ITAGAKI Takahiro wrote: > Hi, I found the cause. Thanks a lot. Patch just checked in, please try again with CVS HEAD. > The attached patch fixes the segfault. Regression tests can finish > successfully but there is still a difference. The diff seems to be > trivial and come from error message changes. There is a special mingw expected file in there. But given that this test apparently never ran on any buildfarm member I wonder whether this special setup works. It appears to work for other tests though, but your regression.diffs suggests it doesn't here. Could you please check this by checking out the changes, re-running "make checktcp" and checking whether the regression.diffs file changes? Thanks Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> wrote: > It appears to work for other tests though, but your > regression.diffs suggests it doesn't here. Could you please check this by > checking out the changes, re-running "make checktcp" and checking whether the > regression.diffs file changes? I re-ran the test and got 'source FAILED' at connect/test1. The difference comes from another line which we didn't touch this time. There are no differences between expected/connect-test1-minGW32.stderr and results/connect-test1.stderr, but *-minGW32.stderr seems not to be used by regression test in my environment. Who renames *-minGW32.stderr to .stderr ? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center