I've encountered something that confuses me in a core file because dbx and mdb seem to be telling me different things. According to dbx:
$ dbx /.../httpd core ... t...@3 (l...@3) terminated by signal ILL (Illegal Instruction) 0xff046df0: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! 0xff046e00 ... (dbx) dis __lwp_park 0xff046ddc: __lwp_park : mov %o1, %o2 0xff046de0: __lwp_park+0x0004: mov %o0, %o1 0xff046de4: __lwp_park+0x0008: clr %o0 0xff046de8: __lwp_park+0x000c: mov 77, %g1 0xff046dec: __lwp_park+0x0010: ta 8 0xff046df0: __lwp_park+0x0014: bcc,a,pt %icc,__lwp_park+0x24 ! 0xff046e00 0xff046df4: __lwp_park+0x0018: clr %o0 0xff046df8: __lwp_park+0x001c: cmp %o0, 91 0xff046dfc: __lwp_park+0x0020: move %icc,0x4, %o0 0xff046e00: __lwp_park+0x0024: retl Notice that there is no indication that __lwp_park_0x14 has anything wrong with it. This appears to be hand-coded assembly that hasn't changed for a long time. However, when I look at it with mdb, I see: # mdb core Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ] > ::stack libc.so.1`__lwp_park+0x14(0, 174058, 0, 0, 7d89c, 0) libc.so.1`cond_wait_queue+0x4c(174098, 174058, 0, 0, 1c00, 0) libc.so.1`cond_wait+0x10(174098, 174058, 0, 1c00, 0, 1741b8) libc.so.1`pthread_cond_wait+8(174098, 174058, 0, 0, 174058, ff0402a0) libapr-0.so.0.9.4`apr_thread_cond_wait+0x44(174090, 174050, 2aa688, 240, 2aa780, 34e820) ap_queue_pop+0x78(174038, fe2fbf1c, fe2fbf10, 0, 34e820, ff0c5480) worker_thread+0x160(1742f8, 1a4858, 0, 0, feb40a00, 1) libapr-0.so.0.9.4`dummy_worker+0x48(1742f8, fe2fc000, 0, 0, ff2d0a58, 1) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > ::status debugging core file of httpd (32-bit) from XXX file: /.../httpd initial argv: /.../httpd ... threading model: multi-threaded status: process terminated by SIGILL (Illegal Instruction) > libc.so.1`__lwp_park::dis libc.so.1`__lwp_park: mov %o1, %o2 libc.so.1`__lwp_park+4: mov %o0, %o1 libc.so.1`__lwp_park+8: clr %o0 libc.so.1`__lwp_park+0xc: mov 0x4d, %g1 libc.so.1`__lwp_park+0x10: ta 0x8 libc.so.1`__lwp_park+0x14: 0x3a480004 <<< Notice that this instruction is not decoded! libc.so.1`__lwp_park+0x18: clr %o0 libc.so.1`__lwp_park+0x1c: cmp %o0, 0x5b libc.so.1`__lwp_park+0x20: 0x91646004 libc.so.1`__lwp_park+0x24: retl libc.so.1`__lwp_park+0x28: nop According to mdb, it looks to me like someone clobbered __lwp+0x14. However, pmap suggests this shouldn't be possible because the memory segment is readable and executable but not writable. $ pmap core .... FEF80000 1152K r-x-- /lib/libc.so.1 ... >From the dbx output in the beginning of this message, we could see that __lwp_park starts at address 0xff046df0, which is between FEF80000 and FF0A0000 (FF0A0000 = FEF80000 + 1152k). Why do mdb and dbx disagree on the contents of __lwp_park+0x14 (and +0x20)? Is mdb reading the core and dbx reading the executable and libs from the file system? Does modification to a read-only memory segment suggest a hardware error? -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
