Android で WebView を使ってると、signal 11 (SIGSEGV) で落ちることが多々ありました。
具体的には、mWebView.reload(); や、adb から再インストール→起動した時、などに発生します。

調べたところ、次の組み合わせで落ちていた模様。

mWebView.getSettings().setCacheMode(WebSettings.LOAD_DEFAULT);
mWebView.getSettings().setJavaScriptEnabled(true);

js ファイルのキャッシュが悪さをしている…？

解決策１：Javascript をオフにしてみる

mWebView.getSettings().setJavaScriptEnabled(false);

とりあえず落ちなくなりました。でも Javascript が使えないと困ります。

解決策２：キャッシュをオフにしてみる

mWebView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);

これでも落ちなくなりました。でもキャッシュは使いたいです。

解決策３：onPageStarted 時にキャッシュをクリアしてみる

public void onPageStarted(WebView webView, String url, Bitmap favicon) {
webView.clearCache(true);
}

解決策２とあまり変わりません。
ここで js ファイルのキャッシュのみ削除とかができれば良さそうなのですが…。

解決策４：js ファイルのみキャッシュが発生しないようにしてみる

よくある js ファイルの URL を毎回変えてあげる手です。
通信量が増える、キャッシュが膨れ上がる、そもそもサーバー側が弄れない場合は使えない、などなど多々問題がありますが、
場合によってはこれで解決できそうです。

追記（未検証）：shouldInterceptRequest でごにょごにょ

shouldInterceptRequest を使えば、js がリクエストされたときのみ独自で js を取得するなどが可能かも。
ただ shouldInterceptRequest を使うことで SIGSEGV が発生する事例もあるようなので、
もっと根が深いところで落ちてるのかも…。
もうちょっと検証する必要がありそうです。

補足

data/data/{パッケージ名}/caches
data/data/{パッケージ名}/databases

キャッシュはこのあたりに sqlite などで入ってるようです。
興味がある人は覗いてみるといろいろ分かるかも知れません。
onPageStarted 時にここを直接弄るという手も考えたのですが、今後も通じるとは限らないのでオススメはできません。