> On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: > > [ ... ] > >> My present code uses thread_create(). I am seeing > kernel panics due to an ASSERT fail in the > sfmmu_tsbmiss_exception(). > > Can you please post the part of the output of > "::msgbuf" (from > mdb on your crashdump) following the "panic[cpu...] " > line ? > panic[cpu0]/thread=2a108169cc0: BAD TRAP: type=31 rp=2a1081693a0 addr=349 mmu_fsr=0 occurred in module "unix" du e to a NULL pointer dereference
updisk: trap type = 0x31 addr=0x349 pid=984, pc=0x1034db8, sp=0x2a108168c41, tstate=0x4400001601, context=0x1 g1-g7: 60016022090, 2a108169cc0, 42f90, 8, 121c574, 0, 2a108169cc0 000002a1081690c0 unix:die+78 (31, 2a1081693a0, 349, 0, 2a108169180, 108dc00) %l0-3: 0000000000000000 0000000000000031 0000000001000000 0000000000002000 %l4-7: 000000000182d0f0 000000000182d000 0000000000000005 0000000000000001 000002a1081691a0 unix:trap+9d8 (2a1081693a0, 0, 5, 1c00, 0, 1) %l0-3: 0000000000000000 0000060016022090 0000000000000031 0000000000000000 %l4-7: ffffffffffffe000 00000000004325ca 0000000000000005 0000000000000001 000002a1081692f0 unix:ktl0+64 (60008b5cb64, 42f98, 1, fffffffffffffff8, 7331b, 1 ) %l0-3: 000000000180c000 0000000000000000 0000004400001601 000000000101e3a8 %l4-7: 00000300014c3e40 00000000004325ca 0000000000000000 000002a1081693a0 000002a108169440 genunix:uiomove+90 (2a1081695a0, 42001, 31, 0, 43254b, 60015481 0c8) %l0-3: 000000000180c000 0000000000000001 0000000000000000 0000000000001c00 %l4-7: 00000300014c3e40 00000000004325ca 0000000000000002 000000000180c000 000002a1081694f0 unix:ktl0+64 (60008b5cb64, 42f98, 1, fffffffffffffff8, 7331b, 1 ) %l0-3: 000000000180c000 0000000000000000 0000000080001607 0000000001034d64 %l4-7: 0000000000000008 000002a108169940 0000000000000000 000002a1081695a0 000002a108169640 genunix:uiomove+90 (60008b5cb5c, 8, 0, 2a108169950, 0, 8) %l0-3: 000002a108169960 000002a108169950 0000000000000002 0000000000008000 %l4-7: 0000000000000008 000002a108169940 000002a108169950 0000060008b5cb64 000002a1081696f0 genunix:struiocopyout+38 (60003b53080, 2a108169950, 2a108169864 , 0, 60008b5cb64, 1) %l0-3: 0000030015d9bd18 0000030015d9bc98 0000000000000002 0000000000008000 %l4-7: 0000000000000008 0000000000000008 000002a108169950 0000060008b5cb64 000002a1081697a0 genunix:strread+4b4 (0, 2a108169950, 0, 30017460860, 0, 0) %l0-3: 0000030015d9bd18 0000030015d9bc98 0000000000000002 0000000000008000 %l4-7: 0000000000000000 0000000000000000 0000060003b53080 0000000000000000 000002a108169870 ipfs:ipfs_in+1e8 (0, 3001bba0940, 30017460860, 8, 2a108169ab0, 0) %l0-3: 00000000018ec400 0000000000000000 0000030015d9bc98 0000060005e80000 %l4-7: 0000060005e80068 0000000000000008 00000600153ad4e0 0000000000000000 000002a108169990 ipfs:ipfs_active_in+ec (60005e80000, 3001bba0940, 60016dc0400, 600153a0000, 0, 60005e800d8) %l0-3: 0000000000000000 0000000000000000 00000600153ad120 00000000704a5400 %l4-7: 0000060005e80068 0000060005e80000 00000600153ad4e0 0000000000000000 > I do think you're running way down the wrong track > there. You get a trap > because of an invalid pointer, that the trap handling > mechanism doesn't > tell you that clearly but fails somewhere else is > more than likely just an > artifact. The _real_ meat is elsewhere. > > when you do crashdump analysis, don't always focus > only on the topmost > function in a stacktrace. There's more to it than > that and the bug you try > to track down & fix isn't necessarily at the very > place where things fall > over. > > Are you willing to share that crashdump with the > community ? > I dont think you would like this, Its from Solaris 10 not OpenSolaris. > Thx, > FrankH. > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
