Re: Problem with latest setup-x86.exe
Achim Gratz writes: Corinna Vinschen writes: I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. The patch WJFFM. But in line 266 of main.cc set_cout() is still called if unattended_mode -q (or --help) is set. -- 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
Re: Problem with latest setup-x86.exe
On Nov 19 09:30, Harry G McGavran Jr wrote: Achim Gratz writes: Corinna Vinschen writes: I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. The patch WJFFM. But in line 266 of main.cc set_cout() is still called if unattended_mode -q (or --help) is set. Sure. The problem was not the set_cout function but overloading the fopen function. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFZc9bSK5ZI.pgp Description: PGP signature
Re: Problem with latest setup-x86.exe
Corinna Vinschen writes: Achim Gratz writes: Corinna Vinschen writes: I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. The patch WJFFM. But in line 266 of main.cc set_cout() is still called if unattended_mode -q (or --help) is set. Sure. The problem was not the set_cout function but overloading the fopen function. FWIW -- what brought me to line 266 was that I started playing with the latest setup-x86.exe (The 17-Nov. 2013 one) in a cmd window and noticed that the problem only existed with -q or --help. I normally use setup.exe with -q so I was seeing this all the time. So after looking at main.cc it was too hard to pass up line 266 as a possible culprit. A bit more interesting though is that later I started using the Windows debugger under the cmd window on that same setup-x86.exe and could see the null pointer problem, but of course there were not symbols or source. So, for grins I decided to decompress it with upx -d and voila, it fixed the problem as long as I ran the uncompressed version. For further grins, I decided to try compressing it again and most of the common options brought the problem back -- BUT -- if I used --compress-exports=0 in upx, then I got a compressed version that doesn't have the problem. Even with --best and --compress-exports=0 I get a version that works. So, this is just FWIW -- other executables compress with upx and work just fine. Previous versions of setup (prior to the incantations of the current version) work just fine -- so not being a windows person any more that I absolutely have to, I'm not going to pursue this any further, but this might be useful information for someone someday. -- 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
Re: Problem with latest setup-x86.exe
On Nov 17 18:54, Achim Gratz wrote: Christopher Faylor writes: I appreciate your looking at the source code but given what you changed, I don't understand how what you did would fix that. If your changes were really necessary then something would have to be seriously wrong with mscvrt handling of argv strings. That points to a problem on your system, not in the code. This is not the bug you are looking for... The changes from Harry effectively shut out the code path that triggers the bug by introducing another one. The bug is in a nutshell, that \\?\conout$ isn't a valid UNC path and with the override of fopen as per the latest changes by Corinna creating an ofstream tries to use that to get the console output handle. I'm not sure how to fix this, it seems odd that there'd be no UNC variant of conout$, but my search has turned up empty. I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBuLoTZf2kZ.pgp Description: PGP signature
Re: Problem with latest setup-x86.exe
Corinna Vinschen wrote: I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. I grabbed the latest source (which has the nt_fopen in it) and built it without the argv patch, but it still has the same problem. __argv is always zero. So, I tried the following under cygwin's mingw32: #include stdio.h #include stdlib.h /* extern char *** __p___argv(void); */ #if 1 #define argc _argc #define argv _argv #endif #if 0 #define argc __argc #define argv __argv #endif int main(int argc, char **argv, char **envp) { register int i; printf (_argc = 0x%x\n, _argc); printf (__argc = 0x%x\n, __argc); printf (__p___argc() = 0x%x\n, __p___argc()); printf (*(__p___argc()) = 0x%x\n, *(__p___argc())); printf (\n); printf (_argv = 0x%x\n, _argv); printf (__argv = 0x%x\n, __argv); printf (__p___argv() = 0x%x\n, __p___argv()); printf (*(__p___argv()) = 0x%x\n, *(__p___argv())); printf (\n); printf(argc=%d\n, argc); for (i=0; iargc; i++) printf(argv[%d]=%s\n, i, argv[i]); return(0); } and then I ran it on my machine and four other windows 7 pro machines using tst abc def and get: _argc = 0x3 __argc = 0x0 __p___argc() = 0x755830e4 *(__p___argc()) = 0x0 _argv = 0x5b1680 __argv = 0x0 __p___argv() = 0x755830c0 *(__p___argv()) = 0x0 argc=3 argv[0]=C:\cygwin\usr\local\src\cygwin_setup\tst\tst.exe argv[1]=abc argv[2]=def on all these machines. I don't know how that for loop on __argv in main.cc can work with __argv always returning zero, but admittedly setup.exe does work on some of these machines without my changes, just not on others. My changes produce a setup that does work on all of them. I have to admit I haven't been able to figure out what __argv really does since it always returns zero on any machine I try. So, I'm still puzzled. -- 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
Re: Problem with latest setup-x86.exe
Harry G McGavran Jr writes: int main(int argc, char **argv, char **envp) The entry point in setup.exe is WinMain, which has a different signature and entry point. The use of __argv ties into the actual RTC entry point of WinMainCRTStartup and gets populated on startup. If indeed on one of your machines the behaviour is different than on others, you might pick up a different RTC. Try to find out from where this CRT, more specifically msvcrt.dll, is coming. These days you can expect a dozen of these in several places on your system and with the wrong path settings you might pick up a rogue one. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Re: Problem with latest setup-x86.exe
Corinna Vinschen writes: I just explained that in a reply an the cygwin-apps list: http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html I applied a patch to setup which should fix the issue. The patch WJFFM. :-) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Re: Problem with latest setup-x86.exe
Christopher Faylor writes: I appreciate your looking at the source code but given what you changed, I don't understand how what you did would fix that. If your changes were really necessary then something would have to be seriously wrong with mscvrt handling of argv strings. That points to a problem on your system, not in the code. This is not the bug you are looking for... The changes from Harry effectively shut out the code path that triggers the bug by introducing another one. The bug is in a nutshell, that \\?\conout$ isn't a valid UNC path and with the override of fopen as per the latest changes by Corinna creating an ofstream tries to use that to get the console output handle. I'm not sure how to fix this, it seems odd that there'd be no UNC variant of conout$, but my search has turned up empty. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Re: Problem with latest setup-x86.exe
On Tue, Nov 12, 2013 at 10:54:03AM -0700, Harry G McGavran Jr wrote: On only one of my Windows 7 machines the latest setup-x86.exe works but always exits with an Access Violation. I appreciate your looking at the source code but given what you changed, I don't understand how what you did would fix that. If your changes were really necessary then something would have to be seriously wrong with mscvrt handling of argv strings. That points to a problem on your system, not in the code. 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
Re: Problem with latest setup-x86.exe
On 11/12/2013 10:54 AM, Harry G McGavran Jr wrote: On only one of my Windows 7 machines the latest setup-x86.exe works but always exits with an Access Violation. So, I downloaded the source to setup and built it. But in order to make the build work, I had to remove -Werror from the Makefile and add a definition for ARRAYSIZE to main.cc. The fix to the Access violation was to remove an extra _ in the code for the argv handling in main.cc On Tue, 12 Nov 2013 13:31:31 -0500, Christopher Faylor wrote: I appreciate your looking at the source code but given what you changed, I don't understand how what you did would fix that. If your changes were really necessary then something would have to be seriously wrong with mscvrt handling of argv strings. That points to a problem on your system, not in the code. Perhaps, but I would have no idea how to figure out problems with mscvrt. I found the problem by just using gdb on the setup.exe built without the __argv fix. __argv was always a null pointer. (Since __argv seems to be a definition, I always had to look at the results of invoking __argv when using gdb). When looking at how _argv was handled, it looked like that was the thing to use, so when I tried that, the pointers were all fine. So, if in fact the original code is correct, I don't know how to find out what changed in mscvrt. Previous versions of setup-x86 seem not to have this problem for some reason. -- 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