panic: already on hash list

[YONETANI Tomokazu]

On Wed, Jul 23, 2008 at 09:04:02PM +0800, Sepherosa Ziehau wrote:
> On Tue, Jul 22, 2008 at 8:28 PM, YONETANI Tomokazu <qhwt+dfly at les.ath.cx> wrote:
> > Hi.
> > Caught this panic while playing with my build box.  I don't know the exact
> > moment when it panicked, as the monitor was connected to another box, but
> > here's what I was doing before the panic anyway:
> >
> > - login to the build box from the console, and slogin to the router box
> >  (running DragonFly 1.8), and rebooted it.
> > - switch the monitor/keyboard to the router box, wait for it to boot,
> >  and login to the console.  slogin to the build machine, start GNU screen,
> >  start w3m (a text-based web browser, similar to lynx), tried to visit
> >  Google but it didn't work (this was expected, because for some reason mpd
> >  starts up earlier than ipnat and I always have to restart before I can
> >  connect to the Internet from behind the router).
> > - split the screen inside GNU screen, and typed ctrl+C on w3m.  A few seconds
> 
> I think this ctrl+C is important to the problem :)

Maybe, or maybe not.  I wasn't looking at the panicked machine's console
at that time, so I'm not sure if it was ctrl+C that triggered the panic,
or it was already dumping the kernel memory when I hit ctrl+C.  Or it
could be SIGWINCH which triggered it.  In any case, the panic is not
easy to reproduce.  I also saw a complete lock up (no ctrl+alt+esc) when
I slogin'ed to this machine yesterday, but I'm not sure if it's related
to this problem at all.

> One thing I need you to help confirm is that does w3m put the socket
> into nonblock mode?  I didn't seem to be able to download w3m source
> code.

I took a quick look at source code, and it seemed it didn't.
In case you can't find it elsewhere, here's the one:
  http://122.249.219.233/distfiles/w3m-0.5.2.tar.gz

> I think it may be caused by following pattern of user code:
> 
> s = socket();
> /* s is not put into nonblock mode */
> while (1) {
>   if (connect(s) < 0) {  <==== here you hit ctrl+C
>     if (errno == EINTR)
>       continue; <==== another connect(2) attempt on 's'
>     ...
>   }
>   ...
> }
> 
> We probably could create a much simpler test program by using the
> above code pattern to reproduce the panic ...

If I run above code and hit ctrl+C, the program terminates.  If I change
it to mask SIGINT, it ignores ctrl+C until connection times out, and in the
following iterations connect() fails immediately.  Hmm...

Thanks.