Update:
I have random segfaults all over the place. I would usually assume this
is due to bad memory, but a couple of things seem strange. 'test-memory'
is OK, the kernel itself is stable so far. Gcc or perl have not
segfaulted yet, despite building a kernel and trying to build ports
for some time.
What segfaults are ksh, cat (a lot), ln, make before I recompiled it
with "-ggdb -O0" (same with ksh).
Here's some cat debugging:
$ gdb /bin/cat
/usr/ports/pobj/gettext-0.18.1/gettext-0.18.1/gettext-tools/libgettextpo/cat.core
<stfu>
This GDB was configured as "sparc-unknown-openbsd5.1"...
warning: exec file is newer than core file.
Core was generated by `cat'.
Program terminated with signal 11, Segmentation fault.
#0 0x00014b38 in malloc_init () at /usr/src/lib/libc/stdlib/malloc.c:490
490 for (; p != NULL && *p != '\0'; p++) {
(gdb) info registers
g0 0x0 0
g1 0x4d 77
g2 0x45 69
g3 0x12412b 1196331
g4 0x4b 75
g5 0x0 0
g6 0x0 0
g7 0x10160 65888
o0 0x0 0
o1 0xffffffff -1
o2 0x3f 63
o3 0xf99d5fb0 -107126864
o4 0xf7fdeb38 -134354120
o5 0xfebd2415 -21158891
sp 0xf7fde8a8 0xf7fde8a8
o7 0x14b68 84840
l0 0x62c000 6471680
l1 0x2 2
l2 0x140d0 82128
l3 0x2000 8192
l4 0x124070 1196144
l5 0xf7fde910 -134354672
l6 0x62c000 6471680
l7 0x226240 2253376
i0 0x616c2f62 1634479970
i1 0xf99d5fb0 -107126864
i2 0x124128 1196328
i3 0xf7fde958 -134354600
i4 0x124110 1196304
i5 0x632400 6497280
fp 0xf7fde960 0xf7fde960
i7 0x16730 91952
y 0x0 0
psr 0x40000081 1073741953
wim 0x0 0
tbr 0x0 0
pc 0x14b38 0x14b38 <malloc_init+904>
npc 0x14880 0x14880 <malloc_init+208>
fsr 0x0 0
csr 0x0 0
(gdb) disassemble 0x00014b30 0x00014b40
Dump of assembler code from 0x14b30 to 0x14b40:
0x00014b30 <malloc_init+896>: cmp %i0, 0
0x00014b34 <malloc_init+900>: bne,a 0x14880 <malloc_init+208>
0x00014b38 <malloc_init+904>: ldsb [ %i0 ], %g1
0x00014b3c <malloc_init+908>: inc %l1
End of assembler dump.
(gdb) x 0x616c2f62
0x616c2f62: Cannot access memory at address 0x616c2f62
It's about to jump to <malloc_init+208>, but before that it does its
branch prediction thing and loads a byte from a memory location that
isn't mapped... Now I don't know much about sparc assembly, but that
seems to be a code generation bug - or am I misinterpreting what's going
on here?
