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:

#0  0x08052fb3 in gcx.Gcx.bigAlloc(uint) ()
#1  0x08052434 in gcx.GC.mallocNoSync(uint) ()
#2  0x080522d7 in gcx.GC.malloc(uint) ()
#3  0x0804e7fb in _d_new ()
#4  0x0804b522 in D main () at gcx.d:2
#5  0x0804b59f in main ()

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 +++

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:
>
> #0  0x08052fb3 in gcx.Gcx.bigAlloc(uint) ()
> #1  0x08052434 in gcx.GC.mallocNoSync(uint) ()
> #2  0x080522d7 in gcx.GC.malloc(uint) ()
> #3  0x0804e7fb in _d_new ()
> #4  0x0804b522 in D main () at gcx.d:2
> #5  0x0804b59f in main ()
>
> 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 +++
> 

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

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

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

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:
>>
>> #0  0x08052fb3 in gcx.Gcx.bigAlloc(uint) ()
>> #1  0x08052434 in gcx.GC.mallocNoSync(uint) ()
>> #2  0x080522d7 in gcx.GC.malloc(uint) ()
>> #3  0x0804e7fb in _d_new ()
>> #4  0x0804b522 in D main () at gcx.d:2
>> #5  0x0804b59f in main ()
>>
>> 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 +++
>>

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:
>>>
>>> #0  0x08052fb3 in gcx.Gcx.bigAlloc(uint) ()
>>> #1  0x08052434 in gcx.GC.mallocNoSync(uint) ()
>>> #2  0x080522d7 in gcx.GC.malloc(uint) ()
>>> #3  0x0804e7fb in _d_new ()
>>> #4  0x0804b522 in D main () at gcx.d:2
>>> #5  0x0804b59f in main ()
>>>
>>> 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 +++
>>>
> 

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.

# import std.stdio;
#
# int main(){
#	uint[] tmp = new uint[100_000_000];
#	uint x = 0;
#
#	uint len = tmp.length;
#	for(uint i=0; i<len; i++){
#		tmp[i]=i;
#	}
#
#	writefln("%s %s\n", tmp[$-2], tmp[$-1]);
#	return 0;
# }

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