[0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 #18292

wuxudong · 2018-03-09T10:29:41Z

In project react-native-chart-wrapper#229, It works well in react-native 0.53.0, but will crash in react-native 0.54.0 when data points are more than 512 in android platform.

On further review, I found the crash is related to jni function ReadableNativeArray.getType(index).

In react-native 0.53.0, ReadableNativeArray.getType(index) will only care the type at the index,
but in react-native 0.54.0, ReadableNativeArray.getType(index) will get type of every element in the array, then return the type at index, but crash if array.size > 512.

Environment

Environment:
OS: macOS High Sierra 10.13.3
Node: 9.3.0
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: 2.3 AI-162.4069837

Packages: (wanted => installed)
react: 16.1.1 => 16.1.1
react-native: 0.54.0 => 0.54.0

Expected Behavior

ReadableNativeArray.getType(index) can return element type at index when ReadableNativeArray.size > 512

Actual Behavior

It crash. Log is listed below.

03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422] DALVIK THREADS (25):
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422] "main" prio=7 tid=1 Runnable
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   | group="" sCount=0 dsCount=0 obj=0x753ad610 self=0xf218b400
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   | sysTid=1777 nice=-4 cgrp=default sched=0/0 handle=0xf6b30534
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   | state=R schedstat=( 2092057505 231514723 12205 ) utm=164 stm=44 core=1 HZ=100
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   | stack=0xff2a0000-0xff2a2000 stackSize=8MB
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   | held mutexes= "abort lock" "mutator lock"(shared held)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #00 pc 0057302e  /system/lib/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+238)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #01 pc 0053f40e  /system/lib/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+526)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #02 pc 0053c40b  /system/lib/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+75)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #03 pc 0055c00b  /system/lib/libart.so (_ZN3art14DumpCheckpoint3RunEPNS_6ThreadE+1115)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #04 pc 005522ce  /system/lib/libart.so (_ZN3art10ThreadList13RunCheckpointEPNS_7ClosureE+590)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #05 pc 00551e42  /system/lib/libart.so (_ZN3art10ThreadList4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEb+962)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #06 pc 00528268  /system/lib/libart.so (_ZNK3art10AbortState14DumpAllThreadsERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEPNS_6ThreadE+424)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #07 pc 00527fb6  /system/lib/libart.so (_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+1078)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #08 pc 0051832b  /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+155)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #09 pc 0011a653  /system/lib/libart.so (_ZN3art10LogMessageD1Ev+1747)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #10 pc 002cd248  /system/lib/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+376)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #11 pc 003d9f07  /system/lib/libart.so (_ZN3art3JNI11NewLocalRefEP7_JNIEnvP8_jobject+919)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #12 pc 0013f9db  /system/lib/libart.so (_ZN3art8CheckJNI6NewRefEPKcP7_JNIEnvP8_jobjectNS_15IndirectRefKindE+1083)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #13 pc 0012d419  /system/lib/libart.so (_ZN3art8CheckJNI11NewLocalRefEP7_JNIEnvP8_jobject+57)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #14 pc 0003df8b  /data/app/com.example-1/lib/x86/libreactnativejni.so (???)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #15 pc 0003e27a  /data/app/com.example-1/lib/x86/libreactnativejni.so (???)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #16 pc 00046988  /data/app/com.example-1/lib/x86/libreactnativejni.so (???)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #17 pc 000489b5  /data/app/com.example-1/lib/x86/libreactnativejni.so (???)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #18 pc 00049c55  /data/app/com.example-1/lib/x86/libreactnativejni.so (???)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   native: #19 pc 00064abc  /data/app/com.example-1/oat/x86/base.odex (Java_com_facebook_react_bridge_ReadableNativeArray_importTypeArray__+104)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.facebook.react.bridge.ReadableNativeArray.importTypeArray(Native method)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.facebook.react.bridge.ReadableNativeArray.getLocalTypeArray(ReadableNativeArray.java:72)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   - locked <0x0235b8bf> (a com.facebook.react.bridge.ReadableNativeArray)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.facebook.react.bridge.ReadableNativeArray.getType(ReadableNativeArray.java:166)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.github.wuxudong.rncharts.data.LineDataExtract.createEntry(LineDataExtract.java:91)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.github.wuxudong.rncharts.data.DataExtract.createEntries(DataExtract.java:66)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.github.wuxudong.rncharts.data.DataExtract.extract(DataExtract.java:35)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at com.github.wuxudong.rncharts.charts.ChartBaseManager.setData(ChartBaseManager.java:420)
03-09 01:25:03.294  1777  1777 F art     : art/runtime/runtime.cc:422]   at java.lang.reflect.Method.invoke!(Native method)



03-09 01:25:03.353  1888  1888 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-09 01:25:03.353  1888  1888 F DEBUG   : Build fingerprint: 'Android/vbox86p/vbox86p:7.1.1/NMF26Q/genymo03202243:userdebug/test-keys'
03-09 01:25:03.353  1888  1888 F DEBUG   : Revision: '0'
03-09 01:25:03.353  1888  1888 F DEBUG   : ABI: 'x86'
03-09 01:25:03.353  1888  1888 F DEBUG   : pid: 1777, tid: 1777, name: com.example  >>> com.example <<<
03-09 01:25:03.353  1888  1888 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
03-09 01:25:03.354  1888  1888 F DEBUG   : Abort message: 'art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): local reference table overflow (max=512)'
03-09 01:25:03.354  1888  1888 F DEBUG   :     eax 00000000  ebx 000006f1  ecx 000006f1  edx 00000006
03-09 01:25:03.354  1888  1888 F DEBUG   :     esi f6b3058c  edi f6b30534
03-09 01:25:03.354  1888  1888 F DEBUG   :     xcs 00000023  xds 0000002b  xes 0000002b  xfs 0000006b  xss 0000002b
03-09 01:25:03.354  1888  1888 F DEBUG   :     eip f6a5cbb9  ebp ffa98a28  esp ffa989cc  flags 00000296
03-09 01:25:03.356  1888  1888 F DEBUG   : 
03-09 01:25:03.356  1888  1888 F DEBUG   : backtrace:
03-09 01:25:03.356  1888  1888 F DEBUG   :     #00 pc 00000bb9  [vdso:f6a5c000] (__kernel_vsyscall+9)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #01 pc 0007a30c  /system/lib/libc.so (tgkill+28)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #02 pc 00075b55  /system/lib/libc.so (pthread_kill+85)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #03 pc 0002786a  /system/lib/libc.so (raise+42)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #04 pc 0001ee46  /system/lib/libc.so (abort+86)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #05 pc 005184c5  /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+565)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #06 pc 0011a653  /system/lib/libart.so (_ZN3art10LogMessageD1Ev+1747)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #07 pc 002cd248  /system/lib/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+376)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #08 pc 003d9f07  /system/lib/libart.so (_ZN3art3JNI11NewLocalRefEP7_JNIEnvP8_jobject+919)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #09 pc 0013f9db  /system/lib/libart.so (_ZN3art8CheckJNI6NewRefEPKcP7_JNIEnvP8_jobjectNS_15IndirectRefKindE+1083)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #10 pc 0012d419  /system/lib/libart.so (_ZN3art8CheckJNI11NewLocalRefEP7_JNIEnvP8_jobject+57)
03-09 01:25:03.356  1888  1888 F DEBUG   :     #11 pc 0003df8b  /data/app/com.example-1/lib/x86/libreactnativejni.so
03-09 01:25:03.356  1888  1888 F DEBUG   :     #12 pc 0003e27a  /data/app/com.example-1/lib/x86/libreactnativejni.so
03-09 01:25:03.356  1888  1888 F DEBUG   :     #13 pc 00046988  /data/app/com.example-1/lib/x86/libreactnativejni.so
03-09 01:25:03.356  1888  1888 F DEBUG   :     #14 pc 000489b5  /data/app/com.example-1/lib/x86/libreactnativejni.so
03-09 01:25:03.356  1888  1888 F DEBUG   :     #15 pc 00049c55  /data/app/com.example-1/lib/x86/libreactnativejni.so
03-09 01:25:03.356  1888  1888 F DEBUG   :     #16 pc 004e7abc  /data/app/com.example-1/oat/x86/base.odex (offset 0x483000)
03-09 01:25:03.635   577  1893 W ActivityManager:   Force finishing activity com.example/.MainActivity

Steps to Reproduce

I create a simplified project to reproduce the crash without using any third party library.

