VmmScatterMemory crashes with option FLAG_NOCACHE

[intef0]

Python API.

When calling process.memory.scatter_initialize() reading works, but there's a 300ms cache delay.

When adding a flag: process.memory.scatter_initialize(memprocfs.FLAG_NOCACHE)

• Linux: getting *** stack smashing detected ***: terminated
• Windows 10: all read operations return nothing

Both platforms running latest available from pip. Using Acorn/FT2232h as a acquisition device DEVICE: FPGA: FT2232H #1 PCIe gen2 x1 [0,0,1000] [v4.9,0b00] [ASYNC,NORM]

[ufrisk]

Are you getting the stack error directly when calling process.memory.scatter_initialize() or is it in subsequent calls?

What is your Python version and is it 32-bit Python or 64-bit Python?

[intef0]

It's crashing on the initialize call. Python version 3.11.6 64bit.

[ufrisk]

Can you check if this issue is now resolved if you upgrade the memprocfs package.

You may have to reboot the computer afterwards if its not working initially (I had to do it for some unknown reason).

[intef0]

Initial quick test confirms that the stack smashing is gone with the 5.8.21. Though it seems to fail to read anything: VmmScatterMemory.read(): Failed.

I guess the addresses and code should be fine as just taking the FLAG_NOCACHE away works without a problem. Tested only with Linux atm. Probably unrelated, but read_type() was also earlier failing with scatter memory reader. Reading the same same address with .read() provided expected result. Could do some more tests with read_type() to confirm when I get some time.

[ufrisk]

I've tested this against a memory dump file, but for the scatter implementation it should not matter which memory backend is used.

You'd have to for the scatter memory:

1. scatter_initialize()
2. scatter_memory.prepare() N times
3. scatter_memory.execute() to perform the actual read
4. scatter_memory.read() the data that was previously prepared. Reading outside prepared ranges will fail.

The Python scatter implementation is just a wrapper around the C/C++ implementation and it should work... If you still don't get it to work please let me know.

[intef0]

Your snippet works for me, modified it a bit to mimic my use case and can replicate (because I was lazy to upkeep a list of addresses I already prepared + they are wider than I read in single read -> clear before execute). I can work around that though now :+1: Thanks for the updates!

[ufrisk]

There was an additional error in the clear() method. The flag was interpreted as a PID.

This should now also be resolved in 5.8.22.

Can you please once again try to verify it works?

[intef0]

Indeed I can confirm that 5.8.22 works. Excellent work!

Here's btw the thing with the read_type() I mentioned earlier.

[intef0]

Here's another quick test.

[ufrisk]

Sorry about that, sloppy fix from my part. hopefully things should now work better in 5.8.23.

[intef0]

Yep, works! Thanks for the fixes! And sorry to dig up so much dirt, in same issue nonetheless :smile:

[ufrisk]

No worries about that. I'm sorry this Python delivery had so many quality issues. Too much copy and paste and too little testing sadly.

But some of the bugs were quite nasty. size of long on Linux seems to be 8 bytes whilst on Windows its 4 bytes. Anyway all is good now and things are resolved. 👍

Please let me know if you should run into issues again in the future.