About Swift: Execution Was Interrupted, Reason: Exc_Bad_Instruction (Code=Exc_1386_Invop, Subcode=0X0)

Why do I get the EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) in swift

for .. in .. in Swift does not iterate over indices. It iterates over actual array elements. Hence i is the element, not the index.

Using if i % 2 == 0 will fix your problem.

Swift 3 migration EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) on casting

Usually, in Swift, you cannot cast a closure to another type with as!.
(You should take the wrong suggestion as a bug of Swift/Xcode and send a Bug Report to Apple.)

You need to modify the closure's parameter types and return type as declared -- (NSNumber?,Int) -> [Any]!:

    let colorRange = { (param1: NSNumber?, param2: Int) -> [Any]! in
return [UIColor.red]
}

aSpecialMethod(colorRange: colorRange)

Or put the closure where Swift can infer the types and omit type annotations:

    aSpecialMethod { param1, param2 in
return [UIColor.red]
}

Swift Playground Error: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

When the line var f:Bool = isPrime(i) is called, initial value of i is 0, division by zero gives an unknown value. Better change your loop to for i in 1 ..< 100

Swift Data.subdata fails with EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

The indices of a Data value (or of collections in general) are not necessarily zero-based. A slice shares the indices with the originating data. Example:

let buffer = Data(bytes: [1, 2, 3, 4, 5, 6])[2..<4]

print(buffer.count) // 2
print(buffer.indices) // 2..<4

let tmpData = buffer.subdata(in: 0..<2)
// Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

Therefore you have to take the start index into account:

let tmpData = buffer[buffer.startIndex ..< buffer.startIndex + 2]
print(tmpData as NSData) // <0304>

or simply use the prefix:

let tmpData = buffer.prefix(2)
print(tmpData as NSData) // <0304>

Applied to your case:

let tempData = incomingDataBuffer.prefix(headerSizeInBytes)

Swift: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) on accessing JSON URL

Your guard statement is useless because you're forced unwrapping the value in the parentheses.

To make the guard statement fully functional you need a second optional binding:

guard let stationURL = nxCurrentStation?.stationStreamURL, 
let streamURL = URL(string: stationURL) else { ...

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) - underlying causes

The identifier "EXC_BAD_INSTRUCTION" seems to indicate an attempt to execute an invalid opcode. On IA32 hardware, it is a fault of type Invalid Opcode Exception (#UD) and has interrupt vector value of 6. It can be triggered for a number of reasons but it generally means that the byte sequence that encode the incoming instruction is invalid or reserved, or has inconsistent operands relative to the instruction, or is to long (>15 bytes), or uses an IA32 extension not supported by the current hardware, or is the UD2 opcode, or attempting to execute some instruction while the machine is in some state that prevents its execution, or some other corner cases.

Now, one possible explanation for cause for this kind of fault is that the compiler you are using assumes that some hardware features are accessible to the target (executing) machine and compiles code accordingly. The target machine features can generally specified as compile flag options. For example, floating point operations and standard math functions will normally only generate x87 fpu instruction, but using the combination of -mfpmath=sse and -msse instruct compiler to generate SSE scalar instructions for usual floating point calculations. The SEE instruction sets are an extension feature of IA32 architecture and are not available on all machines. Portable code for an architecture should be compiled to machine independent generic code for this architecture.

Another possible but less probable cause for this hardware fault is that the compiler might itself be bugged and generate some invalid byte sequence.

I don't think some undefined behavior would lead to an invalid opcode fault on most architectures. While it is true that UB may lead to any kind of erratic behavior, UB conditions are mostly never detectable at compile time and as such, the usually generate a General Protection Fault (#GP) on IA32 (which is called a segmentation fault in unix nomenclature). On the opposite, attempting to generate an undefined opcode is a condition that is always detectable at compile time (unless the code is self generating at runtime, or if the byte code stream gets misaligned and the instruction pointer points in the middle of some opcode).

swift- get exc_bad_instruction (code=exc_i386_invop, subcode=0x0) with array value replacement in while loop

The console shows what your error is:

fatal error: Index out of range

You're going out of bounds with thelistx [theAt] [theCt]

Changing while Ct < C to Ct < C - 1 keeps your calls in the bounds of the array.



Related Topics



Leave a reply



Submit