While TASsing, it regularly happens to me that openmsx crashes. It is hard to reproduce, and I regularly work for hours before it happens. It seems to always happen while holding down the minus-key, which I have bound to -repeat "prev_frame". The crash has the error message:
Assertion 't = find_next_time_event(m)' failed at pulse/mainloop.c:722, function calc_next_timeout(). Aborting.
This is on Debian's latest version, 0.10.1-2, running on a sid Debian GNU/Linux system.
I think it may always happen when another program starts playing a sample (for example, when a message comes in on my chat program).
I'll try to get a stack backtrace at some point.
I have a backtrace:
And with some more information:
Some discussion on this:
<quibus> shevek: by the way - that crash you reported, isn't it in libpulse/pulseaudio?
<quibus> openMSX doesn't use that directly, it uses libSDL as audio api
<mth> I was thinking the same thing: [15:06] <mth> regarding bug 555: there is no openMSX frame on the stack, so I'd say it's more likely a bug of SDL 1.2 or pulseaudio
<mth> since it's an assert, it's most likely an internal bug in pulseaudio
<mth> because doing input validation with asserts is usually not a good idea
<quibus> exactly
<quibus> I also trigger it once in a while</quibus></quibus></mth></mth></mth></mth></quibus></quibus>
Perhaps it helps to file a bug at PulseAudio?