Exc_Bad_Instruction (Code=Exc_I386_Invop, Subcode=0X0) on Dispatch_Semaphore_Dispose

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) on dispatch_semaphore_dispose

From your stack trace, EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) occurred because dispatch_group_t was released while it was still locking (waiting for dispatch_group_leave).

According to what you found, this was what happened :

• dispatch_group_t group was created. group's retain count = 1.
• -[self webservice:onCompletion:] captured the group. group's retain count = 2.
• dispatch_async(...., ^{ dispatch_group_wait(group, ...) ... }); captured the group again. group's retain count = 3.
• Exit the current scope. group was released. group's retain count = 2.
• dispatch_group_leave was never called.
• dispatch_group_wait was timeout. The dispatch_async block was completed. group was released. group's retain count = 1.
• You called this method again. When -[self webservice:onCompletion:] was called again, the old onCompletion block was replaced with the new one. So, the old group was released. group's retain count = 0. group was deallocated. That resulted to EXC_BAD_INSTRUCTION.

To fix this, I suggest you should find out why -[self webservice:onCompletion:] didn't call onCompletion block, and fix it. Then make sure the next call to the method will happen after the previous call did finish.

---

In case you allow the method to be called many times whether the previous calls did finish or not, you might find someone to hold group for you :

• You can change the timeout from 2 seconds to DISPATCH_TIME_FOREVER or a reasonable amount of time that all -[self webservice:onCompletion] should call their onCompletion blocks by the time. So that the block in dispatch_async(...) will hold it for you.
  
  OR
• You can add group into a collection, such as NSMutableArray.

---

I think it is the best approach to create a dedicate class for this action. When you want to make calls to webservice, you then create an object of the class, call the method on it with the completion block passing to it that will release the object. In the class, there is an ivar of dispatch_group_t or dispatch_semaphore_t.

Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) Swift on macOS appp

I found solution;
in apple sandbox documentation

If the app crashes when you attempt to run it, specifically by receiving an EXC_BAD_INSTRUCTION signal, the most likely reason is that you previously ran a sandboxed app with the same bundle identifier but a different code signature. This crashing upon launch is an App Sandbox security feature that prevents one app from masquerading as another and thereby gaining access to the other app’s container.

And then change this line

let cgImage = texture.imageFromTexture()!.takeRetainedValue()

as below

let cgImage = texture.imageFromTexture()!.takeUnretainedValue()

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) error loading from Bundle

I think the problem at here

 let alertSound = URL(fileURLWithPath: Bundle.main.path(forResource: "219069_annabloom_click1", ofType: "wav")!)

meaning of this sign is ! the value is not nil.
But I think you have't added the file correctly or there is issue with .wav extension double check it so it returns nil and app is crashed.

Step 1: make sure you have added sound file correctly

Step 2: verify extension is same in code and file

make sure the module is selected

SwiftUI Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) when making pop

After hours, I found a solution, problem was in changing appearance of UINavigationBar.

Closing question

A problem showing Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) during runtime

That's really interesting unexpected coincidence issue, but here is fix

Text("Tap the flag of")
   .foregroundColor(.white)   // << use '.' (dot) before foregroundColor!!

Text(countries[correctAnswer])
   .foregroundColor(.white)   // << same !!

what does Error “Thread 1:EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)” mean?

It means that there there are instructions that lead to a crash, such as force unwrapping something that doesn't exist, and getting a value of nil.

Take a look through your code and see if there are any situations where you force unwrap something that does not necessarily exist.

---

Related Topics