Bug 848667 - -m 4096 crashes under valgrind
-m 4096 crashes under valgrind
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.3
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Markus Armbruster
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-16 03:35 EDT by yunpingzheng
Modified: 2014-03-03 19:13 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-26 20:59:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description yunpingzheng 2012-08-16 03:35:43 EDT
Description of problem:
 see: bug https://bugzilla.redhat.com/show_bug.cgi?id=750739

when we use "qemu-kvm -m 4096", the programe will  hang after cont.
several minutes will Segmentation fault(core dump).
if use -m < 4096(like "-m 1024"), it works normally.

Version-Release number of selected component (if applicable):

How reproducible:
100%

Steps to Reproduce:
1.download valgrind-3.8.0.tar.bz2 form valgrind download page: www.valgrind.org.
2.install the valgrind.
3.run # valgrind /usr/libexec/qemu-kvm --nodefaults --no-kvm -vnc :0 -S -m 4096 -monitor stdio
4.check the vm status using monitor command
(qemu) info status
5.cont the vm
(qemu) c
6. program hang,several minutes will 
  
Actual results:

stdio==8260== Memcheck, a memory error detector
==8260== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==8260== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==8260== Command: qemu-kvm -nodefaults -m 4096 -vnc :0 -no-kvm -S -monitor stdio
==8260== 
==8260== Warning: set address range perms: large range [0x394d6000, 0x6b4d6000) (defined)
==8260== Warning: set address range perms: large range [0x6b4d6040, 0x9d4d6040) (undefined)
==8260== Warning: set address range perms: large range [0x9d4d8000, 0x19d4d8000) (undefined)
QEMU 0.12.1 monitor - type 'help' for more information
(qemu) 
(qemu) info status
VM status: paused (prelaunch)
(qemu) c
(qemu) ==8260== Invalid read of size 8
==8260==    at 0x21CE68: tb_link_phys (exec.c:1126)
==8260==    by 0x21D27C: tb_gen_code (exec.c:914)
==8260==    by 0x220166: cpu_x86_exec (cpu-exec.c:168)
==8260==    by 0x16CEDA: main (vl.c:4061)
==8260==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8260== 
==8260== 
==8260== Process terminating with default action of signal 11 (SIGSEGV)
==8260==  Access not within mapped region at address 0x0
==8260==    at 0x21CE68: tb_link_phys (exec.c:1126)
==8260==    by 0x21D27C: tb_gen_code (exec.c:914)
==8260==    by 0x220166: cpu_x86_exec (cpu-exec.c:168)
==8260==    by 0x16CEDA: main (vl.c:4061)
==8260==  If you believe this happened as a result of a stack
==8260==  overflow in your program's main thread (unlikely but
==8260==  possible), you can try to increase the size of the
==8260==  main thread stack using the --main-stacksize= flag.
==8260==  The main thread stack size used in this run was 10485760.
==8260== 
==8260== HEAP SUMMARY:
==8260==     in use at exit: 5,155,215,436 bytes in 1,830 blocks
==8260==   total heap usage: 3,108 allocs, 1,278 frees, 5,157,690,287 bytes allocated
==8260== 
==8260== LEAK SUMMARY:
==8260==    definitely lost: 16 bytes in 2 blocks
==8260==    indirectly lost: 0 bytes in 0 blocks
==8260==      possibly lost: 0 bytes in 0 blocks
==8260==    still reachable: 5,155,215,420 bytes in 1,828 blocks
==8260==         suppressed: 0 bytes in 0 blocks
==8260== Rerun with --leak-check=full to see details of leaked memory
==8260== 
==8260== For counts of detected and suppressed errors, rerun with: -v
==8260== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 27 from 7)

the programe hang there

several minutes will core dump

Segmentation fault (core dumped)

Expected results:


Additional info:
host: 
kernel:kernel-2.6.32-296.el6.x86_64
qemu-kvm:qemu-kvm-rhev-0.12.1.2-2.302.el6.x86_64
valgind: 3.8.0
Comment 2 Markus Armbruster 2012-09-07 07:52:02 EDT
Bug summary is jumping to conclusions, fixing.
Comment 3 Markus Armbruster 2012-09-07 07:52:45 EDT
Can you reproduce with --enable-kvm instead of --no-kvm?
Comment 4 yunpingzheng 2012-09-09 23:04:22 EDT
when using  --enable-kvm, can not reproduce this issue.
Comment 5 Ademar Reis 2012-09-26 20:59:42 EDT
Closing as wontfix because it's not reproduced with --enable-kvm.

Note You need to log in before you can comment on or make changes to this bug.