Skip to content
This repository has been archived by the owner on Mar 4, 2019. It is now read-only.

Compiled hello.jl hangs #46

Open
jacob-ruth opened this issue Nov 21, 2017 · 3 comments
Open

Compiled hello.jl hangs #46

jacob-ruth opened this issue Nov 21, 2017 · 3 comments

Comments

@jacob-ruth
Copy link

jacob-ruth commented Nov 21, 2017

Hi- I'm fairly new to Julia but have been having an issue with compiling static julia.
my hello.jl:

module Hello
Base.@ccallable function julia_main(ARGS::Vector{String})::Cint
    n = parse(Int, readline(STDIN))
    i :: UInt64 = 0
    while i < n
        i = i + 1
        println(i)
    end
    return 0;
end
end

which prints the numbers from 1 to n as expected when called from Julia. However, when compiling this and running it, it will hang at some large number (the number it hangs at is the same every time it is run after being compiled, but changes when recompiled).

I don't think it is an IO issue, since another program which did more work in the loop, but did not print anything was also hanging.

This was compiled with Julia version 0.6.1

@NHDaly
Copy link
Contributor

NHDaly commented Jan 31, 2018

Huh, yeah for me it behaves very similarly, but it segfaults instead of hanging. (I'm on macOS 10.13.3, julia v0.6.2)

164454
164455
164456
164457

signal (11): Segmentation fault: 11
while loading no file, in expression starting on line 0
gc_push_root at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_mark_stack at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_scan_obj_ at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_push_root at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
...
gc_scan_obj_ at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_push_root at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_mark_module at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_scan_obj_ at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_push_root at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_mark_module at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_scan_obj_ at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
gc_push_root at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
_jl_gc_collect at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
jl_gc_collect at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
jl_gc_pool_alloc at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
jl_gc_alloc at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
jl_alloc_string at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/libjulia.dylib (unknown line)
dec at /Users/daly/src/static-julia/builddir/libhello.dylib (unknown line)
print at ./show.jl:261
unknown function (ip: 0x11ac57099)
print at ./strings/io.jl:40
julia_main at /Users/daly/src/static-julia/builddir/libhello.dylib (unknown line)
julia_main at /Users/daly/src/static-julia/builddir/libhello.dylib (unknown line)
main at /Users/daly/src/static-julia/./builddir/hello (unknown line)
Allocations: 2321417 (Pool: 2320272; Big: 1145); GC: 0
[2]    40575 segmentation fault  ./builddir/hello

For me, it seems like which number it segfaults on is more dependent on how I invoke it than on recompiling:

$ ./builddir/hello
1844674407370955161
...
164457

$ echo 1844674407370955161 | ./builddir/hello
164468

the numbers always seemed to be around 164,000:
164457
163977
164468

And, of course, calling this method from the julia REPL directly works just fine.

@NHDaly
Copy link
Contributor

NHDaly commented Jan 31, 2018

Based on the segfault, it looks like the error is something to do with attempting to allocate and then print the string.

And, in fact, I can verify that it works just fine if the print statement is moved to after the while loop:

$echo 164468 | ./builddir/hello
164468
$ ./builddir/hello
164457
164457
$ echo 174457000000 | ./builddir/hello   # even for very big numbers.
174457000000

@NHDaly
Copy link
Contributor

NHDaly commented Jan 31, 2018

And I guess the failing call to dec comes from the println, which makes sense.

[1] dec(x) at intfuncs.jl:597
  | x::Int64 = 2
[2] show(io, n) at show.jl:259
  | io::Base.TTY = Base.TTY(RawFD(14) open, 0 bytes waiting)
  | n::Int64 = 2
[3] print(io, x) at strings/io.jl:27
  | io::Base.TTY = Base.TTY(RawFD(14) open, 0 bytes waiting)
  | x::Int64 = 2
  | #temp#::Bool = false
[4] print(io, xs) at strings/io.jl:37
  | io::Base.TTY = Base.TTY(RawFD(14) open, 0 bytes waiting)
  | xs::Tuple{Int64,Char} = (2, '\n')
  | x::Int64 = 2
  | #temp#::Int64 = 2
  | #temp#::Bool = false
[5] println(io, xs) at strings/io.jl:54
  | io::Base.TTY = Base.TTY(RawFD(14) open, 0 bytes waiting)
  | xs::Tuple{Int64} = (2,)
[6] println(xs) at coreio.jl:5
  | xs::Tuple{Int64} = (2,)

I guess for some reason it's messing up when trying to alloc so many strings so quickly... Looks like a bug, but I wouldn't know where to look.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants