Opened 7 years ago

Closed 3 years ago

#7091 closed defect (wontfix)

Assertion 0 == g->n_members failed error (from libevent)

Reported by: mr-4 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.3-alpha
Severity: Keywords: tor-relay bufferevents
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The full error message I get is "Error from libevent: bufferevent_ratelim.c:724: Assertion 0 == g->n_members failed in bufferevent_rate_limit_group_free".

This happened after the following sequence of events:

  1. Tried to connect to google.com using tor to check my mail and got "Tried for 120 seconds to get a connection to [scrubbed]:993. Giving up. (waiting for circuit)" message appearing twice.
  2. After a while I shutdown tor.
  3. The above message appeared.

Please let me know if you need any more info.

Child Tickets

Change History (12)

comment:1 Changed 7 years ago by nickm

Keywords: tor-relay bufferevents added

comment:2 Changed 7 years ago by nickm

I'm assuming this Tor was built with bufferevents; what version of Libevent did you use?

comment:3 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:4 in reply to:  2 ; Changed 7 years ago by mr-4

Don't know about buffevents - how do I check this out? As for libevent - libevent-2.0.20 (built from source).

comment:5 in reply to:  4 ; Changed 7 years ago by nickm

Replying to mr-4:

Don't know about buffevents - how do I check this out?

How did you configure Tor? What are the first few lines it outputs when it starts?

As for libevent - libevent-2.0.20 (built from source).

comment:6 in reply to:  5 Changed 7 years ago by mr-4

Replying to nickm:

How did you configure Tor? What are the first few lines it outputs when it starts?

I finally got it!

Seeing how I compiled tor, the buffevents option is active. Since I am building from source using Fedora's own rpmbuild, the following commands were used to create the tor rpm:

export LDFLAGS='-m%{isa_bits} -Wl,--as-needed,--library-path=%{_libdir}'
%configure --enable-gcc-warnings --disable-asciidoc --enable-gcc-hardening --enable-linker-hardening --enable-bufferevents --disable-nat-pmp --disable-upnp --disable-tor2web-mode --with-tor-user=_dmz_tor --with-tor-group=_dmz_tor
make %{?_smp_mflags}

comment:7 Changed 7 years ago by mr-4

Forgot to add the first lines when tor starts up:

Parsing GEOIP file /home/_dmz_tor/geoip.csv.
Bootstrapped 5%: Connecting to directory server.
Bootstrapped 10%: Finishing handshake with directory server.
We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block.
To correct this, use a version of OpenSSL built with none of its ciphers disabled.

The last 2 messages were caused by me disabling some dubious/undesirable ssl cipher suites in my openssl implementation (I use version 1.01c).

comment:8 Changed 7 years ago by nickm

Okay, the --enable-bufferevents suggests that you are indeed running with the bufferevents networking backend layer. That's still pretty alpha, alas, and it's going to run into bugs. You might want to disable it for now if you want a more stable server. But in either case, let's see if we can figure this one out. I seem to recall that there was a related problem with shutting down connections in the libevent rate-limiting test; that's a good place for us to start debuggign.

comment:9 in reply to:  8 ; Changed 7 years ago by mr-4

Replying to nickm:

That's still pretty alpha, alas, and it's going to run into bugs. You might want to disable it for now if you want a more stable server.

Nope - if I wanted close-to-100% stable server I would have stayed with 2.3.x.

I like this version of tor, not least because of the memory footprint - it seems to be much less than 2.3.x. It also doesn't have the annoying messages I used to keep getting my syslog filled with. There are other reasons for staying with 2.4.x too, not least to help with the testing.

But in either case, let's see if we can figure this one out. I seem to recall that there was a related problem with shutting down connections in the libevent rate-limiting test; that's a good place for us to start debuggign.

I am all for that, though I should make you aware - I am running tor on a RAM-only device where debugging tools are virtually non-existent.

When I prepare the image, it is compressed and locked in as read-only. That image is then uncompressed and loaded into RAM at bootup (my "/" is in RAM). So, after a reboot all changes are, obviously, completely lost.

With all that in mind, I am a willing tester and want to get to the bottom of this bug...

comment:10 in reply to:  9 Changed 7 years ago by nickm

Replying to mr-4:

Replying to nickm:

That's still pretty alpha, alas, and it's going to run into bugs. You might want to disable it for now if you want a more stable server.

Nope - if I wanted close-to-100% stable server I would have stayed with 2.3.x.

I like this version of tor, not least because of the memory footprint - it seems to be much less than 2.3.x. It also doesn't have the annoying messages I used to keep getting my syslog filled with. There are other reasons for staying with 2.4.x too, not least to help with the testing.

To be clear, I was saying that the code you get with --enable-bufferevents is pretty alpha: even more alpha than the rest of 0.2.4.x. But testing it is cool.

comment:11 Changed 7 years ago by mr-4

Yeah, I know. Again though, if I could help with the testing (not just on this bug) I am willing to do so - just let me know.

comment:12 Changed 3 years ago by nickm

Resolution: wontfix
Status: newclosed

The bufferevents code and corresponding build options have been removed in 0.2.9.2-alpha

Note: See TracTickets for help on using tickets.