2009/2/27 Anthony Liguori <aliguori@xxxxxxxxxx>: > 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". Cheers -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
