"multiple definition of `sys_tracing'" compiling against tor@head

[numbleroot]

Hello all,

Thanks for developing and maintaining this tool suite.

When trying to set up shadow + tgen + shadow-plugin-tor on a fresh Ubuntu 18.04 machine, I get the following error message during the ./setup build step of shadow-plugin-tor:

...
[ 97%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/channelpadding_negotiation.c.o
[ 97%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/circpad_negotiation.c.o
[ 98%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/ed25519_cert.c.o
[ 98%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/link_handshake.c.o
[ 98%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/netinfo.c.o
[ 98%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/pwbox.c.o
[ 99%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/sendme_cell.c.o
[ 99%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/socks5.c.o
[ 99%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/hs/cell_common.c.o
[ 99%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/hs/cell_establish_intro.c.o
[100%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/hs/cell_introduce1.c.o
[100%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/trunnel/hs/cell_rendezvous.c.o
[100%] Building C object src/tor/CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/ext/trunnel/trunnel.c.o
[100%] Linking C shared library libshadow-plugin-tor.so
CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/lib/trace/trace_sys.c.o:(.data.rel.ro.local+0x0): multiple definition of `sys_tracing'
CMakeFiles/shadow-plugin-tor.dir/__/__/__/tor/src/lib/trace/trace_stub.c.o:(.data.rel.ro.local+0x0): first defined here
collect2: error: ld returned 1 exit status
src/tor/CMakeFiles/shadow-plugin-tor.dir/build.make:10376: recipe for target 'src/tor/libshadow-plugin-tor.so' failed
make[2]: *** [src/tor/libshadow-plugin-tor.so] Error 1
CMakeFiles/Makefile2:113: recipe for target 'src/tor/CMakeFiles/shadow-plugin-tor.dir/all' failed
make[1]: *** [src/tor/CMakeFiles/shadow-plugin-tor.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
2020-10-27 19:04:15,026 INFO make returned 2
[2020-10-27 19:04:15.026553] Shadow Setup: ERROR! Non-zero return code from make.
2020-10-27 19:04:15,026 INFO returning code '2'

These are the steps that I used to install the full tool suite (after initial updating, user creation, etc. on the complete-vanilla box):

sudo apt-get install --yes autotools-dev autoconf cmake gcc g++ libc-dbg \
    libglib2.0-dev libigraph-dev make python3 python3-pyelftools xz-utils \
    python3-numpy python3-lxml python3-matplotlib python3-networkx python3-scipy \
    dstat git htop screen

cd /home/user
git clone https://github.com/shadow/shadow.git
cd /home/user/shadow
./setup build --clean --debug --jobs 4 --test
./setup install

cd /home/user
git clone https://github.com/shadow/tgen
mkdir tgen/build
cd /home/user/tgen/build
cmake .. -DCMAKE_INSTALL_PREFIX=/home/user/.shadow
make && make install

cd /home/user
git clone [email protected]:torproject/tor.git
git clone https://github.com/shadow/shadow-plugin-tor.git
cd /home/user/shadow-plugin-tor
./setup dependencies --assume-yes
./setup build --assume-yes --clean --debug --jobs 4 --tor-prefix /home/user/tor
./setup install

uname -a yields:

Linux buildmachine 4.15.0-122-generic #124-Ubuntu SMP Thu Oct 15 13:03:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Am I missing something here? Any help is much appreciated, thanks in advance.

[sporksmith]

You might find it useful to use the "known good" versions of shadow and tor from the continuous integration workflow: https://github.com/shadow/shadow-plugin-tor/blob/master/.github/workflows/build_and_test.yml.

LMK if that resolves the issue, though even if it does we can keep this open to investigate why it's breaking on the newer version(s)

[stevenengler]

This is an issue specifically with tor master, it builds fine with the current latest tor version 0.4.4.5.

There is a bug in the CMake file that causes shadow-plugin-tor to always build with tracing included, which is fixed by #113. This is why there is a tracing-related error even though you didn't enable the tracing option. In the past this didn't matter since the tracing code was just a stub and didn't do anything. Now in tor master, the tracing code has been rewritten and will no longer work with shadow-plugin-tor. To fix this, the CMake file will need to be updated to include the correct files as in tor's build steps.

[numbleroot]

Thanks, both of you. Checking out tor-0.4.4.5 indeed avoided this build failure. Also good to know about the known good versions of the full tool suite in the workflow file. I guess this issue will be resolved entirely when #113 is merged, however, please feel free to proceed with this issue whichever way you see fit.

[stevenengler]

Just to clarify, #113 won't fix this issue (building shadow-plugin-tor with tor master), but is needed before an actual fix can be implemented.

[numbleroot]

I see. I interpreted the changes in #113 to remove tracing code (and thus prevent it from being built) in case the tracing option was not enabled. Good luck with the actual fix!

[stevenengler]

With tor's new tracing code, you can no longer just remove the tracing code since the stub will actually be required now (for example sys_tracing will be accessed elsewhere in tor). So the fix will be to conditionally include either the stub if tracing is disabled, or include one of the tracers depending on which is selected (usdt or lttng).

[numbleroot]

So, including src/lib/trace/trace_stub.c in case tracing is disabled (which I assume is the default)?

[stevenengler]

I think that it is that simple for when tracing is disabled, but for when tracing is enabled, there should also be an option to specify which tracing tool to use (src/lib/trace/lttng or src/lib/trace/usdt). And then we should also check if shadow will actually work with these new tracing tools, and I know very little about them.

But I also don't really understand why the option to remove tracing was initially added to shadow-plugin-tor, so maybe on some platforms there's a complication that I don't know about. But shadow-plugin-tor has been adding tracing automatically for almost a year and no one has complained, so maybe that is no longer an issue.

[numbleroot]

Matt's commit message mentions that trace "depended on options being defined in other files that aren't always defined", which is what caused problems for shadow-plugin-tor. But maybe that has changed since 2016, particularly with tor's tracing subsystem rewrite that you mentioned.

[sporksmith]

I'll take a look at this