TypeError: global.nativeTraceBeginSection is not a function (Systrace)

[moiseshilario]

Is this a bug report?

Yes

Have you read the Bugs section of the Contributing to React Native Guide?

Yes

Environment

1. react-native -v: react-native-cli: 2.0.1, react-native: 0.46.1
2. node -v: v7.10.0
3. npm -v: 4.6.1
4. yarn --version (if you use Yarn): Not used in this bug

Then, specify:

• Target Platform: iOS

• Development Operating System: macOS Sierra v 10.12

• Build tools: Xcode Version 8.3.3 (8E3004b)

I'm running react-native run-ios deploying to iOS emulator Version 10.0 (SimulatorApp-745.10), running iOS 10.3 in an iphone 6.

Steps to Reproduce

(Write your steps here:)

1. Run react-native run-ios with Systrace enabled

2. Reload your app (manually or with live/hot reload)

3. Check the logs

Expected Behavior

The app should reload normally.

Actual Behavior

The error TypeError:global.nativeTraceBeginSection gets launched into the console:

And in the UI:

After that, the whole emulator crashes and the only way to restore it is running react-native run-ios again.
One temporary workaround to get rid of this error is disabling Systrace in the DevMenu, but this is less than ideal.

Reproducible Demo

https://snack.expo.io/ryCtYZHrZ

Observation: Even though I included a snack, I'm afraid you can't fully reproduce this problem without a Mac and an iOS emulator, the reason being that the Systrace is not an Expo function.

[janicduplessis]

I just discussed this with @javache and it seems like the issue is that Systrace is currently broken with the c++ bridge because the module currently doesn't get compiled for the OSS build.

For some reason I did not get that crash but instead no JS trace were reported in the trace I recorded.

[sportsbench]

@janicduplessis any idea when a fix for this will be pushed? This is causing serious development time problems for me.

[javiercr]

Same problem on v0.47, I was hoping for this commit by @gaearon to fix systrace, but it seems for some reason it still doesn't work ¯\_(ツ)_/¯

[gaearon]

I didn’t fix anything related to C++ bridge.

[javiercr]

Ops, thanks for the clarification and sorry about the confusion! Let's hope for that C++ bridge fix!

[javache]

I'm aware of this issue. We currently don't have these methods on the C++ bridge since the C++ implementation depends on fbsystrace, which is not open-source. As a workaround, you can revert back to RCTBatchedBridge (ReactLegacy), we'll try to find a solution for this soon.

[javiercr]

@javache what would be the process to "revert to RCTBatchedBridge"? Do you mean just using and older RN release?

As explained in #15371, without systrace and without proper JS remote debugging, with the current release of RN is quite hard to debug any performance problem, so any guidance on how to do this would be more than appreciated! Thanks!

[almost]

Does anyone have any workarounds for this? Or any hints about how to revert to RCTBatchedBridge. Seems like this was a pretty vital part of the RN development process, how on earth does one fix performance issues without being able to see where they are?

[almost]

Ok, here's how to switch back to RCTBatchedBridge. First you need to make sure the bridge is being created with a delegate, I think this might be default for new projects but if you have an existing project you may need to change it. Here's the code from my AppDelegate.m:

  RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self
                                         launchOptions:launchOptions];
  
  RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge moduleName:@"yourapp" initialProperties:nil];

You then need the delegate method for getting the sourceURL and ALSO a new method called "shouldBridgeUseCxxBridge" to tell RN not to use the CxxBridge. Both of these should be added to AppDelegate:

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge {
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index.ios" fallbackResource:nil];
}

- (BOOL)shouldBridgeUseCxxBridge:(RCTBridge *)bridge {
  return NO;
}

At this point your project will crash when you start it. The files needed for the BatchedBridge aren't included in the xcode project. So you'll need to add them by right clicking on React.xcodeproj in xcode and selecting Add files to "React.xcodeproj". You need the following files:

./node_modules/react-native/React/Base/RCTBatchedBridge.mm
./node_modules/react-native/React/Executors/
./node_modules/react-native/React/Profiler/RCTJSCProfiler.h
./node_modules/react-native/React/Profiler/RCTJSCProfiler.m

You should now be able to start the project and use SysTrace again!

Of course you have to re-add those files every time you setup the code, those changes won't be saved to git. I'm sure you could add a script to do it to package.json's install section but I'm really hoping this gets fixed properly soon as I'm sure people outside Facebook also need to write React Native apps that don't suck (and I don't see how to do that without SysTrace to make them fast).

[javiercr]

@almost thank you so much! And I absolutely agree that we need to get this fixed properly, not having systrace makes improving performance problems almost impossible.

[javiercr]

@almost I followed your instructions and now I can do the systrace and generate the json file, however when I open it with Chrome tracing I just see calls to RCT* stuff, I can't see any of the JS calls I used to see before. Are you experiencing the same? Thanks!

[almost]

It's working ok for me, I'm seeing the JS trace points as well as the native ones. I'm on RN version 0.46.1, not sure if that makes a difference. Could be related to @gaearon's commit you mentioned above...

[javiercr]

Thanks! I was using v0.47, after downgrading to 0.46.1 and repeating the same steps now I can see some of my JS calls.

However with 0.46.1 I can't still see traces for the full JS execution:

I see this CalendarMonth.render() (one of my components) that takes 2 seconds but I cannot dig any further than that 😔

[almost]

That's most likely because CalendarMonth.render isn't instrumented. Systrace isnt like a JS profile you'd get from Chrome. It relies on explicit calls to the systrace functions to let it know when things start and stop. React Native includes a bunch of calls but you can always instrument your own code. It even supports async code (will be shown in a separate track) which can be very useful.

[almost]

If you wanted a JS profile it might be worth using Remote JS Debugging then running the profile in Chrome. Obviously you'll get different performance characteristics in Chrome, but it can still give you a good idea of what's causing a problem. But for most RN performance problems I find Systrace far more helpful.

[javiercr]

I think I remember in the past using systrace and getting detailed calls beyond render(), but I can't be 100% sure, maybe I was using remote JS debugging, not systrace.

The problem with Remote JS debugging in this case is that the JS code is the bottleneck (not the RN bridge), and the remote debugger makes JS much faster than in a normal device / simulator, making debugging the bottleneck not that easy.

I'll try adding some instrumentation to my code as you suggested, thanks!

PS: sorry for hijacking the thread a little bit, but given the current situation of profiling with the latest versions of RN, I think this kind of stuff may be interesting for other people.

[JanErikFoss]

Using React Native 48.4 and React 16.0.0-alpha.12 I cannot use the fix provided by @almost

These files do not exist
./node_modules/react-native/React/Profiler/RCTJSCProfiler.h
./node_modules/react-native/React/Profiler/RCTJSCProfiler.m

[remoteportal]

I just started learning React Native today and downloaded everything fresh. Getting the exact same error on a "hello, world" app:

global.nativeTraceBeginSection is not a function

How is anyone using React Native to build apps if the simplest app won't run?

[jayshah123]

For android ? AFAIK it has never be working on android due to missing fbsystrace.h
Some of issues iceboxed recently #14394 #15022
Any help is appreciated.

[brunolemos]

While this is not fixed,
any other way to profile react native performance like we can do on react for web?

A way that shows the render time for each component (flame graph).

[gaearon]

I don’t have background on this issue but it’s weird that it’s broken. I’m fairly sure I had this working about a couple of months ago.

As a temporary workaround, I think enabling Chrome debugging might work? Then in the Perfromance tab of Chrome you can “record” and see measurements in the User Timing subsection. Give it a try and let me know.

[brunolemos]

@gaearon nope, doesn't work with or without chrome debugging enabled.
Also with or without xcode attached.

[axemclion]

This is a known problem, and systrace is not enabled yet on iOS.

In the meantime, you could use Safari to get Sampling profiler working on JSC. Its not everything that systrace can give you, but could still be useful stop gap till systrace issue is fixed.

[axemclion]

Here is how I got safari working with JSC for sampling profiler

https://twitter.com/nparashuram/status/1153369115962302465

[mack-wang]

I also have this problem, but when I changed General > Bundle Identifier back to the default name, I found this problem no longer happened.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

[matt-oakes]

This is still an issue on 0.61.

[zcramos]

Is it possible to revert to the old bridge in RN 0.61 using CocoaPods? The instructions posted above by @almost don't apply anymore because there is no React.xcodeproj in my workspace...

[zcramos]

After some digging, it looks like JSCTracing.cpp, which previously provided the global.nativeTrace* methods in js, were removed with RN 0.58.0.

edit: github was hiding a bunch of comments, I now see that the batched bridge was also removed before the tracing methods were :/

What are people using to debug JS-side performance issues in RN? Recording a session in the performance tab of dev tools doesn't seem to provide any level of detail whatsoever - I just see Task and Function Call, and things like that. :/

[yassati]

Stop and resatrt app

[a-dilettante]

I just had a go at hacking the RCTProfile implementation (v0.60.4) and I managed to get the native part going but now I'm struggling with the JS side.

After some digging, it looks like JSCTracing.cpp, which previously provided the global.nativeTrace* methods in js, were removed with RN 0.58.0.

@zcramos, I'm trying to understand how JSCTracing fits into the big picture with 0.60.4, but it's proving to be quite a problem.

[evelant]

2.5 years later, this is still broken and systrace is still in the official docs as a debugging tool. Here's another related issue: #26032

Has anybody found alternative methods of profiling performance on Android? Chrome devtools don't give accurate results, react-devtools profiler appears to be broken... It seems there are no options left for perf debugging on Android.

[chrisgibson17]

It looks like the folks over at microsoft/react-native-windows have their own implementation of fbsystrace.h thats been mentioned earlier in this thread - fbsystrace.h.

My C++ knowledge is lacking/non-existent but would this mean the C++ bridge could be recompiled with proper systrace support if this was included?

[SudoPlz]

@axe-fb are we doing something wrong? Is Systrace now permanently broken for Android now that global.nativeTraceBeginSection is missing?

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[evelant]

This is still an issue. 3 years and counting, can we at least get systrace removed from the docs since it hasn’t worked for 3 years?

[DrRefactor]

Are there any updates on the topic? Systrace seems to be crucial tool for production-level Android apps...

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.