Skip to content

Using Chan from a thread created from a c library crashes after sometime #12391

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

Closed
arturoc opened this issue Feb 19, 2014 · 6 comments · Fixed by #12397
Closed

Using Chan from a thread created from a c library crashes after sometime #12391

arturoc opened this issue Feb 19, 2014 · 6 comments · Fixed by #12397
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@arturoc
Copy link
Contributor

arturoc commented Feb 19, 2014

Reporting this here after asking in IRC

something like this:

spawn(proc(){    
    let (port,chan): (comm::Port<Message>, comm::Chan<Message>) = comm::Chan::new();
    let mut chan = ~chan;
    set_c_callback(c_callback, cast::transmute(&mut *chan));
});

extern "C" fn c_callback (data: *c_void){
    unsafe{
    let channel = data as *mut comm::Chan<Message>;
        (*channel).send(MessageType);
    }
}

where c_callback is called from a thread created by the c library crashes the application after a while with:

fatal runtime error: assertion failed: !ptr.is_null()

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffd7fff700 (LWP 28971)]
0x0000000000483d4b in rt::util::abort::h66e24f48938afe6eMim::v0.10.pre ()
(gdb) bt
#0 0x0000000000483d4b in rt::util::abort::h66e24f48938afe6eMim::v0.10.pre ()
#1 0x00000000007b73d1 in rt::local_ptr::compiled::take::he8a5e3f0ec45f53amAs::v0.1 ()
#2 0x00000000007c7778 in comm::Chan$LT$T$GT$::send::hfedc51b572bd5818fot::v0.1 ()
...

previously SharedChan seemed to work without problem

@huonw
Copy link
Member

huonw commented Feb 19, 2014

cc @alexcrichton

It looks like the new std::comm can no longer be used outside a runtime?

@alexcrichton
Copy link
Member

Whoops, testing a fix now (sorry about that!)

bors added a commit that referenced this issue Feb 20, 2014
The fairness yield mistakenly called `Local::take()` which meant that it would
only work if a local task was available. In theory sending on a channel (or calling try_recv) requires
no runtime because it never blocks, so there's no reason it shouldn't support
such a use case.

Closes #12391
@arturoc
Copy link
Contributor Author

arturoc commented Feb 20, 2014

thanks!

@arturoc
Copy link
Contributor Author

arturoc commented Feb 21, 2014

sorry to post on a closed issue, but i'm finding the same problem now in SyncChan/SyncPort not sure if it's a real bug or in this case it's supposed to work like that?

@alexcrichton
Copy link
Member

You won't be able to use those off the runtime because a send involves then receiving which blocks the task. You're only able to block if you have a local rust task available.

@arturoc
Copy link
Contributor Author

arturoc commented Feb 23, 2014

that's what i was suspecting, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants