summary refs log tree commit diff stats
path: root/results/classifier/118/all/1332297
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/all/1332297')
-rw-r--r--results/classifier/118/all/1332297195
1 files changed, 195 insertions, 0 deletions
diff --git a/results/classifier/118/all/1332297 b/results/classifier/118/all/1332297
new file mode 100644
index 000000000..f32db5656
--- /dev/null
+++ b/results/classifier/118/all/1332297
@@ -0,0 +1,195 @@
+permissions: 0.966
+architecture: 0.953
+graphic: 0.951
+register: 0.949
+assembly: 0.943
+debug: 0.936
+PID: 0.933
+device: 0.932
+boot: 0.929
+semantic: 0.927
+arm: 0.925
+performance: 0.918
+kernel: 0.910
+files: 0.907
+ppc: 0.907
+user-level: 0.900
+KVM: 0.897
+virtual: 0.896
+socket: 0.896
+risc-v: 0.889
+hypervisor: 0.885
+mistranslation: 0.885
+peripherals: 0.877
+vnc: 0.873
+TCG: 0.861
+VMM: 0.854
+x86: 0.852
+network: 0.848
+i386: 0.658
+
+qemu-img: crash on check of an image with large value in the 'size' header field 
+
+The qemu-img crashes on the next command:
+
+qemu-img check test_image
+
+'test_image' can be found in the attachment. It's a fuzzed test image with the qcow2 image header only. Suppositional cause of the failure is the value of 'size' header field set to maximum uint_64 value.
+
+System information:
+
+qemu.git: 6baa963f4dcc2118
+Host: Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64  GNU/Linux
+
+
+
+The bug description missed qemu-img error:
+
+(process:12283): GLib-ERROR **: gmem.c:110: failed to allocate 18446744059294601304 bytes
+
+
+On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote:
+> The bug description missed qemu-img error:
+> 
+> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate
+> 18446744059294601304 bytes
+
+Thanks, there has been recent work by Kevin Wolf to handle memory
+allocation failures gracefully without terminating QEMU.  This sounds
+like a candidate for g_try_malloc() and friends.
+
+Does the following patch series solve the problem?
+https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html
+
+Stefan
+
+
+Am 24.06.2014 um 15:19 hat M.Kustova geschrieben:
+> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote:
+> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote:
+> >> The bug description missed qemu-img error:
+> >>
+> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate
+> >> 18446744059294601304 bytes
+> >
+> > Thanks, there has been recent work by Kevin Wolf to handle memory
+> > allocation failures gracefully without terminating QEMU.  This sounds
+> > like a candidate for g_try_malloc() and friends.
+> >
+> > Does the following patch series solve the problem?
+> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html
+> 
+> These patches are conflicting with current master. So I can't test
+> them as they are.
+> 
+> Do you have a developer repository or branch containing these patches,
+> so I could test it on the pre-release base?
+
+I'm just about to send a new version, I'll keep you CCed there.
+
+Kevin
+
+
+Am 25.06.2014 um 11:32 hat M.Kustova geschrieben:
+> On Tue, Jun 24, 2014 at 7:36 PM, Kevin Wolf <email address hidden> wrote:
+> > Am 24.06.2014 um 15:19 hat M.Kustova geschrieben:
+> >> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote:
+> >> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote:
+> >> >> The bug description missed qemu-img error:
+> >> >>
+> >> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate
+> >> >> 18446744059294601304 bytes
+> >> >
+> >> > Thanks, there has been recent work by Kevin Wolf to handle memory
+> >> > allocation failures gracefully without terminating QEMU.  This sounds
+> >> > like a candidate for g_try_malloc() and friends.
+> >> >
+> >> > Does the following patch series solve the problem?
+> >> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html
+> >>
+> >> These patches are conflicting with current master. So I can't test
+> >> them as they are.
+> >>
+> >> Do you have a developer repository or branch containing these patches,
+> >> so I could test it on the pre-release base?
+> >
+> > I'm just about to send a new version, I'll keep you CCed there.
+> 
+> "[PATCH v4 21/21] qcow2: Return useful error code in refcount_init()"
+> is still broken for the current master.
+
+In which way? I can cleanly apply the whole patch series on master (even
+tried applying the emails from my inbox to be sure).
+
+Kevin
+
+
+Am 25.06.2014 um 11:54 hat M.Kustova geschrieben:
+> On Wed, Jun 25, 2014 at 1:42 PM, Kevin Wolf <email address hidden> wrote:
+> > Am 25.06.2014 um 11:32 hat M.Kustova geschrieben:
+> >> On Tue, Jun 24, 2014 at 7:36 PM, Kevin Wolf <email address hidden> wrote:
+> >> > Am 24.06.2014 um 15:19 hat M.Kustova geschrieben:
+> >> >> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote:
+> >> >> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote:
+> >> >> >> The bug description missed qemu-img error:
+> >> >> >>
+> >> >> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate
+> >> >> >> 18446744059294601304 bytes
+> >> >> >
+> >> >> > Thanks, there has been recent work by Kevin Wolf to handle memory
+> >> >> > allocation failures gracefully without terminating QEMU.  This sounds
+> >> >> > like a candidate for g_try_malloc() and friends.
+> >> >> >
+> >> >> > Does the following patch series solve the problem?
+> >> >> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html
+> >> >>
+> >> >> These patches are conflicting with current master. So I can't test
+> >> >> them as they are.
+> >> >>
+> >> >> Do you have a developer repository or branch containing these patches,
+> >> >> so I could test it on the pre-release base?
+> >> >
+> >> > I'm just about to send a new version, I'll keep you CCed there.
+> >>
+> >> "[PATCH v4 21/21] qcow2: Return useful error code in refcount_init()"
+> >> is still broken for the current master.
+> >
+> > In which way? I can cleanly apply the whole patch series on master (even
+> > tried applying the emails from my inbox to be sure).
+> 
+> Beginning from line #49 in master:
+> 
+>     if (s->refcount_table_size > 0) {
+>         BLKDBG_EVENT(bs->file, BLKDBG_REFTABLE_LOAD);
+>         ret = bdrv_pread(bs->file, s->refcount_table_offset,
+> 
+> The patch:
+> 
+>    if (s->refcount_table_size > 0) {^M
+>          if (s->refcount_table == NULL) {^M
+> +            ret = -ENOMEM;^M
+>              goto fail;^M
+>          }^M
+>          BLKDBG_EVENT(bs->file, BLKDBG_REFTABLE_LOAD);^M
+>          ret = bdrv_pread(bs->file, s->refcount_table_offset,^M
+> 
+> At least master version doesn't have this condition.
+
+It is code added in patch 11 of the same series.
+
+Kevin
+
+
+The series fixed the crash, but qemu-img started to produce the confusing output:
+
+$ qemu-img check test_image
+
+ERROR: I/O error in check_refcounts_l1
+No errors were found on the image.
+
+QEMU nowadays seems to report "Check failed: Cannot allocate memory" ... so I assume that is OK and we can now close this bug?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Have the same proble: qemu-img: Check failed: Cannot allocate memory
+