[ANNOUNCEMENT] [1.7] Updated [security]: bash-3.2.49-23

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A new release of bash, 3.2.49-23, has been uploaded for those testing
cygwin 1.7, replacing 3.2.49-22 as current.

NEWS:
=====
This is a package refresh, built against cygwin 1.7.  It closes a buffer
overflow exploit security hole that was reported to me off-list; the
exploit was only possible when using long path names under cygwin 1.7
coupled with bash compiled under cygwin 1.5.  It also removes special
handling for DOS paths, since cygwin 1.7 is less accommodating to those
(use /cygdrive instead).

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you absolutely
must use files with \r\n line endings, consider mounting the directory
where those files live as a text mount.  However, text mounts are not as
well tested or supported on the cygwin mailing list, so you may encounter
other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific shell option, named "igncr"
to force bash to ignore \r, independently of cygwin's mount style.  As of
bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to accept
this patch into the future bash 4.0 even on Linux, rather than keeping it
a cygwin-specific patch, but only time will tell.  There are several ways
to activate this option:
4a. For a single affected script, add this line just after the she-bang:
~ (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the shopt, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks the
current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
5. You can also experiment with the IFS variable for controlling how bash
will treat \r during variable expansion.
6. The bash hack for honoring the underlying mount point of DOS-style
paths has been discontinued, as had been promised in several prior release
notes.  Use POSIX-style paths instead.
7. There are varying levels of speed at which bash operates.  The fastest
is on a binary mount with igncr disabled (the default behavior).  Next
would be text mounts with igncr disabled and no \r in the underlying file.
Next would be binary mounts with igncr enabled.  And the slowest that bash
will operate is on text mounts with igncr enabled.
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
9. If you forget to read this release announcement, the best you can
expect when you complain to the list is a link back to this email.

Remember, you must not have any bash or /bin/sh instances running when you
upgrade the bash package.  This release requires cygwin-1.7.0-50 or
later; and it requires libreadline7-6.0.3-1 or later.  See also the
upstream documentation in /usr/share/doc/bash/.

DESCRIPTION:
============
Bash is an sh-compatible shell that incorporates useful features from the
Korn shell (ksh) and C shell (csh).  It is intended to conform to the IEEE
POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers functional
improvements over sh for both programming and interactive use. In
addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to Linux distributions.

UPDATE:
=======
To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.
Save it and run setup, answer the questions and pick up 'bash' in the
'Base' category (it should already be selected).

DOWNLOAD:
=========
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==========
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake
volunteer cygwin bash maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=================================
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send email
to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@...

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMGLYACgkQ84KuGfSFAYBaJgCeOUFnU0wnvpQRvIxNJvnMYljF
yEYAnjoZP3DPn4UX8fXgBxlAwiQOFdp+
=cnEu
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

On Wed, July 1, 2009 22:17, Eric Blake wrote:
> It also removes special
> handling for DOS paths, since cygwin 1.7 is less accommodating to those
> (use /cygdrive instead).

Can you clarify what this means exactly compared to say the latest bash
version in cigwin 1.5? Personally, I rely on using DOS paths from the bash
command line everyday. eg. "cd $FOO" where FOO is some environment
variable containing a forward slash DOS path.

-Edward


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Edward Lam on 7/1/2009 8:52 PM:
> On Wed, July 1, 2009 22:17, Eric Blake wrote:
>> It also removes special
>> handling for DOS paths, since cygwin 1.7 is less accommodating to those
>> (use /cygdrive instead).
>
> Can you clarify what this means exactly compared to say the latest bash
> version in cigwin 1.5? Personally, I rely on using DOS paths from the bash
> command line everyday. eg. "cd $FOO" where FOO is some environment
> variable containing a forward slash DOS path.

If you have /cygdrive/c mounted as a text mount point, then

echo > /cygdrive/c/file

continues to do text processing, but the alternate construct

echo > c:\file

now behaves in a binary fashion (in 1.5, I had been special casing DOS
paths to make them obey the underlying mount point, but cygwin 1.7 goes
further to discourage DOS paths, so I'm no longer worried about
maintaining that special-case).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMI4sACgkQ84KuGfSFAYAMUACgiu+ugLU6az+5oXnXb22HXbup
T3oAoNTDoU41BZYZL9r3h+Ve03MQqgVH
=9LbM
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Christopher Faylor-8]

