Re: Problem Report: Segfault in oskit-mach
ATTN: Marcus, Roland
Hi,
Haven't had the inertia to do it today, but I'll see if I can get
your info compiled tomorrow. On a whim, I wondered if my
scsi bios was the culprit (last week I booted from hda but
now I boot from sda for many reasons). I toggled my bios boot
options and tried it under ide control but it didn't make any
noticable difference.
One note, I'm using oskit 20010214 with the Debian patch,
and I re-CVS'd oskit-mach last weekend. Previously I could
compile with --enable-smp=2 but now it bombs out near the
end of the make, apparently looking for some functions which
deal with the x86 cpu registers. I'll do a cvs update and rebuild
oskit-mach before I send another problem report.
Also, I did a dselect upgrade of my linux os to the current
state of woody. This is my build environment, so that might
or might not be significant.
My source tree is set up as:
/usr/src/gnu/oskit-0.97.20010214
/usr/src/gnu/hurd-20020103/oskit-mach
I now build oskit directly in its top level dir, not in build, to
simplify the remote debugging. I compile oskit-mach in a
build subdir. I run "make clean" on oskit after "make install",
and I do not clean oskit-mach/build. I make a tarball of the
whole /usr/src/gnu directory and ftp it over to the hppa
machine. Then I launch i686-linux-gdb from within that
tree.
The pain in the butt thing is that if I modify a file
on the linux box I have to sync it on the hp9k because
obviously I can't mount the source via nfs before my
kernel boots. I probably could go the other way, but the
hp9k's scsi drives are an order of magnitude slower than
the ones on the linux/hurd system and then it would be slow
and sucky to compile it all. I suppose I should get some kind
of localnet cvs thing going one of these days, finally apache
is fixed (thanks to Debian, I didn't do anything)
So I'm too busy drinkin' tonight to do any serious hacking.
Party on dudes...
Marcus Brinkmann wrote:
On Sun, Mar 03, 2002 at 11:38:38PM -0500, B. Douglas Hilton wrote:
Program received signal SIGSEGV, Segmentation Fault.
0x00156173 in trap_from_kernel ()
What we always need is a complete backtrace (bt full), the register settings
(info reg) and the assembler code in that location (x/40i or so).
Ok, duly noted.
Roland McGrath replied:
Sadly, it's been instant reboots all day long. I finally got it
to crash at a trap now though on my latest compile. Here
is the info I have gleaned from my debugger:
You need to step more slowly. Do "display/i $pc" and then use "si" (short
for "stepi") instead of regular "step". Then you will see exactly what
happened.
No problem.
Reply to: