ddd can't read a .core file.

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host is a 1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10. When I
try to load a .core file into ddd the target’s cpu goes to 100% and stays
there while the ddd console’s little green light (ddd busy) just blinks
forever. The .core is a 20M file. I gave it 5 minutes to load, but it
never finished. Any idea what gives? Is it due to how my QNX application
failed?

Tom.

2

Thomas Green <Thomas.Green@siemens.com> wrote:

My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host is a 1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10. When I
try to load a .core file into ddd the target’s cpu goes to 100% and stays
there while the ddd console’s little green light (ddd busy) just blinks
forever. The .core is a 20M file. I gave it 5 minutes to load, but it
never finished. Any idea what gives? Is it due to how my QNX application
failed?

Care to try it with plain gdb?

ntox86-gdb /path/to/binary /var/dumps/binary.core

Does that chew 100% forevery?

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

3

Chris,

I tried gdb, as you suggested, and got a little further this time. I loaded
the debug executable and core file, then gave gdb the “info stack” command.
This is what I got then the cpu went to 100%:

#0 0xb032968e in MsgSend () from /x86/lib/libc.so.2
#1 0xb03156cc in read () from /x86/lib/libc.so.2
#2 0xb0336fde in _Frprep () from /x86/lib/libc.so.2
#3 0xb0334ede in fgetc () from /x86/lib/libc.so.2
#4 0x081fa0a7 in bool std::_Fgetc (_Byte=@0x804763b, _File=0xb034f200)
at /usr/include/cpp/fstream:18
#5 0x081f7aa6 in std::basic_filebuf<char, std::char_traits >::uflow
(this=0xb883a020) at /usr/include/cpp/fstream:228
#6 0x081f7cde in std::basic_filebuf<char, std::char_traits

::underflow (this=0xb883a020) at /usr/include/cpp/fstream:209

Normally you get 10 backtrace points.

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bed31o$hau$1@nntp.qnx.com…

Thomas Green <> Thomas.Green@siemens.com> > wrote:
My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host is a
1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10. When
I
try to load a .core file into ddd the target’s cpu goes to 100% and
stays
there while the ddd console’s little green light (ddd busy) just blinks
forever. The .core is a 20M file. I gave it 5 minutes to load, but it
never finished. Any idea what gives? Is it due to how my QNX
application
failed?


Care to try it with plain gdb?

ntox86-gdb /path/to/binary /var/dumps/binary.core

Does that chew 100% forevery?

chris

–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

4

There was a problem with gdb/C++/stabs debugging format where gdb would get
into a circular loop while resolving debugging information. Just for
chuckles, try compiling your app with -gdwarf-2 and see if you have the same
problem. I’m pretty sure it was only for stabs that the problem existed.

cheers,

Kris

“Thomas Green” <Thomas.Green@Siemens.com> wrote in message
news:beed0c$plu$1@inn.qnx.com…

Chris,

I tried gdb, as you suggested, and got a little further this time. I
loaded
the debug executable and core file, then gave gdb the “info stack”
command.
This is what I got then the cpu went to 100%:

#0 0xb032968e in MsgSend () from /x86/lib/libc.so.2
#1 0xb03156cc in read () from /x86/lib/libc.so.2
#2 0xb0336fde in _Frprep () from /x86/lib/libc.so.2
#3 0xb0334ede in fgetc () from /x86/lib/libc.so.2
#4 0x081fa0a7 in bool std::_Fgetc (_Byte=@0x804763b,
_File=0xb034f200)
at /usr/include/cpp/fstream:18
#5 0x081f7aa6 in std::basic_filebuf<char, std::char_traits >::uflow
(this=0xb883a020) at /usr/include/cpp/fstream:228
#6 0x081f7cde in std::basic_filebuf<char, std::char_traits<char
::underflow (this=0xb883a020) at /usr/include/cpp/fstream:209

Normally you get 10 backtrace points.

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bed31o$hau$> 1@nntp.qnx.com> …
Thomas Green <> Thomas.Green@siemens.com> > wrote:
My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host is
a
1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10.
When
I
try to load a .core file into ddd the target’s cpu goes to 100% and
stays
there while the ddd console’s little green light (ddd busy) just
blinks
forever. The .core is a 20M file. I gave it 5 minutes to load, but
it
never finished. Any idea what gives? Is it due to how my QNX
application
failed?


Care to try it with plain gdb?

ntox86-gdb /path/to/binary /var/dumps/binary.core

Does that chew 100% forevery?

chris

–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\

5

Problem solved: I updated the ntox86-gdb to the gdb beta I got from my
co-worker Marty Doane, who got it from QNX.

Thanks.


“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:beetuv$ins$1@nntp.qnx.com…

