FATAL SIGNAL 11 (Sigsegv) at 0x00000000 (code=1)?

Question

Why does this problem occur?

public static String path;
private VideoView mVideoView;


mVideoView = (VideoView) findViewById(R.id.surface_view);
mVideoView.setVideoPath(path);
mVideoView.setMediaController(new MediaController(this));
mVideoView.requestFocus();

//...

    private int mLayout = VideoView.VIDEO_LAYOUT_ZOOM;

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        if (mVideoView != null)
            mVideoView.setVideoLayout(mLayout, 0);
        super.onConfigurationChanged(newConfig);
    }

Answer 1

I had the same problem using samsung galaxy tab 2 loading any WiX website getting:

Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)

and exiting the whole application.

Researching more, I found a post talking about a ROM BUG. So, I plug a phone and F11 (eclipse) to compile the same code. And... It's is working! I'm still getting the error in my tablet.

TABLET: Samsung Galaxy Tabg 2 GT-P5100 ANDROID 4.0.3 KERNEL 3.0.8

PHONE: Samsung Galaxy Young DUOS (old but firmware updated) GT-S6102B ANDROID 4.4.2 KERNEL 2.6.35.7

Work in my phone, but crashes on tablet when I load any website made with WiX tool.

good information here: google+ link

Answer 2

Most likely a threading problem... I once ran in a Fatal Signal 11 as well, when I was doing stuff on the wrong thread...

Probably the setVideoLayout()-call in you onConfigurationChanged() implementation.

Would be helpful tho, if you could post some more code...

Answer 3

I had a similar problem when finishing my activity with two TextureViews (i.e. pressing the home button):

Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa4680000 in tid 29013 (pool-4-thread-1)

The logcat showed that the segv showed up inside a drawXXX function. So I tried to not draw when the surface is destroyed:

private synchronized void doDraw(Canvas canvas) {
...
}

doDraw() is called regularly by a background thread. To be precise, using a ScheduledExecutorService. This thingy is stopped in the destroyed listener, which also got the synchronized keyword:

public synchronized boolean onSurfaceTextureDestroyed(SurfaceTexture surfaceTexture) {
    executorService.shutdownNow();
    return true;
}

This guarantees that the surface can only be destroyed when currently nothing is drawn.

No more crashes on leaving the activity now!

It seems to me that nobody is using TextureViews but still SurfaceViews. Unfortunately, the latter has some problems when drawing translucent graphics on some devices, that's why I switched to TextureView.

Hope this helps.

Answer 4

The error message you are seeing is caused by dereferencing a null pointer in native code. From what you show it's hard to guess what may be the cause.

In your place I'd double check that you're not passing a null references to a system or library method.

Answer 5

You can see from the last Garbage Collection call that the garbage collector has failed to free any memory and that you you have no memory available. How big are your buffers? How much additional head room do they need?

One possible solution is to investigate using the larger heap size by setting android:largeHeap="true" to allow large heap size in your application manifest, documented on the developers site..

Answer 6

As mentioned by Nicola, this is most likely caused by dereferencing a null pointer in the native code. I had a similar issue and resolved it by debugging the stack trace.

If you turn off filtering in your log cat, you will see the entire stack trace. This will give you detailed information at where the crash occurred, I used the following python script in order to find the exact cause; https://code.google.com/p/android-ndk-stacktrace-analyzer/wiki/Usage

In my case a null pointer was occurring due to running a custom android build.

Good luck