On Sun, Jun 7, 2020 at 5:53 PM <luke-tier...@uiowa.edu> wrote:
>
> On Sun, 7 Jun 2020, peter dalgaard wrote:
>
> > So this wasn't tested for a month?
> >
> > Anyways, Free() is just free() with a check that we're not freeing a null
> > pointer, followed by setting the pointer to NULL. At that point of tcltk.c,
> > we have
> >
> > for (objc = i = 0; i < length(avec); i++){
> > const char *s;
> > char *tmp;
> > if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i)))){
> > // tmp = calloc(strlen(s)+2, sizeof(char));
> > tmp = Calloc(strlen(s)+2, char);
> > *tmp = '-';
> > strcpy(tmp+1, s);
> > objv[objc++] = Tcl_NewStringObj(tmp, -1);
> > free(tmp);
> > }
> > if (!isNull(t = VECTOR_ELT(avec, i)))
> > objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
> > }
> >
> > and I can't see how tmp can be NULL at the free(), nor can I see it
> > mattering if it is not set to NULL (notice that it goes out of scope with
> > the for loop).
>
> Right. And the calloc->Calloc change doesn't look like an issue either
> -- just checking for a NULL.
>
> If the crash is happening in free() then that most likely means
> corrupted malloc data structures. Unfortunately that could be
> happening anywhere.
Writing R extensions, section 6.1.2 says: "Do not assume that memory
allocated by Calloc/Realloc comes from the same pool as used by
malloc: in particular do not use free or strdup with it."
I think the reason is that R uses dlmalloc for Calloc on Windows:
https://github.com/wch/r-source/blob/c634fec5214e73747b44d7c0e6f047fefe44667d/src/main/memory.c#L94-L103
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
