 No.08324
NekoEd Senior Tester
Mar 7, 2012, 11:54
|
Can't reproduce here. (SDLMAME64/Linux 0.145u3) |
|---|---|
 No.08325
Scagazza Tester
Mar 7, 2012, 12:14
edited on: Mar 7, 2012, 12:17
|
Same error with all the laser disc games. Mame 0.145u3 64-bit built with usual command and latest development tool: make all TARGETOS=win32 PTR64=1 no optimizations |
 No.08326
Fujix Administrator
Mar 7, 2012, 14:33
|
Reproduced in my MAME64.Error: attempt to free untracked memory in (null)(0)! 000000000022D3E8: 00000000010DC559 (not found) 000000000022D3F0: 000007FEFF5C3FC0 (_iob_func) 000000000022D3F8: 000000000022D3F0 (not found) 000000000022D400: 000000000022D3F8 (not found) 000000000022D408: 000000000022C750 (not found) 000000000022D410: 000000000022D560 (not found) |
|
No.08327
Firewave Senior Tester
Mar 7, 2012, 17:48
|
I think the memory tracking is only done in the Windows code. And I remember a change at some point, that prevented NULL pointers being added to the memory tracking. Looks like the same issue to me. |
 No.08328
B2K24 Senior Tester
Mar 7, 2012, 17:51
|
here is a self compiled 0.145u3 run on Win 7 Ultimate X64 mame64 -window -verbose cubeqst Average speed: 99.66% (98 seconds) Sound: buffer overflows=3 underflows=0 Error: attempt to free untracked memory in (null)(0)! 000000000022D3E8: 00000000010DC559 (wininput_init(running_machine&)+0x10a9) 000000000022D3F0: 000007FEFE2B3FC0 (_iob_func) 000000000022D3F8: 000000000022D3F0 (+0x22d3f0) 000000000022D400: 000000000022D3F8 (+0x22d3f8) 000000000022D408: 000000000022C750 (+0x22c750) 000000000022D410: 000000000022D560 (+0x22d560) |
 No.09946
hap Developer
Nov 3, 2013, 20:08
|
before mameworld forum flushes that thread: posted by peter ferrie: "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. ----------------------------------------------- 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. " |
|
No.10496
Firewave Senior Tester
Mar 21, 2014, 09:01
|
Looks like this was fixed by the emualloc rewrite. |