Bug: buffers.c:1688: assert_buf_ok: Assertion ch->data >= &ch->mem[0] failed

[Nick Mathewson]

On Fri, Apr 18, 2008 at 07:33:32AM +0200, Fabian Keil wrote:
> A few days ago one of my servers triggered:
> 
> Apr 10 17:07:45.728 [notice] Tor 0.2.0.23-rc (r14173) opening log file.
> Apr 10 17:07:46.005 [warn] I have no descriptor for the router named "zwiebelkuchen" in my declared family; I'll use the nickname as is, but this may confuse clients.
> Apr 10 17:07:46.005 [warn] I have no descriptor for the router named "zwiebelsuppe" in my declared family; I'll use the nickname as is, but this may confuse clients.
> Apr 10 17:07:46.052 [notice] Your Tor server's identity key fingerprint is 'SlickLittleGirl AD35 6EF8 E87A 89E6 C898 B745 00D5 8607 AC69 1178'
> Apr 10 17:07:53.825 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent network-status consensus.
> Apr 10 17:07:54.190 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
> Apr 10 17:08:09.066 [notice] We now have enough directory information to build circuits.
> Apr 10 17:08:11.621 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
> Apr 10 17:08:18.088 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
> Apr 10 17:08:18.375 [notice] Performing bandwidth self-test...done.
> Apr 11 12:25:25.848 [err] Bug: buffers.c:1688: assert_buf_ok: Assertion ch->data >= &ch->mem[0] failed; aborting.
> 
> Unfortunately it doesn't look like a core dump has been created.

Hm. Unfortunately, this looks like one we're not going to be able to
trace down without at least a stack trace.  If you like, you can
submit it to the bugtracker so we don't forget about it.