printf("valid writes...\n");
for (int i = 0; i < BUFFER_SIZE; i++)
{
buf[i] = 0xFF;
}
printf("invalid write...\n");
buf[-1] = 0xFF;
printf("invalid writes...\n");
for (int i = 0; i < MEM_GUARD_SIZE; i++)
{
buf[-i] = 0xFF;
}
printf("freeing memory\n");
FreeMemory(buf);
return 0;
}
This works in my simple test case, but there's one catch: the actual project does a metric ton of small memory allocations. The 4KB overhead plus the alignment requirement makes the memory fragmented to the point where the allocations start to fail, even with a 512MB Z3 RAM expansion. I tried smaller guard blocks while keeping the alignment as 4KB, but that ended up causing all sorts of freezes and crashes. I guess my only option is Linux? :(
This is just like television, only you can see much further.
If a PPC binary of the program exists: you can run 32bit or 64bit PPC big endian programs on little endian 64 bit x64 Linux with qemu user mode emulatation ("qemu-ppc" instead of "qemu-system-ppc"). You don't need to have PPC Linux installed, only download some Linux PPC iso and loop-mount it (and likely some filesytem image inside that as well) so you can tell qemu with "-L" where to pick up some PPC versions of libs the PPC binary needs.
I recently tried this with old (2011) version of 32 bit AROS PPC hosted on Linux version and it works pretty well. On old PC here (10 years old?) it "boots" into WB in 3 to 4 seconds (x86 AROS hosted debug version "boots" in maybe 0.5 seconds).
That sounds promising, because I had a terrible luck trying to install recent PPC Linux distros in QEMU. The project can be built for i386 Linux I think I could make a PPC executable with reasonable effort. I saw that GDB is supported via user mode emulation, but I guess I'm going to need Valgrind too to catch the illegal writes outside the allocated blocks?
This is just like television, only you can see much further.
@BSzili I don't know if valgrind works with user mode emulation (I've only found old tickets that said it did not work but could be fixed since). Otherwise there are docs at https://www.qemu.org/docs/master/system/ppc/amigang.html about running Linux on my boards in QEMU. Or for Linux any other PPC board may be used which can probably run more recent distros but PPC emulation is quite neglected. But you can use up to 2GB memory with AmigaOS on QEMU. Another idea, if you can replace the allocation in the code you're debugging (e.g. with some preprocessor #defines) to call your own wrapper you could allocate more memory for some guard bytes before and after the address returned to the application then you can check it on free or when a crash occurs.
If I read your code correct, you allocated memory, you protect it, and then return memory after the MEM_GUARD_SIZE? what is that supposed to do?
Typically, if you have broken for loop or while loop… it’s the end of the memory you need to protect, not the beginning of memory. even if did protect end of memory. you have problem with the memory page size, [protected][data][alignment][protected]… you might not catch bug sense you likely to write into alignment part.
pointer are not well understood by many developers, a pointer is a element. “Ptr+=10;” is the offset: “sizeof(*ptr) * 10”; 10 is not in bytes its number of elements of the pointer to increment, this why always need to cast to byte pointers, before doing any additions, unless you intend something else.
wont it be better to create a memory copy protect, concept instead..
Crashes are often caused by non-initialized offsets, or pointers. Random crap in memory, causing pointers to be set, or offsets being set to something else than 0. It should be one of the prime suspects. Besides making sure you actually got memory after an allocation. Also, se lot developers who do not set pointer to NULL after freeing. yeh sure it faster if you don’t but it’s not uncommon to create a cleanup routine and accidentally call it twice because you forgot a return or a break. stack corruption can be a issue, lets say you array with 10 items, it’s easy to accidently writ 11 items into it and corrupt next variable in the stack, its easy add extra variable after the array with 0xCAFECAFE or something like that, if want to check that array do not overwrite next variable on the stack..
Crashes on addresses like 0xFFFFF424, is good indication of zero pointer somewhere in the code.
Edited by LiveForIt on 2025/7/4 13:26:26 Edited by LiveForIt on 2025/7/4 14:25:18 Edited by LiveForIt on 2025/7/4 14:28:21
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@balaton The most recent PPC Linux distro I managed to install in qemu was Debian 12, but it self-destructed after an update and it no longer boots. I had no success with smaller distros, usually I couldn't even get their installer to work.
This is just like television, only you can see much further.
@BSzili I think PPC is unsupported in Debian for a while so you should try something contemporary to these machines or what's known to work on real machine. The most recent Debian I've found that supported AmigaNG machines was about Debian 8.11 and if you just want to run valgrind on it don't update it. Other Linux distros that are newer and still have PPC versions that might work are https://github.com/finnix/finnix-docs/blob/main/platforms.md (only old version) or https://www.adelielinux.org/download/ but maybe these only support -machine mac99,via=pmu which is closest to PowerMac3,1 (that is also listed for MorphOS on my page in the signature below). Maybe you could get AmigaOS running on one of the boards in QEMU and 2GB could be enough to debug it with the page protection trick. Or you can try a PPC64 distro with qemu-system-ppc64 that should still be able to run 32 bit PPC code. Those may be better supported for spapr for example but I don't have much experience with that.
Yeah, I should probably give the OS4 MMU protection another shot in QEMU with more memory. I already made a debug allocator on Windows using VirtualProtect functions to test this approach "live" and it seems to do what I need it to do. I still have to hunt down an OS4 disc for one of these systems though.
This is just like television, only you can see much further.
Yeah, I should probably give the OS4 MMU protection another shot in QEMU with more memory. I already made a debug allocator on Windows using VirtualProtect functions to test this approach "live" and it seems to do what I need it to do. I still have to hunt down an OS4 disc for one of these systems though.
This is just like television, only you can see much further.
As you suggest, I recommend you to build and debug on Linux PPC (yes, I know it is hard to get a distribution and keep it working) and I would have added an intermediary step too: build and debug on Linux x86, that has fantastic tools to track memory issues (compiler sanitizers).
Unfortunately the problem only manifested on OS4 so far, so I'm trying to catch it there. I don't even know if it'll happen on big endian Linux, it's just a backup plan if the QEMU OS4 path fails.
This is just like television, only you can see much further.
@BSzili I am on a long vacation until the end of July but ... If you need some Linux Debian 8 (disk image) under QEMU I can send you. Under A1 and PEG2. Let me know Under QEMU Sam460 I have somewhere on a backup Debian sid disk image from 2024. I also have Adelia ppc 1.0-beta5 under PEG2 (only works with QEMU) -> https://github.com/smarkusg/adelielinu ... os-2/releases/tag/6082024 I rebuilt Adelia (Linux kernel) to work on PEG2 with QEMU. Maybe it will be helpful.