>>>> trap "echo USR1caught" USR1
>>>> read -t 1
>>>> foo=$( kill -USR1 $$ )
>>>> echo 'Yeah! no Segmentation fault!'
>>> Thanks for the report.
>> Thanks for bash in the first place.
>>
>>
>>> Fixed in the next version.
>> Chet, is there any workaround for existing versions?
>
> Sure. There's the usual idiom. It's unusual to see a script that uses
> command substitution for this. [...]
> In general, if you want to do something like set an alarm to go off in
> the future, [...]
I want not.
I think you did not (and could not) guess what I want to perform
here. These 3 lines were isolated (with great pain) from a script
several hundreds lines long. So let me flesh it a little bit:
export MASTER_PID=$$
trap "incrementSomeCounter" USR1
...
read -t 1 # code totally unrelated to the trap
...
foo=$( ...
kill -USR1 $MASTER_PID # increment parent's counter
...
kill -USR1 $MASTER_PID # increment parent's counter again
...
echo "returnValue"
)
>> I mean, there must be some memory corruption involved in here, so is
>> it possible to dodge it without upgrading? For instance, would simply
>> avoiding the "-t" option of "read" be enough to guarantee no memory
>> corruption? Other? Thanks a lot in advance!
> It's a combination of the assignment statement and the trap handling.
> Yes, there is memory corruption that occurs, because the trap handler
> doesn't unwind-protect a global variable used by the expansion and
> execution code.
Sorry I do not understand "unwind-protect".
In more practical terms, are you saying here that:
- removing the "-t" option from "read" dodges the immediate crash, but
not the memory corruption? So bash might still crash later?
- in other words, triggering a trap from a command expansion will
always corrupt memory? (I mean: without your recent fix)
Cheers,
Marc
