Bug 695561

We removed Data::Alias from distribution, because it doesn't work with 5.12.x at all. See https://bugzilla.redhat.com/show_bug.cgi?id=611014
But if I install Data::Alias from cpan and run it with 5.13.x, it does work.

The only change in perl was ExtUtils::ParseXS upgrade to 2.2206.

The undefined symbol comes from systemtap headers while compiling Alias.c:



# 139 "/usr/include/sys/sdt.h" 3 4
# 1 "/usr/include/sys/sdt-config.h" 1 3 4
# 140 "/usr/include/sys/sdt.h" 2 3 4
# 10 "/usr/lib64/perl5/CORE/perldtrace.h" 2
# 18 "/usr/lib64/perl5/CORE/perldtrace.h"
__extension__ extern unsigned short perl_sub__entry_semaphore __attribute__ ((unused)) __attribute__ ((section (".probes")));
# 29 "/usr/lib64/perl5/CORE/perldtrace.h"
__extension__ extern unsigned short perl_sub__return_semaphore __attribute__ ((unused)) __attribute__ ((section (".probes")));

Lukas,
is it possible that there is bug in systemtap support for Perl? The upgrade to new parser of XS files could make the problem visible. At the moment we are not aware of any other "broken" modules.

The _foo_semaphore symbols are defined in an .o file that may be produced from
the dtrace .d probe specification via /usr/bin/dtrace -G.  This object file would
need to be linked into the respective library/binary.

systemtap 1.4 changed the elf symbol visibility of these symbols to "hidden".
Perhaps former builds of the perl module accidentally relied on these being
non-hidden, and thus satisfied by the libperl.so copy of those symbols.

(In reply to comment #1)
> We removed Data::Alias from distribution, because it doesn't work with 5.12.x
> at all. ...

This is incorrect.  I'm familiar with the bug you reference, but that was at a time when Data::Alias had not been updated in 3 years.  Now a new maintainer has taken it over, and 5 new versions have been released since then.  And the fact of the matter is that it _does_ work with perl-5.12.3-141.fc14: I _had_ it working perfectly until the security upgrade came along and broke it. :-(

But note that the problem only manifests when Data::Alias is installed from CPAN.  If installed via yum (on perl-5.12.3-141.fc14), Data::Alias works, but the Alias.so does _not_ contain the reference to the undefined symbol, so I doubt the upgrade would break it in that instance.  I have no idea what the difference is.

(In reply to comment #4)
> The _foo_semaphore symbols are defined in an .o file that may be produced from
> the dtrace .d probe specification via /usr/bin/dtrace -G.  This object file
> would
> need to be linked into the respective library/binary.
> 
> systemtap 1.4 changed the elf symbol visibility of these symbols to "hidden".
> Perhaps former builds of the perl module accidentally relied on these being
> non-hidden, and thus satisfied by the libperl.so copy of those symbols.

Interesting.  I know we need to find a permanent solution, but can I implement a temporary workaround by linking in the object file you mention above?  How would I go about doing that?

Okay, we've been working a bit more on this problem; the additional info provided above has been quite helpful.

The first thing we tried is, removing systemtap.  I have no need for it, really.  So I just did this:

 yum remove systemtap systemtap-runtime systemtap-sdt-devel

All 3 removed cleanly, no dependencies on them were identified.

Now, I try to reinstall Data::Alias again (via CPAN).  Now I get a new error:

/usr/bin/perl "-Iinc" /usr/share/perl5/ExtUtils/xsubpp  -typemap /usr/share/perl5/ExtUtils/typemap  Alias.xs > Alias.xsc && mv Alias.xsc Alias.c
gcc -c   -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic   -DVERSION=\"1.12\" -DXS_VERSION=\"1.12\" -fPIC "-I/usr/lib64/perl5/CORE"   Alias.c
In file included from /usr/lib64/perl5/CORE/mydtrace.h:14:0,
                 from /usr/lib64/perl5/CORE/cop.h:138,
                 from /usr/lib64/perl5/CORE/perl.h:3428,
                 from Alias.xs:14:
/usr/lib64/perl5/CORE/perldtrace.h:9:21: fatal error: sys/sdt.h: No such file or directory
compilation terminated.
make: *** [Alias.o] Error 1

And, now that I see this error, I remember that _this_ is why I installed systemtap in the first place.

Now, tracking back the error as best we can, we see this in /usr/lib64/perl5/CORE/mydtrace.h:

 #if defined(USE_DTRACE) && defined(PERL_CORE)

Basically, it looks like if USE_DTRACE weren't defined, there'd be no problem.  So we did this:

perl -V | grep -i trace
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -DDEBUGGING=-g -Dversion=5.12.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dotherlibdirs=/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi:/usr/local/lib/perl5/site_perl/5.10.0:/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi:/usr/lib/perl5/vendor_perl:/usr/lib/perl5/site_perl'

So it looks to us like the -Dusedtrace=/usr/bin/dtrace might be the source of the problem.  Now, I personally don't have any need of this flag in my Perl, AFAIK, and I'd be surprised if most other Perl programmers did either.  Is it possible to get the Perl built without it?

If not, we need to figure out a way to make everyone play nice together. :)

The perl module building mechanisms are supposed to do the proper sys/sdt.h
make/options, so individual perl module writers don't have to worry about it.
Something in the perl system is just a little bit wrong.  I'm not familiar
enough with it to point a finger, but wherever the .pm compile/link stuff is
kept is where I'd start looking.

(In reply to comment #8)
> The perl module building mechanisms are supposed to do the proper sys/sdt.h
> make/options,

No they're not. Perl modules shouldn't be exposed to sys/sdt.h at all.

The problem here seems to be that Data::Alias cheats by defining PERL_CORE and using POPSUB. It's Data::Alias' problem and can easily be worked around by:

--- Alias.xs.orig	2011-02-22 21:41:15.000000000 +0100
+++ Alias.xs	2011-04-13 14:36:41.570559332 +0200
@@ -14,6 +14,7 @@
 #include "perl.h"
 #include "XSUB.h"
 
+#define RETURN_PROBE(func, file, line)
 
 #ifdef USE_5005THREADS
 #error "5.005 threads not supported by Data::Alias"

(In reply to comment #9)
> (In reply to comment #8)
> > The perl module building mechanisms are supposed to do the proper sys/sdt.h
> > make/options,
> 
> No they're not. Perl modules shouldn't be exposed to sys/sdt.h at all.

Then it seems to me that Perl should not be built with -Dusedtrace; this would cause the mydtrace.h to skip including sys/sdt.h (see comment #7).

> The problem here seems to be that Data::Alias cheats by defining PERL_CORE and
> using POPSUB. It's Data::Alias' problem and can easily be worked around by:

I'll open a bug on CPAN's RT for Data::Alias' author.  But I still don't see why Perl is bringing in dtrace at all.

(In reply to comment #10)
> I'll open a bug on CPAN's RT for Data::Alias' author.  But I still don't see
> why Perl is bringing in dtrace at all.

Systemtap makes use of the same sdt style markers for probing purposes.  By enabling -Dusedtrace, users of Systemtap can probe their perl applications as well.

Well, I can confirm that if I patch the Alias.xs as recommended in comment #9 _and_ I reinstall systemtap-sdt-devel, then it installs and runs fine.  (Apparently systemtap and systemtap-runtime are not actually required.)

I also note that one of you fine Redhat folks already created a bug against Data::Alias in CPAN RT, so thanks for that.

I assume that this breakage slipped through the cracks because the RPM version of Data::Alias was removed, as per the bug mentioned in comment #1.  Since the newer versions of Data::Alias seem to work with Perl 5.12, perhaps that package should be resurrected.

Anyway, thanks everyone for their time.

If this package is used, I could re-add it into Fedora. Would be anyone interested in review #202876?

Upstream fixed it in new release.