[Spice-devel] spice crashes

Thu Feb 21 02:43:27 PST 2013

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
>>