Hello Alon, ok, after compiling libssl-dev with -DPURIFY qemu fails to start under valgrind: root@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@xxxxxxxxxx>: > > > ----- Original Message ----- >> 2013/2/20 Alon Levy <alevy@xxxxxxxxxx>: >> >> >> 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 >> _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel