[lldb-dev] EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0) against ios sim 4.6.3 (5.0.1 is fine)

Greg Clayton gclayton at apple.com
Tue Feb 4 09:49:53 PST 2014


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

On Feb 4, 2014, at 8:17 AM, Carlo Kok <ck at remobjects.com> wrote:

> 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
> -- 
> Carlo Kok
> RemObjects Software
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev




More information about the lldb-dev mailing list