After some further consideration, I went out of my way to figure
out I
could get exactly the output you're getting. This doesn't use
ptrace,
but it's not something you would likely do on accident. I figured
I'd
post this because there might be a (very, very, very) slight chance
that you're doing something similar with a global class. Here's the
gdb transcript where you see different output for normal shell
execution and within gdb...
haven:test jon$ g++ -o test test.cc
haven:test jon$ ./test
shouldn't get here
haven:test jon$ gdb test
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2
04:07:49 UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for
shared libraries .... done
(gdb) break main
Breakpoint 1 at 0x1e42
(gdb) r
Starting program: /Users/jon/test/test
Reading symbols for shared libraries +++. done
darwin-i386
Program exited normally.
(gdb)
And here's the code....
#include <sys/types.h>
#include <sys/ptrace.h>
#include <stdio.h>
#include <assert.h>
#include <stdbool.h>
#include <unistd.h>
#include <sys/sysctl.h>
// stolen from the ADC website
static bool AmIBeingDebugged(void)
// Returns true if the current process is being debugged (either
// running under the debugger or has a debugger attached post
facto).
{
int junk;
int mib[4];
struct kinfo_proc info;
size_t size;
// Initialize the flags so that, if sysctl fails for some bizarre
// reason, we get a predictable result.
info.kp_proc.p_flag = 0;
// Initialize mib, which tells sysctl the info we want, in
this case
// we're looking for information about a specific process ID.
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = KERN_PROC_PID;
mib[3] = getpid();
// Call sysctl.
size = sizeof(info);
junk = sysctl(mib, sizeof(mib) / sizeof(*mib), &info, &size,
NULL, 0);
assert(junk == 0);
// We're being debugged if the P_TRACED flag is set.
return ( (info.kp_proc.p_flag & P_TRACED) != 0 );
}
// code to run before the main()
class premain {
public:
premain(void);
};
premain::premain(void) {
if(AmIBeingDebugged()) {
printf("darwin-i386\n");
exit(EXIT_SUCCESS);
}
}
// instance in global scope
premain *mypremain = new premain();
int main(void){
printf("shouldn't get here\n");
return 0;
}
I hope that helps. This seems like it might be an interesting
problem
if it's something to do with your actual code and not something
to do
with how gdb is configured.
-Jon Bringhurst <email@hidden>
On Nov 27, 2007 5:19 PM, Jonathan Bringhurst <email@hidden>
wrote:
Seems to work fine for me on leopard.
haven:test jon$ uname -a
Darwin haven 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22
PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
haven:test jon$ cat test.c
#include <stdio.h>
main(){printf("hw\n");}
haven:test jon$ cc -o test test.c
haven:test jon$ gdb test
...snip...
(gdb) break main
Breakpoint 1 at 0x1fde
(gdb) r
Starting program: /Users/jon/test/test
Reading symbols for shared libraries ++. done
Breakpoint 1, 0x00001fde in main ()
(gdb) c
Continuing.
hw
Program exited with code 012.
(gdb)
Perhaps you have ptrace() called with PT_DENY_ATTACH? This could
simulate the behavior you're currently experiencing.
-Jon Bringhurst <email@hidden>
On Nov 27, 2007 4:40 PM, Dave Chen <email@hidden> wrote:
When I try to run my command-line programs in gdb all it does
is print
"darwin-i386" and then exit normally. It never actually runs
the program.
Here's an example:
puget => gdb fillHoles
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2
04:07:49 UTC
2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i386-apple-darwin"...Reading
symbols for shared
libraries ....... done
(gdb) b main
Breakpoint 1 at 0x100004b5f: file
/nfs/mead/Users/dave/dsrc/geom/fillHoles.C, line 527.
(gdb) r
darwin-i386
Program exited normally.
It never even stops at the breakpoint I put at main.
Anyone have any idea what is going on or seen anything
similar? If I run
the program without gdb, I can attach to the process OK, but I
just can't
start programs in gdb.
Thanks,
Dave
David T. Chen, PhD [Lockheed Martin
contractor]
mailto:email@hidden http://erie.nlm.nih.gov/
~dave
phone:301.435.3264 iphone:301.524.3174
Office of High Performance Computing and Communications
National Library of Medicine
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Scitech mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/scitech/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Scitech mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/scitech/email@hidden
This email sent to email@hidden