On Wed, Jul 01, 2009 at 09:03:39PM -0600, Eric Blake wrote:

>If you have /cygdrive/c mounted as a text mount point, then
>
>echo > /cygdrive/c/file
>
>continues to do text processing, but the alternate construct
>
>echo > c:\file
>
>now behaves in a binary fashion (in 1.5, I had been special casing DOS
>paths to make them obey the underlying mount point, but cygwin 1.7 goes
>further to discourage DOS paths, so I'm no longer worried about
>maintaining that special-case).

And for those who want to wail about this, take a look at the various
"Why is Cygwin so slow????" threads that have been here in the last
month.  Every special case accommodation we make to allow MS-DOSisms
to work seamlessly adds code to Cygwin and cause corresponding slowness
for everything.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Andy Koppe]

2009/7/2 Christopher Faylor:
> And for those who want to wail about this, take a look at the various
> "Why is Cygwin so slow????" threads that have been here in the last
> month.  Every special case accommodation we make to allow MS-DOSisms
> to work seamlessly adds code to Cygwin and cause corresponding slowness
> for everything.

Will text mount points be chucked out completely eventually? Those are
pure evil.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Corinna Vinschen-2]

On Jul  2 06:42, Andy Koppe wrote:
> 2009/7/2 Christopher Faylor:
> > And for those who want to wail about this, take a look at the various
> > "Why is Cygwin so slow????" threads that have been here in the last
> > month.  Every special case accommodation we make to allow MS-DOSisms
> > to work seamlessly adds code to Cygwin and cause corresponding slowness
> > for everything.
>
> Will text mount points be chucked out completely eventually? Those are
> pure evil.

No, they will stay since there are people out there still relying on
text mounts.  However, as far as I'm concerned (and I have a gut feeling
that cgf has a quite similar point of view) we won't ask maintaners to
go out of their way to care for them.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

Christopher Faylor wrote:
> And for those who want to wail about this, take a look at the various
> "Why is Cygwin so slow????" threads that have been here in the last
> month.  Every special case accommodation we make to allow MS-DOSisms
> to work seamlessly adds code to Cygwin and cause corresponding slowness
> for everything.

That's an interesting view. So are you saying that this is why MINGW is
faster?

-Edward

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Christopher Faylor-8]

On Thu, Jul 02, 2009 at 09:58:06AM +0200, Corinna Vinschen wrote:

>On Jul  2 06:42, Andy Koppe wrote:
>> 2009/7/2 Christopher Faylor:
>> > And for those who want to wail about this, take a look at the various
>> > "Why is Cygwin so slow????" threads that have been here in the last
>> > month. ?Every special case accommodation we make to allow MS-DOSisms
>> > to work seamlessly adds code to Cygwin and cause corresponding slowness
>> > for everything.
>>
>> Will text mount points be chucked out completely eventually? Those are
>> pure evil.
>
>No, they will stay since there are people out there still relying on
>text mounts.  However, as far as I'm concerned (and I have a gut feeling
>that cgf has a quite similar point of view) we won't ask maintaners to
>go out of their way to care for them.

Yeah, they are still apparently a necessarily evil.  However talk about
code complication...  That's one of the worst.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Christopher Faylor-8]

On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
>Christopher Faylor wrote:
>>And for those who want to wail about this, take a look at the various
>>"Why is Cygwin so slow????" threads that have been here in the last
>>month.  Every special case accommodation we make to allow MS-DOSisms to
>>work seamlessly adds code to Cygwin and cause corresponding slowness
>>for everything.
>
>That's an interesting view.  So are you saying that this is why MINGW
>is faster?

No, they just aren't as mean as we are.  We like to make things
purposely slow because then people suffer.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

Christopher Faylor wrote:
> On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
>> Christopher Faylor wrote:
>>> And for those who want to wail about this, take a look at the various
>>> "Why is Cygwin so slow????" threads that have been here in the last
>>> month.  Every special case accommodation we make to allow MS-DOSisms to
>>> work seamlessly adds code to Cygwin and cause corresponding slowness
>>> for everything.
 >>
>> That's an interesting view.  So are you saying that this is why MINGW
>> is faster?
>
> No, they just aren't as mean as we are.  We like to make things
> purposely slow because then people suffer.

I asked what I thought was a sensible question for someone who doesn't
know the internal workings of cygwin/mingw. It wasn't meant as a flame
bait. I was just interested in what trade-offs mingw might be making for
its speed.

-Edward

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Christopher Faylor-8]

On Thu, Jul 02, 2009 at 02:10:27PM -0400, Edward Lam wrote:

>Christopher Faylor wrote:
>>On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
>>>Christopher Faylor wrote:
>>>>And for those who want to wail about this, take a look at the various
>>>>"Why is Cygwin so slow????" threads that have been here in the last
>>>>month.  Every special case accommodation we make to allow MS-DOSisms to
>>>>work seamlessly adds code to Cygwin and cause corresponding slowness
>>>>for everything.
>>>
>>>That's an interesting view.  So are you saying that this is why MINGW
>>>is faster?
>>
>>No, they just aren't as mean as we are.  We like to make things
>>purposely slow because then people suffer.
>
>I asked what I thought was a sensible question for someone who doesn't
>know the internal workings of cygwin/mingw.  It wasn't meant as a flame
>bait.  I was just interested in what trade-offs mingw might be making
>for its speed.

I guess I forgot the reference:

http://cygwin.com/acronyms/#WJM

The answer to your question is easily discernible just by reading the
respective web pages to the two projects.  The important word to find on
the Cygwin web page is "emulation".  On the MinGW web page, the word to
scan for would be "native" (or maybe "minimal").

This has been discussed multiple times in this very mailing list, even
as recently as a couple of days ago.

If you want more of a clue, look at the number of linux packages that
Cygwin offers versus the number that MinGW provides.  Do you see a
disparity?  Why do you think that is?  Hmm.  Maybe the MinGW project
is mean too.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

Hi Eric,

I seem to no longer be able to install bash 3.2.49-22 in cygwin 1.7? I
even tried doing a fresh cygwin install, choosing explicitly to use bash
3.2.49-22 instead of 3.2.49-23. During the installation, I get an error
saying that cygreadline6.dll is missing. Any ideas?

I also tried doing a fresh cygwin install, and then re-running
setup-1.7.exe to install the older bash release. Same problem.

