EXC_BAD_ACCESS causing application crash

[emiller]

Hello,

We're starting to see hard crashes in our application that appear to be originating from the StarLogger, resulting in random crashes in our application. Any insight would be great. Here is information from our Sentry integration:

Is it possible to disable StarIO10's logger entirely to avoid this issue?

[gare-bear]

@emiller can you post your code so we can see what/how you're logging?

[emiller]

Hi @gare-bear -- I would be glad to but we aren't logging anything via the star library, in fact we weren't even aware there was such a facility available to us in StarIO10. One thing worth noting is that the exceptions tend to pop up randomly, even when we aren't executing print logic.

Here is a snippet of the print flow though if it helps:

  const settings = new StarConnectionSettings();
  settings.interfaceType = interfaceType;
  settings.identifier = identifier;
  settings.autoSwitchInterface = true;

  const printer = new StarPrinter(settings);
  printer.openTimeout = CONNECT_TIMEOUT;

  try {
    await printer.open();
    const status = await printer.getStatus();

    if (status.hasError) {
      if (status.coverOpen) {
        throw new StandardPrintError('cover_open');
      }

      if (status.paperEmpty) {
        throw new StandardPrintError('no_paper');
      }
    }

    var imgs = "<business logic>"

    const builder = this.printCommandBuilder(width, imgs);
    const commands = await builder.getCommands();

    await printer.print(commands);

    if (status.paperNearEmpty) {
      const warning = new StandardPrintWarning('low_paper');
      return new StandardPrintResult('ok', true, warning);
    }

    return new StandardPrintResult('ok', false);

  } catch (error) {
    if (error instanceof StarIO10InUseError) {
      throw new StandardPrintError('in_use_error', error?.message, { location: 'final_catch' });
    } else if (error instanceof StandardPrintError) {
      throw error;
    } else {
      throw new StandardPrintError('unknown', error?.status?.()?.toString?.(), { location: 'final_catch' });
    }

  } finally {
    await printer.close();
    await printer.dispose();
  }

[gare-bear]

@emiller can you post your device specs? Need the OS, Software Version, and Model Number

[user512]

Hi @gare-bear, I work with @emiller and here is the device spec. iPad Air (4th generation), Model:J308AP, running iOS 14.4.2

And here is our Sentry public link: https://sentry.io/share/issue/7a0894d60d3a42f78d1f240f70da0cc4/

[gare-bear]

@user512 Hi Tom, thanks a bunch for sharing this. I'll ask @bandit-ibayashi to review this when he has a chance.

[bandit-ibayashi]

@emiller @user512 Thank you for your report and giving us the code snippet. I made a confirmation app based on this code and am now confirming the reproduction.

I haven't been able to reproduce the crash yet, but could you tell us how often it happens?

[user512]

I wasn't sure what's a good way to measure that, but here's a screenshot showing the frequency of the crash. I clicked onto the first 10 and they are all related to the StarLogger error.

I have personally "reproduce" this bug by quitting the app (swipe up when in app drawer) and upon quitting the app, Sentry informed me the app has crashed.

[jamiesunderland]

Attached below is a stacktrace I captured

The EXC_BAD_ACCESS appears to be coming from a zombie in the "delete(void*)" call of

StarLogger::getFullPath(std::1::basic_string<char, std::__1::char_traits, std::1::allocator > const&).

This is due to a bad pod setup that is creating duplicate headers across the arm64 and x86 frameworks, resulting in the EXC_BAD_ACCESS.

The problem is all the Objective-C files not under either the x86 or arm64 framework paths that @import StarIO10 from the node_module ios root.

While both frameworks incorporate a StarIO10-Swift bridging file, Swift is not modular header compatible and you end up importing two references to the StarIO static library (albeit the same target arch). This is because clang treats the bridge files as arch specific in Objective-C. Ie. it assumes everything in those frameworks is modular and isn't smart enough to know the swift is static since it isn't compiled at the same time. Ironically this is why you aren't getting duplicate linker errors (though you should be!).

