Bug: memory allocation of 9223372036854775807 bytes failed

[pcaversaccio]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (7545c7a 2024-03-12T00:16:54.294788023Z)

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

See CI run here:

memory allocation of 9223372036854775807 bytes failed
Aborted (core dumped)
 ELIFECYCLE  Test failed. See above for more details.
Error: Process completed with exit code 1.

I haven't changed the tests for 3 months, except for that PR pcaversaccio/createx#90 which raises now with that error.

[mattsse]

hmm, I'm unable to reproduce this locally.

couldn't locate where this overflow before allocating might have happened.

could you perhaps rerun with RUST_LOG=trace

[pcaversaccio]

hmm, I'm unable to reproduce this locally.

couldn't locate where this overflow before allocating might have happened.

could you perhaps rerun with RUST_LOG=trace

I can't reproduce this error locally neither. I only face it in the CI, unfortunately. 3 hrs ago I pushed a commit that passed the tests (cf. pcaversaccio/createx@5811b5a). So there happened something in between...

[pcaversaccio]

Let me try locally using RUST_LOG=trace and with the same CI run params for the fuzz and invariant tests. Maybe I can reproduce like that...

[onbjerg]

Can you try rerunning the CI? I'm wondering if this is maybe a fuzz or invariant test allocating a crazy big type?

[pcaversaccio]

Can you try rerunning the CI? I'm wondering if this is maybe a fuzz or invariant test allocating a crazy big type?

Rerunning here:

• https://github.com/pcaversaccio/createx/actions/runs/8251331509?pr=90
• https://github.com/pcaversaccio/createx/actions/runs/8251324345?pr=90

[onbjerg]

Looks to have completed successfully (no core dump), albeit with failing tests. Am I reading correctly?

[pcaversaccio]

Looks to have completed successfully (no core dump), albeit with failing tests. Am I reading correctly?

It looks like this indeed but maybe it just didn't get there due to an early revert due to the failing test (which has never failed until now; maybe time for an additional assume lol). But let me rerun it, because it might be simply bad luck (again)...

[mattsse]

the error looks like a classic allocate capacity with underflow error, but I was unable to identify where

[pcaversaccio]

the error looks like a classic allocate capacity with underflow error, but I was unable to identify where

Still running locally to see if I can reproduce. This so weird really. Merged my PR in the meantime and you know what, it fucking passed: https://github.com/pcaversaccio/createx/actions/runs/8252329302/job/22571561906. I HATE SOFTWARE :)

[onbjerg]

What would you identify as the largest fuzz/invariant tests in the code base? Might be worth trying to narrow down if it's one of the generators

We should probably log the fuzz seed so this is more easily reproducible

[pcaversaccio]

What would you identify as the largest fuzz/invariant tests in the code base? Might be worth trying to narrow down if it's one of the generators

We should probably log the fuzz seed so this is more easily reproducible

https://github.com/pcaversaccio/createx/blob/main/foundry.toml#L21

10_000 for fuzz and 5_000 for invariant tests

[pcaversaccio]

What would you identify as the largest fuzz/invariant tests in the code base? Might be worth trying to narrow down if it's one of the generators
We should probably log the fuzz seed so this is more easily reproducible

https://github.com/pcaversaccio/createx/blob/main/foundry.toml#L21

10_000 for fuzz and 5_000 for invariant tests

I tried reproduce the bug locally using these params but no luck. Maybe it's just a crazy weird edge case tbh, idk. If you think it's too hard to figure out the issue with the limited data we have, I can close it and reopen again later if I face it again? Thoughts?

[mattsse]

sg!
thanks

[grandizzy]

We should probably log the fuzz seed so this is more easily reproducible

No need since we have #7336 :) just make sure you save the failure file somewhere in CI and download locally to replay (if that's a fuzzed test failing)

[onbjerg]

@grandizzy does this work even if forge ooms?

[grandizzy]

@grandizzy does this work even if forge ooms?

obviously it doesn't :D nm

[pcaversaccio]

Just faced another overflow bug here: #7394