[pecquetj_at_jpe45305.homeunix.org: kern/58581: System call hang 5.x triggered by gnunetd]

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Thu, 30 Oct 2003 01:21:09 -0800
Is anyone else able to reproduce this?

----- Forwarded message from pecquetj <pecquetj_at_jpe45305.homeunix.org> -----

>Number:         58581
>Category:       kern
>Synopsis:       System call hang 5.x triggered by gnunetd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Oct 26 14:40:17 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     pecquetj
>Release:        FreeBSD 5.1 CURRENT i386
>Organization:
>Environment:
System: FreeBSD gnunet.woh.rr.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 11:49:08 EST 2003     root_at_gnunet.woh.rr.com:/usr/src/sys/i386/compile/GNUNET  i386


	
The system is an STB1030 (mediagx) running 5.1-CURRENT downloaded including libs and buildworled from cvs
>Description:
	
When running GNUnet after some random time it stops responding.  TOP indicates 100% system time utilization (0% user).  ktrace stops outputting at this point.  The last part of the ktrace dump is:
  5863 gnunetd  RET   read 1116/0x45c
  5863 gnunetd  CALL  gettimeofday(0xbfad64a8,0xbfad64b0)
  5863 gnunetd  RET   gettimeofday 0
  5863 gnunetd  CALL  break(0xd24c000)
  5863 gnunetd  RET   break 0
  5863 gnunetd  PSIG  SIGPROF caught handler=0x281e0ac0 mask=0x0 code=0x0
  5863 gnunetd  CALL  gettimeofday(0x281f1b18,0)
  5863 gnunetd  RET   gettimeofday 0
No further ktrace information is logged once this happens.
Compiling with INVARIENTS and WITNESS did not change this behavior or result in any logged errors.  gnunetd appears to be unable to respond to any signals except -9 at this point.
I attempted multiple updates of 5.1, starting from RELEASE through three updates of CURRENT with no change in behaviour.  If the system uses the TSC for the clock, the clock will stop when the above event occurs (i.e. the time in the upper right corner of top does not change, and date returns the same time over and over.)  Using i8254 for the clock seems to avoid this side effect, as the clock seems to be unaffected.  Attempting truss on gnunetd gives large numbers of WITNESS warnings that do not appear to be directly related to the problem:
Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held:
Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked _at_ /usr/src/sys/kern/subr_trap.c:260
Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held:
Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked _at_ /usr/src/sys/kern/subr_trap.c:260
Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held:
Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked _at_ /usr/src/sys/kern/subr_trap.c:260
Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held:
Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked _at_ /usr/src/sys/kern/subr_trap.c:260
>How-To-Repeat:
	
install /usr/ports/net/gnunet
create user for running gnunetd (say: gnucli)
su - gnucli
mkdir .gnunet
cp /usr/ports/net/gnunet/work/GNUnet-0.6.0/contrib/gnunet.conf ~/.gnunet
run gnunetd
use truss or ktrace if you feel like it
wait a while
it _always_ hangs as described above.
it sometimes hangs faster if you attempt to insert into the node:
gnunet-insert filename
>Fix:

	
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe_at_freebsd.org"

----- End forwarded message -----
Received on Thu Oct 30 2003 - 00:21:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:27 UTC