1. 技术文章
  2. Signal 11 SIGSEGV Crash in Galaxy S3 Android WebView

Signal 11 SIGSEGV Crash in Galaxy S3 Android WebView

由 百般思念 提交于 2019-11-29 20:19:37

I was playing around with your crashApp.

Using devices; ■ SHARP ISW16SH ■ LG optimus Vu L-06D (can't even survive after 3 ~ 10 pages)

These are the error that I often got. Fatal signal 11 (SIGSEGV) HEAP MEMORY CORRUPTION IN dlfree HEAP MEMORY CORRUPTION IN dlmalloc

Obviously, there's a memory allocation or double freeing problem. And it's not something that can be fix. (unless, NDK) the only solution I found is to hot-swap the webview on the fly. Always load the next page in the newly created webview will prevent this from happening. however, I can't seem to stop memory from dropping. Eventually Android will strike once your app grows into a memory eating monster.

I then start playing with two identical empty activity class. no xml. so,

onCreate() {
　　WebView wv = new WebView(context);
　　setContentView( wv );
}


void onDestroy() {
　　ViewGroup vg = (ViewGroup)game_wv.getParent();
　　vg.removeView(game_wv);
　　destroyWebView( game_wv );
　　game_wv = null;

　　super.onDestroy();
　　System.gc();　　//clean up what's freed in webViewLoadComplete (hopefully)
}

I also called another gc in the onPageFinished just to make sure the other activity is gone for good.

public final class WvClient extends WebViewClient {
　　public void onPageFinished(WebView wv, String url) {
　　　　webViewLoadComplete(game_wv);
　　　　System.gc();　　//clean up the other activity
　　}
}

here's the destroyWebView and webViewLoadComplete. I'm not so sure about some of the functions (like clearAnimation or clearDisappearingChildren) or what's the right order to call. I just... threw everything in there. ha

void destroyWebView( WebView wv ){
　　wv.stopLoading();
//　wv.pauseTimers();
　　wv.clearFormData();
　　wv.clearAnimation();
　　wv.clearDisappearingChildren();
　　wv.clearView();
//　wv.clearCache( true );
　　wv.clearHistory();
//　wv.clearMatches();
//　wv.clearSslPreferences();
　　wv.destroyDrawingCache();
　　wv.freeMemory();
　　wv.destroy();
}

void webViewLoadComplete( WebView wv ){
//　wv.stopLoading();
//　wv.pauseTimers();
//　wv.clearFormData();
　　wv.clearAnimation();
　　wv.clearDisappearingChildren();
//　wv.clearView();
////wv.clearCache( true );
//　wv.clearHistory();
////wv.clearMatches();
////wv.clearSslPreferences();
　　wv.destroyDrawingCache();
　　wv.freeMemory();
//　wv.destroy();
}

somehow, it worked...

Think the ultimate method might be using a NDK?

It is a chronic problem for lower RAM capacity Samsung devices. There is no solution.

I solved a number of low-level crashes, including crashes on 4.0.4, by disabling format-detection in the HEAD of the html page (this was suggested by a friend at Google):

<meta name="format-detection" content="telephone=no" />
<meta name="format-detection" content="email=no" />
<meta name="format-detection" content="address=no"/>

However, the 4.1.1 update brought these crashes back on the S3, and I haven't figured out a workaround this time.

You're not the only one with this problem, I've been googling and it seems that like this other guy http://developer.samsung.com/forum/thread/why-would-webview-hang-with-galaxy-s3-only/77/181155 there is a bug with html 5 on the stock navigator on the S3 (tried so on different roms from different countries), every S3 I tried crashed. Tried on chrome and it works beautifully. I'm sure there's a bug on the stock navigator.

I've been having this problem (or at least very similar) using http://fgnass.github.io/spin.js/

When I take that out of the page, there's no problem. Also seems to happen on Android 4.0 and 4.1 but not 4.3

We have not been able to find a solution other than to work around it and find something other than the spin.js spinner to use. Definitely seems like an Android problem though. What irks me is that it doesn't seem to be more widespread.

Chiming in with my case, as it is a bit different but had the same symptoms. I am maintaining the WebView instance across device rotations through a static variable*, but my mistake was calling WebView.restoreState on that instance when it was not necessary.

Erronous code:

private static FrameLayout _rootView;
@InjectView(R.id.main_webview)
WebView _webView;

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    boolean inflatingNow = _rootView == null;
    if (inflatingNow) {
        Container.Log.d(TAG, "onCreateView: rootView null. Recreating views");
        _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false);
    }
    else {
        Container.Log.d(TAG, "onCreateView: reusing previousely created views");
        ViewHelper.detachFromParent(_rootView); // Detaching from old container 
    }
    ButterKnife.inject(this, _rootView); // Will assign the _webView variable

    if (inflatingNow) {
        configureWebView(_webView);
    }
    if (savedInstanceState != null) {
        _webView.restoreState(savedInstanceState);
    }
    return _rootView;
}

Fixed code:

private static FrameLayout _rootView;
@InjectView(R.id.main_webview)
WebView _webView;

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)  {
    boolean inflatingNow = _rootView == null;
    if (inflatingNow) {
        Container.Log.d(TAG, "onCreateView: rootView null. Recreating views");
        _rootView = (ViewGroup) inflater.inflate(R.layout.fragment_main, container, false);
    }
    else {
        Container.Log.d(TAG, "onCreateView: reusing previousely created views");
        ViewHelper.detachFromParent(_rootView); // Detaching from old container 
    }
    ButterKnife.inject(this, _rootView);

    if (inflatingNow) {
        configureWebView(_webView);
        if (savedInstanceState != null) {
            _webView.restoreState(savedInstanceState);
        }
    }
    return _rootView;
}

*) As a side note I think this is a good approach to reducing the footprint of a device rotation. Added bonus is that the webview remains scrolled at the position the user was at, an no page reloading is needed. Note that this approach implies you're only using the fragment one place at a time in any given activity (singleton).

Personal experience:

I tried a lot of things, such as not using RelativeLayout, not drawing many things behind the webview, and MUCH more, as explained on many StackOverflow posts about this SIGSEGV 11 Webview issue.

Problem happens (only?) on 4.1 Android versions.

What worked for me:

  • I stopped using drawables made of RoundRectShape "close" to the WebView. Maybe something wrong between the hardware layer and round corners ?
  • I stopped putting views OVER the webview (such as a progress view).
  • I stopped making anything that would make the layout be re-computed while the webview is at work. Such as adding a view on my screen dynamically.

Still, there is sometimes a crash due to something else, mostly when going to another activity and coming back to the WebView. In logs, I can see something like "webcoreview: nativeDestroy", probably meaning that something seems to be used then used by someone right after. Then the SIGSEGV 11 appears.

But at least, that happens much less frequently.

标签
android
html5
webview
segmentation-fault
galaxy
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!