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)
#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” <firstname.lastname@example.org> wrote in message
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
GHz x86 / Win2k running Exceed X server 18.104.22.168 and Phindows 2.10. When
try to load a .core file into ddd the target’s cpu goes to 100% and
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
Care to try it with plain gdb?
ntox86-gdb /path/to/binary /var/dumps/binary.core
Does that chew 100% forevery?
Chris McKillop <> email@example.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –