http://defect.opensolaris.org/bz/show_bug.cgi?id=11003
Summary: nwamd cores when trying to print a string
Classification: Development
Product: nwam
Version: unspecified
Platform: i86pc/i386
OS/Version: OpenSolaris
Status: NEW
Severity: normal
Priority: P4
Component: ON daemon
AssignedTo: nwam-dev at opensolaris.org
ReportedBy: sanjay.nadkarni at sun.com
QAContact: nwam-dev at opensolaris.org
--- Comment #0 from Sanjay Nadkarni <sanjay.nadkarni at sun.com> 2009-08-28
04:48:36 UTC ---
I am running build 118. I see a number of cores with the following traceback
libc_hwcap1.so.1`strlen+0x30(80641fc, fe2a0b18, fe2a06d4, 0)
libc_hwcap1.so.1`vsnprintf+0x65(fe2a0704, 400, 80641fc, fe2a0b18)
dprintf+0x2a(80641fc, 0, 0, feef578a)
clear_unscanned_entries+0x310(fe2a0df4, 2, fe2a0df4, 805e17c)
scan_wireless_nets+0xf4(fe2a0df4)
rescan_wifi_no_lock+0x88(0, 0, 2, 2, 306b7769, 0)
periodic_wireless_scan+0x1d7(0, fef80000, fe2a0fec, feefce2e)
libc_hwcap1.so.1`_thrp_setup+0x7e(fed42200)
libc_hwcap1.so.1`_lwp_start(fed42200, 0, 0, feefce2e, 0, 0)
dprint is trying to print:
80641fc/s
0x80641fc: keeping unscanned but connected AP %s %s
which is fairly reasonable except that the strings passed appear to be null.
but strlen of 0x80641fc should be reasonable.
since this is failing in strlen, let's see if there are leaks.
running ::findleaks
::findleaks
BYTES LEAKED VMEM_SEG CALLER
73728 3 fdc8d000 MMAP
8192 1 fe499000 MMAP
77824 1 fde3e000 MMAP
------------------------------------------------------------------------
Total 3 oversized leaks, 159744 bytes
CACHE LEAKED BUFFER CALLER
0807f290 1 0809ef10 ?
0807f510 1 08087ea8 ?
08082510 1 080a9a40 ?
------------------------------------------------------------------------
Total 3 buffers, 680 bytes
So there are some leaks but there is no stack associated with it.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
