[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3-lines long segfault

From: Chet Ramey
Subject: Re: 3-lines long segfault
Date: Mon, 20 Jul 2009 13:03:21 -0400
User-agent: Thunderbird (Macintosh/20090605)

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.

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]