Here's a visualization of the problem

What clang thinks:

x86.framework/
  Bridge-Swift.h (x86)
  StarLib.a (x86) (prebuilt)
arm64.framework/
  Bridge-Swift.h (arm64)
  StarLib.a (arm64) (prebuilt)

What happens at pod build time:

target = arm64 <-- assume building for physical device

x86.framework/ <-- excluded at build time since not arm64
  Bridge-Swift.h (x86) <-- excluded at build time since not arm64
  StarLib.a (arm64) <--- NOT excluded at build time since it's already pre-compiled and x86 version has been excluded
arm64.framework/
  Bridge-Swift.h (arm64)
  StarLib.a (arm64)

This basically leads to you getting 2 arm64 static libs or 2 x86 static libs depending on what you target, since to the files that are arch agnostic and not in the framework paths, both importing the static lib from the x86 or arm64 frameworks is valid.

My guesses why access_errors appear in the logger as opposed to other parts of the framework:

Generally speaking, I'm guessing most StarIO swift ops don't need to be super thread safe because the interfacing obj-c is handling synchronization and the x86 objc interface is correctly excluded in release, but because logger is operating in a worker thread spun up by the duplicate static libs and working on the file-system (making race conditions more probable), the mutex locks before the crashes expose the zombie refs. In short as long as the Objective-C is creating the thread, it will import the correct static lib reference and be thread-aware. When you have worker threads from the duplicated static lib synthesized by the system, they will compete over IO resources with the intended static lib, leading to exc_bad_access issues.

If skeptical see in @emiller's snapshot that there are duplicate refs of Starlogger::worker in the same thread, we should only see a single reference.

Ways to fix:

1) (Worst Way but quick fix) The build phase copy xcframeworks phase calling "${PODS_ROOT}/Target Support Files/react-native-star-io10/react-native-star-io10-xcframeworks.sh"

which does not distinguish copying over headers for arch. If you passed the build arch env into this script and only compiled the respective framework for the target that would fix it.

2) (Better but debug still has zombies) If you change the Release Framework search paths from

"${PODS_ROOT}/../../node_modules/react-native-star-io10/ios/libs" 

to (non-recursive)

"${PODS_ROOT}/../../node_modules/react-native-star-io10/ios/libs",
"${PODS_ROOT}/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-arm64"

you won't get the duplicate headers in release but debug will still have the zombie ref.

3) (Probably the best way but most cumbersome) Create a new framework for the respective archs and put all the loose non-framework Objective-C files into the new respective frameworks.

I can patch this for our own usage but this is a critical bug affecting all ios users that should be addressed. You should also alert the folks whom you know running this library to upgrade or patch.

