Re: 3-lines long segfault

[Chet Ramey]

Marc Herbert wrote:
> Chet Ramey a écrit :
>> Marc Herbert wrote:
>>> The following script crashes bash versions 2.05, 3.2.25, 4.0.16,...
>>>
>>>
>>> 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.  Most existing scripts use simple
subshells to do it, whether (command) or asynchronous commands using `&'.

In general, if you want to do something like set an alarm to go off in
the future, say after 10 seconds, you do something like

{ sleep 10; kill -USR1 $$; } &

and perform a potentially blocking operation.

> 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.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/