www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - bigAlloc Crashes on One of my machines

reply John Demme <me teqdruid.com> writes:
For some reason, my program crashes on Linux on my notebook, but it works
fine on Linux on my desktop.  Here's the gdb backtrace:








Unfortunately, I've been unable to get the line number that this crashes on
since gdb crashes on loading this particular program with it's compiled
with the -g switch.  I'm gonna work on that one.

Here's the code to reproduce it:
void main() {
        void[] tmp = new void[1000000000];
}

So, in short: this code crashes *immediately* on my notebook, and runs on my
desktop (but I kill it after a minute).

So, this code is not particularly important, but one of my programs triggers
this bug through mango.

I have included the output from strace (which for those of you who don't
know, it outputs all of the kernel calls and signals that a program...
uhh... does)

Any ideas?
~John Demme

---------------STRACE OUPUT-----------------------
execve("./gcx", ["./gcx", "2"], [/* 53 vars */]) = 0
uname({sys="Linux", node="neon", ...})  = 0
brk(0)                                  = 0x805c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=85249, ...}) = 0
mmap2(NULL, 85249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f64000
close(3)                                = 0
open("/lib/libpthread.so.0", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260A\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=142466, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f63000
mmap2(NULL, 332928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7f11000
mmap2(0xb7f1f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
MAP_DENYWRITE, 3, 0xd) = 0xb7f1f000
mmap2(0xb7f21000, 267392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
MAP_ANONYMOUS, -1, 0) = 0xb7f21000
close(3)                                = 0
open("/lib/libm.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p3\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=161528, ...}) = 0
mmap2(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7eee000
mmap2(0xb7f0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
MAP_DENYWRITE, 3, 0x20) = 0xb7f0f000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000V\1\000"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1232028, ...}) = 0
mmap2(NULL, 1146096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7dd6000
mprotect(0xb7ee7000, 27888, PROT_NONE)  = 0
mmap2(0xb7ee8000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
MAP_DENYWRITE, 3, 0x111) = 0xb7ee8000
mmap2(0xb7eec000, 7408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
MAP_ANONYMOUS, -1, 0) = 0xb7eec000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7dd5000
mprotect(0xb7ee8000, 4096, PROT_READ)   = 0
mprotect(0xb7f1f000, 4096, PROT_READ)   = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd56c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0xb7f64000, 85249)               = 0
getpid()                                = 12691
rt_sigaction(SIGRTMIN, {0xb7f19630, [], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7f19780, [RTMIN], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0xb7f19960, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbf88c888, 31, (nil), 0}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\327g\27 ", 4)                 = 4
close(3)                                = 0
brk(0)                                  = 0x805c000
brk(0x807d000)                          = 0x807d000
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7cd5000
rt_sigaction(SIGUSR1, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
mmap2(NULL, 1000013824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault)   0 (0) ---
+++ killed by SIGSEGV +++
Nov 03 2005
next sibling parent reply "Kris" <fu bar.com> writes:
Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas the 
desktop can?


"John Demme" <me teqdruid.com> wrote in message 
news:dkeh21$25nl$1 digitaldaemon.com...
 For some reason, my program crashes on Linux on my notebook, but it works
 fine on Linux on my desktop.  Here's the gdb backtrace:








 Unfortunately, I've been unable to get the line number that this crashes 
 on
 since gdb crashes on loading this particular program with it's compiled
 with the -g switch.  I'm gonna work on that one.

 Here's the code to reproduce it:
 void main() {
        void[] tmp = new void[1000000000];
 }

 So, in short: this code crashes *immediately* on my notebook, and runs on 
 my
 desktop (but I kill it after a minute).

 So, this code is not particularly important, but one of my programs 
 triggers
 this bug through mango.

 I have included the output from strace (which for those of you who don't
 know, it outputs all of the kernel calls and signals that a program...
 uhh... does)

 Any ideas?
 ~John Demme

 ---------------STRACE OUPUT-----------------------
 execve("./gcx", ["./gcx", "2"], [/* 53 vars */]) = 0
 uname({sys="Linux", node="neon", ...})  = 0
 brk(0)                                  = 0x805c000
 access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
 directory)
 open("/etc/ld.so.cache", O_RDONLY)      = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=85249, ...}) = 0
 mmap2(NULL, 85249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f64000
 close(3)                                = 0
 open("/lib/libpthread.so.0", O_RDONLY)  = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260A\0"..., 512) 
 =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=142466, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
 =
 0xb7f63000
 mmap2(NULL, 332928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
 =
 0xb7f11000
 mmap2(0xb7f1f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0xd) = 0xb7f1f000
 mmap2(0xb7f21000, 267392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7f21000
 close(3)                                = 0
 open("/lib/libm.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p3\0\000"..., 512) 
 =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=161528, ...}) = 0
 mmap2(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
 =
 0xb7eee000
 mmap2(0xb7f0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x20) = 0xb7f0f000
 close(3)                                = 0
 open("/lib/libc.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000V\1\000"..., 
 512)
 = 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=1232028, ...}) = 0
 mmap2(NULL, 1146096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
 =
 0xb7dd6000
 mprotect(0xb7ee7000, 27888, PROT_NONE)  = 0
 mmap2(0xb7ee8000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x111) = 0xb7ee8000
 mmap2(0xb7eec000, 7408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7eec000
 close(3)                                = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
 =
 0xb7dd5000
 mprotect(0xb7ee8000, 4096, PROT_READ)   = 0
 mprotect(0xb7f1f000, 4096, PROT_READ)   = 0
 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd56c0, 
 limit:1048575,
 seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
 seg_not_present:0, useable:1}) = 0
 munmap(0xb7f64000, 85249)               = 0
 getpid()                                = 12691
 rt_sigaction(SIGRTMIN, {0xb7f19630, [], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_1, {0xb7f19780, [RTMIN], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_2, {0xb7f19960, [], 0}, NULL, 8) = 0
 rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbf88c888, 31, (nil), 0}) = 0
 open("/dev/urandom", O_RDONLY)          = 3
 read(3, "\327g\27 ", 4)                 = 4
 close(3)                                = 0
 brk(0)                                  = 0x805c000
 brk(0x807d000)                          = 0x807d000
 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
 0)
 = 0xb7cd5000
 rt_sigaction(SIGUSR1, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 rt_sigaction(SIGUSR2, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 mmap2(NULL, 1000013824, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0) = -1 ENOMEM (Cannot allocate memory)
 --- SIGSEGV (Segmentation fault)   0 (0) ---
 +++ killed by SIGSEGV +++
 
Nov 03 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Kris wrote:
 Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas the 
 desktop can?
I should have counted the byte size. I bet it would have succeeded on my machine if I'd let it finish. I'll try again later when I'm no longer interested in using my laptop for a while ;-) Sean
Nov 03 2005
parent reply Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 Kris wrote:
 
 Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas 
 the desktop can?
I should have counted the byte size. I bet it would have succeeded on my machine if I'd let it finish. I'll try again later when I'm no longer interested in using my laptop for a while ;-)
Yup, worked fine, though Windows panicked near the end. Sean
Nov 03 2005
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Kelly schrieb am 2005-11-04:
 Sean Kelly wrote:
 Kris wrote:
 
 Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas 
 the desktop can?
I should have counted the byte size. I bet it would have succeeded on my machine if I'd let it finish. I'll try again later when I'm no longer interested in using my laptop for a while ;-)
Yup, worked fine, though Windows panicked near the end.
Something is odd with the Window version. box: 2GB physical ram On Linux the programm prints "99999998 99999999" and exits. On Windows the programm prints "99999998 99999999" and seems to be caught in a loop. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDa+gc3w+/yD4P9tIRAsieAJ4wuSLw6d/aXZ/V9nnB9+MH7XqNMACglq4W WEuDB+x/97SmpaLjVlt5pGY= =zbpi -----END PGP SIGNATURE-----
Nov 04 2005
prev sibling parent reply John Demme <me teqdruid.com> writes:
Well, yes, but it shouldn't crash!  You'll notice that mmap2 returns -1,
signaling that it can't allocate that memory, then bigAlloc crumbles,
probably 'cause it's trying to do something with the -1 return value.

The real problem is that my application is somehow getting Mango to try to
allocate ~888mb of memory.  I'll look into that (seemingly separate issue)
and post on dsource.org, however.

~John

Kris wrote:

 Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas the
 desktop can?
 
 
 "John Demme" <me teqdruid.com> wrote in message
 news:dkeh21$25nl$1 digitaldaemon.com...
 For some reason, my program crashes on Linux on my notebook, but it works
 fine on Linux on my desktop.  Here's the gdb backtrace:








 Unfortunately, I've been unable to get the line number that this crashes
 on
 since gdb crashes on loading this particular program with it's compiled
 with the -g switch.  I'm gonna work on that one.

 Here's the code to reproduce it:
 void main() {
        void[] tmp = new void[1000000000];
 }

 So, in short: this code crashes *immediately* on my notebook, and runs on
 my
 desktop (but I kill it after a minute).

 So, this code is not particularly important, but one of my programs
 triggers
 this bug through mango.

 I have included the output from strace (which for those of you who don't
 know, it outputs all of the kernel calls and signals that a program...
 uhh... does)

 Any ideas?
 ~John Demme

 ---------------STRACE OUPUT-----------------------
 execve("./gcx", ["./gcx", "2"], [/* 53 vars */]) = 0
 uname({sys="Linux", node="neon", ...})  = 0
 brk(0)                                  = 0x805c000
 access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
 directory)
 open("/etc/ld.so.cache", O_RDONLY)      = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=85249, ...}) = 0
 mmap2(NULL, 85249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f64000
 close(3)                                = 0
 open("/lib/libpthread.so.0", O_RDONLY)  = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260A\0"..., 512)
 =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=142466, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
 =
 0xb7f63000
 mmap2(NULL, 332928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
 =
 0xb7f11000
 mmap2(0xb7f1f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0xd) = 0xb7f1f000
 mmap2(0xb7f21000, 267392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7f21000
 close(3)                                = 0
 open("/lib/libm.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p3\0\000"...,
 512) =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=161528, ...}) = 0
 mmap2(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
 =
 0xb7eee000
 mmap2(0xb7f0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x20) = 0xb7f0f000
 close(3)                                = 0
 open("/lib/libc.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000V\1\000"...,
 512)
 = 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=1232028, ...}) = 0
 mmap2(NULL, 1146096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
 0) =
 0xb7dd6000
 mprotect(0xb7ee7000, 27888, PROT_NONE)  = 0
 mmap2(0xb7ee8000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x111) = 0xb7ee8000
 mmap2(0xb7eec000, 7408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7eec000
 close(3)                                = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
 =
 0xb7dd5000
 mprotect(0xb7ee8000, 4096, PROT_READ)   = 0
 mprotect(0xb7f1f000, 4096, PROT_READ)   = 0
 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd56c0,
 limit:1048575,
 seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
 seg_not_present:0, useable:1}) = 0
 munmap(0xb7f64000, 85249)               = 0
 getpid()                                = 12691
 rt_sigaction(SIGRTMIN, {0xb7f19630, [], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_1, {0xb7f19780, [RTMIN], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_2, {0xb7f19960, [], 0}, NULL, 8) = 0
 rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbf88c888, 31, (nil), 0}) = 0
 open("/dev/urandom", O_RDONLY)          = 3
 read(3, "\327g\27 ", 4)                 = 4
 close(3)                                = 0
 brk(0)                                  = 0x805c000
 brk(0x807d000)                          = 0x807d000
 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0)
 = 0xb7cd5000
 rt_sigaction(SIGUSR1, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 rt_sigaction(SIGUSR2, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 mmap2(NULL, 1000013824, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0) = -1 ENOMEM (Cannot allocate memory)
 --- SIGSEGV (Segmentation fault)   0 (0) ---
 +++ killed by SIGSEGV +++
Nov 04 2005
parent "Kris" <fu bar.com> writes:
Right ~ it certainly shouldn't crash :-)

And Mango must be insane to attempt such a thing <g>. I'll go over to 
dsource ...

"John Demme" <me teqdruid.com> wrote in message 
news:dkglse$305i$1 digitaldaemon.com...
 Well, yes, but it shouldn't crash!  You'll notice that mmap2 returns -1,
 signaling that it can't allocate that memory, then bigAlloc crumbles,
 probably 'cause it's trying to do something with the -1 return value.

 The real problem is that my application is somehow getting Mango to try to
 allocate ~888mb of memory.  I'll look into that (seemingly separate issue)
 and post on dsource.org, however.

 ~John

 Kris wrote:

 Perhaps the laptop cannot allocate the 1 GB (virtual) space, whereas the
 desktop can?


 "John Demme" <me teqdruid.com> wrote in message
 news:dkeh21$25nl$1 digitaldaemon.com...
 For some reason, my program crashes on Linux on my notebook, but it 
 works
 fine on Linux on my desktop.  Here's the gdb backtrace:








 Unfortunately, I've been unable to get the line number that this crashes
 on
 since gdb crashes on loading this particular program with it's compiled
 with the -g switch.  I'm gonna work on that one.

 Here's the code to reproduce it:
 void main() {
        void[] tmp = new void[1000000000];
 }

 So, in short: this code crashes *immediately* on my notebook, and runs 
 on
 my
 desktop (but I kill it after a minute).

 So, this code is not particularly important, but one of my programs
 triggers
 this bug through mango.

 I have included the output from strace (which for those of you who don't
 know, it outputs all of the kernel calls and signals that a program...
 uhh... does)

 Any ideas?
 ~John Demme

 ---------------STRACE OUPUT-----------------------
 execve("./gcx", ["./gcx", "2"], [/* 53 vars */]) = 0
 uname({sys="Linux", node="neon", ...})  = 0
 brk(0)                                  = 0x805c000
 access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
 directory)
 open("/etc/ld.so.cache", O_RDONLY)      = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=85249, ...}) = 0
 mmap2(NULL, 85249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f64000
 close(3)                                = 0
 open("/lib/libpthread.so.0", O_RDONLY)  = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260A\0"..., 
 512)
 =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=142466, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
 0)
 =
 0xb7f63000
 mmap2(NULL, 332928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
 0)
 =
 0xb7f11000
 mmap2(0xb7f1f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0xd) = 0xb7f1f000
 mmap2(0xb7f21000, 267392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7f21000
 close(3)                                = 0
 open("/lib/libm.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p3\0\000"...,
 512) =
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=161528, ...}) = 0
 mmap2(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
 0)
 =
 0xb7eee000
 mmap2(0xb7f0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x20) = 0xb7f0f000
 close(3)                                = 0
 open("/lib/libc.so.6", O_RDONLY)        = 3
 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000V\1\000"...,
 512)
 = 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=1232028, ...}) = 0
 mmap2(NULL, 1146096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
 0) =
 0xb7dd6000
 mprotect(0xb7ee7000, 27888, PROT_NONE)  = 0
 mmap2(0xb7ee8000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_DENYWRITE, 3, 0x111) = 0xb7ee8000
 mmap2(0xb7eec000, 7408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED
 MAP_ANONYMOUS, -1, 0) = 0xb7eec000
 close(3)                                = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
 0)
 =
 0xb7dd5000
 mprotect(0xb7ee8000, 4096, PROT_READ)   = 0
 mprotect(0xb7f1f000, 4096, PROT_READ)   = 0
 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd56c0,
 limit:1048575,
 seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
 seg_not_present:0, useable:1}) = 0
 munmap(0xb7f64000, 85249)               = 0
 getpid()                                = 12691
 rt_sigaction(SIGRTMIN, {0xb7f19630, [], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_1, {0xb7f19780, [RTMIN], 0}, NULL, 8) = 0
 rt_sigaction(SIGRT_2, {0xb7f19960, [], 0}, NULL, 8) = 0
 rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbf88c888, 31, (nil), 0}) = 0
 open("/dev/urandom", O_RDONLY)          = 3
 read(3, "\327g\27 ", 4)                 = 4
 close(3)                                = 0
 brk(0)                                  = 0x805c000
 brk(0x807d000)                          = 0x807d000
 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0)
 = 0xb7cd5000
 rt_sigaction(SIGUSR1, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 rt_sigaction(SIGUSR2, {0xb7f1cbe0, ~[], 0}, NULL, 8) = 0
 mmap2(NULL, 1000013824, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0) = -1 ENOMEM (Cannot allocate memory)
 --- SIGSEGV (Segmentation fault)   0 (0) ---
 +++ killed by SIGSEGV +++
Nov 04 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
John Demme wrote:
 For some reason, my program crashes on Linux on my notebook, but it works
 fine on Linux on my desktop.
...
 Here's the code to reproduce it:
 void main() {
         void[] tmp = new void[1000000000];
 }
 
 So, in short: this code crashes *immediately* on my notebook, and runs on my
 desktop (but I kill it after a minute).
I just tried this on my WinXP laptop. It must be stuck in some sort of endless allocation loop, because it practically hung my system and by the time I was able to kill the process it had already allocated over a gig of virtual memory. Perhaps it crashed on your laptop because your swap drive there is smaller? Sean
Nov 03 2005