Opened 13 years ago

Closed 3 years ago

#31256 closed defect (fixed)

ctags 5.8 creates improper tags file when compiled with llvm

Reported by: echosa@… Owned by: jmroot (Joshua Root)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: lion Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: ctags

Description (last modified by ryandesign (Ryan Carsten Schmidt))

So, as the summary says, ctags 5.8 creates improper tags files when compiled on OS X Lion using the Lion .dmg macports install. However, on Snow Leopard, compiled with the Snow Leopard version of macports, the created tags files are correct. The Lion-compiled ctags binary has the same issues on Snow Leopard, and the Snow Leopard-compiled binary works fine on Lion. (So right now, I'm just using a ctags binary compiled on Snow Leopard to get my work done on Lion.)

Here's the command I'm running from my project's root directory:

/opt/local/bin/ctags -e -f /path/to/TAGS -R --tag-relative=yes --totals=no --langmap=php:.php --exclude=.svn --PHP-kinds=+cf .

I'm running this on a PHP project, obviously. Also, you'll notice the -e flag, making the TAGS file etags compatible.

A proper etags reference should basically be of the format:

<file>,<size of tag entry>
<tag information>

A TAGS file will contain many of these.

Here's an example of what the ctags compiled with Snow Leopard is (properly) generating.

../../../Volumes/webdev/biosafety/trunk/application/Bootstrap.php,78
class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719
(... extra lines here for the rest of this tag's information ...)

The important thing here is the path at the beginning.

The ctags compiled on Lion, however, doesn't always have this proper format. Sometimes the path will be /var/some/temp/path/somewhere or, more often, will be nonexistent, like this:

,78
class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719
(... extra lines here for the rest of this tag's information ...)

Notice there is no file reference before the first comma. Note that not all of the tags references are bad. Some are proper, a few have paths to /var/somewhere, but the rest have no file reference at all.

FYI, the way I'm viewing these TAGS files is by loading them in emacs with visit-tags-table and switching to their buffer, which allows them to be seen in plain text.

Change History (12)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Keywords: ctags removed
Owner: changed from macports-tickets@… to mww@…
Port: ctags added

Please remember to use WikiFormatting, and to Cc the maintainer of the affected port.

comment:2 Changed 13 years ago by echosa@…

Sorry about that. First submission, didn't read the guide very carefully. Won't make the same mistake again. Thanks for correcting.

comment:3 Changed 13 years ago by tim.blackman@…

Related bug report on the ctags project site:

https://sourceforge.net/tracker/index.php?func=detail&aid=3247256&group_id=6556&atid=106556

As I noted there, it looks like using the standard compiler but disabling optimization is an effective work around:

export CFLAGS=-O0

Then configure and make as usual.

comment:4 Changed 13 years ago by neverpanic (Clemens Lang)

Sounds like a clang problem to me; try installing with port install ctags configure.compiler=llvm-gcc-4.2 and report back if the issue doesn't happen in this installation.

Note that MacPorts mostly ignores environment variables, as it sets its own ones. If you wanted to disable optimization for MacPorts-compiled binaries use port install ctags configure.optflags=-O0.

comment:5 Changed 13 years ago by echosa@…

Running port install ctags configure.compiler=llvm-gcc-4.2 doesn't change anything.

However, running port install ctags configure.optflags=-O0 fixes the issue, as does using -O1. Compiling with -O2 results in the issue.

comment:6 Changed 12 years ago by jmroot (Joshua Root)

Summary: ctags 5.8 creates improper tags file when compiled on OS X Lionctags 5.8 creates improper tags file when compiled with llvm

Workaround based on the info in comment:5 committed in r93604. Really needs to be fixed upstream though.

comment:7 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Do you have a test case that shows off this issue (like a tarball and a command to run)? I'd like to determine if it is fixed in newer versions of clang, and if not, we need to report this upstream.

comment:8 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added

Cc Me!

comment:9 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: invalid
Status: newclosed

No response. Closing.

comment:10 Changed 3 years ago by jmroot (Joshua Root)

Resolution: invalid
Status: closedreopened

According to someone in the upstream bug, the problem is the code uses strcpy() on overlapping strings (the result of which is undefined).

comment:11 Changed 3 years ago by jmroot (Joshua Root)

Owner: mww@… deleted
Status: reopenedassigned

comment:12 Changed 3 years ago by jmroot (Joshua Root)

Owner: set to jmroot
Resolution: fixed
Status: assignedclosed

In 5f57b2016ff9b894b179dd3b29cc1eb6f714096f/macports-ports (master):

ctags: fix undefined behaviour

Don't use strcpy on overlapping strings as its behaviour is undefined
in that case. Remove previous workaround of using lower -O level.

Closes: #31256

Note: See TracTickets for help on using tickets.