tor 0.2.8.1-alpha-dev - dumping core on test, tor binary dumps core as well

changed milestone to %Tor: 0.2.8.x-final

added component::core tor/tor crash milestone::Tor: 0.2.8.x-final must-fix-before-028-rc owner::yawning priority::very high reporter::yancm resolution::fixed severity::critical status::closed type::defect version::tor 0.2.8.1-alpha labels

Trac:
Keywords: N/A deleted, crash added
Milestone: Tor: unspecified to Tor: 0.2.8.x-final
Priority: Medium to Very High
Severity: Normal to Critical

Can you run a git bisect to find the faulty commit? I can't reproduce the issue.

Is there a better way to compile debug symbols into the build so gdb will give better diagnostics?

If I back up and compile against the "pkgsrc" version of openssl, tor passes the tests, so I suspect I have something messed up in the way I am compiling against openssl 1.1.0-dev. Will continue to investigate. BTW, openssl 1.1.0-dev passes it's self tests fine...

Trac:
Username: yancm

Replying to yancm:

Is there a better way to compile debug symbols into the build so gdb will give better diagnostics? When you configure the build, use ./configure CFLAGS="-O0 -ggdb". Also be sure to recompile any already built objects by running make clean before make.

Trac:
Status: new to needs_information

Here's what I have found so far. I compiled tor with debug symbols and have experimented with executables for both test and tor in gdb. I tried to set a break at the main entry point, but any time it ran, it ended up crashed in the openssl code somewhere. I could not get a backtrace as the stack was somehow no longer available. I did manage to get a debug build of the openssl 1.1.0.dev.alpha3 (something like that anyway), but then openssl changed their configure and build scripts with 1.1.0.dev.alpha4 and I have not yet been able to get a new debug build of openssl...or any build really.

My next step is to turn in an openssl ticket on the build problems and will also ask how to preserve the stack on debug as apparently that is a flag in the config that I cannot figure out...

My apologies for moving slow on this one, day job and life etc. are limiting my time on this ATM...

Trac:
Username: yancm

I can no longer build tor against OpenSSL 1.1.0.dev.alpha* or openssl-1.1.0-pre5-dev which is current as of this typing...

This ticket should probably be closed...

That said, I am still interested in building tor against the latest OpenSSL. I am not familiar enough with tors OpenSSL interface to help with updating the code. I would suggest it looks like the OpenSSL team is nearing some sort of release since the versioning has moved from alpha to preview...

If someone on the tor team has time again to try to adjust the api, I suggest they test against just the 1.1.0 api only by configuring with the following flag "./config --api=1.1.0".

thank you...

Trac:
Username: yancm
Reviewer: N/A to N/A

It would be great if tor-0.2.8-stable is able to build with OpenSSL 1.1.0, particularly if they are released around the same time.

That said, we could fix OpenSSL 1.1.0 compatibility in a point release, after OpenSSL does their release.

Nick, what do you think?

Trac:
Keywords: crash deleted, crash must-fix-before-028-rc added

Huh. Yeah, it would be good to support OpenSSL 1.1.0. I thought we did! Let's give it a try before the release and try to fix it if we can.

(Also we should make sure we build with LibreSSL.)

Trac:
Status: needs_information to assigned
Owner: N/A to yawning

Can't reproduce the test crash with OpenSSL 1.1.0-pre4 or master so I'm inclined to say "Upgrade to a more recent OpenSSL development pre-release snapshot".

This gets OpenSSL 1.1.0-pre4 and 1.1.0-pre5-dev (aka master) building and the tests don't crash, I think the changes are low risk enough that they can be taken for 0.2.8.x, though I did the work against master.

https://git.schwanenlied.me/yawning/tor/src/bug18286

Trac:
Status: assigned to needs_review

I am still unable to build tor (master) against OpenSSL (master)?

I receive the following:

gmake

