Re: decnet versions

["Kevin P. Hannan" <kphannan@america.net>]

  I have not looked through the sources yet, but is this allocation for a
communication buffer?  Are the messages somewhat fixed length?  If so, how
feasible is a pool of buffers.  The pool is allocated early on and they are
reused.  This way even in low memory situations there should not be a failure. 
I say should, but even a pooling scheme can have troubles.

  Another technique I use for DEBUGGING only is to use assertions to ensure
assumptions are met.  Assertions are no substitute for proper error handling,
but in the short term they can help pinpoint errors.

  p = malloc( 400 );
  assert( p != NULL );    // assumption that malloc never fails ;-)
    or 
  assert( p );

  A non-debug build results in no code generated for the assert.

  I am beginning to pour over the sources now.

  Kevin

On Sun, 23 Jan 2000, Steve Whitehouse wrote:
> Hi,
> 
> Thanks for the crash dump & analysis.
> My best guess is that its down to a shortage of memory... I wonder how much
> free memory there was at the time ? I've noticed that there appears to be
> no checks against alloc_skb(size, GFP_ATOMIC) returning NULL which it will
> almost certainly do at some stage unless the box is very lightly loaded.
> Perhaps there might be alot of other net traffic which may be using up the
> atomicly allocatable memory.
> 
> The fix is to return NULL from dn_alloc_skb() if alloc_skb() 
> returned a NULL pointer, and to allow for NULL pointers in each function
> which calls dn_alloc_skb() too. Ok, it might not be the cause of this 
> particular crash, but it will certainly cause problems if it is not fixed,
> 
> Steve.
> 
-----------------------------------------------------------------------------
To unsubscribe from this list, send a mail to majordomo@dreamtime.org
containing the line "unsubscribe linux-decnet"
-----------------------------------------------------------------------------