まずは、別ユーザを作成して、真っ新なアカウントで問題が再現するか確認してみて下さい。
再現するようであれば、firefoxになんらかの問題があると推測されますが、同様の現象はネット検索しても見つからなかったので、再現しないような気がします。
再現しない場合は、プロファイルの問題の可能性が高いです。

皆様のコメントはこれから確認します。
3.6.25を別途インストールして回避しています。

新しいユーザを作成し、そちらで試しても症状は出ました。

apt-cache policy firefox
firefox:
  インストールされているバージョン: 9.0.1+build1-0ubuntu0.10.04.2
  候補: 9.0.1+build1-0ubuntu0.10.04.2
  バージョンテーブル:
*** 9.0.1+build1-0ubuntu0.10.04.2 0
        500 http://jp.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        100 /var/lib/dpkg/status
     3.6.24+build2+nobinonly-0ubuntu0.10.04.1 0
        500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages
     3.6.3+nobinonly-0ubuntu4 0
        500 http://jp.archive.ubuntu.com/ubuntu/ lucid/main Packages

firefox 9.0.1の導入方法は通常のパッケージマネージャーです。
何度か削除して再インストールしていますが、すべてそうです。

レポジトリまでいじるとなると大変なので、そこまでしないと難しいなら
当面は回避策の古いバージョンで行こうと思っています。

3.6の期限切れまでには、10.0が出るようなので、それに期待したいと思います。

残念なことに10でも同じでした。また、風呂ファイルを消して作り直しても駄目でした。
3.6と何が違うのか分かりませんが、ここを手がかりになんとかするしかないですね。

こんな方法はどうでしょうか。

新規ユーザを作成し（既にあればそれで）、ログイン
再現するか検証

再現した場合
    パッケージの依存や衝突、インストール済みファイルをチェックし、問題なければ
    ｆｉｒｅｆｏｘかシステムのバグ（upgradeしてみる？）
再現しない場合
    個人的な環境設定の見直し（ホームフォルダ以下の隠しフォルダ、ファイルをチェック）

10.0などはUbuntuのサポート外のものでしょうか。
ややこしくなるので、使用するバージョンは、標準レポジトリから導入できる9.0.1にしておいていただいた方がよいかと思います。

mozillaZineの方で示されているポインタの先は読まれましたでしょうか。
その中でビデオドライバに起因する問題が挙げられていますが、ハードウェアアクセラレーションの無効化は試してみましたか。

CrushReportの方をみると、なにかのライブラリで参照エラーを起こしているっぽいような気がしました。

sudo updatedb
locate firefox | grep firefox$

などとして、firefoxの場所を探し(おそらく/usr/lib/firefox-9.0.1/firefoxかと思います)、

ldd /usr/lib/firefox-9.0.1/firefox

した場合と、3.6.24との場合で比較してみると、なにか差分がでますでしょうか。

他に気になる点としては、環境変数のLD_LIBRARY_PATHを設定したりしているか、/etc/ld.so.conf.dあたりになにかファイルを追加しているか(標準外パッケージによるインストールも含めて確認要です)、あたりですね。

arata による投稿:

3.6のケース(改めてダウンロードして、デスクトップに解凍したものを使っています)
$ ldd /home/ikegi/デスクトップ/firefox3.6/firefox
        not a dynamic executable

mozillaのサイトからtar.bz2をダウンロードして伸長したものであれば、firefoxはshスクリプトになっていて、firefox-binの方がバイナリファイルのようです。
# lddすると差分を調べるのが厄介なぐらい多数のライブラリがリンクされていますね。。

arata による投稿:

Kubuntuからでは9.0となりますが、10.0がリリースされているので、firefoxが更新を勧めてきます。
これに応じたものとなります。
$ ldd /usr/lib/firefox-9.0.1/firefox
        linux-gate.so.1 =>  (0x00c5b000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x006dc000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00965000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x001ee000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x0046f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00561000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x002e4000)
        /lib/ld-linux.so.2 (0x0071c000)

もう、10.0がでているのですね。
こちらでも、本日更新されました。
そちらもシステムの更新を行うと10.0にアップデートされるかと思いますので、以降は10.0で考えましょう。

