[tor-bugs] #7091 [Tor]: Assertion 0 == g->n_members failed error (from libevent)
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Wed Oct 17 18:54:10 UTC 2012
#7091: Assertion 0 == g->n_members failed error (from libevent)
------------------------------------+---------------------------------------
Reporter: mr-4 | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: unspecified
Component: Tor | Version: Tor: 0.2.4.3-alpha
Keywords: tor-relay bufferevents | Parent:
Points: | Actualpoints:
------------------------------------+---------------------------------------
Comment(by mr-4):
Replying to [comment:8 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...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7091#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list