From: Jo E. S. <jo...@on...> - 2025-09-23 18:10:16
|
On Tue, 2025-09-23 at 17:09 +0200, Thorsten Otto via Freemint-discuss wrote: > On Dienstag, 23. September 2025 14:45:09 CEST Jo Even Skarstein via > Freemint-discuss wrote: > > if I understand you correctly then the docs means "memory currently > > allocated to a process or the kernel" > > Yes, i think that is what was actually meant there. Reading memory > that is not assigned to any process would just return random garbage. > No, not really. Even if it's currently not allocated to a process it doesn't necessarily contain random garbage. It's also a bit strange limitation, as peeking around in free memory is pretty harmless compared to doing the same to allocated memory. But yes, this is a marginal usecase :) > For that you would have to know where the program stores what. Might It is of course more difficult than source level debugging. And not always possible. But when a program crashes you know the address of the basepage, and thus the text, data and bss segments. You also know the address of the instruction that caused the crash, and the address that caused the memory violation. So you have quite a bit of information. You could have had even more - like a register dump and a list of all memory pages allocated to the process - if the kernel hadn't discarded this information before informing the user about the crash. > make more sense to compile the program with the elf toolchain, and > run it in gdb to see where it crashes (yes i know, thats not your > favorite option). You can't do this if you don't have the sources for the crashing program. Jo Even |