Mail Archives: cygwin/2004/07/16/11:27:12
> -----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/pinfo.cc:198
#1 0x61071a32 in set_myself(int, void*) (pid=1, h=0x0) at
../../../../src/winsup/cygwin/pinfo.cc:66
#2 0x61071b84 in pinfo_init(char**, int) (envp=0x0, envc=0) at
../../../../src/winsup/cygwin/pinfo.cc:93
#3 0x61005b74 in dll_crt0_1(char*) () at
../../../../src/winsup/cygwin/dcrt0.cc:785
#4 0x6100614b in _dll_crt0 () at ../../../../src/winsup/cygwin/dcrt0.cc:942
(gdb)
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);
197
- 198 if ((procinfo->process_state & PID_INITIALIZING) &&
(flag & PID_NOREDIR)
199 && cygwin_pid (procinfo->dwProcessId) !=
procinfo->pid)
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/pinfo.cc:195
(gdb)
(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
(gdb)
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.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -