Bug 482903 - debugedit prints: canonicalization unexpectedly shrank by one character
debugedit prints: canonicalization unexpectedly shrank by one character
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Panu Matilainen
Petr Sklenar
: Regression
Depends On: 304121
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-28 13:56 EST by Jack Neely
Modified: 2010-10-23 03:19 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 304121
Environment:
Last Closed: 2009-09-02 07:40:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch to restore old behavior (520 bytes, patch)
2009-03-02 08:37 EST, Olivier Fourdan
no flags Details | Diff
Patch to add a mention in the rpmbuild.8 man page (604 bytes, patch)
2009-03-18 11:04 EDT, Olivier Fourdan
no flags Details | Diff
Patch to address the error in debugedit (7.30 KB, patch)
2009-03-23 05:27 EDT, Olivier Fourdan
no flags Details | Diff
Patch to add a mention in the rpmbuild.8 man page (now also including ja/rpmbuild.8 ) (1.25 KB, patch)
2009-03-24 06:37 EDT, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Jack Neely 2009-01-28 13:56:49 EST
Looks like the new rpm 4.4.2.3-9.el5 package brings this bug to RHEL 5.3.  This is proving to be quite serious.

+++ This bug was initially created as a clone of Bug #304121 +++

Description of problem:
When a the source directory for a file ends with a '/', debugedit can spit out a
"canonicalization unexpectedly shrank by one character" error and fail.  That's
not really enough for most people to figure out what's gone wrong or how to fix it.

Version-Release number of selected component (if applicable):
rpm-build-4.4.2.2-0.5.rc2

How reproducible:
Always

Steps to Reproduce:
1. mkdir src
2. cat > src/foo.c <<- EOF
   int
   main(int argc, char **argv)
   {
        return 0;
   }
EOF
3. cd src
4. gcc -g3 -o foo ../src//foo.c
5. /usr/lib/rpm/debugedit -b `pwd` -d / foo
  
Actual results:
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character

Expected results:
Either not fail, or indicate that a directory name in the table ended with a
'/', which it probably shouldn't have contained.

Additional info:
I actually ran into this with openafs 1.4.4, but I'm including a smaller
reproducer which I think triggers the same bug.

--- Additional comment from pmatilai@redhat.com on 2007-09-27 04:49:46 EDT ---

Hmm, it's not the trailing '/' that troubles debugedit per se but the fact that
the canonicalized path is exactly one character shorter than the original which
is a case that it can't (and can't be made to AFAICT) handle. Roland, care to
comment?

The error message could certainly be clearer on what sort of problem to look for
(basically single extra '/' somewhere in the path).

--- Additional comment from roland@redhat.com on 2007-09-27 19:26:18 EDT ---

Indeed, the format makes it impossible to do rewriting in place unless the table
shrinks by at least 2 or not at all (it's beyond the scope of debugedit to
resize things).  For cases in the directory table you could do an ugly kludge by
repeating the leading / or adding a trailing one to preserve the size.  But
there is no trick like that to do in the file table, where any leading or
trailing slash would change the final file name so it doesn't work (not just is
wrongly ugly).  The !=-1 size restriction is for the whole table cumulatively,
so with extra slashes removed by canonicalization, it is only a problem when
there is only one such file name.  It could do a kludge of adding a trailing
slash to some dir table entry when this arises, which would work and only uglify
some of the names to /foo//bar.  Still, I suspect packagers will be OK with it
being an error they have to fix or work around, if they can tell what to do.

The error message you get now is certainly pretty arcane.  The other error of
the same ilk has a better message.  

Looking at canonicalize_path, I think it is true that a doubled / is the only
way it could shrink by exactly one.  But I could use a second set of eyes to
verify there really is no obscure innocent case that could do that.  If that's
true, then we can simply change the error message to identify this problem.

--- Additional comment from jan.iven@cern.ch on 2007-11-14 05:53:44 EDT ---

FYI, the instance that triggers this bug has apparently been "fixed" in the
Fedora-8-specific OpenAFS SRPM at
http://openafs.org/dl/openafs/1.4.5/fedora-8/SRPMS/openafs-1.4.5-fc8.2.src.rpm
Nonetheless, this could of course affect other packages as well..


--- Additional comment from tibbs@math.uh.edu on 2007-12-06 18:43:46 EDT ---

Just a note that a koji build for syslog-ng failed with the same error:
http://koji.fedoraproject.org/koji/taskinfo?taskID=265344

I'm not sure what would have changed to cause this package to stop building in
this manner.

--- Additional comment from roland@redhat.com on 2007-12-06 20:21:12 EDT ---

This line from the log suggests the problem:

/home/bazsi/zwa/git//syslog-ng/syslog-ng--mainline--2.0/src/cfg-lex.l:247:
warning: ignoring return value of 'fwrite', declared with attribute
warn_unused_result

The common reason for this error is // instead of / inside a file name.
This arises from using a trailing / on a directory name in a macro or makefile
variable usually.  

