|
mach3 untracked memory
#312635 - 08/09/13 03:24 AM
|
|
|
I had a look at MACH3 today, but I understand that the problem is common to other laserdisc games.
There's an allocation using "coretmpl.h" included by "lib\util\chd.c" (it's the fourth call to expand_internal()), but it's using malloc() instead of the tracked allocation. This might be the actual bug.
This block is later attempted to be freed by "coretmpl.h" (same file, different instance) included by "emu\machine\laserdsc.c" (there's only one such free attempt). Or maybe the bug is here.
It is expecting the block to be tracked, and fails because it's not.
For some reason, I see the issue only in MinGW builds, and only with optimisation level=3 (I'm using a 32-bit build).
If I disable optimisations, the problem goes away. If I use VisualC to enable source-level debugging to see the exact place of the problem, then the coretmpl.h is apparently unused.
So I can't progress further with it, but maybe someone else can now.
|
|
|
|
Re: mach3 untracked memory
[Re: peter ferrie]
#312726 - 08/11/13 03:18 PM
|
|
|
I'm probably just talking to myself here, but anyway...
mingw with -O3 assigns the new operator to malloc().
mingw with -O0 assigns the new operator to the overloaded version that calls malloc_file_line().
This happens when using the makefile to build, even when chd.c is the only thing being explicitly compiled.
Can someone explain to me why it happens?
This is the cause of the untracked memory bug.
When the new operator calls the malloc_file_line(), the problem goes away.
|
|
|
| drewcifer |
|
One bad Mutha-(shut yo' mouth!)
|
|
|
|
|
Reged: 07/01/04
|
|
Posts: 431
|
|
Loc: Sweden
|
|
|
|
Send PM
|
|
|
Re: mach3 untracked memory
[Re: peter ferrie]
#312743 - 08/12/13 02:15 AM
|
|
|
> I'm probably just talking to myself here, but anyway...
> mingw with -O3 assigns the new operator to malloc().
> mingw with -O0 assigns the new operator to the overloaded version that calls
> malloc_file_line().
> This happens when using the makefile to build, even when chd.c is the only thing
> being explicitly compiled.
>
> Can someone explain to me why it happens?
>
> This is the cause of the untracked memory bug.
> When the new operator calls the malloc_file_line(), the problem goes away.
You're talking to at least me, but man, I've got nothing. That sounds like some weird behavior for sure. You can imagine a compiler thinking it's being smart by throwing away "redundant" code or something with a higher optimization level, but clearly smart isn't the proper word here...
Andrew
|
|
|
Index 
Threaded 
mach3 untracked memory
Reply
[Re: 
