> On 4/7/2020 3:05 AM, Konovalov, Vadim wrote:
> > As a workaround, you can define
> this environment variable in Perl, then error goes away:
> >
> > vad@bonita:~$ perl
> -MTcl -we '$ENV{FOO}="x";my $i=new Tcl;$i->Eval("set env(FOO) bar");print
> qq/ok\n/'
> > ok
>
> I have not yet given this a try, but does this mean having to
> first set the exact environment variable Tcl sets, or is it
> that *any*
> environment variable needs to be set first from Perl?
Any environment variable needs to be set first from Perl - this will avoid
allocating its name in
>
> > Tcl uses "ckalloc"
> function to allocate strings for name of environment variable "FOO" (or a
> value?)
> > This 'ckalloc' is their helper function, which chains memory into
> link, so to free it after all.
> >
> > IMO If they just use "malloc" the problem
> will go away.
> > I haven't verified this assumption, but 85%-sure of it ??
>
> Because I compiled with -DPURIFY I've already verified this won't
> make a
> difference.
Are you stating that if I change in function "TclSetEnv" here ckalloc to malloc
and ckfree to free:
if (index == -1) {
#ifndef USE_PUTENV
/*
* We need to handle the case where the environment may be changed
* outside our control. ourEnvironSize is only valid if the current
* environment is the one we allocated. [Bug 979640]
*/
if ((env.ourEnviron != environ) || (length+2 > env.ourEnvironSize)) {
char **newEnviron = ckalloc((length + 5) * sizeof(char *));
memcpy(newEnviron, environ, length * sizeof(char *));
if ((env.ourEnvironSize != 0) && (env.ourEnviron != NULL)) {
ckfree(env.ourEnviron);
}
environ = env.ourEnviron = newEnviron;
env.ourEnvironSize = length + 5;
}
index = length;
environ[index + 1] = NULL;
#endif /* USE_PUTENV */
oldValue = NULL;
nameLength = strlen(name);
BTW what if you'll rebuild with USE_PUTENV?
>
> Without manually defining TCL_MEM_DEBUG, ckalloc() is Tcl_Alloc(),
> and Tcl_Alloc() uses TclpAlloc() directly.
> Defining PURIFY undefines
> USE_TCLALLOC, making TclpAlloc()
> use malloc() directly.
>
> This is evident in the valgrind stack trace I posted 2020-03-17.
That's cool
