views:

2382

answers:

3

I've a fairly huge .gdbinit (hence not copied here) in my home directory.

Now if I want to debug code inside Xcode I get this error:

Failed to load debugging library at:

/Developer/Applications/Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/PBGDBIntrospectionSupport.A.dylib

Custom data formatters are disabled.

Error message was:
0x1005c5 "dlopen(/Developer/Applications/Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/PBGDBIntrospectionSupport.A.dylib, 16): image not found"

Actually - as posted below - the debugging still works in Xcode but the Data Formatters breaks. Moving out .gdbinit OR disabling Data Formatters does get gdb in Xcode back in a working state but it's obviously a pain (Including Data Formatters, in the first case)

Any idea as to which settings in gdbinit could cause this error in Xcode ?

Note from Reply: It's seems (from a google search) that this error might happen when linking against the wxWidgets library. Something that I'm not doing here.

Note: if needed I can provide a copy of my (long) .gdbinit

WIP: I will have a look in details at my .gdbinit to see if I can narrow down the issue

A: 

Strange... Looking around my mac, I see that library just fine, and it looks sane.

Have you tried using dtrace to see what xcode and gdb are trying to do when the error happens?

Mike G.
The library is there on mine too, no file integrity issue (if I delete gdbinit, Xcode debugging fully works)
ninendra
ninendra
+5  A: 

My "short" answer:


You may have noticed this already, but just in case:

First of all, even when you see that error, (assuming that you click past it and continue), then you should still be able to use 99% of the debugging features in Xcode. In other words, that error means that only a very small, specific portion of the debugger is "broken" for a given debugging session. It does not mean that debugging is completely down and/or impossible for the given program-execution.

Given the above fact, if you simply want to get rid of the error and do not care whether Custom Data Formatters are working or not, then REMOVE the check-mark next to the following menu item:

  • Run -> Variables View -> Enable Data Formatters

My "long" answer:


The developers in my office had been experiencing this very same Xcode error for quite a while until someone discovered that some third party libraries were the cause.

In our case, this error was happening only for projects using wxWidgets. I am not meaning to imply that usage of wxWidgets is the only possible cause. I am only trying to put forth more information that might lead to the right solution for your case.

Also of interest: we (in my office) were getting this error without any use or presence of any .gdbinit file whatsoever.

It turns out that the "property" of wxWidgets that made it trigger this error was related to a "custom/generic" implementation of "dlopen." Prior to Mac OS X 10.3, dlopen was not provided within the operating system, so apparently some libraries coded their own versions. When such libraries are being used, then apparently the dlopen call that tries to open PBGDBIntrospectionSupport.A.dylib can fail.

Read through the comments on this sourceforge patch submission to learn even further details about dlopen in 10.3 and beyond.

Also, here is another related link:

Message on the Xcode users mailing list about PBGDBIntrospectionSupport and Custom Data Formatters

que que
Very nice reply, ThanksActually I was aware of the wxWidget issue (the only few results on google) but I'm not using it.And I also saw that debugging continue to work, just breaks the Data Formatter which is actually something that I need.I will have a look at my gdbinit in detials
ninendra
A: 

Your error is actually a little different from the one I was getting with wxWidgets. It's been a while since I found the dlopen conflict, but I do remember that I had to use gdb itself in that specific debug session to figure out what was going on. Also, with the wxWidgets issue, the hex address was different every time.

In gdb, call "info symbol" on the hex address that's in the error message. This may give you details on precisely what's failing to load.