Re: Possible bug in Tcl.pm exposed by Tktable?
On 3/25/2020 11:29 PM, S.J. Luo wrote:
Hi,
After further tracing around the sources, I think I've figure out the
root cause of the fault: Tcl interpreter (not Tcl.so, which is
compiled from Tcl.xs) has changed global environment variable of the
process while Perl is not aware of it.
In more detail:
1. Tcl allocated a chunk of memory space to store string 'FOO=bar'
while the code 'set env(FOO) bar' gets executed
2. Tcl modifies the global variable 'environ' (exported by glibc with
type: char**). Then it points to a pointer array with one element
points to the newly allocated string 'FOO=bar'.
3. On exiting of Perl, the destructor of the Tcl interpreter object
gets invoked. The memory chunk with string 'FOO=bar' gets freed by
Tcl. However, the global variable 'environ' still points to the same
location and is still has the element points to the address 'FOO=bar'.
4. Finally Perl thinks the strings pointed by 'environ' was allocated
by itself and calls free() on each element, where one points to string
'FOO=bar', who has already been freed...
To demo the Perl/Tcl behavior, execute
perl -MTcl -e 'Tcl::new->Eval("set env(FOO) bar"); print
"FOO=$ENV{FOO}\n"; system("echo FOO=\$FOO");'
We get the following output before segmentation fault
FOO=
FOO=bar
Here Perl's $ENV{FOO} is still undefined while the true environment of
the process is practically affected because the child process inherits
'FOO=bar'.
Moreover, if we have $ENV{FOO}="bar1" after Eval("set env"), we
will get segmentation fault on it immediately, before exiting of Perl.
So far I am not able to come out a simple way to get it fixed. I think
either Tcl should not change the environment globally, or there should
be some way to inform Perl that environment variables has been
changed.
SJ
Thank you for investigating this in such great detail.
A Tcl::pTk user opened a ticket observing this issue in the
test suite: https://rt.cpan.org/Ticket/Display.html?id=132278
I had briefly looked online for previous reports of similar issues
for Tcl and Perl, and there were plenty of bug reports and improvements
submitted, often from 20+ years ago. I don't think I came across
this exact issue. But in some cases this kind of issue was deemed
expected behavior, so I wouldn't be surprised if raising this
specific issue with either Perl or Tcl today that they still consider
it to be neither new nor unexpected. For example, a program embedding
Tcl is supposed to do things like use/redefine Tcl_PutEnv()
(see https://www.tcl-lang.org/man/tcl8.6/TclLib/Environment.htm).
But this would appear to assume the program writer is/should be
in control of compiling and packaging everything in their program.
It is not possible to do this when intending for Tcl.pm reuse
existing Tcl or Perl installations, such as from package managers.
So maybe Tcl.pm will have to document this as a known issue.
Or, is there a workaround possible in the meantime?
Christopher A. Chavez
RE: Possible bug in Tcl.pm exposed by Tktable?
> Thank you for investigating this in such great detail. > > > A Tcl::pTk user opened > a ticket observing this issue in the > test suite: > https://rt.cpan.org/Ticket/Display.html?id=132278 Can you open the ticket on Tcl.pm, given that we see that it is more relevant here? > > I had briefly looked online > for previous reports of similar issues > for Tcl and Perl, and there were plenty > of bug reports and improvements > submitted, often from 20+ years ago. I don't > think I came across > this exact issue. But in some cases this kind of issue was > deemed > expected behavior, so I wouldn't be surprised if raising this > specific > issue with either Perl or Tcl today that they still consider > it to be neither > new nor unexpected. For example, a program embedding > Tcl is supposed to do > things like use/redefine Tcl_PutEnv() > (see > https://www.tcl-lang.org/man/tcl8.6/TclLib/Environment.htm). I've browsed tcl source code and IMO I've found a bug here (which is not affecting logic and not causing coredumps, but makes some minor inefficiency) This isn't of any importancy though > But this would > appear to assume the program writer is/should be > in control of compiling and > packaging everything in their program. > It is not possible to do this when > intending for Tcl.pm reuse > existing Tcl or Perl installations, such as from > package managers. IMO linker will use your function, if you redefine it in your code and will pass it sooner to linker. So you can "neutralize" freeing environment variables in libtcl IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's environment call - what is it? According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-functions - this is my_setenv? > So maybe Tcl.pm will have to document this as a known issue. > > Or, is there a workaround possible in the meantime? I will work on the fix, when time permits
Re: Possible bug in Tcl.pm exposed by Tktable?
On 4/1/2020 7:19 AM, Konovalov, Vadim wrote: A Tcl::pTk user opened a ticket observing this issue in the test suite: https://rt.cpan.org/Ticket/Display.html?id=132278 Can you open the ticket on Tcl.pm, given that we see that it is more relevant here? I have moved the existing ticket to keep the reporter informed. I meant to adjust the title as well but couldn't do so once it moved. But this would appear to assume the program writer is/should be in control of compiling and packaging everything in their program. It is not possible to do this when intending for Tcl.pm reuse existing Tcl or Perl installations, such as from package managers. IMO linker will use your function, if you redefine it in your code > and will pass it sooner to linker. So you can "neutralize" freeing environment variables in libtcl IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's environment call - what is it? According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-functions - this is my_setenv? Interesting, this is something I'm not familiar with. I have also neglected to consider if other Tcl wrappers (Python, Ruby) are affected and whether they may have already solved the same problem. I will work on the fix, when time permits Thanks. Indeed there should be no rush to fix this. It is a benign issue that might only pose a minor annoyance to users (e.g. "Your program has crashed, report it?" nags from OS); unsaved data does not appear to be in jeopardy because of it. Christopher A. Chavez
