[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xenstored crashes with SIGSEGV
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: > (gdb) print *tdb > $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only = > 16711680, > locked = 0xff0000000000, ecode = 16711680, header = { > magic_food = > "\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377", > version = 0, hash_size = 0, tdb->fd has been initialised, but version and hash_size have not yet. This means we must have failed somewhere between the open() and the call to tdb_new_database() (the second one, the first one is only if TDB_INTERNAL, which is not the case here). There are three interesting actions in that space. The first is tdb_brlock, which could have gone wrong. The second is ftruncate(). This is not a candidate because tdb->flags doesn't have TDB_CLEAR_IF_FIRST (the actual test is on tdb_flags, which is changed by the time of the stack trace, but it is stored in tdb->flags where we can see it. tdb_flags isn't changed before the check, so baring compiler problems I think we can rule that out). The third is the read of the header itself. The fact that tdb->header.magic_food isn't either all zeroes or the requisite magic string "TDB file\n" is suspicious. Instead it is mostly zero with the off 0xff in it. An interesting pattern of 0xff..00..00, may be a coincidence, or not. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |