> 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 tr
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
> 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.
Cool! Th
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 t
> 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 l
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 deta
il.c:254
> 254 if (where) {
> (gdb) p (char*)where
> $5 = 0x618350 "LOGNAME=crystal"
>
> SJ
>
> Konovalov, Vadim wrote
> >
> > You're ingenious!
> >
> > vad@bonita:~$ perl -MTcl -we 'my $i=new Tcl;$i->Init
gt;Eval("set env(FOO) bar");'
> free(): invalid size
> Aborted (core dumped)
>
> Haven't looked deeper though, but the picture now is much more clear! Thanks!
>
> -Original Message-
> From: Christopher Chavez
> Sent: Tuesday, March 17, 2020 6:08 AM
>
FOO) bar");'
free(): invalid size
Aborted (core dumped)
Haven't looked deeper though, but the picture now is much more clear! Thanks!
-Original Message-
From: Christopher Chavez
Sent: Tuesday, March 17, 2020 6:08 AM
To: tcltk@perl.org
Subject: Re: Possible bug in Tcl.pm
On 3/16/2020 4:09 AM, Christopher Chavez wrote:
To partially answer my own question:
there are some compile-time techniques to try like -DPURIFY
https://wiki.tcl-lang.org/page/How+to+debug+memory+faults+in+Tcl+and+extensions
After build from upstream sources (Tcl/Tk core-8-6-branch and
TkTable 2
On 3/16/2020 4:09 AM, Christopher Chavez wrote:
That page mentioned the Tcl exit command, which I've never used
from Perl. Adding it completely prevents the error:
use Tcl;
my $i = new Tcl;
$i->Init;
$i->Eval(<<'EOS');
package require Tk
package require Tktable
On 3/16/2020 3:48 AM, Christopher Chavez wrote:
The addresses involved are inside allocations from Tcl's thread block
cache, which I'm guessing could be heavily reused over the life of a Tcl
program (to minimize direct calls to malloc()). I'll ask Tcl developers,
but is anyone here aware of a
I can't reproduce on windows,
I will have a closer look on ubuntu later.
Can you also try w/o stubs?
Thanks!
-Original Message-
From: Christopher Chavez
Sent: Sunday, March 8, 2020 7:02 AM
To: tcltk@perl.org
Subject: Possible bug in Tcl.pm exposed by Tktable?
[EXTERNAL
On 3/7/2020 10:01 PM, Christopher Chavez wrote:
==17734== Address 0x52012a0 is 8,400 bytes inside a block of size
16,384 alloc'd
==17734== at 0x483577F: malloc (vg_replace_malloc.c:299)
==17734== by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
==17734== by 0x5550549: TclpAlloc (tclThrea
On 3/16/2020 2:22 AM, Konovalov, Vadim wrote:
I can't reproduce on windows,
I will have a closer look on ubuntu later.
Can you also try w/o stubs?
I actually needed to use --nousestubs to get complete stack traces,
otherwise everything between XS_Tcl_Eval and malloc was ???.
When doing this on
Here's an issue I've known about for several months but hadn't reported.
I'm curious if there are any ideas here for debugging or what the cause
might be (if obviously in Tcl.pm), or if I should go ahead and report it
to Debian package maintainers.
Christopher A. Chavez
-
16 matches
Mail list logo
