Assertion ENTRY_TO_CONN(conn)->state == AP_CONN_STATE_CIRCUIT_WAIT failed in circuit_get_open_circ_or_launch at circuituse.c:1835

changed milestone to %Tor: 0.2.6.x-final

added 026-backport 2016-bug-retrospective component::core tor/tor milestone::Tor: 0.2.6.x-final owner::nickm priority::medium regression resolution::fixed status::closed type::defect version::tor unspecified labels

What version of Tor are you running, on what operating system, and what were you doing at the time?

Trac:
Version: N/A to Tor: unspecified
Status: new to needs_information
Summary: bugs to Assertion ENTRY_TO_CONN(conn)->state == AP_CONN_STATE_CIRCUIT_WAIT failed in circuit_get_open_circ_or_launch at circuituse.c:1835
Component: - Select a component to Tor

Is this with Vidalia? If so, does it happen outside of vidalia?

(The line number seems to match up with tor 0.2.6.latest)

I think people are still waiting for details here.

(Meaning, you seem to be spamming trac and generally making a nuisance of yourself, which makes people uninterested in being helpful. Please consider being helpful instead.)

Καλησπέρα! Μπορείς να διαβάσεις αυτά τα μηνύματα?

Αν ναι, σταμάτα να ανοίγεις νέα bug reports για το ίδιο πράγμα κάθε μέρα! Ευχαριστώ! Αν προσέξεις, στα άλλα comments σου έχουν κάνει κάποιες ερωτήσεις που θα μας φέρουν πίο κοντά στο να λύσουμε το πρόβλημα σου!

Σε παρακαλώ απάντησε τις εξής ερωτήσεις:

Χρησιμοποιείς Vidalia? Αν ναι, τοτε έχεις πολύ παλια version του Tor! Δοκίμασε να κατεβάσεις την τελευταία έκδοση από το: https://www.torproject.org/download/download-easy.html.en
Αν έχεις την τελευταία έκδοση και το πρόβλημα συνεχίζεται, τοτε πες μας ποιά έκδοση έχεις, σε ποιο λειτουργικό σύστημα το τρέχεις (Windows, Mac, Linux, ?) και τι έκανες όταν εμφανίστηκε το πρόβλημα.

Μην αγνοήσεις αυτές τις ερωτήσεις! Θέλουμε να λύσουμε το πρόβλημα σου!

Ευχαριστώ!

^ here is a localized attempt

I hit this same assert fail, output here:

Jun 04 XX:39:28 host Tor[310]: Received reload signal (hup). Reloading config and resetting internal state.
Jun 04 XX:39:28 host Tor[310]: Read configuration file "/etc/tor/torrc".
Jun 04 XX:45:03 host Tor[310]: New control connection opened from 127.0.0.1.
Jun 04 XX:50:41 host Tor[310]: New control connection opened from 127.0.0.1.
Jun 04 XX:50:42 host Tor[310]: Query '[scrubbed]' didn't have valid rend desc in cache. Failing.
Jun 04 XX:50:42 host Tor[310]: tor_assertion_failed_(): Bug: src/or/circuituse.c:1835: circuit_get_open_circ_or_launch: Assertion ENTRY_TO_CONN(conn)->state == AP_CONN_STATE_CIRCUIT_WAIT failed; aborting.
Jun 04 XX:50:42 host Tor[310]: Bug: Assertion ENTRY_TO_CONN(conn)->state == AP_CONN_STATE_CIRCUIT_WAIT failed in circuit_get_open_circ_or_launch at src/or/circuituse.c:1835. Stack trace:
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(log_backtrace+0x41) [0x2661fa8631]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(tor_assertion_failed_+0x8c) [0x2661fb62fc]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(+0xb7a8f) [0x2661f45a8f]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(connection_ap_handshake_attach_circuit+0x2d9) [0x2661f46529]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(connection_ap_attach_pending+0x79) [0x2661f64159]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(circuit_build_needed_circs+0x38) [0x2661f45448]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(+0x360d8) [0x2661ec40d8]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/lib/libevent-2.0.so.5(event_base_loop+0x806) [0x2badaa5dca6]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(do_main_loop+0x17d) [0x2661ec4bed]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(tor_main+0x16a5) [0x2661ec79f5]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x2bad9b8b790]
Jun 04 XX:50:42 host Tor[310]: Bug:     /usr/bin/tor(_start+0x29) [0x2661ec1139]
Jun 04 XX:50:42 host systemd[1]: tor.service: main process exited, code=killed, status=6/ABRT
Jun 04 XX:50:42 host systemd[1]: Unit tor.service entered failed state.
Jun 04 XX:50:42 host systemd[1]: tor.service failed.