先に簡単に確認できる方をクリアにしておいた方がよさそうですが、ハードウェアアクセラレーションの無効化の方や、ライブラリパスの設定の方の確認状況いかがでしょうか。

ハードウェアアクセラレーションの無効化は効果がありませんでした。

すいません、横から失礼します。実は、まったく同じ問題で私も悩んでいて、つい6時間ほど前にポストしたばかりです。結果的にクロスポストとなり申し訳ありません。

こちらにも現状を試した内容を書いておきますが、
・リリースは10.04 LTS(すべての最新パッチを当てた状態)
・10.04 LTSでFirefox 9へのアップデート後、Crash Reporterが起動するトラブルが発生。
・Firefoxの9及び10で同様に発生。また、3台稼働しているコンピュータのすべてで発生。
・3台のコンピュータは、32bitと64bitが混在。いずれでも同じトラブルが発生。
・3台のコンピュータは、Firefox Syncで設定を同期(タブの設定を除く)。なお、MacやWindowsのFirefoxとも同期しているが、そちらでは同様のトラブルはなし。
・アドオンを1つずつ無効にした上での再起動を試したが、アドオンすべてで、同じトラブルが発生(つまり、どのアドオンを無効にしても問題が発生する)。
・「ハードウェアアクセラレーション機能を使用する」チェックボックスを外しても同じトラブルが発生
・.mozillaディレクトリの下にあるfirefoxディレクトリを別名待避し、新規設定に置き換えても同じトラブルが発生。
・過去の履歴を消去しても同じトラブルが発生。
・キャッシュをすべて消去しても同じトラブルが発生。

ただ、Crash Reporterが出ても、再起動すれば同様にFirefoxを使用できます。私も、「前回表示されていたタブを表示する」という設定にしているため、使用上大きな問題は起きていません(ただ、気味悪いということは確かですが)。

about:crashesでみてみますと、App Notesのところに「GLXtest process failed...」という分があります。これで試しに検索してみると、やはりUbuntu系でいくつかのトラブル報告が上がっているようです。

ご参考までに私のCrash Reportもつけておきます。
　　https://crash-stats.mozilla.com/report/index/bp-e7f786d0-9df8-4b99-99f0-da75e2120206

お二方ともクラッシュレポートによると，スタックフレーム６の gdk_display_close の呼び出しでセグメンテーションフォールトを起こしているようです．

6     libxul.so     MOZ_gdk_display_close　toolkit/xre/nsAppRunner.cpp:2525

arata さんのクラッシュレポートからはソースコードへのリンクが辿れれます．

私の読み間違いでなければ，ちょっと奇妙なことになっているような…

2485 bool buggyCairoShutdown = cairo_version() < CAIRO_VERSION_ENCODE(1, 4, 0);
2486
2487 if (!buggyCairoShutdown) {
2488 // We should shut down GDK before we shut down libraries it depends on
2489 // like Pango and cairo. But if cairo shutdown is buggy, we should
2490 // shut down cairo first otherwise it may crash because of dangling
2491 // references to Display objects (see bug 469831).
2492 if (!theme_is_qt)
2493 gdk_display_close(display);
2494 }

2495 から 2522までは pango の終了処理等があって，

2523 if (buggyCairoShutdown) {
2524 if (!theme_is_qt)
2525 gdk_display_close(display);
2526 }
2527 }

と続きます．

引用部分のコメントに cairo の終了が buggy ならば gdk_display_close を呼ぶタイミングを変えなければならないとあります．

2485 で cairo がbuggyな1.4.0より古いバージョンかを調べ，
buggy でなければ2493で，
buggy であるならば2525で
gdk_display_closeを呼ぶように読み取れます・
スタックフレームの情報ではお二方の環境で問題を起こしたのは2525のgdk_display_close，
つまり buggy な相当古い cairo を使っていると判定されていることになります．

パッケージサーチでは lucid の libcairo2 は 1.8.10 のはずです．

また，スタックフレームを眺めれば判るように問題を起こしているのは libxul.so なので，
ldd の対象はその共有ライブラリになります．