[GNUnet-developers] testing gnunet-0.5.0

[Jan Marco Alkema]

Hello Igor,

Both mine two Linux servers got a segmentation error. Shame on me I haven't
run gnunetd with gdb. After restarting I got an other segmentation error,
because the segmentation error before doesn't close the "gnunet database"
properly (I believe). Throwing away the gnunet var directory helped
restarting gnunetd. See Appendix for the details.

The other problem is running out of RAM memory of gnunet-download (65 Mb)
when I download a big file. If you use "udp tcp" the break will be earlier
then if you use "udp" protocol only.

If someone want to test this at his server: Try to download:

./gnunet-download -o "nationaletelefoongids2003.ZIP" --
6A2CFAB7960CAA22775D9D77E93113FC3F9AD108
959367363E388A7E080E8E74E4DC789D1FB9DA93 8E53F1A1 499259096

Igor, I rebooted the server (I tested this two times), after I

gdb ./gnunetd

run -d -L DEBUG

I see in the top menu that I have 2 zombie processes? How can I get rid of
the zombie processes? Recompiling the source code for instance, etc.?

  5:28pm  up 22 min,  4 users,  load average: 1.04, 1.39, 1.17
65 processes: 60 sleeping, 3 running, 2 zombie, 0 stopped
CPU states: 45.5% user, 50.7% system,  0.0% nice,  3.6% idle
Mem:    62108K av,   61456K used,     652K free,       0K shrd,     376K
buff
Swap:  192740K av,   83132K used,  109608K free                   54100K
cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1094 root      25   0  3912 1240   976 R    65.0  1.9   8:51 gnunetd
  903 root      22   0  3912 1240   976 S    27.3  1.9   2:45 gnunetd
 1154 root      16   0   668  620   460 R     3.6  0.9   0:27 top
  751 root      15   0   896  668   576 R     0.1  1.0   0:03 sshd
  784 root      15   0   860  580   512 S     0.1  0.9   0:01 sshd
    1 root      15   0   340  304   284 S     0.0  0.4   0:05 init
    2 root      15   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    4 root      15   0     0    0     0 SW    0.0  0.0   0:15 kswapd
    5 root      25   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    6 root      15   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    7 root      25   0     0    0     0 SW    0.0  0.0   0:00 mdrecoveryd
   11 root      15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
  134 root      15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
address@hidden bin]#


># currently connected nodes : 4
I see at this moment on the gnunet 0.5.0 network only 4 other gnunet
servers! One of these servers belongs to me.

I hope that more gnunet-developers put a gnunetd active on the Internet. In
mine opinion it is very useful to let a gnunetd demon (running in gdb) in
background of your (Linux) computer. We can find faster the (segmentation)
bugs in gnunet-0.5.0 distribution ---) N.B. If you find a segmentation error
make a trace like Appendix A and report it to Christian/Igor.

Greetings Jan Marco

Appendix A: Segmentation error:

Dec 26 19:37:13 DEBUG: sending message of 1112 bytes to UDP 65.80.89.29:2086
Dec 26 19:37:13 DEBUG: received 1112 bytes via UDP from 217.215.37.227:2086
(21AD0369583BE242309D5EC27E4257678ADF5C70)
Dec 26 19:37:13 DEBUG: verified UDP helo from 193.10.67.118:2086
Dec 26 19:37:13 INFO: HELO advertisement for protocol 17 received
Dec 26 19:37:13 INFO: binding address of node
21AD0369583BE242309D5EC27E4257678ADF5C70.17
Dec 26 19:37:13 DEBUG: Received sessionkey from host
21AD0369583BE242309D5EC27E4257678ADF5C70.
Dec 26 19:37:13 DEBUG: scanning directory /usr/local/gnunet/var/data/hosts/
for peer identity
Dec 26 19:37:14 WARNING: SKEY rejected from host
21AD0369583BE242309D5EC27E4257678ADF5C70
Dec 26 19:37:16 DEBUG: core calls disconnect on tsession 1198003512
Dec 26 19:37:17 DEBUG: core calls disconnect on tsession 1131566536
Dec 26 19:37:23 DEBUG: core calls disconnect on tsession 1165850688

Segmentation fault

Reporting a segfault:
If any GNUnet application reproducably segfaults, please try getting a stack
trace. Use gdb bin/gnunet-application-name and then at the (gdb) prompt use
run APPLICATION-ARGUMENTS to start the application with the GNU debugger.
Once the segfault occurs, you will get the (gdb) prompt again. Now type ba
to get the stacktrace. Attach the output to the bugreport.

address@hidden bin]# gdb ./gnunetd

GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...

(gdb) run -d -L DEBUG

Starting program: /usr/local/gnunet/bin/gnunetd -d -L DEBUG
[New Thread 8192 (LWP 23429)]
Dec 27 01:23:45 DEBUG: in initStatusCalls
Dec 27 01:23:45 DEBUG: obtaining local IP address from hostname
62.131.97.197
Dec 27 01:23:45 MESSAGE: gnunetd starting
[New Thread 16385 (LWP 23436)]
[New Thread 8194 (LWP 23437)]

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 8192 (LWP 23429)]
0x42073fe0 in _int_free () from /lib/i686/libc.so.6

(gdb) backtrace

#0  0x42073fe0 in _int_free () from /lib/i686/libc.so.6
#1  0x42074a2c in free () from /lib/i686/libc.so.6
#2  0x420aa15f in closedir () from /lib/i686/libc.so.6
#3  0x4001b0e6 in scanDirectory (dirName=0xc5b91990 <Address 0xc5b91990 out
of bounds>, callback=0x804dacc <cronHelper>,
    data=0x0) at storage.c:339
#4  0x0804dbcb in cronScanDirectoryDataHosts (unused=0x0) at
knownhosts.c:605
#5  0x0804ceef in initKnownhosts () at knownhosts.c:139
#6  0x0804a2fa in main (argc=4, argv=0xbffffb04) at gnunetd.c:93
#7  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

(gdb) info threads

  3 Thread 8194 (LWP 23437)  0x420daa02 in accept () from
/lib/i686/libc.so.6
  2 Thread 16385 (LWP 23436)  0x420d224b in poll () from /lib/i686/libc.so.6
* 1 Thread 8192 (LWP 23429)  0x42073fe0 in _int_free () from
/lib/i686/libc.so.6

(gdb) thread 1

[Switching to thread 1 (Thread 8192 (LWP 23429))]#0  0x42073fe0 in _int_free
() from /lib/i686/libc.so.6

(gdb) ba

#0  0x42073fe0 in _int_free () from /lib/i686/libc.so.6
#1  0x42074a2c in free () from /lib/i686/libc.so.6
#2  0x420aa15f in closedir () from /lib/i686/libc.so.6
#3  0x4001b0e6 in scanDirectory (dirName=0xc5b91990 <Address 0xc5b91990 out
of bounds>, callback=0x804dacc <cronHelper>,
    data=0x0) at storage.c:339
#4  0x0804dbcb in cronScanDirectoryDataHosts (unused=0x0) at
knownhosts.c:605
#5  0x0804ceef in initKnownhosts () at knownhosts.c:139
#6  0x0804a2fa in main (argc=4, argv=0xbffffb04) at gnunetd.c:93
#7  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

(gdb) thread 2

[Switching to thread 2 (Thread 16385 (LWP 23436))]#0  0x420d224b in poll ()
from /lib/i686/libc.so.6

(gdb) ba

#0  0x420d224b in poll () from /lib/i686/libc.so.6
#1  0x40072d9e in __pthread_manager () from /lib/i686/libpthread.so.0
#2  0x40072feb in __pthread_manager_event () from /lib/i686/libpthread.so.0

(gdb) thread 3

[Switching to thread 3 (Thread 8194 (LWP 23437))]#0  0x420daa02 in accept ()
from /lib/i686/libc.so.6

(gdb) ba

#0  0x420daa02 in accept () from /lib/i686/libc.so.6
#1  0x40077d43 in accept () from /lib/i686/libpthread.so.0
#2  0x0804af66 in tcpListenMain () at tcpserver.c:281
#3  0x40073941 in pthread_start_thread () from /lib/i686/libpthread.so.0
#4  0x40073a45 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0

(gdb)