Re: 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(at)jabber(dot)org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Hello,

Michael Meskes <meskes(at)postgresql(dot)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

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(at)jabber(dot)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 user connectuser 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(at)jabber(dot)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(at)dunslane(dot)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

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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(at)jabber(dot)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(at)jabber(dot)org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes(at)postgresql(dot)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