Ubuntu
exuberant-ctags package

etags screw filenames starting with ./

Bug #582347 reported by VadimL
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
emacs23 (Fedora)
Fix Released
Medium
emacs23 (Ubuntu)
Confirmed
Undecided
Unassigned
exuberant-ctags (Debian)
Fix Released
Unknown
exuberant-ctags (Ubuntu)
Fix Released
Medium
Colin Watson

Bug Description

Binary package hint: exuberant-ctags

when running etags using following form:
find . -name '*.[hc]' | xargs etags -a
The generated TAGS file contains wrong file names.
The same problem exists with etags problem coming from emacs23 package
Works correctly with :
find ../<upperdir>/. -name '*.[hc]' | xargs etags -a

The same problem reported here: https://bugzilla.redhat.com/show_bug.cgi?id=545398

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: exuberant-ctags 1:5.8-2
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Tue May 18 18:19:43 2010
InstallationMedia: Kubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
ProcEnviron:
 LANGUAGE=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: exuberant-ctags

Revision history for this message
In , Sjoerd (sjoerd-redhat-bugs) wrote :

Created attachment 376898
Patch for the problem described, replacing strcpy with memmove.

Description of problem:
This is a bug against etags.emacs which is packaged in emacs-common, but there is no separate component called emacs-common. This same bug exists in etags.xemacs, packaged in xemacs-common.

When etags is run with filenames starting with "./", it normalizes them to start without "./", but does so incorrectly, messing up the result.

Version-Release number of selected component (if applicable):
emacs-common-23.1-13.fc12.x86_64
xemacs-common-21.5.29-8.fc12.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a file with a C function and path e.g. src/gdk/gdk_atoms.c
2. Run /usr/bin/etags.emacs ./src/gdk/gdk_atoms.c
3. Observe the filename in TAGS

Actual results:
The filename recorded in the TAGS file is src/gdk/gdk_otoms.c (note "o" after underscore).

Expected results:
The filename should be src/gdk/gdk_atoms.c

Additional info:
The problem is a call to strcpy on overlapping buffers. In Fedora 11 and before that seems to have worked, but in Fedora 12 it often does not work, at least not for slightly longer filenames.

The attached patch should also work for etags.xemacs in xemacs-common, except for differing line numbers.

Revision history for this message
In , Sjoerd (sjoerd-redhat-bugs) wrote :

Also see bug 545399 for the XEmacs version of the bug.

Revision history for this message
In , Karel (karel-redhat-bugs) wrote :

I cannot reproduce it on 32-bit Fedora, but the usage of strcpy in the code is clearly wrong. Moreover, this bug is already fixed in the upstream CVS.

Revision history for this message
In , Karel (karel-redhat-bugs) wrote :

http://koji.fedoraproject.org/koji/taskinfo?taskID=1863033

The fix will be a part of next update.

Thanks for nicely detailed bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

emacs-23.1-11.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update emacs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

emacs-23.1-13.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update emacs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

emacs-23.1-13.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
VadimL (vadim-mbdsys) wrote :
Revision history for this message
Jim Blandy (jimb) wrote :

The problem is in lib-src/etags.c's function absolute_filename. If HAVE_MEMMOVE is not #defined, it uses strcpy to try to squeeze out unnecessary '/./' sequences from the path name. However, strcpy behaves unpredictably when the source and destination overlap.

The question to resolve is, why is HAVE_MEMMOVE not being #defined when this package is built by ubuntu? A properly configured 23.2 build from source gives me a working etags.

Revision history for this message
Colin Watson (cjwatson) wrote :

That may well be the problem in emacs23, so I've opened a bug task for that. It's not the problem in exuberant-ctags, though.

In fact, VadimL, are you sure that this bug exists in exuberant-ctags? I haven't been able to reproduce it there. You can make sure you're definitely using the etags from exuberant-ctags by invoking it like this:

  find . -name '*.[hc]' | xargs ctags-exuberant -e -a

Revision history for this message
Colin Watson (cjwatson) wrote :

My test:

  <cjwatson@sarantium ~/src/ubuntu/exuberant-ctags/exuberant-ctags>$ etags gnu_regex/regex.c
  <cjwatson@sarantium ~/src/ubuntu/exuberant-ctags/exuberant-ctags>$ mv TAGS TAGS.safe
  <cjwatson@sarantium ~/src/ubuntu/exuberant-ctags/exuberant-ctags>$ etags ./gnu_regex/regex.c
  <cjwatson@sarantium ~/src/ubuntu/exuberant-ctags/exuberant-ctags>$ diff -u TAGS.safe TAGS
  <cjwatson@sarantium ~/src/ubuntu/exuberant-ctags/exuberant-ctags>$

Revision history for this message
VadimL (vadim-mbdsys) wrote :

I've just tried:

vadim@sinus:~/sgdn/verona$ ctags-exuberant -e -a ./mediastreamer2/src/msconf.c
vadim@sinus:~/sgdn/verona$ mv TAGS TAGS.safe
vadim@sinus:~/sgdn/verona$ ctags-exuberant -e -a mediastreamer2/src/msconf.c
vadim@sinus:~/sgdn/verona$ diff TAGS TAGS.safe
2c2
< mediastreamer2/src/msconf.c,3688
---
> mediastrmer2/2/src/msconf.c,3688
 vadim@sinus:~/sgdn/verona$

Revision history for this message
Daniel Hahler (blueyed) wrote :

This appears to be fixed by the 5.9 snapshot I am trying to get into Ubuntu via bug 732860:

% asrc libmediastreamer-dev
apt-get source libmediastreamer-dev
[...]
Hole:1 http://archive.ubuntu.com/ubuntu/ natty/main linphone 3.3.2-3ubuntu1 (dsc) [2.344 B]
[...]
% cd linphone-*
% ctags -e -a ./mediastreamer2/src/msconf.c
% mv TAGS TAGS.safe
% ctags -e -a mediastreamer2/src/msconf.c
% diff TAGS TAGS.safe
% head TAGS -n2

mediastreamer2/src/msconf.c,3688

Changed in exuberant-ctags (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Daniel Hahler (blueyed) wrote :

Marking the emacs23 task as invalid: it appears the fix in ctags is enough?! (I might be wrong here very likely..)

Changed in emacs23 (Ubuntu):
status: New → Invalid
Revision history for this message
Daniel Hahler (blueyed) wrote :

You might want to test the snapshot build from my PPA:
My PPA is at https://launchpad.net/~blueyed/+archive/ppa/+packages and you should be able to install the version I have uploaded for Lucid: https://launchpad.net/~blueyed/+archive/ppa/+sourcepub/1546567/+listing-archive-extra

Revision history for this message
Colin Watson (cjwatson) wrote :

I don't see why this should be invalid in emacs23, given that the previous comments explicitly describe a bug with references to source files that do not exist in exuberant-ctags. Reopening that task.

Changed in emacs23 (Ubuntu):
status: Invalid → New
Revision history for this message
Colin Watson (cjwatson) wrote :

This is actually Debian #594185. I forgot to link it when I fixed it in 1:5.8-4. It'll be in the next merge.

Bug Watch Updater (bug-watch-updater)
Changed in exuberant-ctags (Debian):
status: Unknown → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

exuberant-ctags (1:5.9~svn20110310-1) unstable; urgency=low

  * New upstream release snapshot (thanks, Daniel Hahler; LP: #732860).
    - Fix crash with comments inside strings in OCaml (LP: #554898).
  * Drop accepted patches:
    - debian/patches/make-match-loop.patch
    - debian/patches/php-ignore-keywords-in-comments.patch
  * For Python, disable -i so imports are not tagged by default (thanks,
    Barry Warsaw; LP: #618979).
  * Upstream uses AC_SYS_LARGEFILE now, so drop explicit
    -D_FILE_OFFSET_BITS=64 in debian/rules.
  * Fix infinite loop parsing vim commands, when a non-alphanumeric
    character other than whitespace or '-' is found before the first
    alphanumeric character after 'command' (LP: #736367).

 -- Colin Watson <email address hidden> Thu, 17 Mar 2011 16:47:08 +0000

exuberant-ctags (1:5.8-4) unstable; urgency=low

  * Apply patch from Ben Spencer to use memmove rather than strcpy on
    overlapping strings (closes: #594185).

 -- Colin Watson <email address hidden> Thu, 17 Feb 2011 13:47:11 +0000

Changed in exuberant-ctags (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs23 (Ubuntu):
status: New → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in emacs23 (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.