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@xxxxxxxxx>: > 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