[K12OSN] Crashing Firefox on terminal in new un-messed with install

Jim McQuillan jam at mcquil.com
Fri Apr 7 23:09:23 UTC 2006


Jim,

LTSP-4.2 has some code in it that limits the amount of memory the X-server
is allowed to use.

Client applications, like firefox are constantly asking the Xserver to
allocate memory, to store things like pixbufs (images) and fonts.

In the past, the xserver would just happily go along and allocate as much
memory as it possibly could, until it uses up ALL memory, and the kernel
would come along and start killing things, to free up some space.  Almost
always, the Xserver would get killed, causing you to lose your session.

Now, with the mechanism that we use to tell the Xserver how much memory
it's allowed to allocate, it will stop BEFORE the kernel kills it.

Unfortunately, client applications don't respond very well to the Xserver
refusing to allocate memory.

In LTSP-4.2, we default to allowing the Xserver to grab 90% of the free
memory.  You can tune it by setting 'XRAMPERC = xx', where 'xx' is the
percentage of free memory that you want to allow the Xserver to use.

To restore the old behaviour from pre-4.2, you can set XRAMPERC = 100
and it will allow the Xserver to grab ALL available memory.

THat additional 10% will probably help out quite a bit.

The other thing you can do is increase the amount of available ram, by
either adding more physical ram, OR, enabling swap over NBD.

I'm not sure if Eric is including ltspswapd.  If he's not, i'll encourage
him to add it, and probably start it by default.

As for documentation on using swap over NBD, I know Scott Balneaves has
been working on writing something up, but I don't know if he's finished
that.

Hope that looooong explanation helps,

Jim McQuillan
jam at Ltsp.org

On Fri, April 7, 2006 6:57 pm, Jim Christiansen wrote:
> I wish it wasn't Friday afternoon...  I'll miss all of you guys for the
> weekend!
>
> I've redone the install on my home test server of the new FC5 with Eric's
> new ltsp packages to confirm my troubles.  What happens on a client is
> that
> when even called by root, Firefox on certain pages (many) will crash with
> the following message in a console:
>
> [root at christiansens ~]# /opt/firefox/firefox
> The program 'firefox-bin' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
>   (Details: serial 42238 error_code 11 request_code 53 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error()
> function.)
>
> On the server, the same webpage loads.  This page is nothing compliated on
> many of the crashing pages and this one is served off of my webserver.
> The
> example crashing page is a large image.  Other pages that crash die so
> fast
> I don't even know what is on them...
>
> I should have checked on the server to see how how the crashing webpages
> behaved days ago... This is my third install and I figured I was messing
> things up with plugins as all of the libraries may have been mixed up
> between 32 and 64 bit versions- but I guess this isn't the case.  Firefox
> dies even without any plugins installed.  No Acroread, java or flash...no
> audio, xine libs, mplayer plugins... nothing extra.
>
> Any ideas appreciated!!  Fire away  :-)
>
> Thanks,  Jim
>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>





More information about the K12OSN mailing list