Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

segfault on trying to allocate too much memory #146

Closed
zingales opened this issue Jul 22, 2011 · 5 comments
Closed

segfault on trying to allocate too much memory #146

zingales opened this issue Jul 22, 2011 · 5 comments
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@zingales
Copy link
Contributor

rand(1000,1000,1000)
Segmentation fault
JeffBezanson added a commit that referenced this issue Jul 22, 2011
@JeffBezanson
fixing issue #146, out of memory error
9b0a342
StefanKarpinski added a commit that referenced this issue Jul 22, 2011
@StefanKarpinski
Merge branch 'master' of github.com:JuliaLang/julia
b5958c6 
* 'master' of github.com:JuliaLang/julia:
  fixing issue #144, handling None better
  fixing issue #137 disable rint, nearbyint, and lrint call lround iround in a previous commit I added trunc, floor, and ceil for integers
  a DGC tweak, and making temp vars local in timing macros
  removing color profile tags from images so firefox doesn't mess up the colors
  fixing issue #146, out of memory error
  fixing regression in reinterpret()
  how the hell did i delete the makefile in my previous commit?
  new web terminal design
  important fix to the message latency fix. the timing is now done in a separate thread so messages can't be delayed by compute tasks.
  Actually fixed permute (for Tensors n>2 dimensions), and fixed ipermute (which uses permute)
  limiting memory/cpu usage and number of active sessions for robustness
  Improved the tensor.j find command, fixed the permute function. Ipermute still needs to be fixed
  no longer crashes if thread creation fails
  better handling of expired sessions
  server no longer crashes when users call exit()
@StefanKarpinski
Copy link
Member

Actually, I still get a segfault:

julia> rand(1000,1000,1000)
zsh: segmentation fault  julia

@JeffBezanson
Copy link
Member

Some kernels might handle this differently, raising SEGV instead of returning NULL from malloc. Can you see if the segfault happens inside malloc?

@StefanKarpinski
Copy link
Member

Here's what I get in gdb:

