X-Authentication-Warning: new-smtp2.ihug.com.au: Host p345-tnt3.syd.ihug.com.au [203.173.133.91] claimed to be acceleron Message-ID: <006501c11742$a3fad650$0a02a8c0@acceleron> From: "Andrew Cottrell" To: , "Eli Zaretskii" Cc: References: <10107280530 DOT AA16684 AT clio DOT rice DOT edu> <7458-Sat28Jul2001095430+0300-eliz AT is DOT elta DOT co DOT il> Subject: Re: Make 3.791 on Windows 2000 test Date: Sat, 28 Jul 2001 18:52:31 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Reply-To: djgpp-workers AT delorie DOT com > > > eax=ff970000 ebx=ff970000 ecx=000001e9 edx=ff980000 esi=ff971210 > > > ebp=000b63f4 esp=000b63cc program=d:\dj204\lib\gcc-lib\djgpp\2.953\cpp0.exe > > > cs: sel=0427 base=01e90000 limit=7e15ffff > > > ds: sel=042f base=01e90000 limit=7e15ffff > > > > Note the strange limit here and EAX/EBX are huge positive (negative). This > > is a sure sign of address wrap - thus NT has returned an address block > > *LOWER* than the initial address. We need to fix sbrk() for NT - which > > means either forcing unixy sbrk() or ignoring blocks returned less than > > the original address. > > One of the first things I asked Andrew to try when this issue surfaced > was to rebuild Make with Unixy sbrk. He did, and reported it didn't > help. > > So either Andrew somehow tested that incorrectly (Andrew, could you > please recheck?), or the address wrap is not the issue here. > I do not know if I mentioned that in both PC's I have 256MB of physical RAM. I jsut checked the setting on Win2K for virtual memory and it is set to use between 384MB and 768MB. Currently it is using 384MB for all drives. Dug out the original email to save time in back tracking what I did. I modified make's main.c and added the following line, but the crash still occured and I couldn't see any extra debug info or extra info in the crash outout attached below. I also just added a printf after I set the malloc_debug level so I can see how many time make is called re-cursively. This was added at line number 774 in make's main.c befiore the main function along with a #inlcude . int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK; This is the output with the crto startup flag set as above and the maloc debug level set to 4. Yet a different crash position. Have I set the crt0 startup flag correctly? info scrolled off the top of the screen..... make.exe[2]: Leaving directory `d:/dj204/gnu/make-3.791/glob' make.exe[1]: Leaving directory `d:/dj204/gnu/make-3.791' gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c ar.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c arscan.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c commands.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c dir.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c expand.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c file.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c function.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c getopt.c gcc -I. -I. -I. -I./glob -DLIBDIR=\"c:/djgpp/lib\" -DINCLUDEDIR=\"c:/djgpp/i nclude\" -DLOCALEDIR=\"/share/locale\" -DHAVE_CONFIG_H -O2 -g -c implicit.c Exiting due to signal SIGSEGV General Protection Fault at eip=00178fc8 eax=ffa90000 ebx=ffa90000 ecx=000001d5 edx=ffaa0000 esi=ffa90ff8 edi=00000fe8 ebp=003dc8cc esp=003dc8a4 program=d:\dj204\lib\gcc-lib\djgpp\2.953\cc1.exe cs: sel=095f base=01d50000 limit=7e29ffff ds: sel=0967 base=01d50000 limit=7e29ffff es: sel=0967 base=01d50000 limit=7e29ffff fs: sel=0937 base=0000f100 limit=0000ffff gs: sel=0977 base=00000000 limit=0010ffff ss: sel=0967 base=01d50000 limit=7e29ffff App stack: [003e0000..00260000] Exceptn stack: [001a8234..001a62f4] Call frame traceback EIPs: 0x00178fc8 __doserrno+1259888 0x00007f5b _func_if+303, line 1119 of function.c 0x00176ae9 __doserrno+1250449 0x000dc9e2 __doserrno+619402 0x000d1388 __doserrno+572720 0x000cf8f9 __doserrno+565921 0x0000acca _reap_children+138, line 483 of job.c 0x00164f38 __doserrno+1177824 0x001514da __doserrno+1097346 0x00009689 __getopt_internal+2249, line 862 of getopt.c 0x0000d578 _open_tmpfile+268, line 772 of main.c 0x0017822f __doserrno+1256407 make.exe: *** [implicit.o] Error 1 DJGPP_204 D:\dj204\gnu\make-3.791>symify make.exe Any other suggestions guys? Is it work migrating from the DJGPP CVS tarball from 15th July to the 29th July when it is released? Bear in mind I have allready applied the _open/_create and NTVDM patches. Andrew