Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
November 04, 2005 bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
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 +++ |
November 04, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Demme | 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 +++ > |
November 04, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Demme | 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 |
November 04, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | 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
|
November 04, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
November 04, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | 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 +++
>>
|
November 05, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Demme | 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 +++ >>> > |
November 05, 2005 Re: bigAlloc Crashes on One of my machines | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly Attachments: | 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
|
Copyright © 1999-2021 by the D Language Foundation