EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0) against ios sim 4.6.3 (5.0.1 is fine)

I'm currently using lldb from september and when debugging against iOS-Sim (i386) 5.0.1 things are fine, but when doing the same with xcode 4.6.3 sim the debugger breaks on a fatal exception EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)

Where can I start looking for the cause of this? Previous versions of lldb worked fine against this. Anyone know if updating will work (Updating llvm, clang, lldb is atm a bit painful for us because we have arm64 patches integrated that main llvm didn't accept) or where I can start looking for what causes this?

full log:

http://pastebin.com/Q2WS1eic
h

The main thing that worries me in your log is:

1391530035.296000000 SBDebugger(08AB30A8)::CreateTarget (filename="(null)", triple=(null), platform_name=(null), add_dependent_modules=1, error=(null)) => SBTarget(0BAFDAA0)

If you know you are debugging to the iOS simulator, then set platform to "ios-simulator" and triple to "i386-apple-ios".
When debugging to a device, then set platform to "remote-ios" and triple to one of "armv7-apple-ios", "armv7s-apple-ios", or "arm64-apple-ios".

This will help LLDB locate the right files as they get loaded as the platforms know where to look. The other worrying lines in this log are:

1391530046.234000000 Target::SetArchitecture setting architecture to unknown ()

1391530046.367000000 Target::SetArchitecture setting architecture to x86_64 (x86_64-apple-macosx)

Both are incorrect and are a result of not having set the platform and triple when creating your target. We see there are a few modules that attempt to realize themselves and immediately cause the module to destroy itself:

1391530053.593000000 0BC6B428 Module::Module((x86_64) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')
1391530053.594000000 DataBufferMemoryMap::MemoryMapFromFileSpec(file="C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews", offset=0x0, length=0xcc54, writeable=0
1391530053.594000000 DataBufferMemoryMap::MemoryMapFromFileSpec(fd=00000004, offset=0x0, length=0xcc54, writeable=0, fd_is_file=1)
1391530053.594000000 0BC9E178 ObjectFile::ObjectFile() module = 0BC6B428 (C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews), file = C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews, file_offset = 0x00000000, size = 52308
1391530053.595000000 0BC9E178 ObjectFile::~ObjectFile ()

1391530053.595000000 DataBufferMemoryMap::Clear() m_mmap_addr = 1ABF0000, m_mmap_size = zu
1391530053.595000000 0BC6B428 Module::~Module((x86_64) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')
1391530053.596000000 0B63E850 Module::Module((i386) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')

You see above we try to make an x86_64 module, we fail, then we revert to i386. If you set the platform and arch this can be avoided.

Let me know if that helps. I would also get a log from the working Xcode and see how it differs to look for more clues.

Greg

The main thing that worries me in your log is:

1391530035.296000000 SBDebugger(08AB30A8)::CreateTarget (filename="(null)", triple=(null), platform_name=(null), add_dependent_modules=1, error=(null)) => SBTarget(0BAFDAA0)

If you know you are debugging to the iOS simulator, then set platform to "ios-simulator" and triple to "i386-apple-ios".
When debugging to a device, then set platform to "remote-ios" and triple to one of "armv7-apple-ios", "armv7s-apple-ios", or "arm64-apple-ios".

I don't think lldb supports arm64 yet?

This will help LLDB locate the right files as they get loaded as the platforms know where to look. The other worrying lines in this log are:

1391530046.234000000 Target::SetArchitecture setting architecture to unknown ()

1391530046.367000000 Target::SetArchitecture setting architecture to x86_64 (x86_64-apple-macosx)

Ah! dunno how I could have missed that. We added support for iOS Sim 64 and somehow when only 32bits is available it fails. Thanks!

Both are incorrect and are a result of not having set the platform and triple when creating your target. We see there are a few modules that attempt to realize themselves and immediately cause the module to destroy itself:

1391530053.593000000 0BC6B428 Module::Module((x86_64) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')
1391530053.594000000 DataBufferMemoryMap::MemoryMapFromFileSpec(file="C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews", offset=0x0, length=0xcc54, writeable=0
1391530053.594000000 DataBufferMemoryMap::MemoryMapFromFileSpec(fd=00000004, offset=0x0, length=0xcc54, writeable=0, fd_is_file=1)
1391530053.594000000 0BC9E178 ObjectFile::ObjectFile() module = 0BC6B428 (C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews), file = C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews, file_offset = 0x00000000, size = 52308
1391530053.595000000 0BC9E178 ObjectFile::~ObjectFile ()

1391530053.595000000 DataBufferMemoryMap::Clear() m_mmap_addr = 1ABF0000, m_mmap_size = zu
1391530053.595000000 0BC6B428 Module::~Module((x86_64) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')
1391530053.596000000 0B63E850 Module::Module((i386) 'C:\ProgramData\RemObjects Software\Oxygene\Symbols\Nougat\192.168.178.2/tempexe9b4c63fbece3414b8c9de67d38fbc0a2-CollectionViews')

You see above we try to make an x86_64 module, we fail, then we revert to i386. If you set the platform and arch this can be avoided.

Let me know if that helps. I would also get a log from the working Xcode and see how it differs to look for more clues.

Yeah if I pass i386 it works. Thanks!