iOS Crash on value change in RNCSliderEventEmitter::onRNCSliderValueChange #782

Activity

1. hamzadev002

   added

   bug reportSomething isn't workingSomething isn't working

   on Mar 9, 2026
2. BartoszKlonowski commented on Mar 20, 2026

   

   BartoszKlonowski

   on Mar 20, 2026

   Member

   More actions

   Hello, @hamzadev002, can you share any repro where you see this crash and some instructions about the specific scenario?
3. BartoszKlonowski

   added

   platform: iOSIssue related to iOS platformIssue related to iOS platform

   requires: author feedbackItem requires some author's actionItem requires some author's action

   on Mar 20, 2026
4. BartoszKlonowski

   added this to Slider-Boardon Mar 20, 2026
5. github-project-automation

   moved this to To be analyzed in Slider-Boardon Mar 20, 2026
6. hamzadev002 commented on Apr 13, 2026

   

   hamzadev002

   on Apr 13, 2026

   Author

   More actions

   I can’t share a repro repo because the project is private, but I can describe the scenario where I’m seeing the crash.

   Setup:

   React Native app
   Slide-in music player UI
   A progress slider on the player screen
   The slider position is updated continuously from playback progress (roughly every second)

   Observed crash scenario:

   Start playback
   Open the player screen
   Let the slider continue receiving progress updates
   Close/dismiss the player screen while playback is still running
   Crash occurs at that time

   I also noticed Firebase logging around this flow, but the main pattern seems to be that the player UI is closed while progress-related updates are still being emitted.

   My suspicion is that a UI event/update is still being dispatched after the player screen or slider component has unmounted.

   Since I can’t share the repo, I’m happy to provide a reduced code snippet for the player screen, slider update logic, and cleanup/unmount handling.
7. dharmeshgigs commented on May 20, 2026

   

   dharmeshgigs

   on May 20, 2026

   More actions

   @hamzadev002 Did you fix this issue?
8. ryanbinns commented on Jun 8, 2026

   

   ryanbinns

   on Jun 8, 2026

   Last edited by ryanbinns

   More actions

   I'm also seeing this issue in my app on an iPhone 17 simulator. It seems to be specific to onValueChange, as using onSlidingComplete does not cause the crash. Using onValueChange, the crash seems to happen any time I drag the slider right to the very end (either end). In my case, I have the slider min and max set to 0 and 1, and the step set to 0.1, if that's helpful.

   <Slider maximumValue={1} minimumValue={0} step={0.1} value={ratio} onValueChange={onSliderChange} style={{backgroundColor: 'transparent'}} />
   
9. bordercore commented on Jul 30, 2026

   

   bordercore

   on Jul 30, 2026

   More actions

   Hit this one too and got a reliable repro, plus a fix that's now verified on a device. Posting in case it helps, since it sounds like the missing piece here has been a way to reproduce it.

   The trigger for us is unmounting the slider's screen immediately after letting go of the thumb:

   1. Slider on a screen
   2. Drag it, release
   3. Straight away, no pause, tap something that unmounts the screen. Ours was a Submit button that swapped the form out for a spinner.
   4. Crash

   Leave about a second between releasing and tapping and it never crashes. That timing dependence is what put us onto the cause.

   _UIFluidSliderInteraction doesn't deliver the control action on touch-up, it defers it to a CA commit handler. If the view is gone by the time that commit runs, _eventEmitter is no longer valid, and RNCSendSliderEvent: dereferences it without checking:

   std::dynamic_pointer_cast<const RNCSliderEventEmitter>(_eventEmitter)
   ->onRNCSliderValueChange(...);

   That's the shared_ptr.h:557 frame. Where the view gets recycled, prepareForRecycle in RCTViewComponentView calls _eventEmitter.reset(), which is one way to get a null there.

   We saw it via two different events. One is onRNCSliderValueChange, identical to the trace in the original report here. The other comes in through sliderTouchEnd:, app binary redacted:

   Crashed: com.apple.main-thread
   0  React     facebook::react::EventEmitter::dispatchEvent(...) + 72
   1  React     facebook::react::EventEmitter::dispatchEvent(...) + 96
   2  AppName   facebook::react::RNCSliderEventEmitter::onRNCSliderSlidingComplete(...) + 403
   3  AppName   -[RNCSliderComponentView RNCSendSliderEvent:withContinuous:isSlidingStart:] + 557 (shared_ptr.h:557)
   4  AppName   -[RNCSliderComponentView sliderTouchEnd:] + 123 (RNCSliderComponentView.mm:123)
   5  UIKitCore -[UIApplication sendAction:to:from:forEvent:] + 100
   6  UIKitCore -[UIControl sendAction:to:forEvent:] + 108
   7  UIKitCore -[UIControl _sendActionsForEvents:withEvent:] + 380
   ...
   10 UIKitCore -[_UIFluidSliderInteraction _handler] + 252
   12 UIKitCore -[_UIFluidSliderInteraction _issueUpdate] + 1416
   17 UIKitCore -[_UIAppCACommitFuture _invoke] + 64
   18 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 120
   19 QuartzCore CA::Context::commit_transaction(...) + 8756
   20 QuartzCore CA::Transaction::commit() + 648
   

   So @ryanbinns, moving to onSlidingComplete isn't a general workaround. Ours crashes inside onRNCSliderSlidingComplete at frame 2. The native side dispatches the event regardless of which handler JS has attached.

   Worth noting #746 doesn't close this either. On 5.2.0 + (BOOL)shouldBeRecycled is there, but RNCSliderComponentView.mm still has 6 unguarded _eventEmitter dereferences and no null checks anywhere. This issue was opened after 5.1.1 shipped, which fits.

   Guarding the cast and dropping the event fixes it. The view is being torn down at that point so there's nothing listening:

   const auto eventEmitter = std::dynamic_pointer_cast<const RNCSliderEventEmitter>(_eventEmitter);
   if (!eventEmitter) {
       return;
   }

   We're running that across all six call sites as a local patch on 5.0.1. The repro that reliably crashed before is clean now on a TestFlight build. Can put up a PR against main if it's wanted.
10. BartoszKlonowski

    removed

    requires: author feedbackItem requires some author's actionItem requires some author's action

    on Aug 13, 2026
11. hamzadev002 commented on Sep 2, 2026

    

    hamzadev002

    on Sep 2, 2026

    Last edited by hamzadev002

    Author

    More actions

    @dharmeshgigs
    No, The library recommends updating to version 5.0.0 for React Native versions above 0.76. However, I did not update it because this issue affects only seven production users, all of whom are on iOS 26 or later.
12. BartoszKlonowski

    added

    v6Issues that are either resolved by, or checked against the v6 releaseIssues that are either resolved by, or checked against the v6 release

    on Oct 5, 2026