The main code is listed below.

DummyManager.java

public class DummyManager extends SimpleViewManager<TextView> {
    @Override
    public String getName() {
        return "RNTypes";
    }

    @Override
    protected TextView createViewInstance(ThemedReactContext reactContext) {
        TextView textView = new TextView(reactContext);
        return textView;
    }

    @ReactProp(name = "data")
    public void setData(TextView textView, ReadableArray data) {
        if (data.size() > 0) {
            textView.setText(data.getType(0).toString());
        }
    }
}

Types.js

class Types extends React.Component {
  getNativeComponentName() {
    return 'RNTypes'
  }

  render() {
    return <RNTypes {...this.props} />;
  }
}

Types.propTypes = {
  ...View.propTypes,
  data: PropTypes.arrayOf(PropTypes.number)
}

var RNTypes = requireNativeComponent('RNTypes', Types)

App.js

export default class App extends React.Component {
 constructor() {
    super();

    this.state = {
      data: Array.from(new Array(500), (val, index) => index),     
    }
  }

  render() {
    return (
      <View style={styles.container}>
        <Text>Type of first element of data</Text>
        <Types data={this.state.data} style={{height:30, width:100}}/>
        
       
      </View>
    );
  }
}

If array size in App.js = 500, it works well, and will crash if array size > 512.

It works well in react-native 0.53.0

The text was updated successfully, but these errors were encountered:

react-native-bot · 2018-03-09T10:30:06Z

Thanks for posting this! It looks like your issue may refer to an older version of React Native. Can you reproduce the issue on the latest stable release?

Thank you for your contributions.

_{How to Contribute • What to Expect from Maintainers}

wuxudong · 2018-03-09T10:37:23Z

I check the code in 0.55.0 and latest master branch, the problem remains. You can find the code analysis here, and reproduce the crash in this project

hramos · 2018-03-09T20:34:41Z

My first reaction when I read the issue is that this is something the chart library would need to address, but on further review it looks like you were able to isolate the issue and reproduce it without using the third party library.

Would you consider rewriting the issue a bit to fill out the repro steps more clearly? For example, expecting "render chart with more than 512 points" could be interpreted as something that is not the core library's concern. It would help community members understand the issue at a glance before deciding to dive in. Thanks!

wuxudong · 2018-03-10T01:54:57Z

I updated the issue a little bit to make it more clear.

wuxudong · 2018-03-15T03:34:55Z

Any progress?

shibbyy · 2018-04-16T08:43:27Z

Waiting for an update regarding this issue.

wuxudong · 2018-04-16T08:57:01Z

ReadableNativeArray.setUseNativeAccessor(true);
ReadableNativeMap.setUseNativeAccessor(true);

can be a temporary workaround.

wkrause13 · 2018-04-21T20:15:19Z

@wuxudong, thanks for suggesting a workaround. Where in your project are you setting?

ReadableNativeArray.setUseNativeAccessor(true);
ReadableNativeMap.setUseNativeAccessor(true);

wuxudong · 2018-04-22T01:20:23Z

I think xxApplication is a good place for it.

 @Override
    public void onCreate() {
        super.onCreate();
        SoLoader.init(this, /* native exopackage */ false);

        // call for react native >= 0.54.0
        // ReadableNativeArray.setUseNativeAccessor(true);
        // ReadableNativeMap.setUseNativeAccessor(true);
        try {
            Method arrayUseNativeAccessor = ReadableNativeArray.class.getDeclaredMethod("setUseNativeAccessor", boolean.class);
            if (arrayUseNativeAccessor != null) {
                arrayUseNativeAccessor.invoke(null, true);
            }

            Method mapUseNativeAccessor = ReadableNativeMap.class.getDeclaredMethod("setUseNativeAccessor", boolean.class);
            if (mapUseNativeAccessor != null) {
                mapUseNativeAccessor.invoke(null, true);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }


    }

hugows · 2018-04-25T18:36:17Z

@wuxudong Actually adding those two lines crashes the app.

I actually moved to react-native-charts-wrapper to better performance/zooming so stopping at 512 elements is a deal breaker..

-- edit --

Those lines stopped crashing the app when I also pasted this there:

SoLoader.init(this, /* native exopackage */ false); // ???

Traviskn · 2018-05-04T16:14:59Z

I am also running into this issue, but I see it when using react-native-sqlite-storage to insert large amounts of data. We can work around by decreasing the batch size of data we import, but it causes performance issues for our use case.

F/art     ( 7563): art/runtime/indirect_reference_table.cc:98] JNI ERROR (app bug): local reference table overflow (max=512)
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98] local reference table dump:
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]   Last 10 entries (of 507):
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       506: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       505: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       504: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       503: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       502: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       501: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       500: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       499: 0x12f88aa0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       498: 0x12f88ab0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       497: 0x12f88ab0 com.facebook.react.bridge.ReadableType
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]   Summary:
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]       505 of com.facebook.react.bridge.ReadableType (3 unique instances)
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]         1 of com.facebook.react.bridge.ReadableNativeArray
F/art     ( 7563): art/runtime/indirect_reference_table.cc:98]         1 of java.lang.Object[] (780 elements)