gmake all-am gmake[1]: Entering directory '/usr/local/src/tor' CC src/common/crypto.o src/common/crypto.c: In function 'crypto_early_init': src/common/crypto.c:295:5: warning: implicit declaration of function 'ERR_load_crypto_strings' src/common/crypto.c:296:5: warning: implicit declaration of function 'OpenSSL_add_all_algorithms' src/common/crypto.c: In function 'crypto_thread_cleanup': src/common/crypto.c:420:3: error: too many arguments to function 'ERR_remove_thread_state' /usr/local/include/openssl/err.h:363:6: note: declared here src/common/crypto.c: In function 'openssl_locking_cb_': src/common/crypto.c:3082:14: error: 'CRYPTO_LOCK' undeclared (first use in this function) src/common/crypto.c:3082:14: note: each undeclared identifier is reported only once for each function it appears in src/common/crypto.c: At top level: src/common/crypto.c:3139:43: error: expected ')' before '*' token src/common/crypto.c: In function 'setup_openssl_threading': src/common/crypto.c:3151:3: warning: implicit declaration of function 'CRYPTO_num_locks' src/common/crypto.c:3156:3: warning: implicit declaration of function 'CRYPTO_set_locking_callback' src/common/crypto.c:3157:3: warning: implicit declaration of function 'CRYPTO_THREADID_set_callback' src/common/crypto.c:3157:32: error: 'tor_set_openssl_thread_id' undeclared (first use in this function) src/common/crypto.c: In function 'crypto_global_cleanup': src/common/crypto.c:3173:3: error: too many arguments to function 'ERR_remove_thread_state' /usr/local/include/openssl/err.h:363:6: note: declared here Makefile:3341: recipe for target 'src/common/crypto.o' failed gmake[1]: *** [src/common/crypto.o] Error 1 gmake[1]: Leaving directory '/usr/local/src/tor' Makefile:1930: recipe for target 'all' failed gmake: *** [all] Error 2

When you built OpenSSL did you build 1.1.0 api explicitly? ("./config --api=1.1.0")

Trac:
Username: yancm

Replying to yancm:

When you built OpenSSL did you build 1.1.0 api explicitly? ("./config --api=1.1.0")

No. I just did the minimum required to get it to build with a debug enabled OpenSSL build. I don't see the point in requesting an API that is obviously still in flux (As in, more shit is broken in master than is in pre4). The things that are deprecated by still declared can wait.

As a side note, the line numbers in your output don't match what I have in my branch, and it's puking on things that I did fix in addition to things that I have that you don't, so part of this likely is human error.

That said, I did push a fixup commit that removes slightly more code (orthogonal to your failure case).

I believe the point in building only against api 1.1.0 is this removes earlier api's that the developers know will be deprecated in 1.1.0; hence if we can build against 1.1.0 api, it probably more stable than building against the amalgam of all api's in master that are not yet deprecated.

I'm not sure I understand the "human error" part? I'm always willing to learn...

Trac:
Username: yancm

The OpenSSL release notes say:

Deprecated interfaces can now be disabled at build time either relative to the latest release via the "no-deprecated" Configure argument, or via the "--api=1.1.0|1.0.0|0.9.8" option.

So that makes it sound to me like "--api=1.1.0" is talking about deprecated interfaces that will nevertheless be included in the 1.1.0 release.

This makes sense. I was reading it as talking about deprecated interfaces that might be included in the 1.1.0 release and hence relying on them might be more of a moving target.

Trac:
Username: yancm

I worry a tiny bit about the use of OPENSSL_VER, given that it doesn't seem to exist in older versions of OpenSSL, and that we already have OPENSSL_V_*() macros. But it doesn't seem to actually break anything for me. So, squashing and merging in 0.2.8.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

tor 0.2.8.1-alpha-dev - dumping core on test, tor binary dumps core as well

pwd

gmake test

gdb src/test/test test.core

Child items ...

Activity

gmake