There was a problem with gdb/C++/stabs debugging format where gdb would
get
into a circular loop while resolving debugging information. Just for
chuckles, try compiling your app with -gdwarf-2 and see if you have the
same
problem. I’m pretty sure it was only for stabs that the problem existed.

cheers,

Kris

“Thomas Green” <> Thomas.Green@Siemens.com> > wrote in message
news:beed0c$plu$> 1@inn.qnx.com> …
Chris,

I tried gdb, as you suggested, and got a little further this time. I
loaded
the debug executable and core file, then gave gdb the “info stack”
command.
This is what I got then the cpu went to 100%:

#0 0xb032968e in MsgSend () from /x86/lib/libc.so.2
#1 0xb03156cc in read () from /x86/lib/libc.so.2
#2 0xb0336fde in _Frprep () from /x86/lib/libc.so.2
#3 0xb0334ede in fgetc () from /x86/lib/libc.so.2
#4 0x081fa0a7 in bool std::_Fgetc (_Byte=@0x804763b,
_File=0xb034f200)
at /usr/include/cpp/fstream:18
#5 0x081f7aa6 in std::basic_filebuf<char, std::char_traits<char
::uflow
(this=0xb883a020) at /usr/include/cpp/fstream:228
#6 0x081f7cde in std::basic_filebuf<char, std::char_traits<char
::underflow (this=0xb883a020) at /usr/include/cpp/fstream:209

Normally you get 10 backtrace points.

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bed31o$hau$> 1@nntp.qnx.com> …
Thomas Green <> Thomas.Green@siemens.com> > wrote:
My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host
is
a
1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10.
When
I
try to load a .core file into ddd the target’s cpu goes to 100% and
stays
there while the ddd console’s little green light (ddd busy) just
blinks
forever. The .core is a 20M file. I gave it 5 minutes to load, but
it
never finished. Any idea what gives? Is it due to how my QNX
application
failed?


Care to try it with plain gdb?

ntox86-gdb /path/to/binary /var/dumps/binary.core

Does that chew 100% forevery?

chris

–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/


\

6

Good. That means it was probably the stabs debug bug that was biting you.

cheers,

Kris

“Thomas Green” <Thomas.Green@Siemens.com> wrote in message
news:bek4fp$g0f$1@inn.qnx.com…

Problem solved: I updated the ntox86-gdb to the gdb beta I got from my
co-worker Marty Doane, who got it from QNX.

Thanks.


“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:beetuv$ins$> 1@nntp.qnx.com> …
There was a problem with gdb/C++/stabs debugging format where gdb would
get
into a circular loop while resolving debugging information. Just for
chuckles, try compiling your app with -gdwarf-2 and see if you have the
same
problem. I’m pretty sure it was only for stabs that the problem
existed.

cheers,

Kris

“Thomas Green” <> Thomas.Green@Siemens.com> > wrote in message
news:beed0c$plu$> 1@inn.qnx.com> …
Chris,

I tried gdb, as you suggested, and got a little further this time. I
loaded
the debug executable and core file, then gave gdb the “info stack”
command.
This is what I got then the cpu went to 100%:

#0 0xb032968e in MsgSend () from /x86/lib/libc.so.2
#1 0xb03156cc in read () from /x86/lib/libc.so.2
#2 0xb0336fde in _Frprep () from /x86/lib/libc.so.2
#3 0xb0334ede in fgetc () from /x86/lib/libc.so.2
#4 0x081fa0a7 in bool std::_Fgetc (_Byte=@0x804763b,
_File=0xb034f200)
at /usr/include/cpp/fstream:18
#5 0x081f7aa6 in std::basic_filebuf<char, std::char_traits<char
::uflow
(this=0xb883a020) at /usr/include/cpp/fstream:228
#6 0x081f7cde in std::basic_filebuf<char, std::char_traits<char
::underflow (this=0xb883a020) at /usr/include/cpp/fstream:209

Normally you get 10 backtrace points.

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bed31o$hau$> 1@nntp.qnx.com> …
Thomas Green <> Thomas.Green@siemens.com> > wrote:
My target is a 700MHz x86 / QNX 6.2.1 with GNU DDD 3.3.1. My host
is
a
1.7
GHz x86 / Win2k running Exceed X server 7.1.0.0 and Phindows 2.10.
When
I
try to load a .core file into ddd the target’s cpu goes to 100%
and
stays
there while the ddd console’s little green light (ddd busy) just
blinks
forever. The .core is a 20M file. I gave it 5 minutes to load,
but
it
never finished. Any idea what gives? Is it due to how my QNX
application
failed?


Care to try it with plain gdb?

ntox86-gdb /path/to/binary /var/dumps/binary.core

Does that chew 100% forevery?

chris

–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/




\