Get IPC protocol working #15
Comments
|
This is a catch-all handler, the exception can come from anywhere; do you have more detail, like the error message and/or the stacktrace? |
|
The only message is: I commented out the catch block and ran it in gdb, and then the stacktrace is: |
|
This is really weird, this means that the thread is not joinable. I've built and run an IPC kernel and IPC client on my machine, it seems to work (thoses added in #16). Can you try #17 and tell me if this fixes the issue (and also the output it gives)? |
|
Ok so actually there is an issue in the destructor implementation, and it always throws when the kernel shutdowns. However it is unrelated to having the IPC protocol working. you can In the meantime I'm gonna release a fix for the destructor issue. |
|
@JohanMabille , thanks for the info. It's a busy week for me, but I'll start poking around to this a bit more next week. |
|
@JohanMabille , sorry for the delay. I finally got a chance to poke at this a bit more. I wasn't able to get as far as a more complete logger, because the crash happens before that. I was able to comment out some catch blocks and get a stack trace though. Does this help narrow anything down at all? For more background, I'm trying to use the LFortran kernel, testing on an Arch Linux machine with the latest gcc (13.1.1). Let me know if there are additional details you'd like. |
|
@everythingfunctional sorry for the delay too, these last weeks have been quite intense. It definitely helps narrowing things, although I really don't understand why it would fail here. I cannot reproduce such a failure with the tiny ipc kernel test I have added to the main branch. Can you dump the connection file passed to the kernel? Also can you indicate with versions of cppzmq and zeromq you are using (although I guess these are automatically pulled by xeus-zmq when you create you environment)? |
|
Sorry for again taking so long to get back to this.
It looks like this: {
"shell_port": 1,
"iopub_port": 2,
"stdin_port": 3,
"control_port": 4,
"hb_port": 5,
"ip": "/home/brad/.local/share/jupyter/runtime/kernel-187920-ipc",
"key": "a33beb30-0a4ad868b05a6ca13f87e6b7",
"transport": "ipc",
"signature_scheme": "hmac-sha256",
"kernel_name": "fortran"
}I'll note that I'm running jupyter like
I'm building xeus and xeus-zmq from source (latest main) and going to try poking around a bunch more with the debugger this week. |
|
Ok, now I think I've gotten somewhere interesting, but now I don't know what to look at next. I compiled libzmq from source too and using the debugger got all the way down into it to here, which has: int zmq::do_getsockopt (void *const optval_,
size_t *const optvallen_,
const void *value_,
const size_t value_len_)
{
// TODO behaviour is inconsistent with options_t::getsockopt; there, an
// *exact* length match is required except for string-like (but not the
// CURVE keys!) (and therefore null-ing remaining memory is a no-op, see
// comment below)
if (*optvallen_ < value_len_) {
return sockopt_invalid ();
}
memcpy (optval_, value_, value_len_);
// TODO why is the remaining memory null-ed?
memset (static_cast<char *> (optval_) + value_len_, 0,
*optvallen_ - value_len_);
*optvallen_ = value_len_;
return 0;
}with and At that point it returns Now that I know where the exception/error originates from, any ideas how/what to look at in terms of why it's an error? |
|
Any chance anyone has looked at this at all? @JohanMabille |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'd like to get the ipc protocol working so that we can make use of more Jupyter kernels in an environment where the tcp protocol is considered to not be sufficiently secure. I've managed to find where an exception is being caught (it's here). Would anybody know where it might be coming from, what the cause might be, or possibly how to fix the problem? I'm happy to make the fix if anybody could help point me in the right direction.
The text was updated successfully, but these errors were encountered: