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.

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

Function as data breaks in threading block #14343

Closed
jnkh opened this issue Dec 10, 2015 · 3 comments
Closed

Function as data breaks in threading block #14343

jnkh opened this issue Dec 10, 2015 · 3 comments
Labels
domain:multithreading Base.Threads and related functionality

Comments

@jnkh
Copy link

jnkh commented Dec 10, 2015

When functions are used as data inside a threading block, it (occasionally) results in a segmentation fault. When the same function is called as a locally defined function, the program runs smoothly.

Here is a minimal example illustrating this. We are calling the function fn(x) in two different ways. Once as is, and once as a data component of a type. It breaks only in the second case.

using Base.Threads

type CarryFunction
    fn::Function
end

alpha = 0.1
fn(x) = alpha*x

function use_anonymous(N::Int, c::CarryFunction)
    a = zeros(N)
    @threads all for i in 1:length(a)
        # a[i] = fn(i) #NO SEGFAULT
        a[i] = c.fn(i) #SEGFAULT (sometimes... but not always!)
    end
    println(a[1],a[end])
end

length = 10000
repetitions = 100
for j = 1:repetitions
    use_anonymous(length,CarryFunction(fn))
end
@yuyichao
Copy link
Contributor

I can't reproduce on #14190 . There where some similar segfaults that I pushed separately so your particular problem might already be fixed on master. Note that you also need to remove the all parameter to the @thread macro now.

@yuyichao yuyichao added the domain:multithreading Base.Threads and related functionality label Dec 10, 2015
@JeffBezanson
Copy link
Sponsor Member

Possibly dup of #11857

@yuyichao
Copy link
Contributor

Likely but hard to tell since none of these have backtraces.......

At least this one is probably reproducible on a more recent master?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:multithreading Base.Threads and related functionality
Projects
None yet
Development

No branches or pull requests

3 participants