http://bugs.winehq.org/show_bug.cgi?id=21424
Summary: Cygwin 1.7.1 bash crashes Product: Wine Version: 1.1.36 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
cygwin installs now, but one sees the following crash
10 [main] bash 9 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 1271 [main] bash 9 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump err:ntdll:RtlpWaitForCriticalSection section 0x736d2784 "loader.c: loader_section" wait timed out in thread 0036, blocked by 003c, retrying (60 sec)
during postinstall, and also when running bash interactively.
http://bugs.winehq.org/show_bug.cgi?id=21424
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #1 from Jeff Zaroyko jeffz@jeffz.name 2010-01-20 02:45:55 --- does bash still work interactively when launched with wineconsole?
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #2 from Dan Kegel dank@kegel.com 2010-01-20 08:44:23 --- Yes. And oddly, now it doesn't crash for me even without wineconsole, maybe it was only on the first two runs?
It does complain bash: /dev/null: No such file or directory bash: cannot create temp file for here document: Invalid request code on every run, though.
http://bugs.winehq.org/show_bug.cgi?id=21424
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Cygwin 1.7.1 bash crashes |Cygwin 1.7.1 bash errors | |during startup
--- Comment #3 from Dan Kegel dank@kegel.com 2010-01-25 19:17:46 --- Also, it starts off with the current directory being the Linux one, which doesn't work too well. ls shows nothing until you cd to the windows version of the directory.
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #4 from Alexandre Julliard julliard@winehq.org 2010-01-26 13:15:56 --- I can't reproduce this, everything works fine here as far as I can tell.
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #5 from Jeff Zaroyko jeffz@jeffz.name 2010-01-26 16:07:48 --- It's looking better than the last time I tried it.
Installed latest cygwin setup, selected the defaults, didn't see any crashes in the installer output.
Ran the .desktop launcher for cygwin (start.exe cygwin.bat), I see the error about /dev/null and the temp file, but it otherwise starts ok, bash without the xterm or wineconsole seems to run without crashing too.
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #6 from Austin English austinenglish@gmail.com 2010-01-27 09:49:41 --- (In reply to comment #5)
It's looking better than the last time I tried it.
Installed latest cygwin setup, selected the defaults, didn't see any crashes in the installer output.
Ran the .desktop launcher for cygwin (start.exe cygwin.bat), I see the error about /dev/null and the temp file, but it otherwise starts ok, bash without the xterm or wineconsole seems to run without crashing too.
I see the same, though I used wine start cygwin.bat in console (not that it matters).
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #7 from Dan Kegel dank@kegel.com 2010-01-28 02:40:29 --- It's just not happy here. I can't even install gcc; halfway through, it complains
fixme:ntdll:NtSetInformationFile Unsupported class (13) mbox fatal: Can't open Package Database for writing: File exists Ending cygwin install
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #8 from Jeff Zaroyko jeffz@jeffz.name 2010-01-28 22:11:07 --- (In reply to comment #7)
It's just not happy here. I can't even install gcc; halfway through, it complains
fixme:ntdll:NtSetInformationFile Unsupported class (13) mbox fatal: Can't open Package Database for writing: File exists Ending cygwin install
Is this because you are re-running the installer? First go it seems happy, rerunning it is another problem. Might be worth filing as a new bug?
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #9 from Austin English austinenglish@gmail.com 2010-01-28 22:14:11 --- (In reply to comment #8)
(In reply to comment #7)
It's just not happy here. I can't even install gcc; halfway through, it complains
fixme:ntdll:NtSetInformationFile Unsupported class (13) mbox fatal: Can't open Package Database for writing: File exists Ending cygwin install
Is this because you are re-running the installer? First go it seems happy, rerunning it is another problem. Might be worth filing as a new bug?
Yeah, I can confirm that. I just tried a fresh install, then went back to install gcc, and saw the mbox error on completion.
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #10 from Austin English austinenglish@gmail.com 2010-09-21 20:12:37 CDT --- May be a cygwin bug...for me on Win7, on first login: 1 [main] bash 4360 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1123 [main] bash 4360 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump Copying skeleton files. These files are for the user to personalise their cygwin experience.
They will never be overwritten nor automatically updated.
0 [main] bash 3144 child_copy: linked dll data write copy failed, 0x33D000 ..0x3414A4, done 0, windows pid 3144, Win32 error 487 1038406 [main] bash 2560 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1039374 [main] bash 2560 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 1099125 [main] bash 4568 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1099428 [main] bash 4568 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 1111472 [main] bash 3508 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1111716 [main] bash 3508 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 1185050 [main] bash 3944 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1185483 [main] bash 3944 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 1303477 [main] bash 2852 child_copy: linked dll data write copy failed, 0x33D000 ..0x3414A4, done 0, windows pid 2852, Win32 error 487 2320737 [main] bash 3496 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2322422 [main] bash 3496 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 2344239 [main] bash 4428 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2345364 [main] bash 4428 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump `./.bashrc' -> `/home/austin//.bashrc' 2519080 [main] bash 3532 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2520665 [main] bash 3532 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 2603854 [main] bash 4040 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2605521 [main] bash 4040 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 2621193 [main] bash 3872 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2621750 [main] bash 3872 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 2724259 [main] bash 4708 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2725711 [main] bash 4708 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump `./.bash_profile' -> `/home/austin//.bash_profile' 2965406 [main] bash 2076 child_copy: linked dll data write copy failed, 0x33D000 ..0x3414A4, done 0, windows pid 2076, Win32 error 487 `./.inputrc' -> `/home/austin//.inputrc' 4255404 [main] bash 4720 exception::handle: Exception: STATUS_ACCESS_VIOLATION 4256409 [main] bash 4720 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump `./bash.exe.stackdump' -> `/home/austin//bash.exe.stackdump' 4575797 [main] bash 3664 exception::handle: Exception: STATUS_ACCESS_VIOLATION 4576443 [main] bash 3664 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 4683692 [main] bash 3100 exception::handle: Exception: STATUS_ACCESS_VIOLATION 4683934 [main] bash 3100 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 4695785 [main] bash 3204 exception::handle: Exception: STATUS_ACCESS_VIOLATION 4696059 [main] bash 3204 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 4748912 [main] bash 4228 exception::handle: Exception: STATUS_ACCESS_VIOLATION 4749784 [main] bash 4228 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 5284343 [main] bash 828 exception::handle: Exception: STATUS_ACCESS_VIOLATION 5284660 [main] bash 828 open_stackdumpfile: Dumping stack trace to bash.exe.stac kdump 5367047 [main] bash 1208 exception::handle: Exception: STATUS_ACCESS_VIOLATION 5368209 [main] bash 1208 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump 5517944 [main] bash 4704 exception::handle: Exception: STATUS_ACCESS_VIOLATION 5518968 [main] bash 4704 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump
austin@pc ~ #
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #11 from Austin English austinenglish@gmail.com 2010-09-21 20:46:12 CDT --- Workaround seems to be simply rm -rf $HOME and restart cygwin. For me on the second time, bash.exe still got a stackdump (well, it made a file named bash.exe.stackdump), but I can run commands and not get tons of errors.
http://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #12 from Austin English austinenglish@gmail.com 2013-05-24 12:31:24 CDT --- (In reply to comment #11)
Workaround seems to be simply rm -rf $HOME and restart cygwin. For me on the second time, bash.exe still got a stackdump (well, it made a file named bash.exe.stackdump), but I can run commands and not get tons of errors.
On cygwin under windows*
you probably don't want to do that under Linux :)
https://bugs.winehq.org/show_bug.cgi?id=21424
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #13 from André H. nerv@dawncrow.de --- (In reply to Dan Kegel from comment #2)
It does complain bash: /dev/null: No such file or directory
Sounds like bug 38107
(In reply to Dan Kegel from comment #7)
fixme:ntdll:NtSetInformationFile Unsupported class (13)
Sounds like bug 30397
(In reply to Austin English from comment #10)
May be a cygwin bug...for me on Win7, on first login: 1 [main] bash 4360 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1123 [main] bash 4360 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump
Sounds like UPSTREAM
https://bugs.winehq.org/show_bug.cgi?id=21424
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=21424
--- Comment #14 from Joel Holdsworth joel@airwebreathe.org.uk ---
May be a cygwin bug...for me on Win7, on first login: 1 [main] bash 4360 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1123 [main] bash 4360 open_stackdumpfile: Dumping stack trace to bash.exe.sta ckdump
Sounds like UPSTREAM
I have encountered a similar issue testing a legacy 32-bit build of cygwin.
32-bit cygwin has now been deprecated, and the code has been removed from the runtime. However, it is still possible to download legacy versions of cygwin from the Cygwin Time Machine:
http://www.crouchingtigerhiddenfruitbat.org/cygwin/timemachine.html
The cygwin runtime (cygwin1.dll) had code which parses ntdll dll code to extract the FAST_CWD pointer both on 32-bit and 64-bit. Here is the (now removed) 32-bit implementation of find_fast_cwd_pointer:
https://github.com/mirror/newlib-cygwin/blob/cygwin-3_1_2-release/winsup/cyg...
Obviously this cannot work correctly in Wine, and the code crashes with a NULL-pointer derefence exception dereferencing the pushedi/movedi pointer without first checking it.
This was later fixed in the cygwin runtime by this patch:
https://github.com/mirror/newlib-cygwin/commit/4ddf5903fd
...which was released in cygwin-3_1_3-release.
So, a possible workabout is to upgrade to the final 32-bit version of cygwin which is built with the cygwin-3_3_6-release version of the runtime.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla