--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.12.31 16:55:52 +0000, John Honniball wrote:
| Martin Husemann wrote:
| >Could you please try to reproduce it and when it enters the debugger
| >do
| OK -- thanks for those two debugger commands!  Results are:
| =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| Stopped in pid 90.1 (tar) at    0x100bab4:      stx             %o1,=20
| [%o0 - 0x8]
|=20
| db> show reg
| tstate      0x82000601
| pc          0x100bab4
| npc         0x100baa8
| ipl         0
| y           0
| g0          0
| g1          0x800
| g2          0x2000
| g3          0x4000
| g4          0x8000000013ffa034
| g5          0x1000
| g6          0
| g7          0x114b40
| o0          0xa870090
| o1          0
| o2          0x1f68
| o3          0x1
| o4          0xa870000
| o5          0x1000000
| o6          0xca4ac21
| o7          0x1255f20
| l0          0
| l1          0
| l2          0
| l3          0
| l4          0
| l5          0
| l6          0
| l7          0
| i0          0
| i1          0
| i2          0
| i3          0
| i4          0
| i5          0
| i6          0
| i7          0
| f0          0
| f2          0
| f4          0
| f6          0
| f8          0
| f10         0
| f12         0
| f14         0
| f16         0
| f18         0
| f20         0
| f22         0x2320
| f24         0x556e697665727320
| f26         0x20204d6443644974
| f28         0xa6e616d65205543
| f30         0x490a737061636577
| f32         0
| f34         0
| f36         0
| f38         0
| f40         0x2320556e69766572
| f42         0x732020204d644364
| f44         0x49740a6e616d6520
| f46         0x5543490a73706163
| f48         0x2320556e69766572
| f50         0
| f52         0
| f54         0
| f56         0
| f58         0
| f60         0
| f62         0
| fsr         0
| gsr         0x600000000
| 0x100bab4:      stx             %o1, [%o0 - 0x8]
| db> bt
| ?(da5e900, 0, ca4b7c0, ca4b7e4, 0, 2) at 0x12544bc
| ?(da5e900, 10ca, 1000, c180000, 0, 0) at 0x11cea18
| ?(0, 1, c180000, 2, 0, 10ca) at 0x11b786c
| ?(da5e900, ca4bba0, 1, c180000, 0, 0) at 0x1253ba4
| ?(0, c1ac3f8, ca4bba0, c180000, 1, 42e04a52) at 0x1252d6c
| ?(16, 8, c1ac3c0, 46b668, 1000, 1000) at 0x12294ac
| ?(9, ca4bdd0, ca4bdc0, 42e04a5500000000, ca4bdd0, 42e04a55ffffffff) at=20
| 0x1229418
|=20
| ?(ca4bed0, 4, 2739d8, 5d, 2739d8, 800) at 0x134063c
| ?(8, 46b668, 1000, 0, 0, 0) at 0x1008cb8

It seems to me the stack is mangled. The last time I saw a problem
like this on i386 it was due to the kernel not handling SSE
exceptions (fixed by Christos).
I don't know the sparc arch very well to understand what's going on
where and I can be pretty damn wrong :-)

		-- Rui Paulo

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDtt4UZPqyxs9FH4QRAsQoAKCDy4Nx7g9AY7RSpe/LuOn0aT5/WACgnJCC
c4Cy7+EubvttEzqg7e8FKSg=
=rdwx
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--