rust 1.62.1 version update

[Anton-4]

• updated version where necessary
• fmt changes
• clippy changes

[Anton-4]

I'm able to reproduce the false interpreter failure locally:

❯ ./examples/false-interpreter/false ./examples/false-interpreter/examples/hello.false 
Hello, World!
Segmentation fault (core dumped)

❯ valgrind --leak-check=full --track-origins=yes examples/false-interpreter/false examples/false-interpreter/examples/hello.false
==11792== Memcheck, a memory error detector
==11792== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==11792== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==11792== Command: examples/false-interpreter/false examples/false-interpreter/examples/hello.false
==11792== 
Hello, World!
==11792== 
==11792== HEAP SUMMARY:
==11792==     in use at exit: 55 bytes in 1 blocks
==11792==   total heap usage: 68 allocs, 67 frees, 15,238 bytes allocated
==11792== 
==11792== 55 bytes in 1 blocks are definitely lost in loss record 1 of 1
==11792==    at 0x484679B: malloc (in /nix/store/73if83n79h4ml8rcb473ym47zmb4vi5x-valgrind-3.19.0/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==11792==    by 0x1206D2: ??? (in /home/anton/gitrepos/roc5/roc/examples/false-interpreter/false)
==11792==    by 0x1FFEFF21D7: ???
==11792==    by 0x692D65736C61662E: ???
==11792==    by 0x746572707265746D: ???
==11792==    by 0x65736C61662F7264: ???
==11792==    by 0x656C706D617864FF: ???
==11792==    by 0x2D65736C61662F72: ???
==11792==    by 0x6572707265746E68: ???
==11792==    by 0x6D6178652F726573: ???
==11792==    by 0x6C65682F73656C6F: ???
==11792==    by 0x65736C61662E6F6B: ???
==11792== 
==11792== LEAK SUMMARY:
==11792==    definitely lost: 55 bytes in 1 blocks
==11792==    indirectly lost: 0 bytes in 0 blocks
==11792==      possibly lost: 0 bytes in 0 blocks
==11792==    still reachable: 0 bytes in 0 blocks
==11792==         suppressed: 0 bytes in 0 blocks
==11792== 
==11792== For lists of detected and suppressed errors, rerun with: -s
==11792== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

I'm now investigating if the leak also happens outside of nix.

[Anton-4]

The leak also happens outside of nix, but the segmentation fault does not:

==31761== Memcheck, a memory error detector
==31761== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==31761== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==31761== Command: examples/false-interpreter/false examples/false-interpreter/examples/hello.false
==31761== 
Hello, World!
==31761== 
==31761== HEAP SUMMARY:
==31761==     in use at exit: 55 bytes in 1 blocks
==31761==   total heap usage: 66 allocs, 65 frees, 15,054 bytes allocated
==31761== 
==31761== 55 bytes in 1 blocks are definitely lost in loss record 1 of 1
==31761==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==31761==    by 0x120712: ??? (in /home/anton/gitrepos/roc/examples/false-interpreter/false)
==31761==    by 0x7: ???
==31761==    by 0x36: ???
==31761==    by 0x800000007: ???
==31761==    by 0x12B156: ??? (in /home/anton/gitrepos/roc/examples/false-interpreter/false)
==31761==    by 0x37E: ???
==31761==    by 0x40004BF: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==31761==    by 0x48B5891: ??? (in /usr/lib/x86_64-linux-gnu/libc-2.31.so)
==31761==    by 0x42A5A954: ???
==31761==    by 0x10A96A4: ???
==31761==    by 0x8FEFFF8C3: ???
==31761== 
==31761== LEAK SUMMARY:
==31761==    definitely lost: 55 bytes in 1 blocks
==31761==    indirectly lost: 0 bytes in 0 blocks
==31761==      possibly lost: 0 bytes in 0 blocks
==31761==    still reachable: 0 bytes in 0 blocks
==31761==         suppressed: 0 bytes in 0 blocks
==31761== 
==31761== For lists of detected and suppressed errors, rerun with: -s
==31761== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[Anton-4]

The leak is also on main but it does appear to be a recent addition, it does not occur on c42b8ad91be2f6291bc35915b99a1af433869239. I'll bisect now to narrow it down.

[Anton-4]

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
b18af7e1f3122401d991ecabe68c887e98ec2007
0606086eb6cde4844f54797ae4509b6f7807cf39
d8a8dff70de8580ea45c52eb351c21de7fcf7d12
cefbf3aa5128b4bca8169a8faa0b6a3ab9b23d58

confirmed bad 15ef517 confirmed good 68bb03e

Tagging @ayazhafiz

[folkertdev]

that does not add up. That confirmed bad commit only changes stuff for wasm. Or is there a gap (i.e. other commits) between the good and bad commits?

[Anton-4]

Yeah, the 4 full SHA commits listed earlier fail before I can properly test them with valgrind. So the error could have been introduced in any of those.

[Anton-4]

Do you know what change from one of the commits below could have caused a memory leak in the false interpreter @ayazhafiz?

b18af7e1f3122401d991ecabe68c887e98ec2007
0606086eb6cde4844f54797ae4509b6f7807cf39
d8a8dff70de8580ea45c52eb351c21de7fcf7d12
cefbf3aa5128b4bca8169a8faa0b6a3ab9b23d58

[ayazhafiz]

It's possibly cefbf3aa5128b4bca8169a8faa0b6a3ab9b23d58 or d8a8dff70de8580ea45c52eb351c21de7fcf7d12 - though it's not clear to me why those would leak, they are safe transformations.

Could you try reverting the merge commit of #3742 and see if the memory leak still reproduces?

[Anton-4]

This is my first time reverting a merge commit so I'm not sure I selected the right parent, but going through git revert 334bc7174fb91c8ca00d9612ba92dc653bce0aa3 -m 2 still has the same leak.

[github-actions[bot]]

Thank you for your contribution! Sometimes PRs end up staying open for a long time without activity, which can make the list of open PRs get long and time-consuming to review. To keep things manageable for reviewers, this bot automatically closes PRs that haven’t had activity in 60 days. This PR hasn’t had activity in 30 days, so it will be automatically closed if there is no more activity in the next 30 days. Keep in mind that PRs marked Closed are not deleted, so no matter what, the PR will still be right here in the repo. You can always access it and reopen it anytime you like!

[Anton-4]

Let's keep it open github-actions bot :)