-Edward

Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A new release of bash, 3.2.49-23, has been uploaded for those testing
> cygwin 1.7, replacing 3.2.49-22 as current.
>
> NEWS:
> =====
> This is a package refresh, built against cygwin 1.7.  It closes a buffer
> overflow exploit security hole that was reported to me off-list; the
> exploit was only possible when using long path names under cygwin 1.7
> coupled with bash compiled under cygwin 1.5.  It also removes special
> handling for DOS paths, since cygwin 1.7 is less accommodating to those
> (use /cygdrive instead).
>
> There are a few things you should be aware of before using this version:
> 1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
> on Linux does not understand \r\n line endings, but interprets the \r
> literally, which leads to syntax errors or odd variable assignments.
> Therefore, you will get the same behavior on Cygwin binary mounts by default.
> 2. d2u is your friend.  You can use it to convert any problematic script
> into binary line endings.
> 3. Cygwin text mounts automatically work with either line ending style,
> because the \r is stripped before bash reads the file.  If you absolutely
> must use files with \r\n line endings, consider mounting the directory
> where those files live as a text mount.  However, text mounts are not as
> well tested or supported on the cygwin mailing list, so you may encounter
> other problems with other cygwin tools in those directories.
> 4. This version of bash has a cygwin-specific shell option, named "igncr"
> to force bash to ignore \r, independently of cygwin's mount style.  As of
> bash-3.2.3-5, it controls regular scripts, command substitution, and
> sourced files.  I hope to convince the upstream bash maintainer to accept
> this patch into the future bash 4.0 even on Linux, rather than keeping it
> a cygwin-specific patch, but only time will tell.  There are several ways
> to activate this option:
> 4a. For a single affected script, add this line just after the she-bang:
> ~ (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
> 4b. For a single script, invoke bash explicitly with the shopt, as in
> 'bash -o igncr ./myscript' rather than the simpler './myscript'.
> 4c. To affect all scripts, export the environment variable BASH_ENV,
> pointing to a file that sets the shell option as desired.  Bash will
> source this file on startup for every script.
> 4d. Added in the bash-3.2-2 release: export the environment variable
> SHELLOPTS with igncr included in it.  It is read-only from within bash,
> but you can set it before invoking bash; once in bash, it auto-tracks the
> current state of 'set -o igncr'.  If exported, then all bash child
> processes inherit the same option settings; with the exception added in
> 3.2.9-11 that certain interactive options are not inherited in
> non-interactive use.
> 5. You can also experiment with the IFS variable for controlling how bash
> will treat \r during variable expansion.
> 6. The bash hack for honoring the underlying mount point of DOS-style
> paths has been discontinued, as had been promised in several prior release
> notes.  Use POSIX-style paths instead.
> 7. There are varying levels of speed at which bash operates.  The fastest
> is on a binary mount with igncr disabled (the default behavior).  Next
> would be text mounts with igncr disabled and no \r in the underlying file.
> Next would be binary mounts with igncr enabled.  And the slowest that bash
> will operate is on text mounts with igncr enabled.
> 8. If you don't like how bash behaves, then propose a patch, rather than
> proposing idle ideas.  This turn of events has already been talked to
> death on the mailing lists by people with many ideas, but few patches.
> 9. If you forget to read this release announcement, the best you can
> expect when you complain to the list is a link back to this email.
>
> Remember, you must not have any bash or /bin/sh instances running when you
> upgrade the bash package.  This release requires cygwin-1.7.0-50 or
> later; and it requires libreadline7-6.0.3-1 or later.  See also the
> upstream documentation in /usr/share/doc/bash/.
>
> DESCRIPTION:
> ============
> Bash is an sh-compatible shell that incorporates useful features from the
> Korn shell (ksh) and C shell (csh).  It is intended to conform to the IEEE
> POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers functional
> improvements over sh for both programming and interactive use. In
> addition, most sh scripts can be run by Bash without modification.
>
> As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
> similar to Linux distributions.
>
> UPDATE:
> =======
> To update your installation, click on the "Install Cygwin now" link on the
> http://cygwin.com/ web page.  This downloads setup.exe to your system.
> Save it and run setup, answer the questions and pick up 'bash' in the
> 'Base' category (it should already be selected).
>
> DOWNLOAD:
> =========
> Note that downloads from sources.redhat.com (aka cygwin.com) aren't
> allowed due to bandwidth limitations.  This means that you will need to
> find a mirror which has this update, please choose the one nearest to you:
> http://cygwin.com/mirrors.html
>
> QUESTIONS:
> ==========
> If you want to make a point or ask a question the Cygwin mailing list is
> the appropriate place.
>
> - --
> Eric Blake
> volunteer cygwin bash maintainer
>
> CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
> =================================
> To unsubscribe to the cygwin-announce mailing list, look at the
> "List-Unsubscribe: " tag in the email header of this message.  Send email
> to the address specified there.  It will be in the format:
>
> cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@...
>
> If you need more information on unsubscribing, start reading here:
>
> http://sourceware.org/lists.html#unsubscribe-simple
>
> Please read *all* of the information on unsubscribing that is available
> starting at this URL.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpMGLYACgkQ84KuGfSFAYBaJgCeOUFnU0wnvpQRvIxNJvnMYljF
> yEYAnjoZP3DPn4UX8fXgBxlAwiQOFdp+
> =cnEu
> -----END PGP SIGNATURE-----
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

Hi Eric,

I got bash 3.2.49-22 running again in cygwin 1.7 after explicitly
installing libreadline6.

Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
7100 64-bit. Basically, bash just crashes on startup. I don't have
access to a Vista machine right now but it's worthwhile confirming on it.

On the given machine, I tried starting cmd.exe as Administrator (to rule
out UAC issues):

Microsoft Windows [Version 6.1.7100]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>cd c:\cygwin\bin

c:\cygwin\bin>cygcheck -c bash cygwin libreadline7
Cygwin Package Information
Package              Version        Status
bash                 3.2.49-23      OK
cygwin               1.7.0-50       OK
libreadline7         6.0.3-1        OK

c:\cygwin\bin>bash
       5 [main] bash 1624 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
    1413 [main] bash 1624 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
   16897 [main] bash 1624 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   17965 [main] bash 1624 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)

I've attached the bash.exe.stackdump.

-Edward

Edward Lam wrote:

