This is possibly a not very helpful header for the bug, but I don't know what the problem is. I tested the svg at the url above. After playing the game some time, I get messages on the console like this: mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory mmap() failed: Cannot allocate memory (GtkLauncher:1879): GStreamer-WARNING **: failed to create thread: Error creating thread: Resource temporarily unavailable (GtkLauncher:1879): GStreamer-WARNING **: failed to create thread: Error creating thread: Resource temporarily unavailable ... and GtkLauncher frezzes. This problem does not happen on every try. The svg uses Sounds. Maybe it's just a single jingle?
Created attachment 47824 [details] Stack trace Looks like an issue with PulseAudio and/or pulsesink. 17 <audio> elements are created to play wav files.
I've learned from Lennart that every Pulse client creates a 64MB shared memory region to hand out to all the streams that use Pulse. GStreamer opens one client per Pulsesink. Some limit on shared memory - in particular on 32bit machines - is 1GB. You do the math. :) No idea about the proper way to solve this. The easiest thing (if the API allows it) would probably be to reduce the shm size of the Pulse client inside GStreamer since we know it'll only get one stream.
(In reply to comment #2) > I've learned from Lennart that every Pulse client creates a 64MB shared memory > region to hand out to all the streams that use Pulse. GStreamer opens one > client per Pulsesink. Some limit on shared memory - in particular on 32bit > machines - is 1GB. > You do the math. :) > > No idea about the proper way to solve this. The easiest thing (if the API > allows it) would probably be to reduce the shm size of the Pulse client inside > GStreamer since we know it'll only get one stream. Well it seems that with current PA it would be quite difficult to do because the shm-size is configured on daemon side. So when the PA context is created by the client, the daemon will create a new pa_mempool based on the shm_size declared in daemon.conf. I found no public API to update that option. Sebastian proposed a better long term solution which would be to make all pulsesinks (in the same process) share a common context.
(In reply to comment #3) > Sebastian proposed a better long term solution which would be to make all pulsesinks (in the same process) share a common context. See https://bugzilla.gnome.org/show_bug.cgi?id=624338 ;)
(In reply to comment #4) > (In reply to comment #3) > > Sebastian proposed a better long term solution which would be to make all pulsesinks (in the same process) share a common context. > > See https://bugzilla.gnome.org/show_bug.cgi?id=624338 ;) With the patch above it still crashes, but differently! Assertion 'q->front' failed at pulsecore/queue.c:83, function pa_queue_push(). Aborting. Assertion 'q->front' failed at pulsecore/queue.c:83, function pa_queue_push(). Aborting. At least I can see that the PA context is being reused, from the gst logs. Now I can't manage to reproduce the crash and get a trace, no sound but I can see on PA output: W: ratelimit.c: 181 events suppressed
This page is no longer available, 404 :(
There is a working game at http://svg.kvalitne.cz/cavern/100/cavern.svg. Not sure whether the content is the same as the old URL, however...
Not sure if this is exactly the same bug, but at least I get this error message, which seems similar enough to post here: (WebKitWebProcess:26004): GStreamer-WARNING **: failed to create thread: Error creating thread: Resource temporarily unavailable What've done in my own python/webkit2gtk prototype browser is to simply play fast bullet chess games on lichess.org. For every move a sound is played, if it's enabled on the site. If it's not enabled, the browser process won't crash. But if it's enabled, sooner or later the WebKitWebProcess will always crash. The WebKit2WebView is_crashed signal isn't even emitted and you can't even reload the page. Would be nice if someone could just confirm my testcase by playing on lichess.org, which is free. Just make sure to play bullet chess, which triggers the problem consistently.
*** Bug 202567 has been marked as a duplicate of this bug. ***
The page can't be opened and I don't know how to reproduce the bug. I'd say to close it.