AssertionError in test_pytest_memray.py

[IvanKhanas]

The test fails for some unknown reason, although all dependencies are present and /dev/kvm and /proc are mounted. The build is performed in an isolated hasher environment without network access

I attach the build log

buildlog.txt

[godlygeek]

Sorry @IvanKhanas, this issue slipped by me and I just noticed it now!

There's two failures in that build log.

This first one:

______________________________ test_memory_exceed ______________________________
Test was limited to 100.0KiB but allocated 117.2KiB

fails for me, too. Our automated test suite doesn't run that test (it's part of our documentation, not our test suite), and it seems like it's bit rotted a bit and no longer passes with current versions of the Python interpreter. We probably need to raise the memory limit in the test, but you should only be running our test suite, with python -m pytest tests/ instead of just python -m pytest - however you're currently invoking it, pytest discovered something that we don't exercise.

This second failure:

_______________________ test_memray_report_native[True] ________________________
...
>           assert "MemoryAllocator_1" in output

looks more interesting. If you're able to, can you add -vv to the pytest invocation so that we can see a more complete diff?

There's two things I can imagine that might be causing that. Most likely it's either failing to unwind the native stack, or failing to match the native stack and Python stack up against each other to form a hybrid stack - this might happen if you're building without frame pointers and stripping dwarf, for instance. In that case you can just ignore the failing test; it's relying on something that isn't present in your builds. The other possibility is that it's successfully finding a hybrid stack, but that the hybrid stack it's getting doesn't match our assumptions (either names were mangled differently, or the stack doesn't contain the frames we expect it to). If so, that would be a bug. Sorry for the long delay in responding to this, hopefully it's not too hard for you to investigate which of those two cases it is at this point!