> Hi Eric,
>
> I seem to no longer be able to install bash 3.2.49-22 in cygwin 1.7? I
> even tried doing a fresh cygwin install, choosing explicitly to use bash
> 3.2.49-22 instead of 3.2.49-23. During the installation, I get an error
> saying that cygreadline6.dll is missing. Any ideas?
>
> I also tried doing a fresh cygwin install, and then re-running
> setup-1.7.exe to install the older bash release. Same problem.
>
> -Edward
>
> Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> A new release of bash, 3.2.49-23, has been uploaded for those testing
>> cygwin 1.7, replacing 3.2.49-22 as current.
>>
>> NEWS:
>> =====
>> This is a package refresh, built against cygwin 1.7.  It closes a buffer
>> overflow exploit security hole that was reported to me off-list; the
>> exploit was only possible when using long path names under cygwin 1.7
>> coupled with bash compiled under cygwin 1.5.  It also removes special
>> handling for DOS paths, since cygwin 1.7 is less accommodating to those
>> (use /cygdrive instead).
>>
>> There are a few things you should be aware of before using this version:
>> 1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
>> on Linux does not understand \r\n line endings, but interprets the \r
>> literally, which leads to syntax errors or odd variable assignments.
>> Therefore, you will get the same behavior on Cygwin binary mounts by
>> default.
>> 2. d2u is your friend.  You can use it to convert any problematic script
>> into binary line endings.
>> 3. Cygwin text mounts automatically work with either line ending style,
>> because the \r is stripped before bash reads the file.  If you absolutely
>> must use files with \r\n line endings, consider mounting the directory
>> where those files live as a text mount.  However, text mounts are not as
>> well tested or supported on the cygwin mailing list, so you may encounter
>> other problems with other cygwin tools in those directories.
>> 4. This version of bash has a cygwin-specific shell option, named "igncr"
>> to force bash to ignore \r, independently of cygwin's mount style.  As of
>> bash-3.2.3-5, it controls regular scripts, command substitution, and
>> sourced files.  I hope to convince the upstream bash maintainer to accept
>> this patch into the future bash 4.0 even on Linux, rather than keeping it
>> a cygwin-specific patch, but only time will tell.  There are several ways
>> to activate this option:
>> 4a. For a single affected script, add this line just after the she-bang:
>> ~ (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
>> 4b. For a single script, invoke bash explicitly with the shopt, as in
>> 'bash -o igncr ./myscript' rather than the simpler './myscript'.
>> 4c. To affect all scripts, export the environment variable BASH_ENV,
>> pointing to a file that sets the shell option as desired.  Bash will
>> source this file on startup for every script.
>> 4d. Added in the bash-3.2-2 release: export the environment variable
>> SHELLOPTS with igncr included in it.  It is read-only from within bash,
>> but you can set it before invoking bash; once in bash, it auto-tracks the
>> current state of 'set -o igncr'.  If exported, then all bash child
>> processes inherit the same option settings; with the exception added in
>> 3.2.9-11 that certain interactive options are not inherited in
>> non-interactive use.
>> 5. You can also experiment with the IFS variable for controlling how bash
>> will treat \r during variable expansion.
>> 6. The bash hack for honoring the underlying mount point of DOS-style
>> paths has been discontinued, as had been promised in several prior
>> release
>> notes.  Use POSIX-style paths instead.
>> 7. There are varying levels of speed at which bash operates.  The fastest
>> is on a binary mount with igncr disabled (the default behavior).  Next
>> would be text mounts with igncr disabled and no \r in the underlying
>> file.
>> Next would be binary mounts with igncr enabled.  And the slowest that
>> bash
>> will operate is on text mounts with igncr enabled.
>> 8. If you don't like how bash behaves, then propose a patch, rather than
>> proposing idle ideas.  This turn of events has already been talked to
>> death on the mailing lists by people with many ideas, but few patches.
>> 9. If you forget to read this release announcement, the best you can
>> expect when you complain to the list is a link back to this email.
>>
>> Remember, you must not have any bash or /bin/sh instances running when
>> you
>> upgrade the bash package.  This release requires cygwin-1.7.0-50 or
>> later; and it requires libreadline7-6.0.3-1 or later.  See also the
>> upstream documentation in /usr/share/doc/bash/.
>>
>> DESCRIPTION:
>> ============
>> Bash is an sh-compatible shell that incorporates useful features from the
>> Korn shell (ksh) and C shell (csh).  It is intended to conform to the
>> IEEE
>> POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers functional
>> improvements over sh for both programming and interactive use. In
>> addition, most sh scripts can be run by Bash without modification.
>>
>> As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
>> similar to Linux distributions.
>>
>> UPDATE:
>> =======
>> To update your installation, click on the "Install Cygwin now" link on
>> the
>> http://cygwin.com/ web page.  This downloads setup.exe to your system.
>> Save it and run setup, answer the questions and pick up 'bash' in the
>> 'Base' category (it should already be selected).
>>
>> DOWNLOAD:
>> =========
>> Note that downloads from sources.redhat.com (aka cygwin.com) aren't
>> allowed due to bandwidth limitations.  This means that you will need to
>> find a mirror which has this update, please choose the one nearest to
>> you:
>> http://cygwin.com/mirrors.html
>>
>> QUESTIONS:
>> ==========
>> If you want to make a point or ask a question the Cygwin mailing list is
>> the appropriate place.
>>
>> - --
>> Eric Blake
>> volunteer cygwin bash maintainer
>>
>> CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
>> =================================
>> To unsubscribe to the cygwin-announce mailing list, look at the
>> "List-Unsubscribe: " tag in the email header of this message.  Send email
>> to the address specified there.  It will be in the format:
>>
>> cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@...
>>
>> If you need more information on unsubscribing, start reading here:
>>
>> http://sourceware.org/lists.html#unsubscribe-simple
>>
>> Please read *all* of the information on unsubscribing that is available
>> starting at this URL.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (Cygwin)
>> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkpMGLYACgkQ84KuGfSFAYBaJgCeOUFnU0wnvpQRvIxNJvnMYljF
>> yEYAnjoZP3DPn4UX8fXgBxlAwiQOFdp+
>> =cnEu
>> -----END PGP SIGNATURE-----
>>
>> --
>> Problem reports:       http://cygwin.com/problems.html
>> FAQ:                   http://cygwin.com/faq/
>> Documentation:         http://cygwin.com/docs.html
>> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>>
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

Exception: STATUS_ACCESS_VIOLATION at eip=04FF0000
eax=04FF0000 ebx=00000001 ecx=0000000B edx=0000000A esi=6FFCCAD4 edi=00000005
ebp=0028CCE8 esp=0028CCDC program=c:\cygwin\bin\bash.exe, pid 580, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028CCE8  04FF0000  (6120B808, 6120C41C, 0028CD50, 61020360)
0028CD78  61020293  (00000000, 0028CDB0, 610066C0, 7EFDE000)
End of stack trace
  23209 [main] bash 580 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  25350 [main] bash 580 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Warren Young]

