Kernel/process dies without error with 0.8

[binste]

When saving a chart with VLC 0.8, my Jupyter Kernel dies without an error:

The same happens when running the test suite in Altair, see "trace trap":

Both things work with VLC 0.7. The result is the same for both the Altair master branch which is still on Vega-Lite 5.6 and this branch where we updated to 5.7

It's a long shot but see my comment here on the vega-lite 5.7 schema not being available for a few hours.

This is on Debian Bullseye with Python 3.11 (docker image: mcr.microsoft.com/vscode/devcontainers/python:0-3.11-bullseye).

[jonmmease]

Thanks for the report. I'll take a look to see if the schema was the issue. I also updated Deno and a few other Rust dependencies in this release, so it's possible we're hitting a regression there. I can downgrade Deno in the short term if necessary, but I may not be able to look at it until tomorrow.

[binste]

No worries, thanks for looking into it!

[jonmmease]

Is this happening for you for every example you try? If so that's a bit puzzling since we run several examples on Linux on CI.

[binste]

Yes, I tried 5 random examples from the Altair gallery, some using vega_datasets and some a pandas dataframe and it happened for all of them.

[binste]

When running it as a Python script I get somewhat of an error:

The following saved as save_chart.py

import altair as alt
import pandas as pd

source = pd.DataFrame({
    'a': ['A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I'],
    'b': [28, 55, 43, 91, 81, 53, 19, 87, 52]
})

chart = alt.Chart(source).mark_bar().encode(
    x='a',
    y='b'
)

chart.save("chart.png", engine="vl-convert")

When executing python save_chart.py I get:

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xffff9a298ea0
==== C stack trace ===============================

    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x104d8f4) [0xffff9b2ed8f4]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x7d91f8) [0xffff9aa791f8]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x10464f4) [0xffff9b2e64f4]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xd06210) [0xffff9afa6210]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc21c40) [0xffff9aec1c40]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc23e30) [0xffff9aec3e30]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc1da14) [0xffff9aebda14]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc1e4dc) [0xffff9aebe4dc]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc1da14) [0xffff9aebda14]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc1e974) [0xffff9aebe974]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc1e250) [0xffff9aebe250]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc29250) [0xffff9aec9250]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc30844) [0xffff9aed0844]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x887390) [0xffff9ab27390]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x887938) [0xffff9ab27938]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0xc2e86c) [0xffff9aece86c]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x7fc2c4) [0xffff9aa9c2c4]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x7fc3e8) [0xffff9aa9c3e8]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x2736d0) [0xffff9a5136d0]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x40ed0c) [0xffff9a6aed0c]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x405a24) [0xffff9a6a5a24]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x6875e8) [0xffff9a9275e8]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x67f250) [0xffff9a91f250]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x690860) [0xffff9a930860]
    /home/vscode/.local/lib/python3.11/site-packages/vl_convert/vl_convert.cpython-311-aarch64-linux-gnu.so(+0x5d44a0) [0xffff9a8744a0]
    /lib/aarch64-linux-gnu/libpthread.so.0(+0x7648) [0xffffab736648]
    /lib/aarch64-linux-gnu/libc.so.6(+0xd2c1c) [0xffffab832c1c]
[1]    10400 trace trap  python save_chart.py

This is still in the debian container. In case it helps, the underlying machine is a Macbook with an M2 chip.

[binste]

Same error when going to Python 3.10. But it works if I use a GitHub Codespace so maybe there is some relation of the bug to the m2 architecture.

[jonmmease]

So just to clarify, you're seeing the error in the mcr.microsoft.com/vscode/devcontainers/python:0-3.11-bullseye docker image running on MacOS with an m2? I should be able to repro that.

[binste]

Exactly, that's the setup where I get the error.

[jonmmease]

Here's what I've found so far. When you create a docker image based on mcr.microsoft.com/vscode/devcontainers/python:0-3.11-bullseye on Apple Silicon, by default you get the aarch64 build of the image. When you then install vl-convert-python from PyPI, it pulls down the aarch64 wheel (as expected). Calling vl-convert in this scenario results in the error.

This wheel is generated on CI from an x64 architecture linux image, cross compiled using Rust/maturin. If I build vl-convert from source inside the aarch64 container, it works without an error. So maybe something about this cross-compilation process breaks with the deno update.

Are you seeing this same error in Altair's CI? This wouldn't have the cross compilation component, so if there is the same error then something else might be going on as well.

[binste]

The Altair CI is not affected by this. We have some other errors there but I do 't think they are caused by vl-convert but by Altair producing incompatible specs in some cases.

[jonmmease]

It should be fixed in 0.8.1. Could you give it a try and let me know?

[binste]

Awesome, I can confirm that 0.8.1 resolves it. Thank you!