When it occurred:

added a new HidServAuth torrc config line for a stealth hs (foo.onion)
ran `kill -SIGHUP $TOR_PID` to force a config reload
ran `torsocks ssh foo.onion`

Arch Linux, x86_64
Tor v0.2.6.8 (git-5c8440b13bde6c88) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2a and Zlib 1.2.8.

edit: should note, possibly I hit the old .onion address because I forgot to update my shell envvar that I store the onion address in first, I don't recall exactly, sorry.

Note: Changing the reporter to cypherpunks so I can obliterate the original submitter since they have chosen to consistently spam trac with duplicate tickets for weeks instead of replying with useful information.

Also thanks for another case that triggers the assert, that should be a starting point.

Trac:
Reporter: slrsab to cypherpunks

Trac:
Keywords: N/A deleted, regression 026-backport added
Milestone: N/A to Tor: 0.2.7.x-final

Same issue.

Debian wheezy.
tor 0.2.6.8-5~d70.wheezy+1
Tor v0.2.6.8 (git-69b46cf274f35955) running on Linux with Libevent 2.0.19-stable, OpenSSL 1.0.1e and Zlib 1.2.7.

Trac:
Cc: N/A to adrelanos@riseup.net

Replying to yawning:

what were you doing at the time?

Get new circuit using arm.

Replying to nickm:

Is this with Vidalia? If so, does it happen outside of vidalia?

Vidalia not involved.

I added a log message in commit aab7d666cd51fdccdb735f7fa2c59f93d0c450e9 that should log a little more info if this error recurs. To see it, reproduce the bug with git master (or with 0.2.7.2-alpha when it's out).

Looking at the code and the stack trace, I see that we seem to be calling circuit_get_open_circ_or_launch() from connection_ap_handshake_attach_circuit(). But connection_ap_handshake_attach_circuit() already did tor_assert(base_conn->state == AP_CONN_STATE_CIRCUIT_WAIT);. So all I can figure is that either we're passing a different connection (!?), or the state has changed between the start of connection_ap_handshake_attach_circuit() and the call to circuit_get_open_circ_or_launch().

Or conceivably, this is in one of the calls to circuit_get_open_circ_or_launch() from within circuit_get_open_circ_or_launch(). But if that's happening, there should be an info-level log message. Maybe also try reproducing the bug with info-level logging?

I hit it too.

Just started relay with 0.2.6.9 two days ago. No hidden services locally, bug occurred on client browsing activity concurrent with moderate relay activity. Client and Videlia running on different systems.

Log messages and gdb stack traces attached in obfuscated form. Have a complete intact core file and supporting set sysroot bundle and am willing to provide that privately. Please contact me at starlight dot 2015q2 at binnacle dot cx.

First reported as #16365 (moved) and yawing identified it as this issue.

Trac:
messages-obfus.txt

log messages

Trac:
gdb-trace-obfus.txt

stack trace

This bug might be reproducible.

It depends on accessing a particular site with a somewhat uncommon client configuration.

Same config and site access gives 0.2.4.27 and 0.2.5.12 fits, though eventually it works. Have fallen back to old version because 0.2.6.9 fails consistently, though in a different manner than the bug-trap so far.

Possibly the site in question is currently under DDOS and so the opportunity to reproduce may be time-limited to the attack.

Contact me privately at starlight dot 2015q2 at binnacle dot cx for the details.

Actually, what would help most would be reproducing it using latest git master, or with 'aab7d666cd51fdccdb735f7fa2c59f93d0c450e9 ' backported to 0.2.6.9, and noting the info-level log messages.

Assertion ENTRY_TO_CONN(conn)->state == AP_CONN_STATE_CIRCUIT_WAIT failed in circuit_get_open_circ_or_launch at circuituse.c:1835

Child items ...

Activity