On Monday 11 January 2010 18:44:39 Graham Keeling wrote: > Hello, > I have some things that appear to be related to bug #1410. > I don't know whether to add them as separate bugs, or as notes to bug > #1410. It may actually be something entirely different! > > > Quick summary of bug #1410: > When trying to bscan or bextract a volume filled with a virtualfull job, > bscan fails complaining about file indexes not being equal. > (the last thing that bscan says is something like this: > Record header file index 731808 not equal record index 82) > > > Here is what I would like to add / enter as new bugs: > > > I have a volume called backup-0009, which contains a single VirtualFull > backup. It is 16MB in size. > I try to do a bls: > > bls -c /etc/bacula/bacula-sd-9103.conf "Disk 1.1" -V backup-0009 > > This outputs a few file names, and then: > 11-Jan 13:34 bls: ERROR TERMINATION at bls.c:395 > Record header file index 14 not equal record index 15 > > If I use the 'forge on' option... > bls -p -c /etc/bacula/bacula-sd-9103.conf "Disk 1.1" -V backup-0009 > ...it forges on, complaining about the same sorts of things, until it > finally segfaults. > > If I try to do a restore via the normal bconsole route, bacula-sd crashes > in a similar way. > It also crashes if I try to do another VirtualFull based on backup-0009. > > I can run both bls and bacula-sd in gdb, but the stack appears corrupted. > With bacula-sd, it looks like this: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 49155 (LWP 30456)] > 0xc0a84cf1 in ?? () > (gdb) bt > #0 0xc0a84cf1 in ?? () > #1 0x0807a9ce in read_records (dcr=0xd2ded057, record_cb=0xc0a84cf1, > mount_cb=0xf0f2c84d) at read_record.c:237 > #2 0x946c7b7b in ?? () > #3 0xd2ded057 in ?? () > #4 0xc0a84cf1 in ?? () > ...and so on, until... > #160 0x00000000 in ?? () > #161 0xb7c17e11 in _int_malloc (av=Cannot access memory at address > 0x4a741398 ) at malloc.c:3816 > Previous frame inner to this frame (corrupt stack?) > > With bls it is very similar. They both use the same code in read_record.c. > > > Can somebody suggest anything else to try?
It sounds like you have gotten this down to a small test case, which is good. Send me the bacukup-00009 volume (email it as an attachment) and the bacula-xx.conf file I need to run bls on it, along with the exact command line (I assume it is the one above), and we will take a look at it. It could well be the same bug. By the way, when using the -p option, it isn't too surprising that it crashes because it is probably getting totally garbage data, but if I have a case where it does crash, I am pretty sure I can fix it to protect itself. > For example, is there some kind of 'electric fence' malloc boundary checker > that I could turn on? Valgrind is pretty good, but the *real* problem is probably occurring much earlier when it starts complaining about out of order indexes. Obviously, I would really like to fix both bugs. Don't worry about sending up to 500MB via email, but please don't copy the list when you do so. Thanks, Kern ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
