expansion terminated the whole process instead of reporting cleanly
Found while verifying documentation for #[name] vs $[%name] (writing the
new tag-hierarchy section surfaced that my own published example was
factually wrong about which sigil reads a keyword attribute - #[name]
actually reads local->variables, a separate store; $[%name] is the real
keyword sigil, confirmed against Tag::getVariable directly). Referencing
an uninitialized #[name] from inside a custom tag's own template crashed
the process outright (SIGABRT) rather than reporting a normal error -
confirmed via a real gdb backtrace, not guessed:
1. Tag::getVariable's "#[" branch and Tag::assignVariable's "local"/
"parent" scope branches all dereferenced `local` unconditionally.
`local` is genuinely NULL at the true top level (jet-2.0.cpp's own
`new jet::__jet(data, out, global, NULL, NULL)`) and stays NULL through
any tag that doesn't establish its own local scope (most don't -
<if>/<while>/<until> are the exception, passing `this` as local via
their splitTagName constructor path). Added NULL checks with clear
messages instead of an unconditional dereference.
2. The real root cause of the actual crash observed, though: jet-2.0.cpp's
own top-level catch(coreutils::Exception) handler unconditionally calls
data.setCursor(global.errorCursor) to show precise source-line context
- but global.errorCursor is updated by every Tag's own construction, so
it can (and, for an error originating inside a custom tag's own
expanded template - container3 in __dotag.cpp - always does) point
into a completely different ZString buffer than `data` (the top-level
script). ZString::setCursor() correctly rejects a cursor outside its
own buffer by throwing - but that throw happens while the ORIGINAL
exception is still being handled inside this same catch block, and a
second exception escaping an active catch block calls std::terminate()
immediately, regardless of any enclosing try/catch. Confirmed via gdb:
the abort's own stack showed __cxa_throw called from
ZString::setCursor, called from the catch block itself.
Fixed by wrapping the precise-location diagnostics in their own
try/catch, falling back to just the error text (already printed first)
plus a note that precise context isn't available, rather than crashing
the whole process. The error text is the useful part either way - the
line-context is a bonus only available when the cursor genuinely
belongs to the top-level buffer.
Verified via a full regression pass (9 real jet-2.0 runs covering custom
tag scoping at 1/2/3 nesting levels, the dump tag tree, <try>/<catch>,
<if>/<else>, and the corrected $[%name] keyword sigil) - all still work,
plus the specific crash reproduction now reports a clean error instead of
aborting.
Brad Arant