Re: [Help-gnunet] [BUG] Internal error: assertion failed

[David Kuehling]

>>>>> "Christian" == Christian Grothoff <address@hidden> writes:

> 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).  

GDB and gnunet is still left in the crashed state (running inside the
'screen' tool), so I just checked memory allocated by gnunetd ("RES"
column shown by 'top') and it shows only 27MB.

What I did before the crash was direct insertion of content
(gnunet-insert -n) with some 100 mb of data and some parallel downloads
of data I found by random queries.  Download ran into data that was
already locally cached (migrated to my node?) so I encountered unusually
high download rates (> 30KB/sec)

some more info obtained from GDB, in select_write:

(gdb) print *sh
$4 = {description = 0xb7fb1c30 "tcpserver", lock = 0x80549a8, 
  thread = 0x80510a0, listen_sock = 0x8054910, ectx = 0x804edf8, 
  load_monitor = 0x0, sessions = 0xaf10e2a8, 
  mh = 0xb7faf9c5 <select_message_handler>, 
  ah = 0xb7fb0173 <select_accept_handler>, 
  ch = 0xb7faf947 <select_close_handler>, mh_cls = 0x0, ah_cls = 0x0, 
  ch_cls = 0x0, timeout = 0, signal_pipe = {10, 11}, is_udp = 0, 
  sessionCount = 7, sessionArrayLength = 14, shutdown = 0, max_addr_len
= 16, 
  memory_quota = 0, socket_quota = 249}

(gdb) print *session
$5 = {sock = 0x8170640, sock_ctx = 0x814a5c8, rbuff = 0x817aa50 "", 
  wbuff = 0xab30b008 "<snip>", 
  lastUse = 1184417128612, timeout = 0, locked = 1, pos = 264, rsize =
1024, 
  wspos = 0, wapos = 33511452, wsize = 33521664}

(gdb) print *sock
$12 = {mon = 0x0, ectx = 0x804edf8, handle = 48, checksum = -48}

(gdb) print *msg
$13 = {size = 5248, type = 2304}

> 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.

keep up the good work :)

regards,

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40