User forums > Help

C::B on snow leopard, gdb issue

(1/2) > >>

spectrum:
Hello all,

i am facing a very strange issue, trying to debug a wxWidget program from inside C::B:
i get this error just after gdb start:

Building to ensure sources are up-to-date
Build succeeded
Selecting target:
debug
Adding source dir: /Users/angelo/barix/tools/bsd/
Adding source dir: /Users/angelo/barix/tools/bsd/
Adding file: bin/debug/bsd
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar  5 04:43:10 UTC 2010)
Program received signal SIGTRAP, Trace/breakpoint trap.
In __dyld_dyld_fatal_error () ()

Backtrace:
#0  0x8fe01065 in __dyld_dyld_fatal_error ()
#1  0x8fe04fa5 in __dyld__ZN4dyld4haltEPKc ()
#2  0x8fe0796b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#3  0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#4  0x8fe01057 in __dyld__dyld_start ()


Looking with ps, i see C::B is invoking gdb with:
/usr/libexec/gdb/gdb-i386-apple-darwin -nx -fullname -quiet -args bin/debug/bsd

Using this same command with gdb from the console, program get loaded correctly and can run.
`--> /usr/libexec/gdb/gdb-i386-apple-darwin -nx -fullname -quiet -args bin/debug/bsd
Reading symbols for shared libraries ...................... done
(gdb) run
Starting program: /Users/angelo/barix/tools/bsd/bin/debug/bsd
Reading symbols for shared libraries .+++++++++++++++++++++..................................................................................................
..

It's really strange, like if gdb launched from C::B is not able to load some dynamic libraries.

Every help is very appreciated.
Many thanks and Regards.
angelo

oBFusCATed:
Inspect the debugger's debug log (the log with the actual commands sent to the debugger), the setting to show the log is in settings->compiler & debugger -> debugger
Keep in mind that this gdb is extremely old.
C::B is made to work best with gdb 6.8+.
Please see if you can update your gdb, I know this is a bit problematic for MacOSX users.

spectrum:
Thanks,

well, i am anti-mac, for several reasons, but this time issue seems to be in C::B,
in the way it launch GDB, since gdb works fine from the console.

The gdb log says :

DYLD_LIBRARY_PATH=.:/opt/local/lib:/usr/local/lib:
Command-line: /usr/bin/gdb -nx -fullname  -quiet -args bin/debug/bsd

.....

then the error.

And the issue is that in DYLD_LIBRARY_PATH forced from CodeBlock /lib/sw folder is missing.
I tried to find if this env var setup is configurable, but i still don't find anything.

every help is appreciated

thanks
angelo

oBFusCATed:
You've not read my post, haven't you?
Read it. And then inspect the log, you'll see that C::B executes many commands you don't see in the normal log.
Execute the same commands in command line gdb and you'll see that it breaks the same way.
Some of the commands are known to break older gdbs (catch c++ exceptions is know to not work with 6.8 and c only projects, for example).

p.s. Please use code tags for pastes of logs/code. It makes post more readable.

spectrum:
hi,

well we are probably both reading posts too fast and entering a misundertanding loop :)
I explain better:

I enabled as you sayd the codeblocks debugger log.
It shows:


--- Code: ---
DYLD_LIBRARY_PATH=.:/opt/local/lib:/usr/local/lib:
Command-line: /usr/bin/gdb -nx -fullname  -quiet -args bin/debug/bsd
...


--- End code ---

And in particular the line
"DYLD_LIBRARY_PATH=.:/opt/local/lib:/usr/local/lib:"
is causing the issue.


As you said, launching the debugger from the console, if i do the same thing that codeblocks do ("DYLD_LIBRARY_PATH=.:/opt/local/lib:/usr/local/lib:")  this break gdb.

GDB is old, but stable, and works fine, except if you are forcing DYLD_LIBRARY_PATH with a wrong path.

regards

Navigation

[0] Message Index

[#] Next page