[ofw] RE: Assert in checked ibbus driver?

James Yang jyang at xsigo.com
Thu Jun 19 15:38:26 PDT 2008


It seems it's a false alarm because p_list is not reset when an item is
removed. One more line is needed "p_list_item->p_list = NULL;"

in function __cl_primitive_remove().

 

Can this line be added to the svn?

 

Thanks,

James

 

CL_INLINE void CL_API

__cl_primitive_remove(

      IN    cl_list_item_t* const   p_list_item )

{

      /* CL_ASSERT that a non-null pointer is provided. */

      CL_ASSERT( p_list_item );

      CL_ASSERT( p_list_item->p_next );

      CL_ASSERT( p_list_item->p_prev );

 

      /* set the back pointer */

      p_list_item->p_next->p_prev= p_list_item->p_prev;

      /* set the next pointer */

      p_list_item->p_prev->p_next= p_list_item->p_next;

 

      /* if we're debugging, spruce up the pointers to help find bugs */

#if defined( _DEBUG_ )

      if( p_list_item != p_list_item->p_next )

      {

            p_list_item->p_next = NULL;

            p_list_item->p_prev = NULL;

            p_list_item->p_list = NULL;

      }

#endif      /* defined( _DEBUG_ ) */

}

 

 

________________________________

From: Tzachi Dar [mailto:tzachid at mellanox.co.il] 
Sent: Thursday, June 19, 2008 12:07 PM
To: Sean Hefty; James Yang; Fab Tillier; ofw at lists.openfabrics.org
Subject: RE: [ofw] RE: Assert in checked ibbus driver?

 

>From a fast reading of the file CL_qlist.h it seems that all "remove
functions" clear the p_list_item->p_list  field. So I guess that most
chances that this is a real bug. Can you try and add a printing to each
time you add or remove an object from the gp_mem_tracker list?

 

Thanks

Tzachi

	 

	 

	I can see item's p_list pointer being cleared when it's removed
from the list. My guess is p_list is left over there when items are
allocated from free memory. I'm not familiar with the code enough to
find all these items and clear them during initialization. It's odd to
see p_list value was there but not p_prev and p_next.

	 

	If I ignore the assertion, it will be OK. However the assert
will come once again, especially during startup and shutdown.

	 

	Thanks,

	James

	 

	
________________________________


	From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
	Sent: Thursday, June 19, 2008 9:11 AM
	To: James Yang; ofw at lists.openfabrics.org
	Subject: RE: Assert in checked ibbus driver?

	 

	Hi James,

	 

	If you clear the p_list pointer does the assert go away?

	 

	-Fab

	 

	From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of James Yang
	Sent: Wednesday, June 18, 2008 6:05 PM
	To: ofw at lists.openfabrics.org
	Subject: [ofw] Assert in checked ibbus driver?

	 

	Can someone shed some light on the following assert I saw in
checked build driver?

	 

	It happened in the function cl_qlist_insert_head() when a new
item is added to the list. And the assertion happens because it thinks
the item is already in the list. However when checking the list item, I
don't see it is linked because its previous and next pointers are both
NULL. The item is also is not in the list by manually checking the list.

	 

	Is this because the item is not initialized properly as it's
said in the comments, or it's a true bug? 

	 

	Thanks,

	James

	 

	----------------------

	CL_INLINE void CL_API

	cl_qlist_insert_head(

	      IN    cl_qlist_t* const       p_list,

	      IN    cl_list_item_t* const   p_list_item )

	{

	      /* CL_ASSERT that a non-null pointer is provided. */

	      CL_ASSERT( p_list );

	      /* CL_ASSERT that a non-null pointer is provided. */

	      CL_ASSERT( p_list_item );

	      /* CL_ASSERT that the list was initialized. */

	      CL_ASSERT( p_list->state == CL_INITIALIZED );

	 

	      /*

	       * The list item must not already be part of the list.
Note that this

	       * assertion may fail if an uninitialized list item
happens to have its

	       * list pointer equal to the specified list.  The chances
of this

	       * happening are acceptable in light of the value of this
check.

	       */

	      CL_ASSERT( p_list_item->p_list != p_list );

	 

	#if defined( _DEBUG_ )

	      p_list_item->p_list = p_list;

	#endif

	 

	      /* Insert before the head. */

	      __cl_primitive_insert( cl_qlist_head( p_list ),
p_list_item );

	 

	      p_list->count++;

	}

	 

	 

	1: kd> k

	ChildEBP RetAddr  

	f795e9fc 80873922 nt!DbgBreakPoint

	f795ece4 f71588c4 nt!RtlAssert+0xba

	f795ed0c f715a5df ibbus!cl_qlist_insert_head+0xb4
[k:\windows-openib\inc\complib\cl_qlist.h @ 782]

	f795ed24 f71b08da ibbus!__cl_free_trk+0x6f
[k:\windows-openib\\core\complib\cl_memory.c @ 342]

	f795ed38 f7218e8d ibbus!__pnp_reg_free+0xfa
[k:\windows-openib\\core\al\kernel\al_pnp.c @ 386]

	f795ed70 f715c0e4 ibbus!async_destroy_cb+0x72d
[k:\windows-openib\\core\al\al_common.c @ 685]

	f795ed8c f7162534 ibbus!__cl_async_proc_worker+0x94
[k:\windows-openib\core\complib\cl_async_proc.c @ 153]

	f795eda0 f71645ec ibbus!__cl_thread_pool_routine+0x54
[k:\windows-openib\core\complib\cl_threadpool.c @ 67]

	f795edac 80949b7c ibbus!__thread_callback+0x2c
[k:\windows-openib\core\complib\kernel\cl_thread.c @ 49]

	f795eddc 8088e062 nt!PspSystemThreadStartup+0x2e

	00000000 00000000 nt!KiThreadStartup+0x16

	 

	1: kd> dt 0x863416a0 _cl_qlist 

	   +0x000 end              : _cl_list_item

	   +0x00c count            : 0x29

	   +0x010 state            : 2 ( CL_INITIALIZED )

	1: kd> dt 0x85485268 _cl_list_item 

	   +0x000 p_next           : (null) 

	   +0x004 p_prev           : (null) 

	   +0x008 p_list           : 0x863416a0 _cl_qlist

	 

 P  Please consider the environment before printing this e-mail or its
attachment(s) 


Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080619/bda42747/attachment.html>


More information about the ofw mailing list