RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 728995 - Debuginfo package issues in perl
Summary: Debuginfo package issues in perl
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: perl
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: perl-maint-list
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 727919
TreeView+ depends on / blocked
 
Reported: 2011-08-08 15:18 UTC by Karel Klíč
Modified: 2013-05-07 10:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-07 10:41:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Karel Klíč 2011-08-08 15:18:41 UTC 
Several problems related to debuginfo were found in the perl-5.10.1-119.el6 package. These issues might affect crash analysis done by Automatic Bug Reporting Tool and its retrace server, and also prevent proper debugging of crashes via GDB.

Debuginfo symbolic links pointing to another path
-------------------------------------------------
Debuginfo package includes a symbolic link to each binary that has the debugging symbols stored there. For perl, two symbolic links do not point to the right binary, and that makes it impossible to use build ids from a coredump to get a list of packages required by it. Usually, this is a packaging error caused usually by placing identical binary into several locations instead of creating a symlink. If one copy of the binary is SUID/SGID, it is not possible to use symlink. You can add a dependency on bug #727872 and rebuild perl when that bug is fixed.

- affected binary: /usr/bin/perl
  affected package: perl-5.10.1-119.el6.i686
  referenced binary: /usr/bin/suidperl
  referenced package: perl-suidperl-5.10.1-119.el6.i686
  debuginfo symlink: /usr/lib/debug/.build-id/f8/48b9e8ff059b14becc9acb6dfaf49d5e5052b0
- affected binary: /usr/bin/perl5.10.1
  affected package: perl-5.10.1-119.el6.i686
  referenced binary: /usr/bin/suidperl
  referenced package: perl-suidperl-5.10.1-119.el6.i686
  debuginfo symlink: /usr/lib/debug/.build-id/f8/48b9e8ff059b14becc9acb6dfaf49d5e5052b0

This issue has been solved in Fedora by /usr/lib/rpm/find-debuginfo.sh creating additional symlinks for identical binaries. However, symlinks should be used instead of duplicating a binary when possible.

Source file missing in debuginfo package
----------------------------------------
Multiple source files that were used by the compiler to generate a binary are missing from the debuginfo package. This is usually caused by the build script creating temporary source files during the build and deleting them after usage, or by moving source files between directories. Missing source files in debuginfo packages make debugging of crashes more difficult.

debuginfo package: perl-debuginfo-5.10.1-119.el6.i686
  debuginfo file: /usr/lib/debug/usr/bin/a2p.debug
    missing source: /usr/src/debug/perl-5.10.1/x2p/y.tab.c
  debuginfo file: /usr/lib/debug/usr/bin/sperl5.10.1.debug
    missing source: /usr/src/debug/perl-5.10.1/sperl.c

Please consider changing the package build script (if that is the cause of this issue) to keep the source files on their compilation place, so rpmbuild can find them when generating debuginfo package.

(This bug was detected and filed by a script.)
Comment 2 RHEL Program Management 2011-08-08 15:41:40 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 3 Petr Pisar 2011-08-30 11:41:50 UTC 
> Debuginfo symbolic links pointing to another path

$ ls -l /usr/bin/{perl,perl5.10.1,sperl5.10.1,suidperl}
-rwxr-xr-x. 2 root root 13512 19. dub 21.28 /usr/bin/perl
-rwxr-xr-x. 2 root root 13512 19. dub 21.28 /usr/bin/perl5.10.1
-rws--x--x. 1 root root 84576 19. dub 21.28 /usr/bin/sperl5.10.1
-rwxr-xr-x. 1 root root 13512 19. dub 21.28 /usr/bin/suidperl

Indeed perl, perl5.10.1 and suidperl are identical.

> Source file missing in debuginfo package

rpmbuild complains:

cpio: perl-5.10.1/sperl.c: Cannot stat: No such file or directory
cpio: perl-5.10.1/x2p/y.tab.c: Cannot stat: No such file or directory

because the build phase does:

rm -f sperl.c
/bin/ln -s perl.c sperl.c
Reusing 'git_version.h' and 'lib/Config_git.pl'
LD_PRELOAD=/builddir/build/BUILD/perl-5.10.1/libperl.so LD_LIBRARY_PATH=/builddir/build/BUILD/perl-5.10.1  ./miniperl -Ilib configpm
`sh  cflags "optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables'" sperl.o` -DIAMSUID sperl.c
[...]
rm -f sperl.c
../miniperl -I../lib find2perl.PL
[...]
LD_PRELOAD=/builddir/build/BUILD/perl-5.10.1/libperl.so LD_LIBRARY_PATH=/builddir/build/BUILD/perl-5.10.1 gcc -o suidperl -fstack-protector -L/usr/local/lib -Wl,-E -Wl,-rpath,/usr/lib/perl5/CORE perlmain.o sperl.o  libperl.so `cat ext.libs` -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
Comment 5 Marcela Mašláňová 2013-05-07 10:41:23 UTC 
I'm not sure how many people are using suid perl, but they should prepare for removal. Next releases of Perl made it obsolete. 

The solution of our problem is not easy and because this part of package will be obsoleted I won't spend our time on this issue.
Note You need to log in before you can comment on or make changes to this bug.