Re: [Qemu-devel] Re: [PATCH] Fix freezing bug in curses console

[Anthony Liguori]

andrzej zaborowski wrote:
> 2009/2/27 Anthony Liguori <address@hidden>:
>   
> > Matthew Bloch wrote:
> >     
> > > Hi there,
> > >
> > > We are running lots of kvm processes in screen and found that about 1 in
> > > 5 froze shortly after startup startup with a backtrace like this one:
> > >
> > > #0  0xf7c7fcd9 in pthread_exit () from /lib/tls/libc.so.6
> > > #1  0xf7cfbe62 in wresize () from /lib/libncurses.so.5
> > > #2  0xf7cfb7ab in is_term_resized () from /lib/libncurses.so.5
> > > #3  0xf7cfb877 in is_term_resized () from /lib/libncurses.so.5
> > > #4  0xf7cfba31 in resize_term () from /lib/libncurses.so.5
> > > #5  0x080d3dd9 in vga_init ()
> > > #6  <signal handler called>
> > > #7  0xf7c0da5b in free () from /lib/tls/libc.so.6
> > > #8  0xf7c0effe in calloc () from /lib/tls/libc.so.6
> > > #9  0xf7cf222e in newpad () from /lib/libncurses.so.5
> > > #10 0x080d3549 in vga_init ()
> > >
> > > We're just using the lenny version of kvm from 2008-12-16.
> > >
> > > On casual inspection, the SIGWINCH signal handling looked ropey to me -
> > > grandpa always told me not to do any real work in a signal handler, and
> > > the backtrace suggested re-entrancy problems in curses, so I changed the
> > > behaviour to set a flag and do the work in the main loop instead.  Maybe
> > > I'm reading the backtrace wrong.
> > >
> > > So far that means that when you resize the window, the display is
> > > corrupt until the VM outputs some text, or the user hits a key.  But I
> > > think it has solved the freezing / crashing bug too - would appreciate
> > > any comments on my analysis or proposed solution.
> > >
> > >       
> > It's racy with select().  A better fix would be to create a pipe and write
> > to that pipe in the SIGWINCH handler.  You should then register an io
> > callback using qemu_set_fd_handler2() that does the actions for SIGWINCH.
> >     
>
> Maybe a bottom half would work?  The scheduling of a bh shouldn't
> constitute "real work".
>   

I think it still suffers from the same race condition so today it 
wouldn't work.  You could fix the bottom half scheduling though so that 
you could safely schedule a bottom half from a signal handler (using 
roughly the same trick).

Regards,

Anthony Liguori

> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>