Bug 32281 - [GStreamer] Can't allocate memory and can't create thread
Summary: [GStreamer] Can't allocate memory and can't create thread
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://svg.kvalitne.cz/cavern/100/cav...
Keywords:
: 202567 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-12-08 12:09 PST by Dirk Schulze
Modified: 2021-04-14 04:19 PDT (History)
9 users (show)

See Also:


Attachments
Stack trace (58.29 KB, text/plain)
2010-02-01 02:46 PST, Philippe Normand
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Schulze 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?
Comment 1 Philippe Normand 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.
Comment 2 Benjamin Otte 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.
Comment 3 Philippe Normand 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.
Comment 4 Philippe Normand 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 ;)
Comment 5 Philippe Normand 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
Comment 6 Philippe Normand 2013-02-22 09:18:02 PST
This page is no longer available, 404 :(
Comment 7 Jonathon Jongsma (jonner) 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...
Comment 8 anewtobi 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.
Comment 9 Philippe Normand 2019-10-04 02:20:35 PDT
*** Bug 202567 has been marked as a duplicate of this bug. ***
Comment 10 Xabier Rodríguez Calvar 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.