[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] GCL on mingw

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] GCL on mingw
Date: Sat, 13 Dec 2003 13:41:15 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:

"Vadim V. Zhytnikov" <address@hidden> writes:

&j          0x22ff64
&Cnil_body  0x54d1a0
core_end    0x101c8000

OK, given that you are having problems around 65000 pages (p/x 65000*4096 + 0x101c8000=0x1ffb0000)
I'm guessing something, most likely the shared library area, starts
at 0x20000000.  Is there any way that you can confirm this?  What is
the max data segment size returned by ulimit -a?  Should be
unlimited.  At the above break point in gdb, can you print the results

p sbrk(65000*4096)

then keep running 'p sbrk(xxx*4096)' with some reasonable interval xxx
until you get over 0x20000000, and let me know if there is a jump and
if so how big.

(gdb) br initlisp
Breakpoint 1 at 0x402df5
(gdb) r ./ <foo
Starting program: C:\msys\1.0\home\vadim\gcl-debug\unixport/raw_gcl.exe ./ <foo

Breakpoint 1, 0x00402df5 in initlisp ()
(gdb) p /x core_end
$1 = 0x101c8000
(gdb) p /x sbrk(65080*4096)
$2 = 0x101c8000
(gdb) p /x sbrk(4096)
$3 = 0x0
(gdb) info dll
DLL Name                          Load Address
ntdll.dll                         77f51000
C:\WINDOWS\system32\kernel32.dll  77e61000
C:\WINDOWS\system32\msvcrt.dll    77c01000
C:\WINDOWS\system32\user32.dll    77d31000
C:\WINDOWS\system32\gdi32.dll     77c61000
C:\WINDOWS\system32\advapi32.dll  77dc1000
C:\WINDOWS\system32\rpcrt4.dll    77cb1000
C:\WINDOWS\System32\wsock32.dll   71ab1000
C:\WINDOWS\System32\ws2_32.dll    71a91000
C:\WINDOWS\System32\ws2help.dll   71a81000
$ ulimit -a
core file size (blocks)     unlimited
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
open files                  256
pipe size (512 bytes)       8
stack size (kbytes)         2046
cpu time (seconds)          unlimited
max user processes          63
virtual memory (kbytes)     2097152

     Vadim V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]