public inbox for [email protected]  

help / color / mirror / Atom feed

From: Erik Wienhold <[email protected]>
To: Tom Lane <[email protected]>
Cc: Pierre Forstmann <[email protected]>
Cc: a.kozhemyakin <[email protected]>
Cc: [email protected]
Subject: Re: pltcl crashes due to a syntax error
Date: Mon, 3 Jun 2024 18:16:48 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAM-sOH9zC5VeycS0BFCV4CAEfDL4OLEh_41oWtVLfbOZCtxNFw@mail.gmail.com>
	<[email protected]>
	<[email protected]>

On 2024-06-03 00:15 +0200, Tom Lane wrote:
> The new bit of information that this bug report provides is that it's
> possible to get a TCL_ERROR result without Tcl having set errorInfo.
> That seems a tad odd, and it must happen only in weird corner cases,
> else we'd have heard of this decades ago.  Not sure if it's worth
> trying to characterize those cases further, however.

ISTM that errorInfo is set automatically only during script evaluation.
The Tcl_AddErrorInfo manpage says:

"The -errorinfo option value is gradually built up as an error unwinds
 through the nested operations.  Each time an error code is returned to
 Tcl_Eval, or any of the routines that performs script evaluation, the
 procedure Tcl_AddErrorInfo is called to add additional text to the
 -errorinfo value describing the command that was being executed when
 the error occurred.  By the time the error has been passed all the way
 back to the application, it will contain a complete trace of the
 activity in progress when the error occurred."

Tcl 8.4 basically uses the same wording.

Except for the reported case, we only call throw_tcl_error in three
places, all after checking the return code from Tcl_EvalObjEx.  And this
one Tcl_ListObjGetElements instance is not called during script
evaluation.

> > Or just do away with throw_tcl_error and call ereport directly.
> 
> I'd say this adds to the importance of having throw_tcl_error,
> because now it's even more complex than before, and there are
> multiple call sites.

I agree to have some uniform error handling.  But from the current usage
it looks as if throw_tcl_error is tied to Tcl_EvalObjEx.

-- 
Erik

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pltcl crashes due to a syntax error
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox