How do you force Firefox to not eat all your memory?

[D. Hugh Redelmeier]

| From: Dave Mason <dmason-bqArmZWzea/GcjXNFnLQ/w at public.gmane.org>

| It saves a shell process hanging around.  Consider it a twitch from when
| it mattered that I usually exec in such wrapper scripts.

Understood.

I'm trying to catch to crashes.  So I do this in an xterm window:

 $ script possible-firefox-crash.typescript47
 $ ulimit -c 20000	# allow core dumps.
 $ date ; firefox --sync ; date

For various reasons, this hasn't been very satisfactory.

- fedora's debug symbol downloader was broken for a while (probably
  due to their repository changover)

- firefox often bails with no core dump (it decides to suicide rather
  than crash)

- I sometimes forget to start it up this way

- the typescript has no timestamps so I don't know which logged
  messages appeared close in time to the termination.

Here's a tail of the most recent capture (probably not an OOM problem):

GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback return
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback: setting status Dispose: applet not destroyed.
  PIPE: plugin read: status Destroy: applet not stopped.
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback return
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback: setting status Dispose: applet not destroyed.
  PIPE: plugin read: status Dispose: applet not destroyed.
GCJ PLUGIN: thread 0xb82590: plugin_in_pipe_callback return
GCJ PLUGIN: thread 0xb82590: GCJ_Destroy
GCJ PLUGIN: thread 0xb82590: plugin_send_message_to_appletviewer
  PIPE: appletviewer read: destroy
  PIPE: plugin wrote: destroy
GCJ PLUGIN: thread 0xb82590: plugin_send_message_to_appletviewer return
GCJ PLUGIN: thread 0xb82590: plugin_stop_appletviewer
GCJ PLUGIN: thread 0xb82590: plugin_stop_appletviewer return
GCJ PLUGIN: thread 0xb82590: plugin_data_destroy
GCJ PLUGIN: thread 0xb82590: GCJ_New: deleting output fifo: /home/hugh/.gcjwebplugin/gcj-instance-10770-0-plugin-to-appletviewer
GCJ PLUGIN: thread 0xb82590: GCJ_New: deleted output fifo: /home/hugh/.gcjwebplugin/gcj-instance-10770-0-plugin-to-appletviewer
GCJ PLUGIN: thread 0xb82590: GCJ_New: deleting input fifo: /home/hugh/.gcjwebplugin/gcj-instance-10770-0-appletviewer-to-plugin
GCJ PLUGIN: thread 0xb82590: GCJ_New: deleted input fifo: /home/hugh/.gcjwebplugin/gcj-instance-10770-0-appletviewer-to-plugin
GCJ PLUGIN: thread 0xb82590: plugin_data_destroy return
GCJ PLUGIN: thread 0xb82590: GCJ_Destroy return
GCJ PLUGIN: thread 0xb82590: NP_Shutdown
GCJ PLUGIN: thread 0xb82590: NP_Shutdown return
  PIPE: appletviewer read: shutdown
APPLETVIEWER: exiting appletviewer
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadIDChoice (invalid resource ID chosen for this connection)'.
  (Details: serial 139381220 error_code 14 request_code 148 minor_code 4)
  (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.)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists