I think I fixed it (SVN HEAD). It's a bit strange that this could happen -- what was going on was that gnunetd was queueing more than 60 MB of content (in, presumably, chunks of about 32k) for some client (gnunet-download or gnunet-gtk) and the client just did not read the data (at least not fast enough). I've now changed the code to block (wait for the client) instead of buffering (and then hitting the buffer-size threshold, which is where it died).
Naturally, this raises the question whether there was a problem with the client (deadlocked, unusually slow) or if this was just really a scheduling issue (no CPU for client, tons of results received quickly by gnunetd). Anyway, the specific crash should be fixed now. Christian On Sunday 15 July 2007 04:57, David Kuehling wrote: > Hi, > > gnunetd 0.7.2a crashed on me. Luckily it ran from inside GDB so > captured some data. > > Jul 14 14:45:31 FATAL: Internal error: assertion failed at select.c:1034 > in select_write. > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1215173712 (LWP 12354)] > 0xb7d6e947 in raise () from /lib/tls/libc.so.6 > > backtrace and thread info attached. > > regards, > > David _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