(gdb) r -e 'rand(10000,10000,10000)'
Starting program: /Users/stefan/projects/julia/julia -e 'rand(10000,10000,10000)'
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000552a7420
0x0000000101afd241 in dsfmt_fill_array_open_open ()
(gdb) bt
#0  0x0000000101afd241 in dsfmt_fill_array_open_open ()
#1  0x0000000101f2fb60 in ?? ()
#2  0x0000000101f2f957 in ?? ()
#3  0x000000010006e0bc in jl_apply (f=0x11654a8c8, args=0x7fff5fbfc570, nargs=1) at julia.h:731
#4  0x0000000100070b24 in jl_trampoline (env=0x11654a8e8, args=0x7fff5fbfc570, nargs=1) at builtins.c:953
#5  0x00000001000684dc in jl_apply (f=0x11654a8c8, args=0x7fff5fbfc570, nargs=1) at julia.h:731
#6  0x0000000100069e14 in jl_apply_generic (env=0x115aaeac0, args=0x7fff5fbfc570, nargs=1) at gf.c:1096
#7  0x0000000101f2d601 in ?? ()
#8  0x000000010006e0bc in jl_apply (f=0x116533ba8, args=0x7fff5fbfc738, nargs=3) at julia.h:731
#9  0x0000000100070b24 in jl_trampoline (env=0x116533bc8, args=0x7fff5fbfc738, nargs=3) at builtins.c:953
#10 0x00000001000684dc in jl_apply (f=0x116533ba8, args=0x7fff5fbfc738, nargs=3) at julia.h:731
#11 0x0000000100069e14 in jl_apply_generic (env=0x115aaeac0, args=0x7fff5fbfc738, nargs=3) at gf.c:1096
#12 0x00000001000a208c in jl_apply (f=0x115bf8fe8, args=0x7fff5fbfc738, nargs=3) at julia.h:731
#13 0x00000001000a2022 in do_call (f=0x115bf8fe8, args=0x118f3ed70, nargs=3, locals=0x0, nl=0) at interpreter.c:40
#14 0x00000001000a22f6 in eval (e=0x116533b88, locals=0x0, nl=0) at interpreter.c:78
#15 0x00000001000a2bb9 in eval_body (stmts=0x118f5e6d0, locals=0x0, nl=0, start=0) at interpreter.c:195
#16 0x00000001000a2687 in eval (e=0x116533b48, locals=0x0, nl=0) at interpreter.c:119
#17 0x00000001000a1e9f in jl_interpret_toplevel_expr (e=0x116533b48) at interpreter.c:21
#18 0x000000010006e377 in jl_toplevel_eval_flex (ex=0x116533b48, fast=1) at builtins.c:276
#19 0x000000010006e53a in jl_toplevel_eval (v=0x116533b48) at builtins.c:314
#20 0x000000010006ed21 in jl_f_top_eval (env=0x0, args=0x7fff5fbfccc0, nargs=1) at builtins.c:446
#21 0x0000000101f23f83 in ?? ()
#22 0x000000010006e0bc in jl_apply (f=0x1142ba768, args=0x7fff5fbfd020, nargs=1) at julia.h:731
#23 0x0000000100070b24 in jl_trampoline (env=0x1142ba788, args=0x7fff5fbfd020, nargs=1) at builtins.c:953
#24 0x00000001000684dc in jl_apply (f=0x1142ba768, args=0x7fff5fbfd020, nargs=1) at julia.h:731
#25 0x0000000100069e14 in jl_apply_generic (env=0x1140f5198, args=0x7fff5fbfd020, nargs=1) at gf.c:1096
#26 0x0000000101f1de55 in ?? ()
#27 0x000000010006e0bc in jl_apply (f=0x114383c28, args=0x0, nargs=0) at julia.h:731
#28 0x0000000100070b24 in jl_trampoline (env=0x114383c48, args=0x0, nargs=0) at builtins.c:953
#29 0x00000001000684dc in jl_apply (f=0x114383c28, args=0x0, nargs=0) at julia.h:731
#30 0x0000000100069e14 in jl_apply_generic (env=0x1140f7f88, args=0x0, nargs=0) at gf.c:1096
#31 0x00000001000018bc in jl_apply (f=0x114380b88, args=0x0, nargs=0) at julia.h:730
#32 0x0000000100001b90 in true_main (argc=2, argv=0x7fff5fbfd3f8) at repl.c:357
#33 0x00000001000a7c58 in julia_trampoline (argc=2, argv=0x7fff5fbfd3f8, pmain=0x1000018c0 <true_main>) at init.c:204
#34 0x0000000100001c21 in main (argc=2, argv=0x7fff5fbfd3f8) at repl.c:369

So it actually looks like malloc is bogusly returning. Bad Darwin.

@JeffBezanson
Copy link
Member

Oh wow, segv on access. It doesn't seem like there's anything we could do about this. Except add a release note.

@StefanKarpinski
Copy link
Member

Yeah, agreed. It's very bad behavior on the part of OS X.

StefanKarpinski pushed a commit that referenced this issue Feb 8, 2018
@andreasnoack
Merge pull request #146 from JuliaLang/anj/remote
9a64b37 
Add compatibillity for argument changes to remotecall functions
KristofferC added a commit that referenced this issue Feb 21, 2018
@KristofferC
Merge pull request #146 from JuliaLang/kc/checkout
928223e 
implement checkout
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Oct 11, 2021
@andreasnoack
Merge pull request JuliaLang#146 from nalimilan/fitstats
afa33d6 
WIP: Add fit statistics functions and document existing ones
Keno pushed a commit that referenced this issue Oct 9, 2023
@KristofferC
work around problem with finding stdlib files (#146)
c0a3c75 
* work around problem with finding stdlib files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@StefanKarpinski @JeffBezanson @zingales