09251: All sets in quizdna.cpp: MAME crashes with "Caught unhandled St9bad_alloc exception: std::bad_alloc" message

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
09251	Crash/Freeze	Minor	Always	2 days ago	2 days ago

Tester	M.A.S.H.	View Status	Public	Platform	MAME (Unofficial Binary)
Assigned To	galibert	Resolution	Fixed	OS	Windows 11/10 (64-bit)
Status [?]	Resolved			Driver	nmk/quizdna.cpp
Version	0.280	Fixed in Version	0.281GIT	Build	64-bit
		Fixed in Git Commit	02bdea6	Github Pull Request #

Summary	09251: All sets in quizdna.cpp: MAME crashes with "Caught unhandled St9bad_alloc exception: std::bad_alloc" message
Description	All games in quizdna.cpp: MAME crashes with "Caught unhandled St9bad_alloc exception: std::bad_alloc" message since MAME 0.274.
Steps To Reproduce	Start MAME 'Quiz Gakuen Paradise (Japan, ver. 1.04)' => mame gakupara
Additional Information	Use Ashura-X's Nightly MAME builds at http://ashura.mameworld.info/nightlybuilds/builds.html WIP: - 0.274: Cleaned up memory banking, palette handling and graphics decoding: Use a memory view to swap ROM over tilemap RAM. Use palette format helpers and generic graphics decoding layouts. Increased the size of ROM regions to cover maximum 32 banks. Reduced code duplication, use more appropriate types [cam900]. Simplified program ROM loading. This still had hold-overs from when the region was the address space. Also put common I/O space mappings in a shared function [Vas Crabb].
Github Commit

Flags
Regression Version	0.274
Affected Sets / Systems	All sets in quizdna.cpp

Attached Files

No.23629 hap Developer 2 days ago	Ashura-X's Nightly MAME = not an official MAME version. I can't confirm anything crashing, but I do see that it's taking around 6 seconds to boot up, which is very slow. I see MAME allocating up to 8GB RAM in the task manager, and when the game finished loading, it's reduced to 4.3GB, which is still a lot. Something's messed up here with memory allocation.
No.23630 hap Developer 2 days ago edited on: 2 days ago	I did some hacks to isolate the test case: Something's going wrong with emumem non-continuous r/w + overlapping memory_view. This is without issue: map(0x8000, 0xbfff).ram(); // continuous map(0x8000, 0xbfff).view(m_romview); m_romview[0](0x8000, 0xbfff).nopr(); This allocated multiple GB when MAME initializes: map(0x8000, 0x8fff).ram(); map(0xa000, 0xbfff).ram(); map(0x8000, 0xbfff).view(m_romview); m_romview[0](0x8000, 0xbfff).nopr(); This too: map(0x8000, 0x9fff).ram(); // 8KB now map(0xa000, 0xbfff).ram(); map(0x8000, 0xbfff).view(m_romview); m_romview[0](0x8000, 0xbfff).nopr(); This too: map(0x8000, 0x8001).noprw(); map(0x8000, 0xbfff).view(m_romview); m_romview[0](0x8000, 0xbfff).nopr();
No.23631 M.A.S.H. Senior Tester 2 days ago	https://git.redump.net/mame/commit/?id=02bdea66ea92f9bd5d0a18547dadafe8cdc3b5b7 "emumem: Avoid splitting handlers on dup-ing, avoiding tons of extra allocations" fixed it. Thanks to hap and Galibert!