Re: [PATCH][BUG] Improper handling of SIGINT after running wait causes crash
On Sun, Jan 3, 2016 at 8:24 AM, Eduardo A. Bustamante López wrote: > On Sat, Jan 02, 2016 at 03:08:54PM +0200, Joey Geralnik wrote: >> I have found an easily reproducible bug in bash that causes it to crash and >> have attached a fix. > > I think this was already reported [..] > And I think the fix is in: > > commit bce12dd773b5dbf2a470b463a1461dcd86a0f266 you are right. that is exactly what fixes the segfault. I verified by creating builds with and without this commit on the same platform where it was reproducible. Some later fix the "in line ^C". Joey: have you checked the devel branch? sincerely, pg
Re: [PATCH][BUG] Improper handling of SIGINT after running wait causes crash
I didn't check the devel branch but reading the previous bug report it's the same issue. So if it's fixed in devel all should be good On Jan 3, 2016 12:36 PM, "Piotr Grzybowski" wrote: > On Sun, Jan 3, 2016 at 8:24 AM, Eduardo A. Bustamante López > wrote: > > On Sat, Jan 02, 2016 at 03:08:54PM +0200, Joey Geralnik wrote: > >> I have found an easily reproducible bug in bash that causes it to crash > and > >> have attached a fix. > > > > I think this was already reported [..] > > And I think the fix is in: > > > > commit bce12dd773b5dbf2a470b463a1461dcd86a0f266 > > you are right. that is exactly what fixes the segfault. I verified by > creating builds with and without this commit on the same platform > where it was reproducible. Some later fix the "in line ^C". > Joey: have you checked the devel branch? > > sincerely, > pg >
Re: using set +o posix unsets POSIXLY_CORRECT, even when POSIXLY_CORRECT is a read only variable
On 12/31/15 7:04 PM, nerdopolis wrote: > I tested on > 4.2.45(1)-release > > basically I have tested > nerdopolis@nerdopolis:~$ readonly POSIXLY_CORRECT=1 > nerdopolis@nerdopolis:~$ set +o posix > nerdopolis@nerdopolis:~$ echo $POSIXLY_CORRECT > > nerdopolis@nerdopolis:~$ > > Although I will admit I'm not sure if it's supposed to do that or not Yes, it does, and yes, it's the intended behavior. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH][BUG] Improper handling of SIGINT after running wait causes crash
On 1/2/16 8:08 AM, Joey Geralnik wrote: > I have found an easily reproducible bug in bash that causes it to crash and > have attached a fix. Thanks for the report. Your analysis is spot on. This was reported and fixed back in July, 2015: http://lists.gnu.org/archive/html/bug-bash/2015-07/msg00045.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Running bash using su -c causes 100% cpu usage on one core
Hi, Im not sure if this is a regression because I already found another bug report with the same symptoms from 2007, but when adding this line to the /etc/rc.local the cpu usage of one of the two cores raises to 100%: su cubie -c "(cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh)" & When executing run.sh (only calls a mono application and redirects the output to a log file) from terminal the cpu usage behaves normally. Im running the preinstalled bash version of cubieez on a cubieboard 2. (I can check the bash version later if needed, no access to the board atm.) Marcus Wichelmann smime.p7s Description: S/MIME cryptographic signature
Re: Running bash using su -c causes 100% cpu usage on one core
It's impossible to tell with the amount of info you provided. That's why there's a 'bashbug' script alongside bash to generate a useful bug report template. Provide: - bash version: bash --version - OS name and version: uname -a - The contents of the run.sh file - If possible also the su version (in my case it doesn't have a version flag, but it's part of the login package). - The output of running said script, with 'set -x' enabled You might not be running bash at all, since you didn't explictly called /bin/bash, instead letting su run /bin/sh, which could be dash, or any other shell. -- Eduardo Bustamante https://dualbus.me/