Edward Lam wrote:
>>
>> No, they just aren't as mean as we are.  We like to make things
>> purposely slow because then people suffer.
>
> I asked what I thought was a sensible question for someone who doesn't
> know the internal workings of cygwin/mingw. It wasn't meant as a flame
> bait.

Flame?  Oh, my no.  That was just a light warming in a little butter and
garlic.  (Ah, grilled newbie, yum.)  Flaming is not subtle here.  Like
in many online fora, it's best to try to maintain a thick skin here, so
as to be less easily upset.

Cygwin is slow because there is a huge amount of code in it to try and
provide POSIX.1 interfaces and semantics on top of the Win32 API, so
that programs assuming a POSIX environment can just be recompiled to run
on Windows.[1]  MinGW provides so few packages because they're only
trying to port the build tools, which are portable, not depending on
POSIX.  That rules out a huge number of packages that would be
impractical to port directly to Windows.

[1] That's the ideal, anyway.  It even happens quite a lot these days,
probably even most of the time.

[2] There's still a lot of work that goes into MinGW to handle various
Windowsisms.  They're not just recompiling GCC for Windows over there.

P.S. sidefx.com, eh?  I found the Houdini demo interesting, but not
enough so that I'm going to set aside C4D and modo.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Christopher Faylor-8]

On Thu, Jul 02, 2009 at 04:14:23PM -0600, Warren Young wrote:
>Like in many online fora, it's best to try to maintain a thick skin
>here, so as to be less easily upset.

It is more fun to translate attempts at humor or sarcasm as a
near-mortal wounds.  This allows others to heroically step in to offer
succor when someone is so seriously pierced.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please don't top-post, and trim your replies to just include relevant
text: http://cygwin.com/acronyms/#TOFU

According to Edward Lam on 7/2/2009 3:14 PM:
> Hi Eric,
>
> I got bash 3.2.49-22 running again in cygwin 1.7 after explicitly
> installing libreadline6.

Yes, a side effect of the version bump is a library dependency change, so
setup.hint no longer explicitly lists libreadline6.

>
> Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
> 7100 64-bit. Basically, bash just crashes on startup. I don't have
> access to a Vista machine right now but it's worthwhile confirming on it.

I don't have access to any of these (just XP, here), so I can't really
tell where things are crashing.  It works just fine for me.

> Frame     Function  Args
> 0028CCE8  04FF0000  (6120B808, 6120C41C, 0028CD50, 61020360)
> 0028CD78  61020293  (00000000, 0028CDB0, 610066C0, 7EFDE000)

61020293 looks like an address in the dll range, probably cygwin1.dll.  It
would be nice to know what function is dying, but doing that may require
rebuilding a bash image with debugging symbols.  Did you by chance do any
rebasing?  Maybe this is a case where I didn't use the correct gcc-4 flags
for compilation, at which point an updated binutils/gcc might fix things.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpNS6gACgkQ84KuGfSFAYDcGQCeN6jGHQ5tEuepsIAudxFrxcpg
00oAoMZhUO01XKJ0m+7WW656HP8s/SOV
=Ku9F
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Vincent R.]

>> Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
>> 7100 64-bit. Basically, bash just crashes on startup. I don't have
>> access to a Vista machine right now but it's worthwhile confirming on
it.
>
> I don't have access to any of these (just XP, here), so I can't really
> tell where things are crashing.  It works just fine for me.
>
>> Frame     Function  Args
>> 0028CCE8  04FF0000  (6120B808, 6120C41C, 0028CD50, 61020360)
>> 0028CD78  61020293  (00000000, 0028CDB0, 610066C0, 7EFDE000)
>
> 61020293 looks like an address in the dll range, probably cygwin1.dll.
It
> would be nice to know what function is dying, but doing that may require
> rebuilding a bash image with debugging symbols.  Did you by chance do any
> rebasing?  Maybe this is a case where I didn't use the correct gcc-4
flags
> for compilation, at which point an updated binutils/gcc might fix things.
>
Same problem here (I am attaching output from msvc debugger) :

'bash.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll'
cYgFFFFFFFF 61156900'bash.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll'
'bash.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll'
cYgstd 28ccf5 d 3First-chance exception at 0xf9350000 in bash.exe:
0xC0000005: Access violation.
cYgSiGw00f 11 0x8D0 0x28CE94First-chance exception at 0xf9350000 in
bash.exe: 0xC0000005: Access violation.
cYgSiGw00f 11 0x8D0 0x28CE94The thread 'Win32 Thread' (0xfc8) has exited
with code 0 (0x0).
'bash.exe': Loaded 'C:\Windows\SysWOW64\psapi.dll'
The program '[0xBB8] bash.exe: Native' has exited with code 35584 (0x8b00).



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Corinna Vinschen-2]

On Jul  3 10:11, Vincent R. wrote:

> >> Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
> >> 7100 64-bit. Basically, bash just crashes on startup. I don't have
> >> access to a Vista machine right now but it's worthwhile confirming on
> it.
> >
> > I don't have access to any of these (just XP, here), so I can't really
> > tell where things are crashing.  It works just fine for me.
> >
> >> Frame     Function  Args
> >> 0028CCE8  04FF0000  (6120B808, 6120C41C, 0028CD50, 61020360)
> >> 0028CD78  61020293  (00000000, 0028CDB0, 610066C0, 7EFDE000)
> >
> > 61020293 looks like an address in the dll range, probably cygwin1.dll.
> It
> > would be nice to know what function is dying, but doing that may require
> > rebuilding a bash image with debugging symbols.  Did you by chance do any
> > rebasing?  Maybe this is a case where I didn't use the correct gcc-4
> flags
> > for compilation, at which point an updated binutils/gcc might fix things.
> >
> Same problem here (I am attaching output from msvc debugger) :
> [...]

