This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gcc 3.3.1-3 runtime error: static data storage size

> -----Original Message-----
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 16 July 2004 15:16

> >Yes, I see.  Yhe problem is the default stack size on cygwin 
> (2 MB), you
> >can increase it.
> >
> >$ gcc -o aa -Wl,--stack,8388608 aa.c
> >
> >$ ./aa
> >ok
> >
> >$ cat aa.c
> >#define NXY 7000
> >
> >int xy[NXY][NXY];
> >main(){
> >printf("ok\n");
> >}
> Why would the stack size affect a global variable?
> cgf

  It's a problem in Cygwin's startup code, triggered purely by the size of
the common section.

(gdb) bt
#0  pinfo::init(int, unsigned long, void*) (this=0x610f59e4, n=4012, flag=1,
in_h=0x0) at ../../../../src/winsup/cygwin/
#1  0x61071a32 in set_myself(int, void*) (pid=1, h=0x0) at
#2  0x61071b84 in pinfo_init(char**, int) (envp=0x0, envc=0) at
#3  0x61005b74 in dll_crt0_1(char*) () at
#4  0x6100614b in _dll_crt0 () at ../../../../src/winsup/cygwin/


  It turns out that pinfo::init has this chunk of code:

	195	      procinfo = (_pinfo *) MapViewOfFileEx (h, access, 0,
0, 0, mapaddr);
 	196	      ProtectHandle1 (h, pinfo_shared_handle);
-	198	      if ((procinfo->process_state & PID_INITIALIZING) &&
(flag & PID_NOREDIR)
 	199		  && cygwin_pid (procinfo->dwProcessId) !=
 	200		{
-	201		  release ();
-	202		  set_errno (ENOENT);
-	203		  return;
 	204		}

  And the SEGV happens when we attempt to test (procinfo->process_state &
PID_INITIALIZING) because procinfo is NULL, meaning the MapViewOfFileEx call
must have failed....  let's just see how it gets called

procinfo = (_pinfo *) MapViewOfFileEx (h, access, 0, 0, 0, mapaddr);

(gdb) print/x h
$2 = 0x730

(gdb) print/x access
$3 = 0x6

(gdb) print/x mapaddr
$4 = 0x400000

Ok, what's handle 0x730?

  730: Section       \BaseNamedObjects\cygwin1S4.cygpid.4076

and the return value after stepping over the function call?

(gdb) print $eax
$6 = 0

Hmm, so what's the actual error?

(gdb) info breakpoints
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x00401072 in main at aa.c:5
2   breakpoint     keep y   0x61071eee in pinfo::init(int, unsigned long,
void*) at ../../../../src/winsup/cygwin/


(gdb) set $eip=0x77f5f5d4
(gdb) disass $eip $eip+12
Dump of assembler code from 0x77f5f5d4 to 0x77f5f5e0:
0x77f5f5d4 <ntdll!RtlGetLastWin32Error+0>:	mov    %fs:0x18,%eax
0x77f5f5da <ntdll!RtlGetLastWin32Error+6>:	mov    0xfb0(%eax),%eax
End of assembler dump.

(gdb) stepi
No symbol "procinfo" in current context.
Cannot access memory at address 0x4

0x77f5f5da in ntdll!RtlGetLastWin32Error () from ntdll.dll

(gdb) print/x $eax
$6 = 0x7ffde000

(gdb) stepi
No symbol "procinfo" in current context.
Cannot access memory at address 0x4

0x77f5f5e0 in ntdll!RtlGetLastWin32Error () from ntdll.dll

(gdb) print $eax
$7 = 0


  Hmm.  How strange.  The last Win32 error code is zero.

  However, it seems to be a variant of the
can't-map-the-shared-heap-at-the-same-address-in-the-child-process bug,
presumably because the huge common section occupies that address range, and
the lack of a NULL-pointer test on the return from MapViewOfFileEx leads to
the SEGV.  But I can't say for sure that that is what was going on; I didn't
actually verify the process space layout was as I guess.  And I don't know
why there wasn't an error return code either.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]