Re: 3-lines long segfault

Marc Herbert wrote: > - 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) It i

Re: 3-lines long segfault

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 th

Re: 3-lines long segfault

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 fo

Re: 3-lines long segfault

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

Re: 3-lines long segfault

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. Fixed in the next version. Chet -- ``The lyf so short, the craft so lon