|
Description
|
I am on a tucani (AST2100),
SunOS tucani-3 5.11 snv_108 i86pc i386 i86pc
Running memory arena checkers such as watchmalloc.so.1
(with a loader preload to have a simple memcpy that
does not fetch beyond its source, as noted in bug
6811052 memcpy fetches past the end of the source on i386 and amd64)
shows the following access of freed memory:
mdb: logging to "/tmp/stack.watchmalloc"
> $
no process
SIGTRAP: Trace/Breakpoint Trap
%cs = 0x0043 %eax = 0x00000001
%ds = 0x004b %ebx = 0xfeba1000
%ss = 0x004b %ecx = 0x084e3b68
%es = 0x004b %edx = 0x084e3b68
%fs = 0x0000 %esi = 0x00000000
%gs = 0x01c3 %edi = 0x00000001
%eip = 0xfeb7d2e8 libdevinfo.so.1`di_prop_next_common+0x30
%ebp = 0x080463e8
%kesp = 0x00000000
%eflags = 0x00010246
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
status=<of,df,IF,tf,sf,ZF,af,PF,cf>
%esp = 0x080463e0
%trapno = 0xe
%err = 0x4
> <eip/i
libdevinfo.so.1`di_prop_next_common+0x30: subl (%edx),%ecx
> $C
080463e8 libdevinfo.so.1`di_prop_next_common+0x30(84e3b68, 0, 0, 6, 84274a8,
feba1000)
08046408 libdevinfo.so.1`di_prop_drv_next+0x13(84e3b68, 0, 8046458, feb7cb1a)
08046448 libdevinfo.so.1`di_prop_next+0x4b(84e3b68, 0, 8046478, feb7cf2a)
08046498 libdevinfo.so.1`di_prop_search+0x6d(fffffffe, 84e3b68, febb8634, 1)
080464b8 libdevinfo.so.1`di_prop_lookup_ints+0x23(fffffffe, 84e3b68, febb8634,
80464f4)
08046648 libpciaccess.so.0`pci_device_solx_devfs_probe+0x303(8433678, 1, 0,
febb2f78)
08046668 libpciaccess.so.0`pci_device_probe+0x2d(8433678, 8, 80466a8, fee8da71,
820f7c0, 6)
080466c8 xf86PciProbe+0xda(81eabef, 1, 8046738, 80d57b5, 81eabef, 0)
080466d8 xf86BusProbe+0x17(81eabef, 0, 81ead47, 8426118, fec90280, 0)
08046738 InitOutput+0x3b5(8425860, 1, 80467c4, 80ac3f1, fec92a00, fef350c0)
0804679c main+0x280(1, 80467c4, 80467cc)
080467b8 _start+0x80(1, 8046a2c, 0, 8046a43, 8046a5c, 8046a6b)
It appears to me that di_fini is being called in pci_device_solx_devfs_probe.
The di_fini (3DEVINFO) man page says "All handles associated with this
snapshot become invalid after the call to di_fini()". But after that, eight
lines down, I think the subroutine is calling di_prop_lookup_ints with
a handle args.node which was stored from walking the device tree.
|