cxref Package produces blank output, but works fine when built from source. ($1680696) · Snippets

cxref Package produces blank output, but works fine when built from source.

Edited Oct 22, 2017

When running cxref 1.6e from the xenial Universe package, it fails to produce any output. However, when I run it after building it from source myself, it works fine. Here's an strace of the difference between two executables. Unfortunately, I'm out of time to debug this further, hopefully someone can take it from here.

This is the system I'm using (Acer Chromebook 14):

$ uname -a
Linux aServer 4.9.4-galliumos-braswell #1 SMP PREEMPT galliumos2 Thu Feb 23 01:58:04 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

This is how you build cxref from source:

$ apt-get build-dep cxref
$ apt-get source cxref
$ pushd cxref-*
$ debuild -us -uc
$ popd

This is how you get xv6, a sample set of c sources to run cxref against:

$ git clone git://github.com/mit-pdos/xv6-public.git

This is how you diff the package's and your newly built cxref's strace without ASLR, which produces a much cleaner diff:

$ export cxrefSrc="cxref-1.6e/src/cxref"
$ export xv6Dir="xv6-public"
$ export cxrefArgs="$xv6Dir/wc.c -xref-all -raw"
$ export command="diff -uw <(strace cxref $cxrefArgs 2>&1) <(strace $cxrefSrc $cxrefArgs 2>&1)"
$ setarch $(uname -m) -R /bin/bash -c "$command" | sed -n '9,73p'

This shows that in the working version, we =lstat= a number of files that we do not in the broken version, which is probably where the bug is. Thereafter, we read and write files differently, probably because of that lstatting. If only I had time to trace through the source to see what that meant. At least I have a working cxref now, though.

When running cxref 1.6e from the xenial Universe package, it fails to produce any output.  However, when I run it after building it from source myself, it works fine.  Here's an strace of the difference between two executables.  Unfortunately, I'm out of time to debug this further, hopefully someone can take it from here.

This is the system I'm using (Acer Chromebook 14):

$ uname -a
    Linux aServer 4.9.4-galliumos-braswell #1 SMP PREEMPT galliumos2 Thu Feb 23 01:58:04 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

This is how you build cxref from source:

$ apt-get build-dep cxref
    $ apt-get source cxref
    $ pushd cxref-*
    $ debuild -us -uc
    $ popd

This is how you get xv6, a sample set of c sources to run cxref against:

$ git clone git://github.com/mit-pdos/xv6-public.git

This is how you diff the package's and your newly built cxref's strace without ASLR, which produces a much cleaner diff:

$ export cxrefSrc="cxref-1.6e/src/cxref"
    $ export xv6Dir="xv6-public"
    $ export cxrefArgs="$xv6Dir/wc.c -xref-all -raw"
    $ export command="diff -uw <(strace cxref $cxrefArgs 2>&1) <(strace $cxrefSrc $cxrefArgs 2>&1)"
    $ setarch $(uname -m) -R /bin/bash -c "$command" | sed -n '9,73p'

This shows that in the working version, we =lstat= a number of files that we do not in the broken version, which is probably where the bug is.  Thereafter, we read and write files differently, probably because of that lstatting.  If only I had time to trace through the source to see what that meant.  At least I have a working cxref now, though.

package-strace_vs_src-strace.diff 3.89 KB