Traviskn · 2018-05-04T16:38:24Z

@wuxudong's workaround seems to prevent this issue, we put the setUseNativeAccessor calls in the onCreate of our MainApplication class

objHua · 2018-05-28T11:09:56Z

is there any new progress? I have also encountered this issue. version 0.54.3

gaodeng · 2018-08-11T05:45:24Z

any news on this?

dryganets · 2018-08-29T00:50:07Z

@hramos, this is a pretty standard JNI problem.

I think the problem in the methods below - you are trying to return an array of local references there I think this might trigger the limit check. Try to pass big enough data chunk through the bridge and it will choke.

  jni::local_ref<jni::JArrayClass<jstring>> importKeys();
  jni::local_ref<jni::JArrayClass<jobject>> importValues();
  jni::local_ref<jni::JArrayClass<jobject>> importTypes();

One possible solution is to convert the refs to globals before putting to array and release the local refs. There is a 64k limit for global references as well. Unlikely somebody will pass such a big data structure, but everything is possible. Some modules transfer DB responses using NativeMap and NativeArray.

Another solution is to chunk the data from native for these methods.

I hope you measuring this carefully. The whole Arrays/Maps rework looks like a big landmine to me now, I glad you leave a way to turn it off.

Once it will be fixed appropriately the performance gain should be re-evaluated ...

dryganets · 2018-08-29T19:00:44Z

I think I found the problem.
Ironically, the local_ref's release method doesn't release anything.
The local_ref is an alias for the basic_strong_ref with LocalRefAllocator.
basic_strong_ref release method returns the current reference and sets the internal reference to null, it doesn't perform release action.

to release it reset should be called. Will publish PR with the fix soon :)
I think you need to fix you refs - with such design it is really easy to make a mistake, the good thing in java it crashes eventually, in other places you could just have memory leaks.

Summary: release method of local_ref and global_ref doesn't call deallocator, in fact, it leaves the caller responsible for deletion of the reference, while otherwise the reference is released on scope left. Fixes facebook#18292. Pull Request resolved: facebook#20913 Differential Revision: D9616237 Pulled By: hramos fbshipit-source-id: 021aa3e4f039e6b7a98da3e4224c1ee49d5a4921

coldbess · 2018-10-30T08:46:03Z

RN0.57.5 will be solved
react-native-community/releases#54 (comment)

Summary: release method of local_ref and global_ref doesn't call deallocator, in fact, it leaves the caller responsible for deletion of the reference, while otherwise the reference is released on scope left. Fixes #18292. Pull Request resolved: #20913 Differential Revision: D9616237 Pulled By: hramos fbshipit-source-id: 021aa3e4f039e6b7a98da3e4224c1ee49d5a4921

Summary: release method of local_ref and global_ref doesn't call deallocator, in fact, it leaves the caller responsible for deletion of the reference, while otherwise the reference is released on scope left. Fixes facebook#18292. Pull Request resolved: facebook#20913 Differential Revision: D9616237 Pulled By: hramos fbshipit-source-id: 021aa3e4f039e6b7a98da3e4224c1ee49d5a4921

react-native-bot added Old Version Ran Commands One of our bots successfully processed a command. labels Mar 9, 2018

hramos added Issue: Author Provided Repro This issue can be reproduced in Snack or an attached project. and removed Old Version labels Mar 9, 2018

