|
Trouble compiling Mame after the C++17 change
#389203 - 12/25/20 09:19 PM
|
|
|
This will be a follow up to an issue on github for an "out of memory" error when Mame compiles up to the emumem files: https://github.com/mamedev/mame/issues/7590.
So despite using mingw64.exe to compile Mame, I still get the "cc1plus.exe: out of memory allocating bytes" issue even on a PC with 16GB. Tried with multiple flags like "-j5 PTR64=1 TOOLS=0 OPTIMIZE=3 SYMBOLS=0 REGENIE=1" with some enabled and disabled and still failed to compile. I'm pretty much stumped at this point and thought others compiling Mame past the C++17 change would have this issue too. Any professional help would be appreciated to fix this issue.
P.S. I would also ask if it's possible to make a bat executable to start mingw64 in a specific directory so that you won't have to use "cd" every time when starting mingw64.
Edited by Hydreigon (12/25/20 09:24 PM)
|
-.-
|
|
|
Re: Trouble compiling Mame after the C++17 change
[Re: Hydreigon]
#389232 - 12/27/20 09:39 PM
|
|
|
12/27/2020
Decided to do a fresh install for msys64. I am currently unable to compile with mingw64.exe due to an "MINGW32 is not set" error and using config64.bat under "C:\msys64\win32" doesn't work either. Compiling under win32env.bat still gives me the "out of memory" error.
There is very little information on this stuff on how to get a compile environment for Mame properly working. Is 16GB of ram not enough anymore?
|
-.-
|
|
|
Re: Trouble compiling Mame after the C++17 change
[Re: Hydreigon]
#389233 - 12/27/20 09:46 PM
|
|
|
> 12/27/2020
>
> Decided to do a fresh install for msys64. I am currently unable to compile with
> mingw64.exe due to an "MINGW32 is not set" error and using config64.bat under
> "C:\msys64\win32" doesn't work either. Compiling under win32env.bat still gives me
> the "out of memory" error.
>
> There is very little information on this stuff on how to get a compile environment
> for Mame properly working. Is 16GB of ram not enough anymore?
16GB is enough, I've been on 16GB for a while now since some of my RAM died.
|
|
|
|
Memory leak when compiling the emumem files.
[Re: Haze]
#389235 - 12/28/20 01:33 AM
|
|
|
Something within Mame's code is causing cc1plus.exe to memory leak when it compiles at the emumem files (at least on my end). It shouldn't have to use >10 GB of ram just to compile Mame.Didn't mean to say 10GB b/c that was from compiling under -j5.
So the "j" setting from my examination determines how much instances of cc1plus are used when compiling Mame. I decided to check memory behavior for only one cc1plus instance and the memory used for this application just kept rising until it was finished with an emumem file. Highest I seen it go up to so far was about 5 GB of ram used compiling emumem_mview.cpp.
What I did was use Resource Monitor to inspect cc1plus.exe's memory usage. Wait until cc1plus compiles the emumem files and watch the ram usage rise.
Edit: Seems to be a known issue: https://github.com/mamedev/mame/commit/5...8891bc1008ed94. Going to have to compile with two cc1plus instances "-j2" until this bug is fixed for good.
|
-.-
|
|
|
Re: Trouble compiling Mame after the C++17 change
[Re: Hydreigon]
#389239 - 12/28/20 03:55 AM
|
|
|
> 12/27/2020
>
> Decided to do a fresh install for msys64. I am currently unable to compile with
> mingw64.exe due to an "MINGW32 is not set" error and using config64.bat under
> "C:\msys64\win32" doesn't work either. Compiling under win32env.bat still gives me
> the "out of memory" error.
>
> There is very little information on this stuff on how to get a compile environment
> for Mame properly working. Is 16GB of ram not enough anymore?
The steps described here are exactly how I set up a MAME build environment: https://docs.mamedev.org/initialsetup/compilingmame.html#using-a-standard-msys2-installation
You can build MAME with 16GB of RAM. You can build with as little as 4GB of RAM with swap enabled, it just takes a long time. As I told you before, the 32-bit compiler is running out of address space. If you’re using GCC9, try upgrading to GCC10 – it’s a bit more efficient in C++17 mode. But really, you should just do 64-bit builds.
|
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Hydreigon]
#389241 - 12/28/20 04:01 AM
|
|
|
> Something within Mame's code is causing cc1plus.exe to memory leak when it compiles
> at the emumem files (at least on my end). It shouldn't have to use >10 GB of ram just
> to compile Mame.Didn't mean to say 10GB b/c that was from compiling under -j5.
It’s not a memory leak, it just uses a lot of memory to compile emumem_aspace.cpp, emumem_mview.cpp and luaengine.cpp – a leak is when it loses track of allocations and never releases memory.
> So the "j" setting from my examination determines how much instances of cc1plus are
> used when compiling Mame. I decided to check memory behavior for only one cc1plus
> instance and the memory used for this application just kept rising until it was
> finished with an emumem file. Highest I seen it go up to so far was about 5 GB of ram
> used compiling emumem_mview.cpp.
>
> What I did was use Resource Monitor to inspect cc1plus.exe's memory usage. Wait until
> cc1plus compiles the emumem files and watch the ram usage rise.
Well yeah, compiling large, complex functions with lots of templates uses a lot of memory.
> Edit: Seems to be a known issue:
> https://github.com/mamedev/mame/commit/5...891bc1008ed94..
> Going to have to compile with two cc1plus instances "-j2" until this bug is fixed for
> good.
That has nothing to do with RAM usage when compiling, that issue would cause MAME to crash with a stack overflow on start. It’s completely unrelated, and it is fixed.
|
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Hydreigon]
#389243 - 12/28/20 04:34 AM
|
|
|
> Something within Mame's code is causing cc1plus.exe to memory leak when it compiles
> at the emumem files (at least on my end). It shouldn't have to use >10 GB of ram just
> to compile Mame.Didn't mean to say 10GB b/c that was from compiling under -j5.
>
> So the "j" setting from my examination determines how much instances of cc1plus are
> used when compiling Mame. I decided to check memory behavior for only one cc1plus
> instance and the memory used for this application just kept rising until it was
> finished with an emumem file. Highest I seen it go up to so far was about 5 GB of ram
> used compiling emumem_mview.cpp.
>
> What I did was use Resource Monitor to inspect cc1plus.exe's memory usage. Wait until
> cc1plus compiles the emumem files and watch the ram usage rise.
>
> Edit: Seems to be a known issue:
> https://github.com/mamedev/mame/commit/5...891bc1008ed94..
> Going to have to compile with two cc1plus instances "-j2" until this bug is fixed for
> good.
I can compile with -j40 on 16GB if I want, Windows will just use swapfile, it takes much longer that way, and thrashes the disk like hell, but no out of memory.
If you're trying to use a 32-bit environment or something, keep in mind that's no longer officially supported, and on the machine you have, there's no reason to do that.
|
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Haze]
#389247 - 12/28/20 06:09 AM
|
|
|
> I can compile with -j40 on 16GB if I want, Windows will just use swapfile, it takes
> much longer that way, and thrashes the disk like hell, but no out of memory.
>
> If you're trying to use a 32-bit environment or something, keep in mind that's no
> longer officially supported, and on the machine you have, there's no reason to do
> that.
Extremely odd in my humble opinion you can get Mame to compile. Also, I am NOT trying to use a 32-bit environment. I've done like two fresh installs today and made sure to double click that config64.bat file. This was what made me think it was a bug in Mame's code.
I may have to send some information about my system if necessary.
|
-.-
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Hydreigon]
#389248 - 12/28/20 07:20 AM
|
|
|
> Extremely odd in my humble opinion you can get Mame to compile. Also, I am NOT trying
> to use a 32-bit environment. I've done like two fresh installs today and made sure to
> double click that config64.bat file. This was what made me think it was a bug in
> Mame's code.
Given that MAME development is proceeding, we’re getting test results for daily builds, and we’re planning a release this month, I don’t see how you could rationally think it’s odd that someone can compile MAME. You seem to be intentionally ignoring what people are telling you.
|
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Vas Crabb]
#389295 - 12/31/20 03:18 AM
|
|
|
> Given that MAME development is proceeding, we’re getting test results for daily
> builds, and we’re planning a release this month, I don’t see how you could rationally
> think it’s odd that someone can compile MAME. You seem to be intentionally ignoring
> what people are telling you.
My test results from compiling Mame do not lie. The memory leaks at those emumem files were always consistent every time I compiled mame.
If those leaks do not happen from your end, then I am for sure curious. In the meantime, I will have to allocate more storage device memory to ram or compile with a small amount of cc1plus files; -j2 is the max for now.
|
-.-
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Hydreigon]
#389296 - 12/31/20 03:34 AM
|
|
|
> > Given that MAME development is proceeding, we’re getting test results for daily
> > builds, and we’re planning a release this month, I don’t see how you could
> rationally
> > think it’s odd that someone can compile MAME. You seem to be intentionally ignoring
> > what people are telling you.
>
> My test results from compiling Mame do not lie. The memory leaks at those emumem
> files were always consistent every time I compiled mame.
>
> If those leaks do not happen from your end, then I am for sure curious. In the
> meantime, I will have to allocate more storage device memory to ram or compile with a
> small amount of cc1plus files; -j2 is the max for now.
Again, it is not a memory *leak* they just require a lot of memory to compile.
If you've disabled or limited your swap file, don't you think this might have been important information to disclose?
|
|
|
|
Re: Memory leak when compiling the emumem files.
[Re: Hydreigon]
#389302 - 12/31/20 05:18 AM
|
|
|
> My test results from compiling Mame do not lie. The memory leaks at those emumem
> files were always consistent every time I compiled mame.
You’re using terminology incorrectly. It is not a “memory leak”, compiling those files just requires a lot of memory.
> If those leaks do not happen from your end, then I am for sure curious. In the
> meantime, I will have to allocate more storage device memory to ram or compile with a
> small amount of cc1plus files; -j2 is the max for now.
Take a step back here. The code was migrated to C++17 about a month ago. Which of the following scenarios is more plausible?
- No-one can compile MAME, the successful GCC builds on GitHub Actions are faked, and we’ve gone through the motions of a month of development and subsequent release preparations for shits and giggles.
- We can all compile MAME just fine, and the compiler failing to allocate memory really is caused by a 32-bit compiler running out of addressable space.
There is no way what you’re saying is correct. On a system with at least 8GB of available RAM/swap, a 64-bit version of GCC or clang will not fail to allocate memory building any of MAME’s source files. The errors you are describing only happen with 32-bit compilers, and even then the 32-bit version of GCC10 can successfully compile MAME.
You’re the one with the issue here, yet you’re trying to tell the people who can compile MAME successfully that they don’t know what they’re talking about.
|
|
|
Index 
Threaded 
Trouble compiling Mame after the C++17 change
Reply
[Re: 