I can reproduce the problem on Vista 32 bit and W7 32 bit.  I can not
reproduce it on XP for some reason, same as Eric.

AFAICS from the stackdump, trying to call the ctors of cygreadline-9.dll
crashes.

Here's a commented stackdump from the W7 machine:

Exception: STATUS_ACCESS_VIOLATION at eip=075A0000
eax=075A0000 ebx=0022CE64 ecx=0000000B edx=0000000A esi=00000000 edi=00000000
ebp=0022CC78 esp=0022CC6C program=C:\cygwin\bin\bash.exe, pid 2436, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022CC78  075A0000  (6DB80000, 00000001, 0022FD24, 7257CAD0)

^^^^ cygreadline-9.dll ^^^^

vvvv cygwin1.dll ^^^^

0022CC98  610336E1  (6124F444, 00000000, 00000000, 61036BAF) per_module::run_ctors
0022CCC8  610337B4  (6124F43C, 0000002F, 00000003, 00000007) dll::init
0022CCE8  61033811  (611ED440, 00000000, 611812A0, 00000001) dll_list::init
0022CD68  61006EDD  (00000000, 0022CDA8, 61006A5F, 00000000) dll_crt0_1
0022CD98  610049A6  (0022CDA8, 00000000, 00000000, 00000000) _cygtls::call2
0022FF48  61004A0C  (61006A5F, 00000000, 0022FF68, 00459F03) _cygtls::call
0022FF58  61005E4C  (00402010, 611812A0, 0022FF88, 0040103D) _dll_crt0

^^^^ cygwin1.dll ^^^^

vvvv bash.exe vvvv

0022FF68  00459F03  (00402010, 00000000, 00000000, 00000000)
0022FF88  0040103D  (7FFD5000, 0022FFD4, 777FB495, 7FFD5000)
0022FF94  75C410F4  (7FFD5000, 77AD605C, 00000000, 00000000)
0022FFD4  777FB495  (00401000, 7FFD5000, 00000000, 00000000)
0022FFEC  777FB468  (00401000, 7FFD5000, 00000000, 78746341)
End of stack trace

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Edward Lam]

Eric Blake wrote:
> 61020293 looks like an address in the dll range, probably cygwin1.dll.  It
> would be nice to know what function is dying, but doing that may require
> rebuilding a bash image with debugging symbols.  Did you by chance do any
> rebasing?  Maybe this is a case where I didn't use the correct gcc-4 flags
> for compilation, at which point an updated binutils/gcc might fix things.

No, I didn't do any rebasing. I also tried using rebaseall and
peflagsall to no avail.

Incidentally, is installing the bash and libreadline source broken? If I
install the src for say, the make package, it installs it into a
subdirectory under /usr/src. But when I tried to do the same for
bash-3.2.49-23, I just got a bash src tar ball along with a bunch of
patch files. Is this expected?

-Edward

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Eric Blake]

Edward Lam <edward <at> sidefx.com> writes:

> > 61020293 looks like an address in the dll range, probably cygwin1.dll.  It
> > would be nice to know what function is dying, but doing that may require
> > rebuilding a bash image with debugging symbols.  Did you by chance do any
> > rebasing?  Maybe this is a case where I didn't use the correct gcc-4 flags
> > for compilation, at which point an updated binutils/gcc might fix things.
>
> No, I didn't do any rebasing. I also tried using rebaseall and
> peflagsall to no avail.

I'm wondering if the problem is not how I compiled bash, but how I compiled
readline.  Dave, any pointers I should try or maybe a missed compiler flag I
should have used to build libreadline7 with gcc4?  I'm shooting in the dark,
since I can't seem to reproduce the crash.

>
> Incidentally, is installing the bash and libreadline source broken? If I
> install the src for say, the make package, it installs it into a
> subdirectory under /usr/src. But when I tried to do the same for
> bash-3.2.49-23, I just got a bash src tar ball along with a bunch of
> patch files. Is this expected?

It's more than just patch files - it also includes the .cygport file that uses
those patch files.  So yes, this is expected;
quoting /usr/share/doc/Cygwin/bash.README:

Build instructions:
  unpack bash-3.2.49-23-src.tar.bz2
    if you use setup to install this src package, it will be
         unpacked under /usr/src automatically
  cd /usr/src
  cygport bash-3.2.49-23 all

--
Eric Blake



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple