On 28.06.2012 12:18, Corentin Chary wrote:

Please use "gdb -p <pid>" to attach qemu when stuck and use it to dump a full backtrace. Note that I never tested qemu-kvm and the vnc code was originally not written for it, so the locking stuff may be broken if the codebase differs from upstream qemu too much.

Hi Corentin,

it seems that this issue is not caused by the threaded vnc server. The race condition is also reproducible if the threaded vnc server is deactivated.

Sorry for the noise.

Peter

Le 26 juin 2012 17:02, "Peter Lieven" <p...@dlhnet.de <mailto:p...@dlhnet.de>> a écrit :

    On 13.03.2012 16:06, Alexander Graf wrote:

        On 13.03.2012, at 16:05, Corentin Chary wrote:

            On Tue, Mar 13, 2012 at 12:29 PM, Peter Lieven<p...@dlh.net
            <mailto:p...@dlh.net>>  wrote:

                On 11.02.2012 09:55, Corentin Chary wrote:

                    On Thu, Feb 9, 2012 at 7:08 PM, Peter
                    Lieven<p...@dlh.net <mailto:p...@dlh.net>>   wrote:

                        Hi,

                        is anyone aware if there are still problems
                        when enabling the threaded
                        vnc
                        server?
                        I saw some VMs crashing when using a qemu-kvm
                        build with
                        --enable-vnc-thread.

                        qemu-kvm-1.0[22646]: segfault at 0 ip
                        00007fec1ca7ea0b sp
                        00007fec19d056d0
                        error 6 in libz.so.1.2.3.3[7fec1ca75000+16000]
                        qemu-kvm-1.0[26056]: segfault at 7f06d8d6e010
                        ip 00007f06e0a30d71 sp
                        00007f06df035748 error 6 in libc-2.11.1.so
                        <http://libc-2.11.1.so>[7f06e09aa000+17a000]

                        I had no time to debug further. It seems to
                        happen shortly after
                        migrating,
                        but thats uncertain. At least the segfault in
                        libz seems to
                        give a hint to VNC since I cannot image of any
                        other part of qemu-kvm
                        using
                        libz except for VNC server.

                        Thanks,
                        Peter


                    Hi Peter,
                    I found two patches on my git tree that I sent
                    long ago but somehow
                    get lost on the mailing list. I rebased the tree
                    but did not have the
                    time (yet) to test them.
                    
http://git.iksaif.net/?p=qemu.git;a=shortlog;h=refs/heads/wip
                    Feel free to try them. If QEMU segfault again,
                    please send a full gdb
                    backtrace / valgrind trace / way to reproduce :).
                    Thanks,

                I have seen no more crashes with these to patches
                applied. I would suggest
                it would be good to push them to the master repository.

                Thank you,
                Peter

            Ccing Alexander,

        Ah, cool. Corentin, I think you're right now the closest thing
        we have to a maintainer for VNC. Could you please just send
        out a pull request for those?

    hi all,

    i suspect there is still a problem with the threaded vnc server.
    its just a guess, but we saw a resonable number of vms hanging in the
    last weeks. hanging meaning the emulation is stopped and the
    qemu-kvm process does no longer react, not on monitor, not on vnc,
    not on qmp.
    why i suspect the threaded vnc server is that in all cases we have
    analyzed this happened with an open vnc session and only on nodes
    with the threaded vnc server
    enabled. it might also be the case that this happens at a
    resolution change. is there anything known or has someone an idea?

    we are running qemu-kvm 1.0.1 with

     vnc: don't mess up with iohandlers in the vnc thread

     vnc: Limit r/w access to size of allocated memory

    compiled in.

    unfortunately, i was not yet able to reproduce this with a
    debugger attached.

    thanks,
    peter


        Alex



Reply via email to