search for: prev_siz

Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession ES; llvm::orc::RTDyldObjectLinkin...

...m); } if (stream->pos == stream->buffer_size) return -2; /* buffer full */ } } if(emxstream->supersize == 0){ /* need to read more data. try to read a full CHUNK_SIZE */ i_stream_skip(stream->parent, emxstream->prev_size); if (i_stream_read_data(stream->parent, &data, &size, CHUNK_SIZE-1) == -1 && size == 0) { if (stream->parent->stream_errno != 0) { stream->istream.stream_errno = stream->parent->stream_errno; } else {...

...ons(+), 137 deletions(-) diff --git a/lib/qemu.c b/lib/qemu.c index 48e283d48..bdd9947a8 100644 --- a/lib/qemu.c +++ b/lib/qemu.c @@ -44,6 +44,10 @@ #include "guestfs_protocol.h" struct qemu_data { + int generation; /* MEMO_GENERATION read from qemu.stat */ + uint64_t prev_size; /* Size of qemu binary when cached. */ + uint64_t prev_mtime; /* mtime of qemu binary when cached. */ + char *qemu_help; /* Output of qemu -help. */ char *qemu_devices; /* Output of qemu -device ? */ @@ -51,9 +55,42 @@ struct qemu_data { struc...

Hi, this patch series fixes few more issues discovered by Coverity. Thanks, Pino Toscano (6): tail: check the return value pf guestfs_set_pgroup daemon: btrfs: check end_stringsbuf return values everywhere java: use cleanup handlers for structs (lists) as return values lib: qemu: improve handling of FILE* p2v: check more return values p2v: fix possible close(-1) issue cat/tail.c

...y free. */ struct qemu_data * guestfs_int_test_qemu (guestfs_h *g) { + struct qemu_data *data; + struct stat statbuf; + CLEANUP_FREE char *cachedir = NULL, *qemu_stat_filename = NULL, + *qemu_help_filename = NULL, *qemu_devices_filename = NULL; + FILE *fp; + int generation; + uint64_t prev_size, prev_mtime; + + if (stat (g->hv, &statbuf) == -1) { + perrorf (g, "stat: %s", g->hv); + return NULL; + } + + cachedir = guestfs_int_lazy_make_supermin_appliance_dir (g); + if (cachedir == NULL) + return NULL; + + qemu_stat_filename = safe_asprintf (g, "%s/qe...

The patch I posted last week to disable mandatory locking for readonly drives (https://www.redhat.com/archives/libguestfs/2017-September/msg00013.html) was wrong in a couple of respects. Firstly it didn't work, which I didn't detect because my tests were testing the wrong thing. Oops. Secondly it used a simple version number check to detect qemu binaries implementing mandatory locking.

v2 -> v3: - I addressed everything that Pino mentioned last time. - It's tricky to get a stable run when multiple copies of qemu are involved, because the same cache files get overwritten by parallel libguestfs. So I changed the names of the cache files to include the qemu binary key (size, mtime), which removes this conflict. This is in new patch 4/6. Rich.

Patches 1-4 are almost the same as they are when previously posted here: https://www.redhat.com/archives/libguestfs/2017-September/msg00039.html Patch 5 actually uses the mandatory locking test to turn off locking in the narrow case where a drive is opened readonly, and then only for the drive being inspected. Passes ordinary tests (‘check-direct’ and ‘check-valgrind-direct’). Rich.

...4/libc.so.6 > No symbol table info available. > #1? 0x00007f73f1387c75 in abort () from /lib64/libc.so.6 > No symbol table info available. > #2? 0x00007f73f17ab822 in mem_block_alloc (min_size=520) at > data-stack.c:356 > ??????? block = <value optimized out> > ??????? prev_size = <value optimized out> > ??????? alloc_size = 134217728 > #3? 0x00007f73f17abc18 in t_malloc_real (size=<value optimized out>, > permanent=true) at data-stack.c:415 > ??????? block = <value optimized out> > ??????? ret = <value optimized out> > ?????...

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

Patches 1 & 2 were posted previously here: https://www.redhat.com/archives/libguestfs/2016-May/msg00134.html Patch 3 is a hack so I can test this using my own version of qemu (the `-L ?' stuff is not upstream). Patch 4 is where the real action takes place: Replace the caching of qemu features in blob-like files with a sqlite database. Probably the best way to approach this patch is to

...07f73f1386495 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f73f1387c75 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f73f17ab822 in mem_block_alloc (min_size=520) at data-stack.c:356 block = <value optimized out> prev_size = <value optimized out> alloc_size = 134217728 #3 0x00007f73f17abc18 in t_malloc_real (size=<value optimized out>, permanent=true) at data-stack.c:415 block = <value optimized out> ret = <value optimized out> alloc_size = 520 #4 0x0000...

NOTE: Not for upstream, yet. This depends on 3 non-upstream patches. - The qemu rework in libguestfs, which in turn depends on what Pino is up to. - Support for '-L ?' in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02596 - Support for bios-fast.bin in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02408 This commit

This commit uses -bios bios-fast.bin if available, which basically stops SeaBIOS from trying to do PCI probing during boot, which is a waste of time when using the -kernel option. v1 -> v2: - Rebase on top of Pino's work. This still has 3 dependencies: - The qemu memoization work (v2). - Support for '-L ?' in qemu:

...EF __attribute__((cleanup(cleanup_json_t_decref))) + +static void +cleanup_json_t_decref (void *ptr) +{ + json_decref (* (json_t **) ptr); +} + +#else +#define CLEANUP_JSON_T_DECREF +#endif + struct qemu_data { int generation; /* MEMO_GENERATION read from qemu.stat */ uint64_t prev_size; /* Size of qemu binary when cached. */ @@ -54,10 +67,12 @@ struct qemu_data { char *qemu_help; /* Output of qemu -help. */ char *qemu_devices; /* Output of qemu -device ? */ char *qmp_schema; /* Output of QMP query-qmp-schema. */ + char *quer...

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.

...82e38, 0x0, 0x1098, 0x0, 0x0}} ret = <optimized out> #10 0x00007f9d1bccdaf2 in i_stream_qp_decoder_read (stream=0x66dd50) at istream-qp-decoder.c:103 bstream = 0x66dd50 pre_count = 0 post_count = <optimized out> ret = <optimized out> prev_size = 5570 __FUNCTION__ = "i_stream_qp_decoder_read" #11 0x00007f9d1bce6de9 in i_stream_read (stream=0x66ddb0) at istream.c:135 _stream = 0x66dd50 old_size = 0 ret = <optimized out> __FUNCTION__ = "i_stream_read" #12 0x00007f9d1bcebcac...

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel