Skip Menu |
 

This queue is for tickets about the Tcl CPAN distribution.

Report information
The Basics
Id: 21181
Status: resolved
Priority: 0/
Queue: Tcl

People
Owner: Nobody in particular
Requestors: jlange6648 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.89
Fixed in: 1.06



Subject: Tcl Segfaults on SuSE 10.1 x86_64
Download (untitled) / with headers
text/plain 1.8k
On SuSE 10.1 x86_64, attempting to use the Tcl module causes a segmentaion fault. the CPAN tests work properly however. below is some output showing the error. **** jkl@automation:~> perl -e 'use Tcl;' Segmentation fault ***** automation:~/.cpan/build/Tcl-0.89 # gdb perl GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"...(no debugging symbols found) Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) set args -e 'use Tcl;' (gdb) run Starting program: /usr/bin/perl -e 'use Tcl;' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47834521734000 (LWP 5612)] (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47834521734000 (LWP 5612)] 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value optimized Show quoted text
out>) at Tcl.xs:426
426 tclKit_AppInit = Tcl_Init; (gdb) bt #0 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value optimized out>) at Tcl.xs:426 #1 0x0000000000482cf2 in Perl_pp_entersub () #2 0x000000000046515e in Perl_runops_debug () #3 0x0000000000423fff in Perl_call_sv () #4 0x00000000004244d9 in Perl_call_list () #5 0x00000000004545ac in Perl_newATTRSUB () #6 0x0000000000452af4 in Perl_utilize () #7 0x0000000000444ddd in Perl_yyparse () #8 0x00000000004225b3 in perl_free () #9 0x000000000042519d in perl_parse () #10 0x000000000041d674 in main () (gdb)
Download (untitled) / with headers
text/plain 2.2k
I suspect this is due to wrong *.lib files within Tcl-0.89 distribution. (I mean these -- http://search.cpan.org/src/VKON/Tcl-0.89/tcl-core/) Can you please try latest CVS version, which is at http://tcltkce.cvs.sourceforge.net/tcltkce/Tcl/, or may be wait for 0.90 version, which will hopefully be soon... Best regards, Vadim. On Fri Aug 25 15:26:59 2006, jlange6648 wrote: Show quoted text
> On SuSE 10.1 x86_64, attempting to use the Tcl module causes a > segmentaion fault. > > the CPAN tests work properly however. > > below is some output showing the error. > > **** > jkl@automation:~> perl -e 'use Tcl;' > Segmentation fault > > > ***** > automation:~/.cpan/build/Tcl-0.89 # gdb perl > GNU gdb 6.4 > Copyright 2005 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and
you are Show quoted text
> welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for
details. Show quoted text
> This GDB was configured as "x86_64-suse-linux"...(no debugging symbols > found) > Using host libthread_db library "/lib64/libthread_db.so.1". > > (gdb) set args -e 'use Tcl;' > (gdb) run > Starting program: /usr/bin/perl -e 'use Tcl;' > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread 47834521734000 (LWP 5612)] > (no debugging symbols found) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47834521734000 (LWP 5612)] > 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value optimized
> out>) at Tcl.xs:426
> 426 tclKit_AppInit = Tcl_Init; > (gdb) bt > #0 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value > optimized out>) at Tcl.xs:426 > #1 0x0000000000482cf2 in Perl_pp_entersub () > #2 0x000000000046515e in Perl_runops_debug () > #3 0x0000000000423fff in Perl_call_sv () > #4 0x00000000004244d9 in Perl_call_list () > #5 0x00000000004545ac in Perl_newATTRSUB () > #6 0x0000000000452af4 in Perl_utilize () > #7 0x0000000000444ddd in Perl_yyparse () > #8 0x00000000004225b3 in perl_free () > #9 0x000000000042519d in perl_parse () > #10 0x000000000041d674 in main () > (gdb)
Subject: Re: [rt.cpan.org #21181] Tcl Segfaults on SuSE 10.1 x86_64
Date: Wed, 30 Aug 2006 14:39:07 -0400
To: bug-Tcl [...] rt.cpan.org
From: "Jeff Lange" <jlange6648 [...] gmail.com>
Download (untitled) / with headers
text/plain 2.6k
That didn't seem to make any difference. I have found however that if PERL_DL_NONLAZY is set to 1, it will work.. which explains why 'make test' works. -Jeff On 8/30/06, via RT <bug-Tcl@rt.cpan.org> wrote: Show quoted text
> > > <URL: http://rt.cpan.org/Ticket/Display.html?id=21181 > > > I suspect this is due to wrong *.lib files within Tcl-0.89 distribution. > (I mean these -- http://search.cpan.org/src/VKON/Tcl-0.89/tcl-core/) > > Can you please try latest CVS version, which is at > http://tcltkce.cvs.sourceforge.net/tcltkce/Tcl/, or may be wait for 0.90 > version, which will hopefully be soon... > > Best regards, > Vadim. > > On Fri Aug 25 15:26:59 2006, jlange6648 wrote:
> > On SuSE 10.1 x86_64, attempting to use the Tcl module causes a > > segmentaion fault. > > > > the CPAN tests work properly however. > > > > below is some output showing the error. > > > > **** > > jkl@automation:~> perl -e 'use Tcl;' > > Segmentation fault > > > > > > ***** > > automation:~/.cpan/build/Tcl-0.89 # gdb perl > > GNU gdb 6.4 > > Copyright 2005 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and
> you are
> > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> > This GDB was configured as "x86_64-suse-linux"...(no debugging symbols > > found) > > Using host libthread_db library "/lib64/libthread_db.so.1". > > > > (gdb) set args -e 'use Tcl;' > > (gdb) run > > Starting program: /usr/bin/perl -e 'use Tcl;' > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > [Thread debugging using libthread_db enabled] > > [New Thread 47834521734000 (LWP 5612)] > > (no debugging symbols found) > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 47834521734000 (LWP 5612)] > > 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value optimized
> > out>) at Tcl.xs:426
> > 426 tclKit_AppInit = Tcl_Init; > > (gdb) bt > > #0 0x00002b8157ad5b22 in boot_Tcl (my_perl=0x63b010, cv=<value > > optimized out>) at Tcl.xs:426 > > #1 0x0000000000482cf2 in Perl_pp_entersub () > > #2 0x000000000046515e in Perl_runops_debug () > > #3 0x0000000000423fff in Perl_call_sv () > > #4 0x00000000004244d9 in Perl_call_list () > > #5 0x00000000004545ac in Perl_newATTRSUB () > > #6 0x0000000000452af4 in Perl_utilize () > > #7 0x0000000000444ddd in Perl_yyparse () > > #8 0x00000000004225b3 in perl_free () > > #9 0x000000000042519d in perl_parse () > > #10 0x000000000041d674 in main () > > (gdb)
> > > >
Download (untitled) / with headers
text/plain 342b
On Wed Aug 30 14:39:19 2006, jlange6648 wrote: Show quoted text
> That didn't seem to make any difference. > > I have found however that if PERL_DL_NONLAZY is set to 1, it will work.. > which explains why 'make test' works.
Thanks for looking into this... Do you reproduce this on AMD64, or on SuSE, or what configuration, in your opinion, is problematic?
Subject: Re: [rt.cpan.org #21181] Tcl Segfaults on SuSE 10.1 x86_64
Date: Thu, 31 Aug 2006 08:39:48 -0400
To: bug-Tcl [...] rt.cpan.org
From: "Jeff Lange" <jlange6648 [...] gmail.com>
Download (untitled) / with headers
text/plain 1014b
I have 2 different boxes running SuSE 10.1 x86_64 on Intel processors, one a hyperthreaded p4, and one a dual core p4. I also just tried it on a IBM laptop running SuSE 10.1 x86 and it also fails, so it looks like a SuSE 10.1 issue, not an x64 issue to recap: this works: Show quoted text
>PERL_DL_NONLAZY=1 perl -e 'use Tcl;'
this dosen't: Show quoted text
>PERL_DL_NONLAZY=0 perl -e 'use Tcl;'
here is the versions of the relevant packaged on my system: perl-5.8.8-12 tcl-devel-8.4.12-14 tcl-8.4.12-14 tcllib-1.8-10 glibc-2.4-31.1 Tcl.pm from CPAN Thanks, -Jeff On 8/30/06, via RT <bug-Tcl@rt.cpan.org> wrote: Show quoted text
> > > <URL: http://rt.cpan.org/Ticket/Display.html?id=21181 > > > On Wed Aug 30 14:39:19 2006, jlange6648 wrote:
> > That didn't seem to make any difference. > > > > I have found however that if PERL_DL_NONLAZY is set to 1, it will work.. > > which explains why 'make test' works.
> > Thanks for looking into this... > > Do you reproduce this on AMD64, or on SuSE, or what configuration, in > your opinion, is problematic? >
CC: tcltk [...] perl.org
Subject: Re: [rt.cpan.org #21181] Tcl Segfaults on SuSE 10.1 x86_64
Date: Sun, 17 Sep 2006 06:03:50 +0400
To: bug-Tcl [...] rt.cpan.org
From: Vadim <vadim [...] vkonovalov.ru>
Download (untitled) / with headers
text/plain 1.1k
via RT wrote: Show quoted text
> Queue: Tcl > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=21181 > > >I have 2 different boxes running SuSE 10.1 x86_64 on Intel processors, one a >hyperthreaded p4, and one a dual core p4. > >I also just tried it on a IBM laptop running SuSE 10.1 x86 and it also >fails, so it looks like a SuSE 10.1 issue, not an x64 issue > >
for some unknown for me reasons two very similar Gentoo installation behave differently - one gives segmentation fault but other do not, seemingly with all the very same versions. (of course there is some difference, but I can't catch what namely isn't good) For such a situation using "--nousestubs" cures the situation. So in my current understanding "stubs" are not dealed properly in Tcl.xs Sorry for not having catched the "--usestubs" situation. Best regards, Vadim. Show quoted text
>to recap: > >this works: > >
>>PERL_DL_NONLAZY=1 perl -e 'use Tcl;' >> >>
> >this dosen't: > >
>>PERL_DL_NONLAZY=0 perl -e 'use Tcl;' >> >>
> >here is the versions of the relevant packaged on my system: >perl-5.8.8-12 >tcl-devel-8.4.12-14 >tcl-8.4.12-14 >tcllib-1.8-10 >glibc-2.4-31.1 >Tcl.pm from CPAN > >
CC: bug-Tcl [...] rt.cpan.org, tcltk [...] perl.org
Subject: Re: [rt.cpan.org #21181] Tcl Segfaults on SuSE 10.1 x86_64
Date: Sun, 17 Sep 2006 15:39:34 -0700
To: Vadim <vadim [...] vkonovalov.ru>
From: Jeff Hobbs <jeffh [...] activestate.com>
Download (untitled) / with headers
text/plain 1.1k
Vadim wrote: Show quoted text
> via RT wrote:
>> Queue: Tcl >> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=21181 > >> >> I have 2 different boxes running SuSE 10.1 x86_64 on Intel processors, one a >> hyperthreaded p4, and one a dual core p4. >> >> I also just tried it on a IBM laptop running SuSE 10.1 x86 and it also >> fails, so it looks like a SuSE 10.1 issue, not an x64 issue
> > for some unknown for me reasons two very similar Gentoo installation > behave differently - one gives segmentation fault but other do not, > seemingly with all the very same versions. > > (of course there is some difference, but I can't catch what namely isn't > good) > > For such a situation using "--nousestubs" cures the situation. > > So in my current understanding "stubs" are not dealed properly in Tcl.xs > > Sorry for not having catched the "--usestubs" situation.
If it is the use of stubs that causes the problem, it may be that the tcl84stub.lib files that ship with the Tcl module are not compatible. You could test this with 'file tcl84stub.lib' on the one shipped with the Tcl module versus the ones on the machines that are obviously not compatible. Jeff
Download (untitled) / with headers
text/plain 181b
I'm also seeing this segfault problem on Debian unstable amd64, with tcl8.4-dev version 8.4.19-2 and Tcl version 0.97 Setting PERL_DL_NONLAZY=1 makes it not segfault, as described.
Subject: Re: [rt.cpan.org #21181] Tcl Segfaults on SuSE 10.1 x86_64
Date: Wed, 19 Aug 2009 10:33:28 -0700
To: bug-Tcl [...] rt.cpan.org
From: Josh803316 <josh803316 [...] gmail.com>
Download (untitled) / with headers
text/plain 5.2k
I get a similar segfault on Fedora Core 11 x86_64 [jnisenson@jpc Perl]$ gdb perl GNU gdb (GDB) Fedora (6.8.50.20090302-37.fc11) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html Show quoted text
>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Missing separate debuginfos, use: debuginfo-install perl-5.10.0-73.fc11.x86_64 (gdb) use Tcl; Undefined command: "use". Try "help". (gdb) set args -e 'use Tcl;' (gdb) run Starting program: /usr/bin/perl -e 'use Tcl;' [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff24cde9a in NpInitialize (my_perl=0x7fffffffd110, X=0x606fa8) at Tcl.xs:445 445 Tcl.xs: No such file or directory. in Tcl.xs /* * If we didn't find TclKit_AppInit, then this is a regular Tcl * installation, so invoke Tcl_Init. * Otherwise, we need to set the kit path to indicate we want to * use the dll as our base kit. */ if (tclKit_AppInit == NULL) { tclKit_AppInit = Tcl_Init; # LINE 445 in Tcl.xs } else { (SIDENOTE: I RAN INTO ANOTHER BUG DURING CPAN INSTALL WHICH I BELIEVE HAS ALREADY BEEN REPORTED as bug 36167) (#1 Install from command line after CPAN failure) [root@jpc Tcl-0.97-hZDODq]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/call.t ....... 1/10 Assertion ((svtype)((_svi)->sv_flags & 0xff)) >= SVt_RV failed: file "Tcl.xs", line 653 at t/call.t line 38. t/call.t ....... Dubious, test returned 88 (wstat 22528, 0x5800) Failed 2/10 subtests t/constants.t .. ok t/createcmd.t .. ok t/eval.t ....... ok t/info.t ....... ok t/result.t ..... ok t/subclass.t ... ok t/trace.t ...... ok t/unicode.t .... ok t/var.t ........ ok Test Summary Report ------------------- t/call.t (Wstat: 22528 Tests: 8 Failed: 0) Non-zero exit status: 88 Parse errors: Bad plan. You planned 10 tests but ran 8. Files=10, Tests=51, 0 wallclock secs ( 0.06 usr 0.01 sys + 0.18 cusr 0.06 csys = 0.31 CPU) Result: FAIL Failed 1/10 test programs. 0/51 subtests failed. make: *** [test_dynamic] Error 255 [root@jpc Tcl-0.97-hZDODq]# patch -i Tcl-rv-assertion.patch patching file Tcl.xs can't find file to patch at input line 16 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |diff -u -r Tcl-0.97.orig/t/result.t Tcl-0.97/t/result.t |--- Tcl-0.97.orig/t/result.t 2008-09-07 09:21:59.000000000 +0900 |+++ Tcl-0.97/t/result.t 2009-08-13 12:55:53.000000000 +0900 -------------------------- File to patch: t/result.t patching file t/result.t [root@jpc Tcl-0.97-hZDODq]# ls ChangeLog Changes Makefile.old Makefile.PL MANIFEST META.yml README t tclcfg.tcl tcl-core Tcl.pm Tcl-rv-assertion.patch Tcl.xs typemap [root@jpc Tcl-0.97-hZDODq]# perl Makefile.PL LIBS = -Ltcl-core/linux-x86_64 -ltclstub8.4 INC = -Itcl-core/include DEFINE = -DUSE_TCL_STUBS Checking if your kit is complete... Looks good Warning: -Ltcl-core/linux-x86_64 changed to -L/root/.cpan/build/Tcl-0.97-hZDODq/tcl-core/linux-x86_64 Writing Makefile for Tcl [root@jpc Tcl-0.97-hZDODq]# make cp Tcl.pm blib/lib/Tcl.pm /usr/bin/perl /usr/lib/perl5/5.10.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.10.0/ExtUtils/typemap -typemap typemap Tcl.xs > Tcl.xsc && mv Tcl.xsc Tcl.c Please specify prototyping behavior for Tcl.xs (see perlxs manual) gcc -c -Itcl-core/include -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.97\" -DXS_VERSION=\"0.97\" -fPIC "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE" -DUSE_TCL_STUBS Tcl.c Tcl.xs: In function ‘Tcl_EvalInPerl’: Tcl.xs:777: warning: value computed is not used Tcl.xs: In function ‘Tcl_PerlCallWrapper’: Tcl.xs:845: warning: value computed is not used Tcl.c: In function ‘XS_Tcl_icall’: Tcl.c:1557: warning: unused variable ‘sv’ Running Mkbootstrap for Tcl () chmod 644 Tcl.bs rm -f blib/arch/auto/Tcl/Tcl.so gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic Tcl.o -o blib/arch/auto/Tcl/Tcl.so \ -L/root/.cpan/build/Tcl-0.97-hZDODq/tcl-core/linux-x86_64 -ltclstub8.4 \ chmod 755 blib/arch/auto/Tcl/Tcl.so cp Tcl.bs blib/arch/auto/Tcl/Tcl.bs chmod 644 blib/arch/auto/Tcl/Tcl.bs Manifying blib/man3/Tcl.3pm [root@jpc Tcl-0.97-hZDODq]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/call.t ....... ok t/constants.t .. ok t/createcmd.t .. ok t/eval.t ....... ok t/info.t ....... ok t/result.t ..... ok t/subclass.t ... ok t/trace.t ...... ok t/unicode.t .... ok t/var.t ........ ok All tests successful. Files=10, Tests=55, 0 wallclock secs ( 0.05 usr 0.02 sys + 0.18 cusr 0.05 csys = 0.30 CPU) Result: PASS
Subject: [rt.cpan.org #21181] An analysis and solution for segment fault problem
Date: Sun, 23 Apr 2017 15:04:55 +0800
To: bug-Tcl [...] rt.cpan.org
From: SJ Luo <sjaluo [...] gmail.com>
Download (untitled) / with headers
text/plain 2.4k
Hi, After installation of Tcl module (version 1.05), I encountered segfault problem similar to that listed in 21181. My system is CentOS Linux 6.9 (x86_64) with Perl 5.10.1: [crystal@great Tcl-1.05-SJ]$ perl -e 'use Tcl;' Segmentation fault (core dumped) but with environment variable PERL_DL_NONLAZY set, things will go fine. I've spent time go through gdb assembly code struggling with it and have got some results. It is quite difficult to debug. In short, it is due to the symbol name confliction: There are functions named Tcl_InitStub() in both libtclstub8.4.a and libtcl8.5.so and a wrong one is being called. In Tcl.xs function NpInitialize(), the libtcl8.5.so is loaded via dlopen() before resolving of Tcl_InitStub() address, which is done on first calling of the function by default (See 1st note below). the The linker incorrectly resolved the symbol address to the one in libtcl8.5.so, while we expected that in libtclstub8.4.a . That caused segmentation fault in following code. When the PERL_DL_NONLAZY env is set to 1, the address of Tcl_InitStub() would be resolved on phase of dlopen("tcl.so",RTLD_NOW), meanwhile libtcl8.5.so was not loaded (dlopen) yet. Therefore the correct function address is resolved and called. I think it might be a bug of gcc or linker, rather than Tcl module. There are some notes: - Although libtclstub8.4.a is static linked. The linker still apply dynamic linking calling procedure (via GOT/PLT table) to Tcl_InitStub(). I don't know why it is done this way. May there is some way to make it actually statically link in code compilation phase. My gcc version is 4.4.7 - In theory, initstubs is a static function pointer, who should be correctly assigned on initialization of Tcl.so. However, gcc did some optimization on the code: gcc thought both address of Tcl_InitStub() and initstubs do not change during program's life time, the initstubs variable is actually reduced after compilation. When we call to initstubs() in source code, it just call Tcl_InitStub() directly, rather than via the function pointer, in executable file. I worked around this issue by adding a line in NpInitialize() right after function variable declaration section. if( initstubs == NULL ) initstubs = NULL; This line forces gcc to think that initstubs might change and actually allocate some memory space to store its value. Then initstubs is now actually existed and correctly set on Tcl.so initialization phase. Now Tcl module works perfectly on my system.
Show quoted text
> In short, it is due to the symbol name confliction: There are functions > named Tcl_InitStub() in both libtclstub8.4.a and libtcl8.5.so and a wrong > one is being called.
Here I attach several small Linux programs with source codes to demonstrate the failure mechanism. Just download the attached file and do: $ make gcc -o myperl -O3 myperl.c -ldl gcc -c -o libtclstub.o -shared -fPIC -O3 libtclstub.c ar rcs libtclstub.a libtclstub.o gcc -o Tcl.so -shared -fPIC -O3 Tcl.c -L . -ltclstub -ldl gcc -o libtcl.so -shared -fPIC -O3 libtcl.c $ ./myperl dlopen() with RTLD_LAZY Tcl.so is called libtcl.so is called (incorrect) $ env PERL_DL_NOLAZY=1 ./myperl dlopen() with RTLD_NOW Tcl.so is called libtclstub.so is called The executable named myperl emulates the dlopen() call by real perl interpreter. Tcl.so is analogous to the one compiled from Tcl.xs. libtcl.so is analogous to the one comes from tcl interpreter binary distribution and libtclstub.a is as the one comes with this CPAN Tcl module. My system information: Linux CentOS 5.11 gcc 4.1.2 ld 2.17.50 glibc-2.5
Subject: Tcl-dlopen.tar.bz2
Download Tcl-dlopen.tar.bz2
application/octet-stream 5.9k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 467b
Hi, A patch is attached to fix this issue by declaring static variable initstub (https://metacpan.org/source/VKON/Tcl-1.05/Tcl.xs#L374) as volatile, which prevents compiler from optimizing out this variable. Therefore, a correct Tcl_InitStubs() func could be preserved before Tcl (libtcl.so) dynamically loaded. I think this solution would be more legitimate. Result of compiler explorer shows the effect of volatile variable. https://godbolt.org/g/RHc7Uu
Subject: Tcl-stub.patch
Download Tcl-stub.patch
text/x-diff 620b
--- Tcl-1.05/Tcl.xs 2016-06-29 00:48:16.000000000 +0800 +++ Tcl-1.05-patched/Tcl.xs 2018-05-28 00:57:49.000000000 +0800 @@ -370,8 +370,10 @@ /* * We want the Tcl_InitStubs func static to ourselves - before Tcl * is loaded dyanmically and possibly changes it. + * Variable initstubs have to be declared as volatile to prevent + * compiler optimizing it out. */ - static CONST char *(*initstubs)(Tcl_Interp *, CONST char *, int) + static CONST char *(*volatile initstubs)(Tcl_Interp *, CONST char *, int) = Tcl_InitStubs; char dllFilename[MAX_PATH]; dllFilename[0] = '\0';
RT-Send-CC: tcltk [...] perl.org
Download (untitled) / with headers
text/plain 639b
Le Dim 27 Mai 2018 13:20:20, sjaluo@gmail.com a écrit : Show quoted text
> Hi, > > A patch is attached to fix this issue by declaring static variable > initstub (https://metacpan.org/source/VKON/Tcl-1.05/Tcl.xs#L374) as > volatile, which prevents compiler from optimizing out this variable. > Therefore, a correct Tcl_InitStubs() func could be preserved before > Tcl (libtcl.so) dynamically loaded. I think this solution would be > more legitimate. > > Result of compiler explorer shows the effect of volatile variable. > > https://godbolt.org/g/RHc7Uu
TYVM! added the fix to repositury https://github.com/gisle/tcl.pm, hopefully soon to be released
patch applied, please reopen if problem persists


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.