question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

SIGSEGV crash with ART library on Android

See original GitHub issue

This issue is somewhat intermittent, but I have managed to create a minimal example that will crash with some regularity. When the ART library is used to render a component it seems it will cause a crash on Android after it has rendered several times. This issue happens looks to have started with React Native 0.21 and only happens on Android.

Unfortunately the crash happens deep in libc and tracing the cause of the issue has been difficult. The code below reproduces the issue on Android. It will sometimes crash quite quickly (within seconds) and sometimes takes a bit longer (tens of seconds) with an error in the log like:

A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x9fa40028 in tid 4388 (mqt_js)

import React, { Text, View } from 'react-native';
const { Surface, Group, Shape } = React.ART;

const Smiley = React.createClass({
  render() {
    return (
      <Surface width={32} height={32}>
        <Group scaleX={1} scaleY={1} rotation={this.props.rotation} originX={16} originY={16} opacity={this.props.opacity}>
          <Group>
            <Shape fill="#222" d="M16 .004 c-8.837 0 -16 7.164 -16 16 0 8.837 7.163 16 16 16 s16 -7.163 16 -16 c0 -8.836 -7.163 -16 -16 -16 z m0 29 c-7.16 0 -12.985 -5.832 -12.985 -13 s5.825 -13 12.985 -13 c7.16 0 12.985 5.832 12.985 13 s-5.825 13 -12.985 13 z"/>
            <Shape fill="#222" d="M7.932 12.77 A2.513 2.5 0 1 0 12.958 12.77 A2.513 2.5 0 1 0 7.932 12.77 z"/>
            <Shape fill="#222" d="M18.872 12.77 A2.513 2.5 0 1 0 23.898000000000003 12.77 A2.513 2.5 0 1 0 18.872 12.77 z"/>
            <Shape fill="#222" d="M24.054 18.39 a1.006 1.006 0 0 0 -.85 .01 c-.005 .004 -.01 .003 -.015 .006 l-.98 .506 c-.62 .278 -1.4 .664 -2.43 .992 -1.04 .328 -2.53 .503 -4.09 .575 -1.56 -.08 -3.05 -.25 -4.09 -.58 -1.04 -.33 -1.82 -.72 -2.43 -.99 l-.97 -.51 -.02 -.01 a1 1 0 0 0 -.85 -.01 .992 .992 0 0 0 -.5 1.32 c1.59 3.502 4.93 5.79 8.58 5.946 .05 .01 .5 .01 .552 0 3.65 -.16 6.99 -2.444 8.582 -5.946 a1 1 0 0 0 -.503 -1.322 z"/>
          </Group>
        </Group>
      </Surface>
    );
  },
});

class CrashTestDummy extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0,
    };
  }

  componentDidMount() {
    setInterval(() => { this.state && this.setState({count: this.state.count + 1}) }, 20);
  }

  render() {
    return (
      <View style={{flex: 1, justifyContent: "center", alignItems: "center"}}>
        <Text>
          Count: {this.state.count}
        </Text>
        <Smiley/>
      </View>
    );
  }
}

React.AppRegistry.registerComponent('CrashTestDummy', () => CrashTestDummy);

I’ve noticed that when I use a more complex component that contains more ART elements, it crashes more quickly, suggesting a memory issue.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:29
  • Comments:49 (16 by maintainers)

github_iconTop GitHub Comments

16reactions
ggsrivascommented, Aug 29, 2016

Did anyone find any workaround or solution to this? I am facing the same issue.

9reactions
experimentsincommented, Jun 17, 2016

We see this too. A lot in debug mode. From the dumps, it looks like a crash on the JSC (JavaScriptCore) execution thread.

I started thinking in terms of building a debug version of JSC to see if we could get more information. What I found wasn’t entirely encouraging. The JSC build used in React Native seems to come from here:

https://github.com/facebook/android-jsc

and is only buildable with Buck out of the box. I also looked to see which version of JSC it was based on. In fetch_sources.sh it grabs:

http://builds.nightly.webkit.org/files/trunk/src/WebKit-r174650.tar.bz2

I searched for that version here:

https://webkit.org/nightly/archives/

and the timestamp on it is: October 14, 2014 1:09 PM GMT.

I would suggest that the dependence of React Native for Android on an 18 month old (and counting) snapshot of JSC should be of some concern to us all.

Read more comments on GitHub >

github_iconTop Results From Across the Web

android - Native library crashes on accessing the method with ...
"Sometimes" in most situations means that out-of-bounds memory writing happens. Verify that you are not doing it in method1.
Read more >
Diagnosing Native Crashes | Android Open Source Project
The following sections include common types of native crash, an analysis of a sample crash dump, and a discussion of tombstones.
Read more >
diagnosing segv_accerr in shared library - Google Groups
I'm trying to figure out why I get a SEGV_ACCERR in my app when the shared library called via ndk and jni throws...
Read more >
ART Crashed with Segmentation Fault [226413323]
The enclosed test.jar triggers a segmentation fault in ART. ... 10455 10455 F DEBUG : #00 pc 00000000004b9185 /apex/com.android.art/lib64/libart.so (void ...
Read more >
Android app crash on startup - SIGSEGV - Kivy/KivyMD - Reddit
Android app crash on startup - SIGSEGV - Kivy/KivyMD ... 17:29:36.295 1820 1842 I art : Starting a blocking GC Explicit 08-22 17:29:36.307 ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found