Re: My strange problems
Re: My strange problems
- Subject: Re: My strange problems
- From: Jim Ingham <email@hidden>
- Date: Thu, 11 Nov 2004 11:44:38 -0800
I have a bug about Jan's problem, but to be clear, it is not that gdb
was causing any problem with Jan's code, it was just that gdb wasn't
telling him that there were two copies of this function, and correctly
determining which one was used in which context.
If you are using ZeroLink, definitely try turning that off, ZeroLink
does alter the way the Linker binds up symbols, since it turns all your
.o's into independent bundles. The dynamic linker tries to fix things
back up, but it doesn't always reproduce exactly what the static linker
would do.
Note that none of the problems mentioned in the note you cited would
cause your development version to crash, all of them are about gdb not
telling you where a symbol is, or breaking in the right place or
whatever. If your app is actually segfaulting, and the stack pointer
is off in never-never land, that is almost certainly a real problem,
maybe caused by some other part of the development environment, like
ZeroLink, or maybe a latent problem in your code.
Jim
On Nov 11, 2004, at 4:05 AM, super bady wrote:
Jan, thanks for your sharing.
I found a related article:
http://lists.apple.com/archives/xcode-users/2004/Nov/msg00101.html
From that, it is likely that current gdb in Xcode causes that. If
so, are there some ways for us to attain to workable dynamic libraries
which also support c++ namespace at the same time?
Any suggestion is appreciated.
Thanks a lot!
On Thu, 11 Nov 2004 01:07:55 -0800, Jan Brittenson
<email@hidden> wrote:
I had a similar problem; a library I built and used wanted to be
initialized with a call
along the lines of lib_init(argc, argv). It would then use gnu getopt
to parse library
specific options. It would work in production builds, but not in
development. When
run it would die with exactly the same bus error you're seeing on an
attempt
to read *optind. Gnu getopt of course defined its own optind.
Turning
off zero
link would make the problem go away. In the end I simply replaced all
references to
optind with gnu_optind.
I looked at it in the debugger and couldn't find anything wrong -- the
code, optind,
everything looked just fine. But tryping to step it... bus error.
Clearly in this case
the debugger was looking at one optind, the code at another.
-Jan.
super bady wrote:
I am building a C++ project on Mac OS X 10.3.3. This project
contain tens of dynamic libraries(.dylib). They are all build by gcc.
When I debug it in the Xcode or GDB, it crashs after some actions.
The
debugger console show that:
Program received signal: "EXC_BAD_ACCESS"
Unable to disassemble ??.
The call stack captured by Xcode only has one frame which is "??".
When I look at the crash report, it shows:
Exception: EXC_BAD_ACCESS(0x0001)
Codes: KERN_PROTECTION_FAILURE(0x0002) at 0x00000000
More strange, when i build one of the libraries with release
version, the project do not crash and work well.
For callstack cann't be abtained when crashing, I do not know who
cause this crash. Code the that strange library or GCC. For this
project is a little large, I am not sure that whether it has exceeded
the capacity of gcc or gdb.
Have you met such problem befor? Any suggestions is appreciated.
Thanks!
By the way, my system info is as follows:
CPU: G5
OS : OS X 10.3.3
gcc: 3.3.20030304(Apple build 1666)
gdb: 5.3-20030128(apple version gdb-330.1)
xcode: 1.5
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40rockgarden.net
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden