[Spice-devel] spice crashes

Thu Feb 21 03:00:38 PST 2013

Hello Alon,

forget my last mail, it was just noise. I had an error in my conf.

Best regards,
TF

2013/2/21 Trebor Forban <trebor.forban at gmail.com>:
> Hello Alon,
>
> ok, after compiling libssl-dev with -DPURIFY qemu fails to start under valgrind:
>
> root at thfs1:~# less qemu-1.4.0-system-x86_64_valgrind-2013-02-21-11-12.log
> ==5726== Memcheck, a memory error detector
> ==5726== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==5726== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==5726== Command: /usr/bin/qemu-system-x86_64 -name
> master99,process=master99 -cpu qemu64 -rtc base=localtime -enable-kvm
> -runas master -smp 1/e
> ==5726== Parent PID: 5724
> ==5726==
> ==5726== Warning: noted but unhandled ioctl 0xae00 with no size/direction hints
> ==5726==    This could cause spurious value errors to appear.
> ==5726==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
> writing a proper wrapper.
> ==5726== Warning: noted but unhandled ioctl 0xae03 with no size/direction hints
> ==5726==    This could cause spurious value errors to appear.
> ==5726==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
> writing a proper wrapper.
> ==5726== Warning: noted but unhandled ioctl 0xae01 with no size/direction hints
> ==5726==    This could cause spurious value errors to appear.
> ==5726==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
> writing a proper wrapper.
> ==5726== Warning: client switching stacks?  SP change: 0x7feffc8f8 --> 0x9e88d98
> ==5726==          to suppress, use: --max-stackframe=34176711520 or greater
> ==5726== Warning: client switching stacks?  SP change: 0x9e88d28 --> 0x7feffc900
> ==5726==          to suppress, use: --max-stackframe=34176711640 or greater
> ==5726== Warning: client switching stacks?  SP change: 0x7feffd0e8 --> 0x9e88d60
> ==5726==          to suppress, use: --max-stackframe=34176713608 or greater
> ==5726==          further instances of this message will not be shown.
> ==5726== Warning: set address range perms: large range [0x395a6000,
> 0xb95a6000) (undefined)
> ==5726== Syscall param ioctl(generic) points to uninitialised byte(s)
> ==5726==    at 0x7AB8537: ioctl (syscall-template.S:82)
> ==5726==    by 0x34DA38: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==    by 0x3807B1: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==    by 0x382659: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==    by 0x34C3E6: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==    by 0x2F96B9: ??? (in /usr/local/bin/qemu-system-x86_64)
>
> 8<--------------------------------------------------------------------------------------------------------------------------------------------
>    ...
> 8<--------------------------------------------------------------------------------------------------------------------------------------------
>
> ==5726==    at 0x1A4185: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==
> ==5726== Conditional jump or move depends on uninitialised value(s)
> ==5726==    at 0x1A5459: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==
> ==5726== Conditional jump or move depends on uninitialised value(s)
> ==5726==    at 0x1A5148: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==
> ==5726== Conditional jump or move depends on uninitialised value(s)
> ==5726==    at 0x1A519C: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==
> ==5726== Conditional jump or move depends on uninitialised value(s)
> ==5726==    at 0x1A5377: ??? (in /usr/local/bin/qemu-system-x86_64)
> ==5726==
> ==5726==
> ==5726== More than 10000000 total errors detected.  I'm not reporting any more.
> ==5726== Final error counts will be inaccurate.  Go fix your program!
> ==5726== Rerun with --error-limit=no to disable this cutoff.  Note
> ==5726== that errors may occur in your program without prior warning from
> ==5726== Valgrind, because errors are no longer being displayed.
> ==5726==
> ==5726==
> ==5726== HEAP SUMMARY:
> ==5726==     in use at exit: 2,448,921,632 bytes in 6,670 blocks
> ==5726==   total heap usage: 348,986 allocs, 342,316 frees,
> 2,897,944,349 bytes allocated
> ==5726==
> ==5726== LEAK SUMMARY:
> ==5726==    definitely lost: 1,193 bytes in 23 blocks
> ==5726==    indirectly lost: 896 bytes in 42 blocks
> ==5726==      possibly lost: 29,016 bytes in 29 blocks
> ==5726==    still reachable: 2,448,890,527 bytes in 6,576 blocks
> ==5726==         suppressed: 0 bytes in 0 blocks
> ==5726== Rerun with --leak-check=full to see details of leaked memory
> ==5726==
> ==5726== For counts of detected and suppressed errors, rerun with: -v
> ==5726== Use --track-origins=yes to see where uninitialised values come from
> ==5726== ERROR SUMMARY: 10000000 errors from 383 contexts (suppressed: 2 from 2)
> ==5726== could not unlink /tmp/vgdb-pipe-from-vgdb-to-5726-by-root-on-???
> ==5726== could not unlink /tmp/vgdb-pipe-to-vgdb-from-5726-by-root-on-???
> ==5726== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-5726-by-root-on-???
>
> Am I doing something wrong?; any further ideals?
>
> Best Regards,
> TF
>
>
> 2013/2/21 Alon Levy <alevy at redhat.com>:
>>
>>
>> ----- Original Message -----
>>> 2013/2/20 Alon Levy <alevy at redhat.com>:
>>>
>>> >> I haven't recompiled with debugging for the stack trace yet; is it
>>> >> still necessary, or does the information above suffice?
>>> >
>>> > Sorry for dropping the ball on this. I'm afraid it's hard to debug
>>> > even with this information. If you could run the vm under valgrind
>>> > (you need to have a valgrind that has randomization disabled - see
>>> > http://spice-space.org/wiki/index.php?title=Valgrind) it would
>>> > perhaps point to the culprit. Stack trace would help too, but it
>>> > won't point to the problem assuming it is memory corruption.
>>>
>>> Hi Alon,
>>>
>>> when trying to use valgrind I'm getting "Syscall param ioctl(generic)
>>> points to uninitialised byte(s)", so I guess, if I understand
>>> correctly, I need to compile libssl with -DPURIFY, or is there a flag
>>> I can use when compiling valgrind? I would rather not experiment too
>>
>> You are correct, I was mistaken - recompile libssl, not valgrind.
>>
>>> much, as the machine is serving approximately 40 VMs in production
>>> use. I'm a bloody beginner; if you can provide me with more explicit
>>> instructions, so that I don't risk overwriting original libs and
>>> messing up the system, I'd be more than willing to give it a try.
>>
>> After recompiling, assuming the lib is under /tmp/purify/libssl.so.X then you could do
>> LD_LIBRARY_PATH=/tmp/purify valgrind qemu ...
>>
>>>
>>> Under non-debugging circumstances, the crashes can be provoked quite
>>> easily, by overzealous use of the delete-key in msword or outlook.
>>> When running under valgrind albeit without randomization disabled, I
>>> cannot provoke the crashes; I'm guessing, it may be a race condition
>>> that fails to trigger under the substantial slowdown caused by the
>>> debugging.
>>
>> That's too bad. So a backtrace could still be useful. You can also enable more debugging at the server level which might point to the faulting command by adding the following to the command line:
>>
>> -global qxl-vga.cmdlog=1
>>
>>>
>>> regards and thanks,
>>> TF
>>>