Open mattdowle opened 5 years ago
Thanks for the info. @mllg Do you have an idea where this could come from?
You first need to narrow it down. Unfortunately, this is very tedious:
Try if you can reproduce this on r-hub. Then you need to selectively enable/disable tests ... I would first try to validate that the C code in mlrMBO
is the problem, and not the C code in one of the dependencies (BBmisc, for example).
Had a brief look at mlrMBO source. It uses malloc/free and these are all the free()
calls :
./mlrMBO/src$ grep -n -B 2 -A 2 "free(" *.c
avl.c-205- if(freeitem)
avl.c-206- freeitem(node->item);
avl.c:207: free(node);
avl.c-208- }
avl.c-209- avl_clear_tree(avltree);
--
avl.c-218-void avl_free_tree(avl_tree_t *avltree) {
avl.c-219- avl_free_nodes(avltree);
avl.c:220: free(avltree);
avl.c-221-}
avl.c-222-
--
avl.c-326- if(avl_insert_node(avltree, newnode))
avl.c-327- return newnode;
avl.c:328: free(newnode);
avl.c-329- errno = EEXIST;
avl.c-330- }
--
avl.c-399- if(avltree->freeitem)
avl.c-400- avltree->freeitem(item);
avl.c:401: free(avlnode);
avl.c-402- }
avl.c-403- return item;
--
hv.c-130- }
hv.c-131-
hv.c:132: free(scratch);
hv.c-133-
hv.c-134- for (i = 1; i <= n; i++)
--
hv.c-142-
hv.c-143-static void free_cdllist(dlnode_t * head) {
hv.c:144: free(head->tnode); /* Frees _all_ nodes. */
hv.c:145: free(head->next);
hv.c:146: free(head->prev);
hv.c:147: free(head->area);
hv.c:148: free(head->vol);
hv.c:149: free(head);
hv.c-150-}
hv.c-151-
Given the error "double free or corruption (!prev)"
, it's good to set the pointer to NULL after each free()
to avoid accidentally using it again. Runnng again through ASAN after this change, maybe it will spot the root problem. But most of these free()
calls are inside a function defined by mlrBMO, so you'll need to find the caller and ensure it sets the pointer to NULL after caling the free_*
function on it.
There are also 2 references to "leak" in the source. A straightforward leak should be just a leak and not "double free or corruption (!prev)"
(iiuc) but these kinds of memory errors tend to be closely related and give you clues.
./mlrMBO/src$ grep -n "leak" *.c
hv.c:357: /* The memory allocated for the deleted node is lost (leaked)
hv.c:402: /* Returning here would leak memory. */
Hi, I've just submitted data.table 1.12.2 to CRAN. I had no issues with
mlrBMO
in revdep checking: it passedR CMD check
fully OK and wasn't affected by any data.table changes in this release. However, when CRAN ran its revdep tests,mlrMBO
failed with the error"double free or corruption (!prev)"
. My guess is that this is unlikely due to data.table so I asked CRAN maintainers to proceed to publish data.table. This issue is just to follow up. Here is the reply I received from CRAN checks. After that I've pasted my results when I runmlrMBO
through R-devel compiled with ASAN and strict-barrier. There appears to be a memory problem somewhere but I didn't manage to get a line number for you I'm afraid. HTH, Matt