AttributeError seen while running xeus-cpp

[anutosh491]

Hello All,

I maintain xeus-cpp, a Jupyter Kernel to run C++ code.

I am using it with the latest jupyter-server. I didn't see these errors a while back (probably I was using an older version back then) but lately I see this when running it with lab.

Here's a simple readme on how to build the project (shouldn't take more than a couple mins)

This is what I see

I 2025-02-07 10:46:10.431 ServerApp] Kernel started: 18797981-e048-453b-9e6a-12dbb7bb3684
clang version 19.1.6
Target: arm64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Users/anutosh491/micromamba/envs/xeus-cpp/bin
 "/Users/anutosh491/micromamba/envs/xeus-cpp/bin/xcpp" -cc1 -triple arm64-apple-macosx14.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name "<<< inputs >>>" -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=1 -target-sdk-version=14.4 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fbuiltin-headers-in-system-modules -fdefine-target-os-macros -target-cpu apple-m1 -target-feature +zcm -target-feature +zcz -target-feature +v8.4a -target-feature +aes -target-feature +altnzcv -target-feature +ccdp -target-feature +complxnum -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +fptoint -target-feature +fullfp16 -target-feature +jsconv -target-feature +lse -target-feature +neon -target-feature +pauth -target-feature +perfmon -target-feature +predres -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sb -target-feature +sha2 -target-feature +sha3 -target-feature +specrestrict -target-feature +ssbs -target-abi darwinpcs -debugger-tuning=lldb -fdebug-compilation-dir=/Users/anutosh491/work/xeus-cpp/build5/share/jupyter/kernels/xcpp20 -target-linker-version 951.9 -v -fcoverage-compilation-dir=/Users/anutosh491/work/xeus-cpp/build5/share/jupyter/kernels/xcpp20 -resource-dir /Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19 -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 -isystem /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -isystem /Library/Developer/CommandLineTools/usr/include -isystem "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)" -include new -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I /Users/anutosh491/micromamba/envs/xeus-cpp/include -internal-isystem /Users/anutosh491/micromamba/envs/xeus-cpp/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -std=c++20 -fdeprecated-macro -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-implicit-modules -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -fincremental-extensions -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o - -x c++ "<<< inputs >>>"
clang -cc1 version 19.1.6 based upon LLVM 19.1.6 default target arm64-apple-darwin23.5.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
ignoring duplicate directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/anutosh491/micromamba/envs/xeus-cpp/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Users/anutosh491/micromamba/envs/xeus-cpp/bin/../include/c++/v1
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
[E 2025-02-07 10:46:11.297 ServerApp] Uncaught exception in ZMQStream callback
    Traceback (most recent call last):
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 551, in _run_callback
        f = callback(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/jupyter_server/services/kernels/kernelmanager.py", line 600, in record_activity
        parent_msg_type = msg.get("parent_header", {}).get("msg_type", None)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AttributeError: 'NoneType' object has no attribute 'get'
[E 2025-02-07 10:46:11.300 ServerApp] Uncaught exception in zmqstream callback
    Traceback (most recent call last):
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 601, in _handle_events
        self._handle_recv()
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 630, in _handle_recv
        self._run_callback(callback, msg)
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 551, in _run_callback
        f = callback(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/jupyter_server/services/kernels/kernelmanager.py", line 600, in record_activity
        parent_msg_type = msg.get("parent_header", {}).get("msg_type", None)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AttributeError: 'NoneType' object has no attribute 'get'
Exception in callback BaseAsyncIOLoop._handle_events(25, 1)
handle: <Handle BaseAsyncIOLoop._handle_events(25, 1)>
Traceback (most recent call last):
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/tornado/platform/asyncio.py", line 202, in _handle_events
    handler_func(fileobj, events)
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 601, in _handle_events
    self._handle_recv()
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 630, in _handle_recv
    self._run_callback(callback, msg)
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/zmq/eventloop/zmqstream.py", line 551, in _run_callback
    f = callback(*args, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/python3.12/site-packages/jupyter_server/services/kernels/kernelmanager.py", line 600, in record_activity
    parent_msg_type = msg.get("parent_header", {}).get("msg_type", None)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
[I 2025-02-07 10:46:11.358 ServerApp] Connecting to kernel 18797981-e048-453b-9e6a-12dbb7bb3684.

[anutosh491]

That being said I obviously don't have issues while running stuff but thought of raising the above error.

[davidbrochart]

Thanks for reporting @anutosh491.
It seems that in your case the parent header is set to None. I don't know if that is valid, or if there shouldn't be any parent_header entry at all. I opened #1498.

[anutosh491]

Thanks for the fix !

[martinRenou]

I'm not sure about the fix, the parent_header should be there as it's part of the protocol https://jupyter-client.readthedocs.io/en/latest/messaging.html#parent-header

As stated in the docs:

_reply messages MUST have a parent_header

So IMO the fix should be in xeus-cpp which MUST provide a parent header in its reply message

[minrk]

It's definitely a bug in xeus-cpp, but clients should handle bugs like this reasonably gracefully, so I think the PR is correct. Plus, the PR is also only fixing the code to do what it already is trying to do (set msg_type to None if parent_header is unavailable), but it previously only handled the case where parent_header is undefined, not defined and None.

[anutosh491]

Thanks .

Yes, I think the Pr is not doing anything unintended and can be moved in.

[JohanMabille]

More context on this, there are two messages without parent header that can be sent by any xeus kernel on the iopub channel:

• the kernel starting message, which seems to have been there since the start of xeus; I cannot find its equivalent in ipykernel, I don't remember why we added it, and I don't even know if it is compliant with the protocol. @minrk Do you know if there was such a message in ipykernel before?
• the iopub_welcome message which is a valid message introduced in this JEP. This JEP was never implemented in ipykernel as far as I know, and it seems that the kernel protocol documentation has not been updated either.

Therefore, the server should accept an iopub message with no parent header if its topic is iopub_welcome (and maybe kernel_core.XXXX.startng, but not sure) and #1498 actually fixes a bug in jupyter_server. Maybe we could add a log if the parent header is missing and the topic is not iopub_welcome.

[minrk]

Yeah, I'm pretty sure we had a status message at kernel startup at some point, maybe when restarting? But yes, in general IOPub without a parent during startup does make sense in the protocol. This could be stream messages forwarding stderr, for example during debugging, and lacking a parent correctly communicates it was not caused by a request.

[anutosh491]

there are two messages without parent header that can be sent by any xeus kernel on the iopub channel

Yeah just realized that we see two warnings with respect to this as seen above, hence yeah there are 2 messages that need to be considered.

But yes, in general IOPub without a parent during startup does make sense in the protocol. This could be stream messages forwarding stderr, for example during debugging, and lacking a parent correctly communicates it was not caused by a request.

Hmm, this tells me that these 2 (kernel_start & iopub welcome) are not the only ones where we expect an empty parent header. Which means we don't really need to handle them differently as was proposed above ( "Maybe we could add a log if the parent header is missing and the topic is not iopub_welcome.")

So I guess we're done here ? cc @JohanMabille
i) #1498 fixes it for the server
ii) And we don't really need to handle anything for xeus as not having a parent header for iopub is compatible with the protocol.

[JohanMabille]

Yes I think this can be closed

[anutosh491]

Thanks closing it on xeus-cpp's side too
Where we had raised an issue to keep track on any changes required on the xeus side.