Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-2975742 ] bash/console fails under windows 7 when executing the script
|
From: SF/projects/mingw n. l. <min...@li...> - 2012-07-25 12:54:23
|
Bugs item #2975742, was opened at 2010-03-24 01:06 Message generated for change (Comment added) made by gknauf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2975742&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MSYS Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Grebeniuk (gdsfh) Assigned to: Nobody/Anonymous (nobody) Summary: bash/console fails under windows 7 when executing the script Initial Comment: I have the following almost-minimal example, which produces error: ==================== gds@TEXX ~ $ cat ./kva (echo 1 | (tr , , ; echo 2)) > somefile 2>&1 gds@TEXX ~ $ start "" bash -c ./kva ==================== The error is: ==================== Problem signature: Problem Event Name: APPCRASH Application Name: conhost.exe Application Version: 6.1.7600.16385 Application Timestamp: 4a5bc571 Fault Module Name: conhost.exe Fault Module Version: 6.1.7600.16385 Fault Module Timestamp: 4a5bc571 Exception Code: c0000005 Exception Offset: 000000000001533c OS Version: 6.1.7600.2.0.0.272.7 Locale ID: 1049 Additional Information 1: 6aae Additional Information 2: 6aaedae1b1e1c2080c426463c6d386f5 Additional Information 3: 8ca9 Additional Information 4: 8ca95f2add99756da5d3e393c9cf2352 ==================== The MSYS is the most fresh from the "MSYS Base System" which has /bin/tr.exe included -- msysCORE-1.0.11-bin.tar.gz. In a more complex scripts, this error leads to more errors (I suspect it), like ==================== 0 [main] sh 4352 fhandler_console::fixup_after_fork: error opening console after fork, Win32 error 2 0 [main] sh 5664 fhandler_console::fixup_after_fork: error opening console after fork, Win32 error 2 0 [main] grep 5664 fhandler_console::fixup_after_exec: error opening console after exec, errno 2, Win32 error 2 ==================== (this may or may not be linked with the reported issue) ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-25 05:54 Message: @earnie: my tests were on 3 Win7 boxes - 2x 64bit, 1x 32bit - and no AV software installed; windows firewall disabled (since I cant run my tests otherwise), and latest tests on the 32-bit box additionally with UAC disabled. Sorry, I dont get any 'windows error 2', mine are 'Win32 error 6', often coupled with errno 9, like: buildconf: running libtoolize 0 [main] touch 2768 fhandler_console::fixup_after_exec: error opening console after exec, errno 9, Win32 error 6 please see the the file: http://svwe10.itex.at/downloads/curltest/log.diff.gz the conhost crash happens also most of the times (but not always, and can also be caused by the software I'm testing). @keith: I think the main issue is that libtoolize crashes when sh.exe is called with script parameter; this is the only difference which seems to trigger the issue; and msys.bat is in fact also a batch, just it doesnt launch a script but only the shell. I've also tested with the original msys.bat where I only added the script as parameter to sh.exe - just to be sure that I didnt miss any 'magic' the msys.bat might do which my batch doesnt, but result is same; tested with/without -i ... ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-07-25 04:19 Message: We could really do with Cesar or Chuck chiming in on this. I don't have a Win7 box at all; (even when I replace my aging 32-bit laptop with a 64-bit machine, in a couple of weeks, I won't be wasting my time with Win7 -- I'll be reformatting and installing a Debian based 64-bit Linux). I do have a vague recollection of some previous discussion of a change in the console handling in Win7; try googling it. Does double clicking a .bat shortcut attach a console, in the same manner as you would have with an interactive shell session, (MSYS or otherwise)? I don't know. I would recommend raising the issue on the MinGW-Users mailing list; you'll get better exposure, and more chance of a useful response, than restricting the discussion to a bug tracker ticket. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-07-24 21:51 Message: Well, something is fishy. A windows error 2 is "File not find" but I'm thinking it can happen with closed sockets as well. Do you have some antivirus that may be getting in the way? I've had issues with antivirus causing issues during builds of source due to it trying to parse the files that are being generated and removed rather rapidly. ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-24 20:47 Message: oh, forgot these: 1) the archive I pointed to in last post is meant to be extracted to c:\ - it works anywhere, but if you use it at another drive/path then you have to fix the script path in startauto.bat ... 2) while testing I did also switch off Win7 UAC : http://windows.microsoft.com/en-us/windows-vista/Turn-User-Account-Control-on-or-off but that didnt make any difference. ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-24 20:37 Message: Hi Earnie, 1st thanks for your decades of supporting MinGW! haha, if it would be that simple! No, grep doesnt work here (at least not with only -v) since the nasty error messages appear also during configure run - means it happens also in the middle of output lines like: checking for sys/types.h... (fhandler_console error outut)\n yes so these are a little bit harder to remove - but I have a sed hack now which does it almost - the result appears still on next line, but all fhandler errors are removed ... ok, but now some important news: I did now also run my testing on a Win7 32bit box, and guess what? it happens there too!! So now its clear that its *not* related to 64-bit only but also happens with 32bit windows ... further I can say that it always happens when libtoolize is invoked; this is the reason why 1st thought that its a 64bit issue since on the 32bit box I didnt have git so I did build from a snapshot, and that doesnt invoke buildconf & friends (and no libtoolize). I've just packed together the stuff with what I currently test: http://svwe10.itex.at/downloads/curltest/test-bug-2975742.tar.gz and results are really strange: if I run the script autocurl.sh from the shell opened with msys.bat then it works fine; if I double-click startauto.bat to launch it then it throws the fhandler errors ... sure, that sounds as if my batch is wrong, but I did also use the original msys.bat and only added the script parameter to it with same result; so I am confused and atm clueless how to further track down the issue ... the final goal is to use startauto.bat from an AT job; you can use scheduleatjobs.vbs for this ... most likely I'm missing something, but currently I cant imagine what ... any help greatly appreciated! thanks, Guenter. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-07-23 07:00 Message: I didn't even have a Windows 7 system until a few days ago. At the moment my focus is the MinGW runtime and being able to use it on Windows 7. To work around your log problem I suggest you massage it once the build is done such that you create a new file using ``grep -v fixup_after_fork LOGFILE > NEWLOGFILE && mv NEWLOGFILE LOGFILE''. I have yet to have a problem with MSYS and yes I have used it to build packages. You might try executing sh.exe as the administrator, you can set it to do so every time it executes. ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-22 19:23 Message: Keith, let me summarize a bit: 1) the issue is a really nasty one especially because the error messages totally clutter build output 2) currently we dont know how to fix this bug 3) the MSYS developers have no time / resources to debug this bug 4) the error messages are totally useless since the user cant do anything beside reporting them here Conclusion: lets for now look for a simple way to just only supress those errors so that they no longer clutter buildlogs since otherwise the build runs fine (yeah, I just even managed to build + test 64-bit binaries with mingw64). I think what we need until we get a final fix is a commandline option (f.e. --no-fhandler-errors) which just switches off the output of those errors - that would greatly help all those who need to build on 64-bit OS because they target 64-bit and have to test the binaries after build. Find attached a diff from a logfile which I cleaned up with sed; I stil didnt catch all of those errors (would need more sed learning I guess :-P ) but enough to reduce the buildlog from 4.5MB to 1.8MB ... so this diff is now a collection of all those errors which appear in my logfiles; if you look into it you'll see that I did so far only delete those which are on separate lines, but there are still a bunch more which appear in the middle of lines, mainly during configure checks ... please please add a commandline option for now to suppress the errors - that should be fairly easy! hmmm, dont see how to add a file, so in case I dont manage that here's the diff: http://svwe10.itex.at/downloads/curltest/log.diff.gz ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-20 23:48 Message: Sorry Keith for the comment about time take taken; it shouldnt offend but I found it unusual that not at least there was a reply to the initial filed issue - even if that would be only something which you now posted ... - so thanks for getting back fast! I saw the 'voodoo' in msys.bat, and I use it of course ... Unfortunately using this 'alien platfiorm' is required for me since my final goal is to run the testsuite with 64-bit native target :-( I did also google a bit about this issue, and it seems to me that this bug is somehow inherited from Cygwin - there are tons of related reports ... Regarding resources I might be able to provide access to a virtualized Win7 installation for testing purposes, so if someone wants to look into the issue and debug it further then please contact me directly. Thanks again for the fast reply! -Gün. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-07-20 02:24 Message: Guenter, Snide comments about the time taken to resolve this are unlikely to engender sympathy. MSYS is, fundamentally, a collection of 32-bit Windows applications; you note that it runs fine on 32-bit WinXP, but problems arise on 64-bit Win7, (which is an alien platform for MSYS). There is some voodoo in MSYS.bat, to kick-start MSYS under SysWOW64, when it's launched on 64-bit Windows. Is it possible that your usage circumvents that? If so, then problems are inevitable. Beyond that, I can offer nothing further; we have only two active developers for MSYS, and I guess neither of them currently has the magic combination of sufficient incentive, sufficient free time, and appropriate resources, to pursue issues on that alien platform. ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-19 20:54 Message: oh, forgot to add version info: msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 unknown; targ=MINGW32 GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 4.7.0; targ=MINGW32 GNU ld (GNU Binutils) 2.22 24 2011-04-25 01:42:29.000000000 +0200 /bin/msys-1.0.dll 59 2010-04-14 16:15:29.000000000 +0200 /bin/msys-archive-2.dll 48 2011-09-10 08:40:32.000000000 +0200 /bin/msys-bz2-1.dll 40 2010-01-29 02:32:57.000000000 +0100 /bin/msys-crypt-0.dll 48 2010-04-15 00:32:54.000000000 +0200 /bin/msys-crypto-1.0.0.dll 40 2010-01-29 03:06:29.000000000 +0100 /bin/msys-expat-1.dll 92 2010-01-29 02:49:36.000000000 +0100 /bin/msys-gdbm-3.dll 64 2010-01-29 02:49:36.000000000 +0100 /bin/msys-gdbm_compat-3.dll 48 2010-05-04 04:04:46.000000000 +0200 /bin/msys-gmp-10.dll 24 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guile-17.dll 12 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guile-srfi-srfi-1-v-3-3.dll 80 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guile-srfi-srfi-13-14-v-3-3.dll 80 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guile-srfi-srfi-4-v-3-3.dll 52 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guile-srfi-srfi-60-v-2-2.dll 80 2010-05-08 21:26:27.000000000 +0200 /bin/msys-guilereadline-v-17-17.dll 04 2011-10-29 20:18:01.000000000 +0200 /bin/msys-iconv-2.dll 28 2011-10-29 13:22:30.000000000 +0200 /bin/msys-intl-8.dll 46 2010-09-26 07:04:09.000000000 +0200 /bin/msys-ltdl-7.dll 28 2010-04-09 19:40:23.000000000 +0200 /bin/msys-lzma-1.dll 88 2011-09-10 09:01:59.000000000 +0200 /bin/msys-lzma-5.dll 48 2010-04-16 06:50:34.000000000 +0200 /bin/msys-magic-1.dll 64 2010-02-01 23:22:06.000000000 +0100 /bin/msys-minires.dll 44 2010-05-09 02:41:04.000000000 +0200 /bin/msys-opts-25.dll 08 2011-04-27 06:23:31.000000000 +0200 /bin/msys-perl5_8.dll 27 2010-04-28 01:40:27.000000000 +0200 /bin/msys-popt-0.dll 92 2010-02-01 23:29:13.000000000 +0100 /bin/msys-regex-1.dll 44 2010-04-15 00:32:54.000000000 +0200 /bin/msys-ssl-1.0.0.dll 64 2010-02-01 02:44:06.000000000 +0100 /bin/msys-termcap-0.dll 88 2010-02-01 22:40:02.000000000 +0100 /bin/msys-xml2-2.dll 20 2012-05-14 06:29:50.000000000 +0200 /bin/msys-z.dll 8 2010-04-29 20:18:53.000000000 +0200 /bin/make.exe 98 2012-03-31 19:24:11.000000000 +0200 /mingw/bin/gcc.exe 02 2011-11-30 16:20:43.000000000 +0100 /mingw/bin/ld.exe HOME=/home/autobuilder Sysname=MINGW32_NT-6.1 OSTYPE=msys TERM=cygwin PATH=.:/usr/local/bin:/mingw/bin:/bin:/mingw64/bin:/c/php5:/c/Pe rl64/site/bin:/c/Perl64/bin:/c/Windows/system32:/c/Windows:/c/Wi ndows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/ fetched about 4 weeks ago with mingw-get-inst. ---------------------------------------------------------------------- Comment By: Guenter Knauf (gknauf) Date: 2012-07-19 20:37 Message: Hi MinGW devels, now 2 years 4 months later, and still same issue with MSYS running on 64-bit Windows 7; I'm currently trying to setup some curl autobuilds, and while that works great on 32-bit WinXP, it throws tons of fhandler_console::fixup_after_* errors; see here for my autobuilds on Win7 (ultimate and prof): http://curl.haxx.se/dev/builds.html f.e.: http://curl.haxx.se/dev/log.cgi?id=20120719235014-10384 (the logs are regulary purged - so if the above link no longer exists just select another build with 'Win7u-SP1' in description text). Also as you can see the problems start already right at running buildconf - that means long before our testsuite runs ... I would be really great if you could take a look at this issue - it makes the autobuild logs unreadable and more than twice as big (4.4 MB vs 1.9MB). if you have something beta for testing please contact me and I will asap run it! Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2975742&group_id=2435 |