Re: [arch-general] [arch-dev-public] [signoff] bash-4.2.005 and readline-6.2.001
On Tue, Mar 1, 2011 at 11:39 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Another -1. I would recommand everyone to downgrade to the previous versions before rebooting or halting their systems. I had to boot from a live CD in order to downgrade them.
When shutting down, the following was printed:
INIT: Switching to runlevel: 6 INIT: Sending process the TERM signal INIT: no more process left in this runlevel.
And then it just hangs.
On bootup, i got a message about rc.sysinit getting a segfault in bash. Then some errors about not finding the qingy libraries (I use qingy as login manager) probably related to the mount issue that Angel mentionned. Then it hangs.
`unset TZ' is the simplest test case that causes a segmentation fault on my system. The culprit appears to be the chkexport function introduced in patch bash42-005 [1]. From the backtrace [2], I gather it should probably check that find_variable returns a non-NULL value. Changing the line after the find_variable call to read "if (v && exported_p (v))" fixes the issue for me. I've sent a bug report to bug-bash@gnu.org using the neat bashbug command. :p [1] http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-005 [2] http://ompldr.org/vN20yYg
On 01/03/11 23:57, Evangelos Foutras wrote:
On Tue, Mar 1, 2011 at 11:39 AM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
Another -1. I would recommand everyone to downgrade to the previous versions before rebooting or halting their systems. I had to boot from a live CD in order to downgrade them.
When shutting down, the following was printed:
INIT: Switching to runlevel: 6 INIT: Sending process the TERM signal INIT: no more process left in this runlevel.
And then it just hangs.
On bootup, i got a message about rc.sysinit getting a segfault in bash. Then some errors about not finding the qingy libraries (I use qingy as login manager) probably related to the mount issue that Angel mentionned. Then it hangs.
`unset TZ' is the simplest test case that causes a segmentation fault on my system.
The culprit appears to be the chkexport function introduced in patch bash42-005 [1]. From the backtrace [2], I gather it should probably check that find_variable returns a non-NULL value. Changing the line after the find_variable call to read "if (v&& exported_p (v))" fixes the issue for me.
I've sent a bug report to bug-bash@gnu.org using the neat bashbug command. :p
[1] http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-005 [2] http://ompldr.org/vN20yYg
I forwarded your analysis of the issue to the big-bash list as I am subscribed so it will get straight through. Thanks for looking into this, Allan
On 02/03/11 01:16, Allan McRae wrote:
On 01/03/11 23:57, Evangelos Foutras wrote:
On Tue, Mar 1, 2011 at 11:39 AM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
Another -1. I would recommand everyone to downgrade to the previous versions before rebooting or halting their systems. I had to boot from a live CD in order to downgrade them.
When shutting down, the following was printed:
INIT: Switching to runlevel: 6 INIT: Sending process the TERM signal INIT: no more process left in this runlevel.
And then it just hangs.
On bootup, i got a message about rc.sysinit getting a segfault in bash. Then some errors about not finding the qingy libraries (I use qingy as login manager) probably related to the mount issue that Angel mentionned. Then it hangs.
`unset TZ' is the simplest test case that causes a segmentation fault on my system.
The culprit appears to be the chkexport function introduced in patch bash42-005 [1]. From the backtrace [2], I gather it should probably check that find_variable returns a non-NULL value. Changing the line after the find_variable call to read "if (v&& exported_p (v))" fixes the issue for me.
I've sent a bug report to bug-bash@gnu.org using the neat bashbug command. :p
[1] http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-005 [2] http://ompldr.org/vN20yYg
I forwarded your analysis of the issue to the big-bash list as I am subscribed so it will get straight through.
Thanks for looking into this.
And the upstream developer confirmed your fix is good within a minute of me posting there! Allan
On Tue, Mar 1, 2011 at 5:18 PM, Allan McRae <allan@archlinux.org> wrote:
And the upstream developer confirmed your fix is good within a minute of me posting there!
And my bug report to that list is still nowhere to be seen. It must have ended up in a moderation queue or something. :p I'm glad it was that simple fix after all, and thanks for notifying the upstream developers. :)
participants (2)
-
Allan McRae
-
Evangelos Foutras