Обсуждение: pltcl broken on tcl8.5 ?
Buildfarm bobcat is broken running the pltcl regression tests - see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&dt=2008-06-15%2022:43:01 and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1. I'm not sure exactly what has broken here, but I'm guessing it is something in the Tcl libs that has changed somehow. Has anyone been able to get the tests to pass using Tcl 8.5.1? Or does anyone have an idea about why pltcl_elog is sometimes failing to output its message? 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&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&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&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&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