pltcl broken on tcl8.5 ?

Andrew Dunstan <andrew@dunslane.net> writes:

Buildfarm bobcat is broken running the pltcl regression tests - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&amp;dt=2008-06-15%2022:43:01
and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.

I missed 8.5.1, but I can say that pltcl passes its regression test
with both 8.5.0 and 8.5.2 on HPUX. However, that's with a
non-thread-enabled tcl, which might be relevant.

I've had problems in the past with pltcl on multilib Fedora ... are
you by any chance using x86_64, and if so do you have tcldevel.i386
installed as well? I've found that we tend to pick the "wrong" tcl
if given a choice. Although I think the symptom there tends to be
build failure not just a couple of weird test discrepancies.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Buildfarm bobcat is broken running the pltcl regression tests - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&amp;dt=2008-06-15%2022:43:01
and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.

I missed 8.5.1, but I can say that pltcl passes its regression test
with both 8.5.0 and 8.5.2 on HPUX. However, that's with a
non-thread-enabled tcl, which might be relevant.

I've had problems in the past with pltcl on multilib Fedora ... are
you by any chance using x86_64, and if so do you have tcldevel.i386
installed as well? I've found that we tend to pick the "wrong" tcl
if given a choice. Although I think the symptom there tends to be
build failure not just a couple of weird test discrepancies.

No. I have a pure i386 environment (in a VM).

I'll dig a bit more tomorrow.

cheers

andrew

Hi,

On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote:

Has anyone been able to get the tests to pass using Tcl 8.5.1?

All regression tests passed on Fedora-9 while building new RPM sets.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Devrim GÜNDÜZ wrote:

Hi,

On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote:

Has anyone been able to get the tests to pass using Tcl 8.5.1?

All regression tests passed on Fedora-9 while building new RPM sets.

Do you specifically run the PL regression tests?

cheers

andrew

Andrew Dunstan wrote:

Devrim GÜNDÜZ wrote:

Hi,

On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote:

Has anyone been able to get the tests to pass using Tcl 8.5.1?

All regression tests passed on Fedora-9 while building new RPM sets.

Do you specifically run the PL regression tests?

As confirmed by discussion on IRC, the RPM build process only runs "make
check" which doesn't run the PL regression tests.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Buildfarm bobcat is broken running the pltcl regression tests - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&amp;dt=2008-06-15%2022:43:01

and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.

Hoo, nasty. Tcl_GetVar() is resetting interp->result. Not sure why
we didn't see this before ... maybe it didn't use to? Anyway, the
order of execution in

ereport(ERROR,
(errmsg("%s", interp->result),
errcontext("%s\nin PL/Tcl function \"%s\"",
UTF_U2E(Tcl_GetVar(interp, "errorInfo",
TCL_GLOBAL_ONLY)),
prodesc->user_proname)));

is machine-dependent, which explains why I didn't see it on HPPA.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Buildfarm bobcat is broken running the pltcl regression tests - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&amp;dt=2008-06-15%2022:43:01

and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.

Hoo, nasty. Tcl_GetVar() is resetting interp->result. Not sure why
we didn't see this before ... maybe it didn't use to? Anyway, the
order of execution in

ereport(ERROR,
(errmsg("%s", interp->result),
errcontext("%s\nin PL/Tcl function \"%s\"",
UTF_U2E(Tcl_GetVar(interp, "errorInfo",
TCL_GLOBAL_ONLY)),
prodesc->user_proname)));

is machine-dependent, which explains why I didn't see it on HPPA.

According to the manual page that's only supposed to happen if the
TCL_LEAVE_ERR_MSG flag is used:

TCL_LEAVE_ERR_MSG
If an error is returned and this bit is set in flags, then an
error message will be left in the interpreter�s result, where it
can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult.
If this flag bit isn�t set then no error message is left and the
interpreter�s result will not be modified.

So this looks like a bug. I guess we could work around it by saving out
interp->result first. As you say, nasty.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

Hoo, nasty. Tcl_GetVar() is resetting interp->result.

According to the manual page that's only supposed to happen if the
TCL_LEAVE_ERR_MSG flag is used:

TCL_LEAVE_ERR_MSG
If an error is returned and this bit is set in flags, then an
error message will be left in the interpreter�s result, where it
can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult.
If this flag bit isn�t set then no error message is left and the
interpreter�s result will not be modified.

But notice that they specify using Tcl_GetObjResult or
Tcl_GetStringResult, rather than touching the field directly.
I suspect they'd regard this as not-a-bug. In any case I found
the responsible code: Tcl_SaveInterpState/Tcl_RestoreInterpState
restore the result as an object not a string. I see no such
routines in 8.4.

As I look at this, I think it's got even more problems: it's assuming
that interp->result is in the database encoding, which seems a pretty
faulty assumption considering it came from Tcl. pltcl_elog converts
to the database encoding before calling Tcl_SetResult, which makes
that path all right as long as Tcl doesn't do anything with the string
before exiting, but I don't particularly trust that assumption either.
All in all this is really quite broken.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

Hoo, nasty. Tcl_GetVar() is resetting interp->result.

According to the manual page that's only supposed to happen if the
TCL_LEAVE_ERR_MSG flag is used:

TCL_LEAVE_ERR_MSG
If an error is returned and this bit is set in flags, then an
error message will be left in the interpreter�s result, where it
can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult.
If this flag bit isn�t set then no error message is left and the
interpreter�s result will not be modified.

But notice that they specify using Tcl_GetObjResult or
Tcl_GetStringResult, rather than touching the field directly.
I suspect they'd regard this as not-a-bug. In any case I found
the responsible code: Tcl_SaveInterpState/Tcl_RestoreInterpState
restore the result as an object not a string. I see no such
routines in 8.4.

As I look at this, I think it's got even more problems: it's assuming
that interp->result is in the database encoding, which seems a pretty
faulty assumption considering it came from Tcl. pltcl_elog converts
to the database encoding before calling Tcl_SetResult, which makes
that path all right as long as Tcl doesn't do anything with the string
before exiting, but I don't particularly trust that assumption either.
All in all this is really quite broken.

Yes. At any rate, your fix has worked on my test bed.

cheers

andrew