wuxudong changed the title ~~[0.54.0] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512~~ [0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 Mar 10, 2018

react-native-bot added Android Ran Commands One of our bots successfully processed a command. labels Mar 13, 2018

react-native-bot added Android Ran Commands One of our bots successfully processed a command. labels Mar 18, 2018

janicduplessis removed the Android label Mar 18, 2018

react-native-bot added Platform: Android Android applications. Ran Commands One of our bots successfully processed a command. labels Mar 18, 2018

janicduplessis removed the Android 🤖 label Mar 19, 2018

react-native-bot added the Platform: macOS Building on macOS. label Mar 20, 2018

hramos removed the Platform: macOS Building on macOS. label Mar 29, 2018

DanielZlotin mentioned this issue Jun 5, 2018

Update profiler app to latest react-native react-native-community/jsc-android-buildscripts#30

Open

patricksmith mentioned this issue Jun 20, 2018

Fetch no longer returns all rows of the same-name response headers after RN Upgrade #18837

Closed

3 tasks

wfhm mentioned this issue Aug 28, 2018

[Android] Pushwoosh setTags API APP crashes when setting list tag with approx 1600 tags, Pushwoosh/pushwoosh-react-native-plugin#31

Closed

dryganets mentioned this issue Aug 29, 2018

Incorrect ref API usage fixed. #20913

Closed

facebook-github-bot closed this as completed in 09c78fe Aug 31, 2018

hramos added the Resolution: Fixed A PR that fixes this issue has been merged. label Oct 30, 2018

dryganets mentioned this issue Nov 1, 2018

0.57.4 Discussion react-native-community/releases#54

Closed

socialsuiteDan mentioned this issue Mar 19, 2019

Crash during sync due to known React Native issue forcedotcom/SalesforceMobileSDK-ReactNative#115

Closed

facebook locked as resolved and limited conversation to collaborators Aug 31, 2019

react-native-bot added the Resolution: Locked This issue was locked by the bot. label Aug 31, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 #18292

[0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 #18292

wuxudong commented Mar 9, 2018 •

edited

Loading

react-native-bot commented Mar 9, 2018

wuxudong commented Mar 9, 2018 •

edited

Loading

hramos commented Mar 9, 2018 •

edited

Loading

wuxudong commented Mar 10, 2018

wuxudong commented Mar 15, 2018

shibbyy commented Apr 16, 2018

wuxudong commented Apr 16, 2018

wkrause13 commented Apr 21, 2018

wuxudong commented Apr 22, 2018

hugows commented Apr 25, 2018 •

edited

Loading

Traviskn commented May 4, 2018

Traviskn commented May 4, 2018

objHua commented May 28, 2018

gaodeng commented Aug 11, 2018

dryganets commented Aug 29, 2018 •

edited

Loading

dryganets commented Aug 29, 2018

coldbess commented Oct 30, 2018 •

edited

Loading

[0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 #18292

[0.54.0][Android] Crash in ReadableNativeArray.getType when size of ReadableNativeArray > 512 #18292

Comments

wuxudong commented Mar 9, 2018 • edited Loading

Environment

Expected Behavior

Actual Behavior

Steps to Reproduce

react-native-bot commented Mar 9, 2018

wuxudong commented Mar 9, 2018 • edited Loading

hramos commented Mar 9, 2018 • edited Loading

wuxudong commented Mar 10, 2018

wuxudong commented Mar 15, 2018

shibbyy commented Apr 16, 2018

wuxudong commented Apr 16, 2018

wkrause13 commented Apr 21, 2018

wuxudong commented Apr 22, 2018

hugows commented Apr 25, 2018 • edited Loading

Traviskn commented May 4, 2018

Traviskn commented May 4, 2018

objHua commented May 28, 2018

gaodeng commented Aug 11, 2018

dryganets commented Aug 29, 2018 • edited Loading

dryganets commented Aug 29, 2018

coldbess commented Oct 30, 2018 • edited Loading

wuxudong commented Mar 9, 2018 •

edited

Loading

wuxudong commented Mar 9, 2018 •

edited

Loading

hramos commented Mar 9, 2018 •

edited

Loading

hugows commented Apr 25, 2018 •

edited

Loading

dryganets commented Aug 29, 2018 •

edited

Loading

coldbess commented Oct 30, 2018 •

edited

Loading