On 23/08/2021 11:50, Roberto A. Foglietta wrote:
Il giorno lun 23 ago 2021 alle ore 11:15 Harald van Dijk
<har...@gigawatt.nl <mailto:har...@gigawatt.nl>> ha scritto:
On 23/08/2021 10:09, Roberto A. Foglietta wrote:
> Il giorno lun 23 ago 2021 alle ore 10:45 Harald van Dijk
> <har...@gigawatt.nl <mailto:har...@gigawatt.nl>
<mailto:har...@gigawatt.nl <mailto:har...@gigawatt.nl>>> ha scritto:
>
> On 23/08/2021 09:16, Roberto A. Foglietta wrote:
> I did the same.
You changed command eval false to false, but the 'command' builtin was
the key element there, that is what made the syntax error non-fatal.
'command eval false' is not the same thing as simply 'false' (at least
not in busybox ash).
Hi Harald, thanks to your deep knowledge of the shell we finally reached
the point!
The attached patch solves two questions/issues:
- not exit exceptions disables trap ERR (solved)
- not exit exceptions might do memory leak (not the case, verified)
Sorry, but this approach cannot work. The fact that an exception was
raised and handled does not tell you where it was handled, it does not
tell you whether the handler is still active.
Consider:
trap '
command eval ")"
false
' ERR
false
echo done
In bash, it prints:
bash: eval: line 6: syntax error near unexpected token `)'
bash: eval: line 6: `)'
done
With your patches, I see with busybox ash:
ash: eval: line 5: syntax error: unexpected ")"
ash: eval: line 5: syntax error: unexpected ")"
ash: eval: line 5: syntax error: unexpected ")"
[>22000 lines omitted for brevity...]
ash: eval: line 5: syntax error: unexpected ")"
ash: eval: line 5: syntax error: unexpected ")"
Segmentation fault (core dumped)
This happens because you now clear the 'recursive' flag even though the
ERR trap is still being executed, so the 'false' command inside the ERR
trap triggers the ERR trap recursively.
What should happen is that the ERR handler is unblocked once the ERR
handler stops running, regardless of whether that is because of a normal
return or an exception. One way this can be reliably done is by
installing an exception handler, allowing 'doingtrap' and 'recursive' to
be cleared upon return in all cases. I do not know whether this is the
best way, but it is at least a correct way.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