StarIO10`StarLogger::worker:
    0x10898154c <+0>:    stp    x28, x27, [sp, #-0x60]!
    0x108981550 <+4>:    stp    x26, x25, [sp, #0x10]
    0x108981554 <+8>:    stp    x24, x23, [sp, #0x20]
    0x108981558 <+12>:   stp    x22, x21, [sp, #0x30]
    0x10898155c <+16>:   stp    x20, x19, [sp, #0x40]
    0x108981560 <+20>:   stp    x29, x30, [sp, #0x50]
    0x108981564 <+24>:   add    x29, sp, #0x50            ; =0x50 
    0x108981568 <+28>:   sub    sp, sp, #0x590            ; =0x590 
    0x10898156c <+32>:   mov    x23, x0
    0x108981570 <+36>:   adrp   x8, 311
    0x108981574 <+40>:   ldr    x8, [x8, #0x720]
    0x108981578 <+44>:   ldr    x8, [x8]
    0x10898157c <+48>:   stur   x8, [x29, #-0x68]
    0x108981580 <+52>:   add    x0, x0, #0x48             ; =0x48 
    0x108981584 <+56>:   str    x0, [sp, #0xf8]
    0x108981588 <+60>:   mov    w8, #0x1
    0x10898158c <+64>:   strb   w8, [sp, #0x100]
    0x108981590 <+68>:   bl     0x1089e82d4               ; symbol stub for: std::__1::mutex::lock()
    0x108981594 <+72>:   add    x8, sp, #0x340            ; =0x340 
    0x108981598 <+76>:   add    x0, x8, #0x1a0            ; =0x1a0 
    0x10898159c <+80>:   add    x20, x8, #0x8             ; =0x8 
    0x1089815a0 <+84>:   adrp   x8, 311
    0x1089815a4 <+88>:   ldr    x8, [x8, #0x588]
    0x1089815a8 <+92>:   add    x9, x8, #0x18             ; =0x18 
    0x1089815ac <+96>:   add    x8, x8, #0x40             ; =0x40 
    0x1089815b0 <+100>:  str    x8, [sp, #0x4e0]
    0x1089815b4 <+104>:  str    x9, [sp, #0x340]
    0x1089815b8 <+108>:  str    x0, [sp]
    0x1089815bc <+112>:  mov    x1, x20
    0x1089815c0 <+116>:  bl     0x1089e8358               ; symbol stub for: std::__1::ios_base::init(void*)
    0x1089815c4 <+120>:  str    xzr, [sp, #0x568]
    0x1089815c8 <+124>:  mov    w8, #-0x1
    0x1089815cc <+128>:  str    w8, [sp, #0x570]
    0x1089815d0 <+132>:  adrp   x9, 311
    0x1089815d4 <+136>:  ldr    x9, [x9, #0x6b0]
    0x1089815d8 <+140>:  add    x8, x9, #0x18             ; =0x18 
    0x1089815dc <+144>:  add    x9, x9, #0x40             ; =0x40 
    0x1089815e0 <+148>:  str    x9, [sp, #0x4e0]
    0x1089815e4 <+152>:  str    x8, [sp, #0x340]
    0x1089815e8 <+156>:  mov    x0, x20
    0x1089815ec <+160>:  bl     0x108986ea0               ; std::__1::basic_filebuf<char, std::__1::char_traits<char> >::basic_filebuf()
    0x1089815f0 <+164>:  mov    x0, x23
    0x1089815f4 <+168>:  bl     0x108982e98               ; StarLogger::makeDirectoryIfNeeded()
    0x1089815f8 <+172>:  add    x8, x23, #0xa8            ; =0xa8 
    0x1089815fc <+176>:  str    x8, [sp, #0x8]
    0x108981600 <+180>:  add    x8, sp, #0x108            ; =0x108 
    0x108981604 <+184>:  add    x22, x8, #0x8             ; =0x8 
    0x108981608 <+188>:  add    x21, x8, #0x1a0           ; =0x1a0 
    0x10898160c <+192>:  add    x25, x23, #0x30           ; =0x30 
    0x108981610 <+196>:  adrp   x8, 311
    0x108981614 <+200>:  ldr    x8, [x8, #0x5d0]
    0x108981618 <+204>:  add    x8, x8, #0x8              ; =0x8 
    0x10898161c <+208>:  str    x8, [sp, #0x10]
    0x108981620 <+212>:  adrp   x26, 311
    0x108981624 <+216>:  ldr    x26, [x26, #0x568]
    0x108981628 <+220>:  b      0x108981634               ; <+232>
    0x10898162c <+224>:  ldrb   w8, [x23, #0xd8]
    0x108981630 <+228>:  cbnz   w8, 0x108981e8c           ; <+2368>
    0x108981634 <+232>:  add    x1, sp, #0xf8             ; =0xf8 
    0x108981638 <+236>:  ldr    x0, [sp, #0x8]
    0x10898163c <+240>:  bl     0x1089e8280               ; symbol stub for: std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)
    0x108981640 <+244>:  b      0x108981658               ; <+268>
    0x108981644 <+248>:  ldr    x0, [sp, #0xe0]
    0x108981648 <+252>:  str    x24, [sp, #0xe8]
    0x10898164c <+256>:  bl     0x1089e83dc               ; symbol stub for: operator delete(void*)
    0x108981650 <+260>:  cmp    x27, x19
    0x108981654 <+264>:  b.eq   0x10898162c               ; <+224>
    0x108981658 <+268>:  add    x8, sp, #0xe0             ; =0xe0 
    0x10898165c <+272>:  mov    x0, x23
    0x108981660 <+276>:  bl     0x1089822a8               ; StarLogger::listFiles()
    0x108981664 <+280>:  ldp    x9, x8, [sp, #0xe0]
    0x108981668 <+284>:  cmp    x8, x9
    0x10898166c <+288>:  b.ne   0x108981790               ; <+580>
    0x108981670 <+292>:  add    x8, sp, #0xc8             ; =0xc8 
    0x108981674 <+296>:  mov    x0, x23
    0x108981678 <+300>:  bl     0x10898276c               ; StarLogger::getNewFileName()
    0x10898167c <+304>:  add    x8, sp, #0x30             ; =0x30 
    0x108981680 <+308>:  add    x1, sp, #0xc8             ; =0xc8 
    0x108981684 <+312>:  mov    x0, x23
    0x108981688 <+316>:  bl     0x108982d18               ; StarLogger::getFullPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
    0x10898168c <+320>:  add    x0, sp, #0x108            ; =0x108 
    0x108981690 <+324>:  add    x1, sp, #0x30             ; =0x30 
    0x108981694 <+328>:  bl     0x10898381c               ; std::__1::basic_ofstream<char, std::__1::char_traits<char> >::basic_ofstream(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int)
    0x108981698 <+332>:  ldr    x8, [sp, #0x340]
    0x10898169c <+336>:  ldur   x8, [x8, #-0x18]
    0x1089816a0 <+340>:  add    x9, sp, #0x340            ; =0x340 
    0x1089816a4 <+344>:  add    x27, x9, x8
    0x1089816a8 <+348>:  ldr    x8, [sp, #0x108]
    0x1089816ac <+352>:  ldur   x8, [x8, #-0x18]
    0x1089816b0 <+356>:  add    x9, sp, #0x108            ; =0x108 
    0x1089816b4 <+360>:  add    x28, x9, x8
    0x1089816b8 <+364>:  mov    x0, x27
    0x1089816bc <+368>:  mov    x1, x28
    0x1089816c0 <+372>:  bl     0x1089e8364               ; symbol stub for: std::__1::ios_base::swap(std::__1::ios_base&)
    0x1089816c4 <+376>:  ldr    x8, [x27, #0x88]
    0x1089816c8 <+380>:  ldr    x9, [x28, #0x88]
    0x1089816cc <+384>:  str    x9, [x27, #0x88]
    0x1089816d0 <+388>:  str    x8, [x28, #0x88]
    0x1089816d4 <+392>:  ldr    w8, [x27, #0x90]
    0x1089816d8 <+396>:  ldr    w9, [x28, #0x90]
    0x1089816dc <+400>:  str    w9, [x27, #0x90]
    0x1089816e0 <+404>:  str    w8, [x28, #0x90]
    0x1089816e4 <+408>:  ldr    x27, [sp, #0x3c0]
    0x1089816e8 <+412>:  cbz    x27, 0x108981724          ; <+472>
    0x1089816ec <+416>:  ldr    x8, [sp, #0x348]
    0x1089816f0 <+420>:  ldr    x8, [x8, #0x30]
    0x1089816f4 <+424>:  mov    x0, x20
    0x1089816f8 <+428>:  blr    x8
    0x1089816fc <+432>:  mov    x0, x27
    0x108981700 <+436>:  bl     0x1089e8508               ; symbol stub for: fclose
    0x108981704 <+440>:  cbnz   w0, 0x10898170c           ; <+448>
    0x108981708 <+444>:  str    xzr, [sp, #0x3c0]
    0x10898170c <+448>:  ldr    x8, [sp, #0x348]
    0x108981710 <+452>:  ldr    x8, [x8, #0x18]
    0x108981714 <+456>:  mov    x0, x20
    0x108981718 <+460>:  mov    x1, #0x0
    0x10898171c <+464>:  mov    x2, #0x0
    0x108981720 <+468>:  blr    x8
    0x108981724 <+472>:  mov    x0, x20
    0x108981728 <+476>:  mov    x1, x22
    0x10898172c <+480>:  bl     0x108986fd0               ; std::__1::basic_filebuf<char, std::__1::char_traits<char> >::swap(std::__1::basic_filebuf<char, std::__1::char_traits<char> >&)
    0x108981730 <+484>:  adrp   x8, 311
    0x108981734 <+488>:  ldr    x8, [x8, #0x6b0]
    0x108981738 <+492>:  mov    x9, x8
    0x10898173c <+496>:  add    x8, x8, #0x18             ; =0x18 
    0x108981740 <+500>:  add    x9, x9, #0x40             ; =0x40 
    0x108981744 <+504>:  str    x9, [sp, #0x2a8]
    0x108981748 <+508>:  str    x8, [sp, #0x108]
    0x10898174c <+512>:  mov    x0, x22
    0x108981750 <+516>:  bl     0x1089841b0               ; std::__1::basic_filebuf<char, std::__1::char_traits<char> >::~basic_filebuf()
    0x108981754 <+520>:  add    x0, sp, #0x108            ; =0x108 
    0x108981758 <+524>:  ldr    x1, [sp, #0x10]
    0x10898175c <+528>:  bl     0x1089e8208               ; symbol stub for: std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()
    0x108981760 <+532>:  mov    x0, x21
    0x108981764 <+536>:  bl     0x1089e837c               ; symbol stub for: std::__1::basic_ios<char, std::__1::char_traits<char> >::~basic_ios()
    0x108981768 <+540>:  ldrsb  w8, [sp, #0x47]
    0x10898176c <+544>:  tbnz   w8, #0x1f, 0x108981990    ; <+1092>
    0x108981770 <+548>:  ldrsb  w8, [sp, #0xdf]
    0x108981774 <+552>:  tbnz   w8, #0x1f, 0x1089819a0    ; <+1108>
    0x108981778 <+556>:  ldrsb  w9, [x25, #0x17]
    0x10898177c <+560>:  and    x8, x9, #0xff
    0x108981780 <+564>:  tbnz   w9, #0x1f, 0x1089819b4    ; <+1128>
    0x108981784 <+568>:  mov    x9, x8
    0x108981788 <+572>:  cbnz   x9, 0x1089819bc           ; <+1136>
    0x10898178c <+576>:  b      0x108981cb4               ; <+1896>
    0x108981790 <+580>:  sub    x27, x8, #0x18            ; =0x18 
    0x108981794 <+584>:  add    x8, sp, #0x30             ; =0x30 
    0x108981798 <+588>:  movi.16b v0, #0x0
    0x10898179c <+592>:  stp    q0, q0, [x8, #0x70]
    0x1089817a0 <+596>:  stp    q0, q0, [sp, #0x80]
    0x1089817a4 <+600>:  stp    q0, q0, [sp, #0x60]
    0x1089817a8 <+604>:  stp    q0, q0, [sp, #0x40]
    0x1089817ac <+608>:  str    q0, [sp, #0x30]
    0x1089817b0 <+612>:  add    x8, sp, #0x108            ; =0x108 
    0x1089817b4 <+616>:  mov    x0, x23
    0x1089817b8 <+620>:  mov    x1, x27
    0x1089817bc <+624>:  bl     0x108982d18               ; StarLogger::getFullPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
    0x1089817c0 <+628>:  ldrsb  w8, [sp, #0x11f]
    0x1089817c4 <+632>:  ldr    x9, [sp, #0x108]
    0x1089817c8 <+636>:  cmp    w8, #0x0                  ; =0x0 
    0x1089817cc <+640>:  add    x8, sp, #0x108            ; =0x108 
    0x1089817d0 <+644>:  csel   x0, x9, x8, lt
    0x1089817d4 <+648>:  add    x1, sp, #0x30             ; =0x30 
    0x1089817d8 <+652>:  bl     0x1089e8784               ; symbol stub for: stat
    0x1089817dc <+656>:  ldrsb  w8, [sp, #0x11f]
    0x1089817e0 <+660>:  tbnz   w8, #0x1f, 0x108981848    ; <+764>
    0x1089817e4 <+664>:  ldr    x8, [sp, #0x90]
    0x1089817e8 <+668>:  ldr    x9, [x23, #0x88]
    0x1089817ec <+672>:  ldrsb  w10, [x9, #0x17]
    0x1089817f0 <+676>:  tbnz   w10, #0x1f, 0x108981860   ; <+788>
    0x1089817f4 <+680>:  and    x9, x10, #0xff
    0x1089817f8 <+684>:  add    x8, x9, x8
    0x1089817fc <+688>:  ldr    x28, [sp, #0x3c0]
    0x108981800 <+692>:  cmp    x8, #0xa00, lsl #12       ; =0xa00000 
    0x108981804 <+696>:  b.ls   0x108981874               ; <+808>
    0x108981808 <+700>:  cbz    x28, 0x108981a84          ; <+1336>
    0x10898180c <+704>:  ldr    x8, [sp, #0x348]
    0x108981810 <+708>:  ldr    x8, [x8, #0x30]
    0x108981814 <+712>:  mov    x0, x20
    0x108981818 <+716>:  blr    x8
    0x10898181c <+720>:  mov    x27, x0
    0x108981820 <+724>:  mov    x0, x28
    0x108981824 <+728>:  bl     0x1089e8508               ; symbol stub for: fclose
    0x108981828 <+732>:  cbz    w0, 0x108981a48           ; <+1276>
    0x10898182c <+736>:  ldr    x8, [sp, #0x348]
    0x108981830 <+740>:  ldr    x8, [x8, #0x18]
    0x108981834 <+744>:  mov    x0, x20
    0x108981838 <+748>:  mov    x1, #0x0
    0x10898183c <+752>:  mov    x2, #0x0
    0x108981840 <+756>:  blr    x8
    0x108981844 <+760>:  b      0x108981a68               ; <+1308>
    0x108981848 <+764>:  ldr    x0, [sp, #0x108]
    0x10898184c <+768>:  bl     0x1089e83dc               ; symbol stub for: operator delete(void*)
    0x108981850 <+772>:  ldr    x8, [sp, #0x90]
    0x108981854 <+776>:  ldr    x9, [x23, #0x88]
->  0x108981858 <+780>:  ldrsb  w10, [x9, #0x17]
...

[gare-bear]

@jamiesunderland Thanks for taking a look at this issue and providing some suggestions on how to fix. I know @bandit-ibayashi is working on another issue (#7), that is quite possibly related and might have similar fixes. I can't make any of these changes myself, so I'll make sure he sees this.

[jamiesunderland]

It's exactly the same issue actually. However, the compile errors people are complaining about in https://github.com/star-micronics/react-native-star-io10/issues/7 are actually good and the desired result. People are getting around them by excluding architectures and messing with framework paths. It's great until you end up with runtime access errors like this one. It's easy to forget compilers are our friends and not our foes.

It's not a bug to support simulators and x86. The problem is that as is, the pod is not setup correctly to cross compile archs and is forcing people to cheat the compiler and then get hard to debug crashes at runtime.

I can post a PR for a temporary patch if you think that would be of benefit to you guys

[gare-bear]

I think that would be great. I'm sure I can convince @bandit-ibayashi to put the temporary fix in another branch until we can build a more complete solution.

[jamiesunderland]

when @emiller @user512 or myself sit down and patch properly we will submit a PR.

Quick dirty production hotfix: For anyone who needs to quickly remedy production issues, you can put the following in a bash script and add it as a postinstall script in your package.json (this will break simulators)

if grep -q x86_64 "node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/Info.plist"; then
  sed -i -e '7,20d' 'node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/Info.plist';
fi
rm -rf 'node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-x86_64-simulator'

no surprise but confirmed it works fine on ios 14.5/xcode 13/tsp 100/sp 700.

I don't use a simulator but I can guarantee it won't work.

[jamiesunderland]

I don't think you have write access setup for me to create a PR. Here is my local diff for ios/StarIo10.xcodeproj/project.pbxproj

@@ -397,10 +394,24 @@
                58B511F01A9E6C8500147676 /* Debug */ = {
                        isa = XCBuildConfiguration;
                        buildSettings = {
+                               "EXCLUDED_ARCHS[sdk=iphoneos*]" = x86_64;
+                               "EXCLUDED_ARCHS[sdk=iphonesimulator*]" = arm64;
+                               "EXCLUDED_SOURCE_FILE_NAMES[sdk=iphoneos*]" = "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-x86_64-simulator/*.*";
+                               "EXCLUDED_SOURCE_FILE_NAMES[sdk=iphonesimulator*]" = "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-arm64/*.*";
                                FRAMEWORK_SEARCH_PATHS = (
                                        "$(SRCROOT)/libs/**",
                                        "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/**",
                                );
+                               "FRAMEWORK_SEARCH_PATHS[sdk=iphoneos*]" = (
+                                       "$(SRCROOT)/libs/**",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-arm64",
+                               );
+                               "FRAMEWORK_SEARCH_PATHS[sdk=iphonesimulator*]" = (
+                                       "$(SRCROOT)/libs/**",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-x86_64-simulator",
+                               );
                                HEADER_SEARCH_PATHS = (
                                        "$(inherited)",
                                        /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include,
@@ -418,9 +429,12 @@
                58B511F11A9E6C8500147676 /* Release */ = {
                        isa = XCBuildConfiguration;
                        buildSettings = {
+                               EXCLUDED_ARCHS = x86_64;
+                               EXCLUDED_SOURCE_FILE_NAMES = "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-x86_64-simulator/*.*";
                                FRAMEWORK_SEARCH_PATHS = (
                                        "$(SRCROOT)/libs/**",
-                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/**",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs",
+                                       "$(SRCROOT)/../../node_modules/react-native-star-io10/ios/libs/StarIO10.xcframework/ios-arm64",
                                );
                                HEADER_SEARCH_PATHS = (
                                        "$(inherited)",

I also recommend dropping the deployment version to 9.0, this causes a lot of conflicts with other libraries and isn't necessary since the swift is static

[joarwilk]

Sorry to bother but any progress on this task? @gare-bear

[gare-bear]

@joarwilk We're hoping to push an update some time this month. If you have an urgent need for an update, you should contact your local Star subsidiary and ask about the possibility of a beta release.

[gare-bear]

If you're still running into this issue and are willing to test a beta release, please contact the integration team to request beta access.

[bandit-ibayashi]

We have updated our React Native SDK including @jamiesunderland suggestion. We appreciate your patience and great contribution!

[gare-bear]

@emiller Since you opened this issue, can you update to 1.1.0 to verify the issue is fixed?

[yachaka]

I had this issue anytime I would close the app. It got resolved with 1.1.0 👍