bug-bash
[Top][All Lists]
Advanced

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

Re: 3-lines long segfault


From: Marc Herbert
Subject: Re: 3-lines long segfault
Date: Mon, 20 Jul 2009 18:25:28 +0100
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

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






reply via email to

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