http://defect.opensolaris.org/bz/show_bug.cgi?id=10462
Renee Danson Sommerfeld <renee.danson at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|nwam-dev at opensolaris.org |renee.danson at sun.com
Status|NEW |CAUSEKNOWN
--- Comment #2 from Renee Danson Sommerfeld <renee.danson at sun.com>
2009-08-05 16:19:06 ---
The more complete stack, and a little poking around at data structures,
revealed the
problem:
> ::stack
libnvpair.so.1`nvlist_free+0x10(deadbeef, 0, ff358340, ff0ec000, 1, deadbeef)
libnwam.so.1`nwam_free+0x20(bfe48, 2d770, 1618c, 61fefeff, 80808080, 1010101)
nwamd_ncu_handle_link_action_event+0x1c0(43000, 18, 43800, 0, 2d670, 43000)
nwamd_event_handler+0x104(ff370488, 1cf88, 431b0, 1cc00, 43000, 164)
main+0x264(2c000, bda48, ffbffe94, 43800, 0, 43000)
_start+0x108(0, 0, 0, 0, 0, 0)
> bfe48::print struct nwam_handle
{
object_type = -0t559038737 (???)
name = [ '\336', '\255', '\276', '\357', '\336', '\255', '\276', '\357',
'\3
36', '\255', '\276', '\357', '\336', '\255', '\276', '\357', '\336', '\255',
'\2
76', '\357', '\336', '\255', '\276', '\357', '\336', '\255', '\276', '\357',
'\3
36', '\255', '\276', '\357', ... ]
name_orig = [ '\336', '\255', '\276', '\357', '\336', '\255', '\276',
'\357'
, '\336', '\255', '\276', '\357', '\336', '\255', '\276', '\357', '\336',
'\255'
, '\276', '\357', '\336', '\255', '\276', '\357', '\336', '\255', '\276',
'\357'
, '\336', '\255', '\276', '\357', ... ]
data = 0xdeadbeef
}
> bfe48/8X
0xbfe48: deadbeef deadbeef deadbeef deadbeef
deadbeef deadbeef deadbeef
deadbeef
>
nwam_free() is trying to free a buffer that's already been freed. Hmm, how
could
that have happened?
The problematic free (a call to nwam_ncp_free(), which is a wrapper around
nwam_free()) occurs at the end of nwamd_ncu_handle_link_action_event();
it's a free of the ncp handle that was obtained earlier in the function. But
looking at that code, we see:
if (nwam_ncp_read(NWAM_NCP_NAME_AUTOMATIC, 0, &ncph)
== NWAM_ENTITY_NOT_FOUND) {
/* error handling for this specific error */
}
...but if nwam_ncp_read() failed for any other reason, say, a permissions
failure (which is exactly what would have been happening on Lizhong's
system, where the passwd, group, and prof_attr files hadn't been merged
properly on bfu of the nwam bits), processing plows on. And in the case
of a permissions failure, nwam_ncp_read() would first alloc the handle, try
to read it, and then free the handle and return the error if the read failed.
So nwamd_ncu_handle_link_action_event() is working with a bogus handle,
and the core dump occurs when it tries to free it again at the end.
--
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.
