RESOLVED INVALID 32281
[GStreamer] Can't allocate memory and can't create thread
https://bugs.webkit.org/show_bug.cgi?id=32281
Summary [GStreamer] Can't allocate memory and can't create thread
Dirk Schulze
Reported 2009-12-08 12:09:48 PST
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?
Attachments
Stack trace (58.29 KB, text/plain)
2010-02-01 02:46 PST, Philippe Normand
no flags
Philippe Normand
Comment 1 2010-02-01 02:46:51 PST
Created attachment 47824 [details] Stack trace Looks like an issue with PulseAudio and/or pulsesink. 17 <audio> elements are created to play wav files.
Benjamin Otte
Comment 2 2010-02-08 03:07:22 PST
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.
Philippe Normand
Comment 3 2010-02-15 07:39:56 PST
(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.
Philippe Normand
Comment 4 2010-08-19 02:40:11 PDT
(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 ;)
Philippe Normand
Comment 5 2010-08-20 04:22:51 PDT
(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
Philippe Normand
Comment 6 2013-02-22 09:18:02 PST
This page is no longer available, 404 :(
Jonathon Jongsma (jonner)
Comment 7 2013-05-15 13:11:45 PDT
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...
anewtobi
Comment 8 2015-09-01 04:57:49 PDT
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.
Philippe Normand
Comment 9 2019-10-04 02:20:35 PDT
*** Bug 202567 has been marked as a duplicate of this bug. ***
Xabier Rodríguez Calvar
Comment 10 2021-04-14 04:11:06 PDT
The page can't be opened and I don't know how to reproduce the bug. I'd say to close it.
Note You need to log in before you can comment on or make changes to this bug.