6091 avl_add doesn't assert on non-debug builds

illumos/illumos-gate@faa2b6be2f

https://www.illumos.org/issues/6091
  Long story short, avl_add's use of ASSERT(0) can cause really strange looking
  crashes on non-debug builds of libavl.so because ASSERTs turn into no-ops.
  ...

Reviewed by: Andy Stormont <astormont@racktopsystems.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Steve Dougherty <steve@asksteved.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
This commit is contained in:
Andriy Gapon 2015-09-11 20:43:14 +00:00
parent 981f27b3d6
commit 96bcca3330

View File

@ -25,6 +25,7 @@
/*
* Copyright (c) 2014 by Delphix. All rights reserved.
* Copyright 2015 Nexenta Systems, Inc. All rights reserved.
*/
/*
@ -635,14 +636,17 @@ avl_add(avl_tree_t *tree, void *new_node)
/*
* This is unfortunate. We want to call panic() here, even for
* non-DEBUG kernels. In userland, however, we can't depend on anything
* in libc or else the rtld build process gets confused. So, all we can
* do in userland is resort to a normal ASSERT().
* in libc or else the rtld build process gets confused.
* Thankfully, rtld provides us with its own assfail() so we can use
* that here. We use assfail() directly to get a nice error message
* in the core - much like what panic() does for crashdumps.
*/
if (avl_find(tree, new_node, &where) != NULL)
#ifdef _KERNEL
panic("avl_find() succeeded inside avl_add()");
#else
ASSERT(0);
(void) assfail("avl_find() succeeded inside avl_add()",
__FILE__, __LINE__);
#endif
avl_insert(tree, new_node, where);
}