http://defect.opensolaris.org/bz/show_bug.cgi?id=12188
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ACCEPTED
CC| |alan.maguire at sun.com
AssignedTo|nwam-dev at opensolaris.org |alan.maguire at sun.com
--- Comment #1 from amaguire <alan.maguire at sun.com> 2009-10-22 19:59:54 UTC
---
The coredump appears to be around the point where we dereference the object
data. This occurs in the door handling thread. Meanwhile thread 1 has disposed
of the data as part of the fini already:
> 1::findstack
stack pointer for thread 1: 8047b68
[ 08047b68 libc_hwcap1.so.1`__lwp_park+0x19() ]
08047ba8 libc_hwcap1.so.1`rw_wrlock_impl+0xbe()
08047bc8 libc_hwcap1.so.1`pthread_rwlock_wrlock+0x3f()
08047be8 nwamd_object_list_lock+0x1a()
08047c08 nwamd_object_decref+0x64()
08047c28 nwamd_object_release_and_destroy+0x10()
08047c48 nwamd_ncu_handle_fini_event+0xb1()
08047c88 nwamd_event_run_method+0x79()
08047cc8 nwamd_event_handler+0x135()
08047de8 main+0x199()
08047e14 _start+0x7d()
>
nwamd_ncu_handle_fini_event() frees the object handle and data prior to doing
the release_and_destroy(). Problem is we drop the object lock before acquiring
the object list lock, and in this case the scan results door thread gets the
object lock before the destroy reacquires it.
It might make sense for nwamd_object_fini() to free associated data depending
on object type.
--
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.
