From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a70US-0001ms-3Q for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:38:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a70UO-0001yU-9k for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:38:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a70UN-0001yM-W0 for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:38:28 -0500 Date: Thu, 10 Dec 2015 12:38:23 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151210123822.GG2570@work-vm> References: <6A17C71B52524C408E7AAF69103E9E490F153F45@fabamailserver.fabagl.fabasoft.com> <20151117113601.GD2498@work-vm> <6A17C71B52524C408E7AAF69103E9E490F15520E@fabamailserver.fabagl.fabasoft.com> <6A17C71B52524C408E7AAF69103E9E490F1552E7@fabamailserver.fabagl.fabasoft.com> <20151117144225.GH2498@work-vm> <6A17C71B52524C408E7AAF69103E9E490F15ECE9@fabamailserver.fabagl.fabasoft.com> <564E00A4.7070207@redhat.com> <6A17C71B52524C408E7AAF69103E9E490F1C71EB@fabamailserver.fabagl.fabasoft.com> <20151203090416.GA2591@work-vm> <6A17C71B52524C408E7AAF69103E9E490F1C771A@fabamailserver.fabagl.fabasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6A17C71B52524C408E7AAF69103E9E490F1C771A@fabamailserver.fabagl.fabasoft.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] WG: [ovirt-users] Segmentation fault in libtcmalloc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Grundmann, Christian" Cc: 'Paolo Bonzini' , "'qemu-devel@nongnu.org'" , "stefanha@redhat.com" * Grundmann, Christian (Christian.Grundmann@fabasoft.com) wrote: > Hi, >=20 > qemu-img-ev-2.3.0-29.1.el7.x86_64 > libvirt-daemon-driver-qemu-1.2.8-16.el7_1.4.x86_64 > qemu-kvm-ev-2.3.0-29.1.el7.x86_64 > qemu-kvm-common-ev-2.3.0-29.1.el7.x86_64 > ipxe-roms-qemu-20130517-7.gitc4bce43.el7.noarch > qemu-kvm-tools-ev-2.3.0-29.1.el7.x86_64 >=20 >=20 > it seems pc-i440fx-rhel7.2.0 is the default for ovirt 3.6=20 >=20 > I tried using only virtio-scsi disk but the VM wont boot (not bootable = device) so i used IDE for the boot disk. I think this seg is actually quite different - although it depends where = the actual corruption happened - looking at the backtrace again the failing thread wasn't the = io thread; it failed in a call from the json parser in the main thread. Dave > a > Thx Christian >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Dr. David Alan Gilbert [mailto:dgilbert@redhat.com]=20 > Gesendet: Donnerstag, 03. Dezember 2015 10:04 > An: Grundmann, Christian > Cc: 'Paolo Bonzini' ; 'qemu-devel@nongnu.org' ; stefanha@redhat.com > Betreff: Re: AW: WG: [ovirt-users] Segmentation fault in libtcmalloc >=20 > * Grundmann, Christian (Christian.Grundmann@fabasoft.com) wrote: > > Hi again, > > got a Segfault today without virtio :-( (one IDE Disk and one=20 > > virtio-scsi) > >=20 > > Core was generated by `/usr/libexec/qemu-kvm -name vmname -S -machine= pc-i440fx-rhel7.2.0,accel=3D'. >=20 > Can you confirm the package version you were using; if you're running t= he pc-i440fx-rhel7.2.0 machine type it must be pretty new. >=20 > Dave >=20 > > Program terminated with signal 11, Segmentation fault. > > #0 0x00007fb299cbd3ab in=20 > > tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::F= r > > eeList*, unsigned long, int) () from /lib64/libtcmalloc.so.4 It looks like it's the main thread in the json parser: > > Thread 1 (Thread 0x7fb29e07cc00 (LWP 29076)): > > #0 0x00007fb299cbd3ab in=20 > > tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::F= reeList*, unsigned long, int) () from /lib64/libtcmalloc.so.4 No symbol t= able info available. > > #1 0x00007fb299cbd47b in=20 > > tcmalloc::ThreadCache::ListTooLong(tcmalloc::ThreadCache::FreeList*, = unsigned long) () from /lib64/libtcmalloc.so.4 No symbol table info avail= able. > > #2 0x00007fb299ccc070 in tc_free () from /lib64/libtcmalloc.so.4 No=20 > > symbol table info available. > > #3 0x00007fb29c58d58f in g_free () from /lib64/libglib-2.0.so.0 No=20 > > symbol table info available. > > #4 0x00007fb29e3b7721 in parser_context_free (ctxt=3D0x7fb2a531e0c0)= at qobject/json-parser.c:358 > > i =3D > > #5 json_parser_parse_err (tokens=3D, ap=3Dap@entry=3D= 0x0, errp=3Derrp@entry=3D0x0) at qobject/json-parser.c:710 > > result =3D 0x7fb2a4bdf600 > > #6 0x00007fb29e3b7767 in json_parser_parse (tokens=3D= ,=20 > > ap=3Dap@entry=3D0x0) at qobject/json-parser.c:694 No locals. > > #7 0x00007fb29e176e04 in handle_qmp_command (parser=3D, tokens=3D) at /usr/src/debug/qemu-2.3.0/monitor.c:5068 > > err =3D > > obj =3D > > input =3D 0x0 > > args =3D 0x0 > > cmd_name =3D > > mon =3D 0x7fb2a153e140 > > #8 0x00007fb29e3b64f2 in json_message_process_token (lexer=3D0x7fb2a= 1460040, token=3D0x7fb2a1424880, type=3DJSON_OPERATOR, x=3D49, y=3D104) a= t qobject/json-streamer.c:87 > > parser =3D 0x7fb2a1460038 > > dict =3D 0x7fb2a3e27200 > > #9 0x00007fb29e3c891f in json_lexer_feed_char (lexer=3Dlexer@entry=3D= 0x7fb2a1460040, ch=3D, flush=3Dflush@entry=3Dfalse) at qob= ject/json-lexer.c:303 > > new_state =3D 100 > > #10 0x00007fb29e3c89ee in json_lexer_feed (lexer=3D0x7fb2a1460040, bu= ffer=3D, size=3D) at qobject/json-lexer.c:3= 56 > > err =3D > > i =3D > > #11 0x00007fb29e3b6689 in json_message_parser_feed (parser=3D > out>, buffer=3D, size=3D) at qobject/js= on-streamer.c:110 No locals. > > #12 0x00007fb29e1758cf in monitor_control_read (opaque=3D, buf=3D, size=3D) at /usr/src/debug/qem= u-2.3.0/monitor.c:5134 > > old_mon =3D 0x0 > > #13 0x00007fb29e2321b0 in qemu_chr_be_write (len=3D,=20 > > buf=3D0x7fff7bea8a30 "}\212\352{\377\177", s=3D0x7fb2a14442e0) at qem= u-char.c:305 No locals. > > #14 tcp_chr_read (chan=3D, cond=3D, opa= que=3D0x7fb2a14442e0) at qemu-char.c:2870 > > chr =3D 0x7fb2a14442e0 > > s =3D 0x7fb2a14363f0 > > buf =3D "}\212\352{\377\177\000\000\360`;\236\262\177\000\000= \030\003\000\000\000\000\000\000\205N;\236\262\177\000\000\240LB\241\262\= 177\000\000\263E;\236\262\177\000\000\240LB\241\262\177", '\000' , "\360\017c\244\262\177\000\000\300\213\352{\377\177\000\000\0= 00\000\000\000\000\000\000\000\060\356t\245\262\177\000\000\000$=E1=A4=B2= \177\000\000@\232\352{\377\177\000\000H\022\212\226\262\177\000\000]\000\= 000\000\000\000\000\000\060\000\000\000\060\000\000\000\220\213\352{\377\= 177\000\000=D0=8A\352{\377\177\000\000\r\000\000\000\000\000\000\000\340\= 234=EE=A4=B2\177\000\000\000d\023\245\262\177\000\000`\376\061\245\262\17= 7\000\000Q\000\000\000\000\000\000\000\325b\004\000\000\000\000\000"... > > len =3D > > size =3D > > #15 0x00007fb29c58799a in g_main_context_dispatch () from=20 > > /lib64/libglib-2.0.so.0 No symbol table info available. > > #16 0x00007fb29e34b288 in glib_pollfds_poll () at main-loop.c:209 > > context =3D 0x7fb2a1491140 > > pfds =3D > > #17 os_host_main_loop_wait (timeout=3D) at main-loop.c= :254 > > ret =3D 2 > > spin_counter =3D 0 > > #18 main_loop_wait (nonblocking=3D) at main-loop.c:503 > > ret =3D 2 > > timeout =3D 4294967295 > > timeout_ns =3D > > #19 0x00007fb29e14aa4e in main_loop () at vl.c:1818 > > nonblocking =3D > > last_io =3D 2 > > #20 main (argc=3D, argv=3D, envp=3D) at vl.c:4394 > > i =3D > > snapshot =3D > > linux_boot =3D > > initrd_filename =3D > > kernel_filename =3D > > kernel_cmdline =3D > > boot_order =3D 0x7fb29e3dda67 "cad" > > boot_once =3D 0x0 > > cyls =3D > > heads =3D > > secs =3D > > translation =3D > > hda_opts =3D > > opts =3D > > machine_opts =3D > > icount_opts =3D > > olist =3D > > optind =3D 78 > > optarg =3D 0x7fb2a14ef8c0 "pc-i440fx-rhel7.2.0" > > loadvm =3D > > machine_class =3D > > cpu_model =3D > > vga_model =3D 0x0 > > qtest_chrdev =3D > > qtest_log =3D > > pid_file =3D > > incoming =3D > > show_vnc_port =3D > > defconfig =3D > > userconfig =3D 111 > > log_mask =3D > > log_file =3D > > mem_trace =3D {malloc =3D 0x7fb29e238480 , = realloc =3D 0x7fb29e238460 , free =3D 0x7fb29e238450 <= free_and_trace>, calloc =3D 0x0, try_malloc =3D 0x0, try_realloc =3D 0x0} > > trace_events =3D > > trace_file =3D > > maxram_size =3D > > ram_slots =3D > > vmstate_dump_file =3D > > main_loop_err =3D 0x0 > > __func__ =3D "main" > >=20 > >=20 > >=20 > >=20 > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] Im Auftrag von=20 > > Paolo Bonzini > > Gesendet: Donnerstag, 19. November 2015 18:02 > > An: Grundmann, Christian ; 'Dr.=20 > > David Alan Gilbert' > > Cc: 'qemu-devel@nongnu.org' ;=20 > > stefanha@redhat.com > > Betreff: Re: WG: [ovirt-users] Segmentation fault in libtcmalloc > >=20 > >=20 > >=20 > > On 19/11/2015 17:00, Grundmann, Christian wrote: > > > Hi, it seems that using virtio-scsi did the trick, But now the VMs=20 > > > are pausing without an coredump, so the underlying Problem (no=20 > > > storage > > > Error) is not fixed, As I am using Snapshots (and so the disks have= =20 > > > to grow very fast) I try if tuning "volume_utilization_percent" and= =20 > > > "volume_utilization_chunk_mb" will help > > > (https://access.redhat.com/solutions/130843) > >=20 > > The fix for virtio-blk is probably this patch: > > http://article.gmane.org/gmane.comp.emulators.qemu.block/6380/raw > >=20 > > Paolo > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK