Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: RE: gcc 3.3.1-3 runtime error: static data storage size Date: Fri, 16 Jul 2004 16:25:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-reply-to: <20040716141546.GC20693@trixie.casa.cgf.cx> Message-ID: X-OriginalArrivalTime: 16 Jul 2004 15:25:43.0250 (UTC) FILETIME=[28AE1B20:01C46B49] > -----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 : mov %fs:0x18,%eax 0x77f5f5da : 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/