It may be a further problem that this absolute directory name appears in the
build.  Presumably it is in # line file name strings in cfg-lex.c, which is
generated from cfg-lex.l.  If this file is included in the upstream tarball like
this, then so it is and that is fine from the rpm-reproducible-builds
perspective.  Even so, upstream should be taught how to generate genericized
file names for their dist tarballs, so it winds up just # line "cfg-lex.l" or
suchlike.  If the rpm build is running lex/flex to generate cfg-lex.c itself,
then it's just our spec file that has to be fixed.

--- Additional comment from silfreed@silfreed.net on 2008-01-08 11:51:04 EDT ---

I've created a patch for syslog-ng that fixes the double slash in the 
cfg-lex.c and cfg-grammar.c files but I still get the error with debuginfo and 
the warning referenced above as well.

I'm sorry I'm not much more help with this; I still don't fully understand 
what the error is here.

--- Additional comment from fedora-triage-list@redhat.com on 2008-05-13 23:16:33 EDT ---

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from orion@cora.nwra.com on 2008-05-27 13:40:58 EDT ---

I'm seeing the same problem, but don't see any '//' occurrences.  See
http://koji.fedoraproject.org/koji/getfile?taskID=630760&name=build.log

If anyone has any suggestions as to how to fix, I would appreciate it.

--- Additional comment from roland@redhat.com on 2008-05-27 17:30:17 EDT ---

Since that was a scratch build, I do not have the sources from pkgs cvs to
reproduce your build problem.

--- Additional comment from orion@cora.nwra.com on 2008-05-27 17:36:54 EDT ---

http://www.cora.nwra.com/~orion/fedora/gridengine-6.2-0.beta.1.fc10.src.rpm

--- Additional comment from roland@redhat.com on 2008-05-27 18:45:27 EDT ---

source/clients/qmon/qmon_cplx.c: 61: #include "spool/flatfile//sge_flatfile_obj.h"
source/libs/spool/flatfile/test_sge_spooling_flatfile.c: 47: #include
"spool/flatfile//sge_flatfile.h"
source/libs/spool/flatfile/test_sge_spooling_flatfile.c: 50: #include
"spool/flatfile//sge_flatfile_obj.h"


--- Additional comment from orion@cora.nwra.com on 2008-05-28 11:10:22 EDT ---

Thanks, didn't think to check for includes inside the source files.
Comment 4 Olivier Fourdan 2009-03-02 08:37:21 EST
Created attachment 333735 [details]
Proposed patch to restore old behavior

The behavior of "debugedit" has not changed, it was already reporting an error in previous updates of EL5.

However, with rpm-4.4.2.3 the script "find-debuginfo.sh" now stops if an error is reported by "debugedit", whereas it used to continue with the previous version rpm-4.4.2-48 that was shipping in Red hat Enterprise Linux up to 5.2.

As a result, some rpm that used to build with EL5.2 now fail in EL5.3. While the error is most likely in the source of the package itself, this is a change in behavior that is perceived as a regression ("it used to build, but not anymore").

The following (trivial) patch does not address the issue with debugedit, it just restores the old behavior so the script find-debuginfo.sh will not stop if "debugedit" fails, as it used to do up to EL 5.2.

Would that be acceptable for EL5.x?
Comment 5 Jack Neely 2009-03-02 11:20:05 EST
I think that would be acceptable for 5.x.
Comment 7 RHEL Product and Program Management 2009-03-04 05:16:31 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.
Comment 11 Olivier Fourdan 2009-03-18 11:04:34 EDT
Created attachment 335710 [details]
Patch to add a mention in the rpmbuild.8 man page

This additional patch just adds the mention of the issue to the rpmbuild man page (the added text in English may need proof reading).

Please note that this patch does not include the other localized versions of the man page for rpmbuild (ie Polish and Japanese).
Comment 14 Olivier Fourdan 2009-03-24 06:37:12 EDT
Created attachment 336443 [details]
Patch to add a mention in the rpmbuild.8 man page (now also including ja/rpmbuild.8 )

Updated patch including Japanese translation from mfuruta@redhat.com

Just for clarity, either these two patches:

 - rpm-4.4.2.3-do-not-break-on-debugedit.patch
 - rpm-4.4.2.3-do-not-break-on-debugedit-man-part2.patch

Or only this one:

 - rpm-4.4.2.3-canon-fix.patch

Should be applied. The first two patches restore the previous behavior and document the error in the man page, whereas the latter addresses the issue in debugedit.
Comment 15 Olivier Fourdan 2009-03-24 06:40:06 EDT
Comment on attachment 336254 [details]
Patch to address the error in debugedit

Patch from http://laiskiainen.org/tmp/debugedit-canon-fix.diff (slightly adapted)
Comment 20 errata-xmlrpc 2009-09-02 07:40:47 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1371.html

Note You need to log in before you can comment on or make changes to this bug.