What about flushing sound anyway? Seems to close cleanly. --- a/src/vsync.c +++ b/src/vsync.c @@ -518,6 +518,9 @@ void vsync_do_end_of_line(void) * during shutdown but here we are - apply workaround. */ + /* deal with any accumulated sound immediately */ + tick_based_sync_timing = sound_flush(); + if (archdep_is_exiting()) { /* UI thread shutdown code can end up here ... :( */ if (can_yield_to_ui) { @@ -527,9 +530,6 @@ void vsync_do_end_of_line(void) return; } - /* deal with any accumulated sound...
resid doesn't overflow the buffer but returns the number of unused cycles. The warning is then suppressed during shutdown: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/sound.c#l1405 so it seems the problem is known.
Likely, but I don't understand the code enough to say. Maybe suspend the sound when the shutdown begins?
I see it only happens during VICE shutdown, so a check like this should suffice to avoid writing outside the bounds: --- a/src/sid/residfp.cc +++ b/src/sid/residfp.cc @@ -310,6 +310,10 @@ static int residfp_calculate_samples(sound_t *psid, short *pbuf, int nr, int int /* CAUTION: unlike ReSID; this does NOT return the number of cycles "left to do" in int_delta_t */ retval = psid->sid->clock(int_delta_t, tmp_buf); if (retval > 0) { + if (retval > nr) { + //DBG(("*** Buffer Overflow")); + retval =...
Error - ../../vice-git/src/sound.c:1355: Error - Memory corruption in higher part of base 0x7f56c00045a0! It's a buffer overflow: when clocking the engine for delta_t cycles the number of samples produced may exceed the size of the buffer https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/sid/residfp.cc#l311 This crude patch seems to fix it, it may lose some samples but at least won't crash --- a/src/sid/residfp.cc +++ b/src/sid/residfp.cc @@ -310,8 +310,9 @@ static int residfp_calculate_samples(sound_t...
Can't reproduce on Linux, but sometimes it crashes at exit: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff65b967f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89 #2 0x00007ffff65636e2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff654bef5 in __GI_abort () at abort.c:77 #4 0x00007ffff654cf2e in __libc_message_impl (fmt=fmt@entry=0x7ffff66c932b...
It seems a limitation of winpthread: https://www.reddit.com/r/cpp/comments/e1wh1t/comment/f8sidau/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button I see some possible solutions/wokarounds: upgrade to gcc 16 which provides native TLS switch from winpthread to mcfgthread disable residfp on mingw builds revert the std::call_once change and see if it works
The plus4emu code seems to agree with fpgated, so here's an improved test which prints the failed check (sorry if my plus/4 code sucks) and the full patch to make the test pass: --- a/src/plus4/ted-mem.c +++ b/src/plus4/ted-mem.c @@ -62,7 +62,7 @@ static int unused_bits_in_registers[64] = 0x00 /* $FF08 */, 0x00 /* $FF09 */, 0xa0 /* $FF0A */, 0x00 /* $FF0B */, 0xfc /* $FF0C */, 0x00 /* $FF0D */, 0x00 /* $FF0E */, 0x00 /* $FF0F */, 0x00 /* $FF10 */, 0x00 /* $FF11 */, 0x00 /* $FF12 */, 0x00 /* $FF13...