Who's Online |
19 user(s) are online ( 15 user(s) are browsing Forums)
Members: 1
Guests: 18
skynet,
more...
|
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular 
|
Thanks, I'll try with Adélie first, but Debian would also be helpful to have as a backup.
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
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.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
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.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
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.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
@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.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
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.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
Back to the original topic, I was finally able to try the MMU protection method. Here's my example program:
#include <proto/exec.h>
#include <stdio.h>
#include <stdlib.h>
#define BUFFER_SIZE 48
#define MEM_ALIGN_SIZE 4096
#define MEM_GUARD_SIZE 4096
void *AllocMemory(int size, int protect)
{
UBYTE *ptr = IExec->AllocVecTags(MEM_GUARD_SIZE + size,
AVT_Type, MEMF_PRIVATE,
AVT_Alignment, MEM_ALIGN_SIZE,
TAG_END);
if (!ptr) return NULL;
if (protect)
{
struct MMUIFace *IMMU = (struct MMUIFace *)IExec->GetInterface((struct Library *)SysBase, (CONST_STRPTR)"MMU", 1, NULL);
ULONG attrs = IMMU->GetMemoryAttrs(ptr, 0);
IMMU->SetMemoryAttrs(ptr, MEM_GUARD_SIZE, (attrs | MEMATTRF_READ_ONLY));
IExec->DropInterface((struct Interface *)IMMU);
}
return ptr ? (ptr + MEM_GUARD_SIZE) : NULL;
}
void FreeMemory(void *block)
{
if (!block) return;
UBYTE *ptr = (UBYTE *)block;
IExec->FreeVec(ptr - MEM_GUARD_SIZE);
}
int main(int argc, char *argv[])
{
BOOL protect = (argc > 1) ? atoi(argv[1]) : 0;
printf("allocating %d bytes protect %d\n", BUFFER_SIZE, protect);
UBYTE *buf = AllocMemory(BUFFER_SIZE, protect);
if (!buf)
{
printf("allocation failed\n");
return 1;
}
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.
|
|
|
|
Re: Open Medal of Honor (BETA)
|
|
Quite a regular
|
Dynamic lighting in id Tech 2 games draws into the lightmaps, so potentially multiple textures have to be updated each frame. I guess this eats up the already limited bus bandwidth.
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
The problem doesn't manifest in its natural habitat (Windows, little endian Linux). Big endian Linux is on my list to try, but only as a last resort as it runs very slow in QEMU :(
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Catching memory corruption "in the act"
|
Posted on: 3/27 17:38
#10
|
Quite a regular
|
It's a very large and complex project, think of 200,000+ lines of C++ code. This is why I need a stack trace at the place where it overwrites a buffer.
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Catching memory corruption "in the act"
|
|
Quite a regular
|
In that case I think I'll try both methods. Thanks for the tips!
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Catching memory corruption "in the act"
|
Posted on: 3/26 19:54
#12
|
Quite a regular
|
@trixie
Drats, that was I afraid of. That tool is quite old :(
@graff
That could work for the block in front of the allocation, but probably not for the one after it, as some padding has to be added for the alignment. There's a good chance the bogus write will happen in that region, especially if it has to be aligned on page boundaries.
|
|
This is just like television, only you can see much further.
|
|
|
|
Catching memory corruption "in the act"
|
|
Quite a regular
|
I'm dealing with some nasty memory corruption and I'd like to find the exact place where it happens. I have guard tags before and after the allocated memory, and I'm wondering if it'd be possible to protect these so I get a Grim Reaper when the program tramples on them.
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Debug kernel parameters for OS44.1FE Classic
|
|
Quite a regular
|
Oh cool, that might come in handy if I want to change the debuglevel for example. BTW, I have the serial debug output now, I was just missing a hard reset. D'oh!
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Debug kernel parameters for OS44.1FE Classic
|
|
Quite a regular
|
Thanks, that did the trick I think. I can't see the serial debug in WinUAE's console yet, but maybe I have to tweak baudrate for that.
|
|
This is just like television, only you can see much further.
|
|
|
|
Debug kernel parameters for OS44.1FE Classic
|
|
Quite a regular
|
How does one set the parameters (debuglevel, munge, etc.) for the debug kernel running in WinUAE? The Wiki says I should use setenv command of the firmware, but the CyberStorm PPC's menu has no such thing. Any tips on how this can be done?  https://wiki.amigaos.net/wiki/Debug_Kernel
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Heretic 2 OS4 and WarpOS Version differences
|
Posted on: 2024/3/26 16:42
#17
|
Quite a regular
|
@TheMagicSN Quote: - AGA Mode (not sure if this was in the release version of H2 WarpOS, I think it was but not sure right now) with HAM8. OS4 H2 requires Graphics Board. The HOL entry says AGA or graphics card so it was probably in the release version as well. Out of curiosity how did the conversion work?
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Introducing the Rear Window blog
|
Posted on: 2024/2/25 19:20
#18
|
Quite a regular
|
@trixieQuote: trixie wrote:@all
The new blog post is a bit more personal this time and less about development, but I hope you'll enjoy it. Your friend is a remarkably unsentimental person. This reminds me of something a history teacher once told us: the past is not behind us, we are standing on it.
Edited by trixie on 2025/5/19 7:58:48
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: About off topic news on Amigans
|
Posted on: 2024/2/20 17:09
#19
|
Quite a regular
|
AWN currently serves its purpose as a containment area for people who will bicker with each other endlessly derailing every thread. This recently started spilling over to EAB too, but fortunately it's not that bad yet due to the size of the forum. I'd imagine if the usual suspects at AWN got banned they'd migrate to a different forum, and continue bickering there.
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: Guide for New A1222 Users
|
Posted on: 2024/2/12 7:03
#20
|
Quite a regular
|
Quote: FirstNinja wrote:@eliyahu
Oh? Since Discord is closed off / propriety software that the owners seemingly refuse to port to AmigaOS, it's certainly is an odd platform for A-EON to make announcements on. Would you please mind quoting their post in this thread, so that everyone can read what they have to say? This gave me a chuckle I'll go back to the shadows now to observe.
|
|
This is just like television, only you can see much further.
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
