Stream: git-wasmtime

Topic: wasmtime / Issue #1318 Remove FPR32; fixes #1303


view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:04):

abrown commented on Issue #1318:

Yeah, I know! I'll keep looking at #1306 but I wanted to avoid having a bug in master for too long.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:17):

abrown commented on Issue #1318:

@alexcrichton, any idea what https://github.com/bytecodealliance/wasmtime/pull/1318/checks?check_run_id=506812657#step:9:4117 means? thread '<unnamed>' panicked at 'trampoline compilation should not produce external symbol relocs', crates/jit/src/compiler.rs:434:9

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:33):

alexcrichton commented on Issue #1318:

Oh dear that sounds like another bug! I haven't run into that, but I can try to dig in.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:39):

abrown commented on Issue #1318:

Good thing we have fuzzing...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:44):

alexcrichton commented on Issue #1318:

Hm ok, so it looks like that condition may still be necessary. It looks like the trampoline is so big it needs the probestack libcall as a relocation, but we assert trampolines don't need relocations. Mind adding the smaller 17-f32-argument test in and leaving that condition in? That way we should still assert this bug at least is fixed and I can get to the other when I get a chance.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:46):

abrown commented on Issue #1318:

Sure, I guess we should open another bug for that specific issue and change the FIXME text to point to that?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:47):

alexcrichton commented on Issue #1318:

Sounds good to me!

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:06):

abrown commented on Issue #1318:

I think this is failing for the same reason as #1319, some cc link error.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:07):

abrown edited a comment on Issue #1318:

I think this is failing for the same reason as #1319--some cc link error--not an actual issue with this PR.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:14):

iximeow commented on Issue #1318:

Where do you see a cc error? I'm seeing

git checkout --progress --force ea9bfb97b4eb6b5dca08bc3de09a83de59245601
##[error]fatal: reference is not a tree: ea9bfb97b4eb6b5dca08bc3de09a83de59245601
Removed matchers: 'checkout-git'
##[error]Git checkout failed with exit code: 128
##[error]Exit code 1 returned from process: file name '/home/runner/runners/2.165.2/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Repository.v1_0.CheckoutTask, Runner.Plugins"'.

in all the logs, which make me wonder if GitHub is feeling okay? How would that commit be missing? But a cc error earlier on might result in the repo disappearing?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:16):

abrown commented on Issue #1318:

No, you're right... this is different. Hm...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:17):

abrown commented on Issue #1318:

Well, I guess the same thing happened on #1319; first I saw a cc error and after re-running all of the actions now I see a Git failure...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:41):

iximeow commented on Issue #1318:

FWIW I have since seen The cc Error: https://github.com/bytecodealliance/wasmtime/runs/507019811 - my intuition is that our build might hit a disk space limit where cc fails on writing out artifacts? I'm a bit sensitive to that specific cause from dealing with it locally.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 17 2020 at 10:58):

github-actions[bot] commented on Issue #1318:

Subscribe to Label Action

This issue or pull request has been labeled: "cranelift", "cranelift:meta"

<details> <summary>Users Subscribed to "cranelift"</summary>

</details>

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.


Last updated: Dec 23 2024 at 12:05 UTC