Problem with latest setup-x86.exe

Problem with latest setup-x86.exe

[Harry G McGavran Jr]

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

This is just FWIW -- but it fixed my problem. The patches
I used follow:



*** ./setup/Makefile.orig	2013-11-12 10:27:00.812425300 -0700
--- ./setup/Makefile	2013-11-12 10:28:53.698882000 -0700
***************
*** 462,468 ****
  BASECXXFLAGS = -Wall -Wno-uninitialized -Wpointer-arith -Wcomments \
  	       -Wcast-align -Wwrite-strings -fno-builtin-sscanf

! AM_CXXFLAGS = -Werror $(BASECXXFLAGS) ${$(*F)_CXXFLAGS}
  AM_CFLAGS = $(AM_CXXFLAGS) -Wmissing-declarations -Winline \
  	    -Wstrict-prototypes -Wmissing-prototypes

--- 462,468 ----
  BASECXXFLAGS = -Wall -Wno-uninitialized -Wpointer-arith -Wcomments \
  	       -Wcast-align -Wwrite-strings -fno-builtin-sscanf

! AM_CXXFLAGS = $(BASECXXFLAGS) ${$(*F)_CXXFLAGS}
  AM_CFLAGS = $(AM_CXXFLAGS) -Wmissing-declarations -Winline \
  	    -Wstrict-prototypes -Wmissing-prototypes

*** ./setup/main.cc.orig	2013-11-07 06:14:18.000000000 -0700
--- ./setup/main.cc	2013-11-12 10:29:06.907637500 -0700
***************
*** 85,90 ****
--- 85,94 ----
  extern char **_argv;
  #endif

+ #ifndef ARRAYSIZE
+ #define ARRAYSIZE(_ar) (sizeof (_ar) / sizeof (_ar[0]))
+ #endif
+
  bool is_64bit;

  using namespace std;
***************
*** 233,250 ****
    snprintf(locale, sizeof locale, ".%u", GetACP());
    setlocale(LC_ALL, locale);

!   char **_argv;
    int argc;
!   for (argc = 0, _argv = __argv; *_argv; _argv++)
      ++argc;
!   _argv = __argv;

    try {
      char cwd[MAX_PATH];
      GetCurrentDirectory (MAX_PATH, cwd);
      local_dir = std::string (cwd);

!     if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
        exit (1);

      if (!((string) Arch).size ())
--- 237,254 ----
    snprintf(locale, sizeof locale, ".%u", GetACP());
    setlocale(LC_ALL, locale);

!   char **argv;
    int argc;
!   for (argc = 0, argv = _argv; *argv; argv++)
      ++argc;
!   argv = _argv;

    try {
      char cwd[MAX_PATH];
      GetCurrentDirectory (MAX_PATH, cwd);
      local_dir = std::string (cwd);

!     if (!GetOption::GetInstance ().Process (argc,argv, NULL))
        exit (1);

      if (!((string) Arch).size ())


--
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]

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

[Harry G McGavran Jr]

>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.
>> 
>>\x1c 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

Re: Problem with latest setup-x86.exe

[Achim Gratz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Problem with latest setup-x86.exe

[Achim Gratz]

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

[Harry G McGavran Jr]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Problem with latest setup-x86.exe

[Harry G McGavran Jr]

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

[Achim Gratz]

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

[Harry G McGavran Jr]

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; i<argc; 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