Opened 3 years ago

Last modified 3 months ago

#20462 reopened defect

Make test failures/bugs on Raspberry Pi 3

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: regression, raspbian, test-failure unit-tests
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

Three test failures and some [warn] bugs on a raspberry pi 3 (Raspbian):

control/rend_service_parse_port_config:
  FAIL src/test/test_controller.c:190: assert(!cfg)
  [rend_service_parse_port_config FAILED]
options/validate__authdir: [forking]
  FAIL src/test/test_options.c:660: assert(msg OP_EQ "Failed to resolve/guess local address. See logs for" " details."): <<NULL>> vs <Failed to resolve/guess local address. See logs for details.>
  [validate__authdir FAILED]
util/socketpair_ersatz: [forking]
  FAIL src/test/test_util.c:5188: assert(0 OP_EQ socketpair_result): 0 vs -111
  [socketpair_ersatz FAILED]
util/time: Oct 25 18:17:48.092 [warn] tor_timegm(): Bug: Result does not fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result does not fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result does not fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
OK
util/parse_http_time: Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result does not fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)

I've attached the buildlog - gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.2 (Raspbian 4.9.2-10)

Child Tickets

Attachments (1)

buildlog (49.5 KB) - added by cypherpunks 3 years ago.
Build/test log

Download all attachments as: .zip

Change History (19)

Changed 3 years ago by cypherpunks

Attachment: buildlog added

Build/test log

comment:1 Changed 3 years ago by nickm

Keywords: regression TorCoreTeam201610 added

comment:2 Changed 3 years ago by dgoulet

Keywords: TorCoreTeam201611 added; TorCoreTeam201610 removed

comment:3 Changed 3 years ago by arma

Description: modified (diff)

(cleaning up formatting of original ticket)

comment:4 Changed 3 years ago by arma

Did this system have no network at the time?

(There are other tickets about unit tests while no network, right?)

comment:5 Changed 3 years ago by arma

Nick asked me to look at the 0.2.9.x tickets. This one looks like a good one to understand better before 0.2.9.x goes stable, in case it's a regression or otherwise will be surprising to people who try to use 0.2.9.x as stable.

comment:6 Changed 3 years ago by cypherpunks

Resolution: fixed
Status: newclosed

I've tested again with 0.2.9.5 (I disabled the firewall prior to running 'make test', the box doubles as a wireless access point) and the only failing test was:

control/rend_service_parse_port_config:

FAIL src/test/test_controller.c:190: assert(!cfg)
[rend_service_parse_port_config FAILED]

I dug into it a bit further and it turns out the router used the ISP (virgin media) do something weird/evil with dns queries that don't resolve (in this case "1.2.3.4.5" from the testcase), the dns query was returning the isps safe search page. I hadn't noticed this before as everything apart from the router uses a differently evil dns provider - a long way of saying its probably fine to close this.

comment:7 Changed 3 years ago by arma

teor: I heard you saying that the unit tests are not supposed to log warnings? If so, does that goal apply to the "[warn] tor_timegm(): Bug: Result does not fit in tor_timegm" lines above?

comment:8 Changed 3 years ago by teor

Resolution: fixed
Status: closedreopened

Yes, there are still multiple bugs here:

  • the unit tests should not depend on DNS (1, 2, 3?)
  • the socketpair_ersatz unit test should be turned off for raspian (like it is for BSD) (3)
  • the BUG warning should be resolved (4)

comment:9 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201612 added; TorCoreTeam201611 removed

Going to December!

comment:10 Changed 2 years ago by nickm

Milestone: Tor: 0.2.9.x-finalTor: 0.3.1.x-final

comment:11 Changed 2 years ago by nickm

Keywords: triaged-out-20170308 added
Milestone: Tor: 0.3.1.x-finalTor: unspecified

comment:12 Changed 2 years ago by nickm

Keywords: regression, TorCoreTeam201612 triaged-out-20170308regression, TorCoreTeam201612, triaged-out-20170308

comment:13 Changed 2 years ago by nickm

Keywords: TorCoreTeam201612 removed

comment:14 Changed 23 months ago by nickm

Keywords: raspbian test-failure unit-tests added; triaged-out-20170308 removed

How is this now? We did a lot of work subsequently to make sure that the DNS dependencies went away; are there any still visible?

comment:15 Changed 8 months ago by meitar

I have a tiny bit more info, shared in the hopes this squeaky wheel gets a bit more grease.

Just today, I also hit the socketpair_ersatz test failure while building Tor on Raspbian. The relevant snippet of output from debuild -rfakeroot -uc -us is:

util/socketpair_ersatz: [forking] 
  FAIL ../src/test/test_util.c:5526: assert(0 OP_EQ socketpair_result): 0 vs -110
  [socketpair_ersatz FAILED]

This single test is the only one that failed. (In my case today, 31 other tests were skipped).

The version of Tor I attempted to build was 0.3.4.8. My Raspberry Pi's uname -a output:

Linux raspberry 4.14.73+ #1148 Mon Oct 1 16:41:23 BST 2018 armv6l GNU/Linux

This was an original Raspberry Pi with a BCM2835 chip.

I believe this is a regression since I have been able to build prior versions of Tor successfully on this same physical device.

Thanks again for all that you do.

comment:16 Changed 8 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.5.x-final

comment:17 Changed 4 months ago by nickm

Is there any chance that this is an IPv6-only issue?

comment:18 Changed 3 months ago by teor

Milestone: Tor: 0.3.5.x-finalTor: unspecified

It could also be a raspian issue with the function calls we use in socketpair_ersatz().

Let's look at this again when we have more information?

Note: See TracTickets for help on using tickets.