[Xapian-discuss] xapian-compact seg faulting & Re: [Xapian-discuss] Error msg xapian-compact: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation

oscaruser at programmer.net oscaruser at programmer.net
Wed Jun 21 18:43:31 BST 2006


gamma:/svr/hda1/omega/data# gdb /home/oscar/xapian/bin/xapian-compact
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) set args -F -m /svr/hda1/omega/data/bsp0*/default /index/omega/data/bsp0*/default /svr/hda1/xapian/default
(gdb) run
Starting program: /usr/home/oscar/xapian/bin/xapian-compact -F -m /svr/hda1/omega/data/bsp0*/default /index/omega/data/bsp0*/default /svr/hda1/xapian/default
postlist: Reduced by 60.6251% 1056040K (1741920K -> 685880K)
record: Reduced by 51.7574% 96480K (186408K -> 89928K)
termlist: Reduced by 53.039% 590112K (1112600K -> 522488K)
position ...
Program received signal SIGSEGV, Segmentation fault.
0x4033f07f in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0  0x4033f07f in memcpy () from /lib/tls/libc.so.6
#1  0x4024cb01 in std::string::append () from /usr/lib/libstdc++.so.6
#2  0x400bc71e in FlintTable::read_tag (this=0xbfffc9c0, C_=0x8071548, tag=0xbfffc9b4) at flint_table.h:128
#3  0x400c7972 in FlintCursor::read_tag (this=0xbfffc9a0) at flint_cursor.cc:220
#4  0x0804d1c3 in main (argc=-1073755728, argv=0xbfffce94) at xapian-compact.cc:474
(gdb) frame 4
#4  0x0804d1c3 in main (argc=-1073755728, argv=0xbfffce94) at xapian-compact.cc:474
474                             cur.read_tag();
(gdb) list
469                                     throw Xapian::DatabaseCorruptError(msg);
470                                 }
471                             } else {
472                                 key = cur.current_key;
473                             }
474                             cur.read_tag();
475                             out.add(key, cur.current_tag);
476                         }
477                     }
478                 }
(gdb) frame 3
#3  0x400c7972 in FlintCursor::read_tag (this=0xbfffc9a0) at flint_cursor.cc:220
220         B->read_tag(C, &current_tag);
(gdb) list
215         if (have_read_tag) return;
216
217         Assert(B->level <= level);
218         Assert(is_positioned);
219
220         B->read_tag(C, &current_tag);
221
222         // We need to call B->next(...) after B->read_tag(...) so that the
223         // cursor ends up on the next key.
224         is_positioned = B->next(C, 0);
(gdb) list -
205         if (!is_positioned) return false;
206
207         (void)Item_(C[0].p, C[0].c).key().read(key);
208         return true;
209     }
210
211     void
212     FlintCursor::read_tag()
213     {
214         DEBUGCALL(DB, void, "FlintCursor::read_tag", "");
(gdb) print C
$1 = (Cursor_ *) 0x8071548
(gdb) print current_tag
$2 = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::__mt_alloc<char>> = {static _S_once = 0, static _S_init = true,
        static _S_options = {_M_align = 8, _M_max_bytes = 128, _M_min_bin = 8, _M_chunk_size = 4080, _M_max_threads = 4096, _M_freelist_headroom = 10,
          _M_force_new = false}, static _S_binmap = 0x805af98, static _S_thread_freelist_first = 0x0, static _S_thread_freelist_mutex = {__m_reserved = 0,
          __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, static _S_thread_key = 0, static _S_bin = 0x805b0a0,
        static _S_bin_size = 5}, <No data fields>}, _M_p = 0x403fb014 "¸\033ª\033\231\033\212\033z\033k\033[\033L\033=\033.\033\037\033\016\033"}}
(gdb) frame 2
#2  0x400bc71e in FlintTable::read_tag (this=0xbfffc9c0, C_=0x8071548, tag=0xbfffc9b4) at flint_table.h:128
128             tag->append(reinterpret_cast<const char *>(p + cd), l);
(gdb) list
123         Key_ key() const { return Key_(p + I2); }
124         void append_chunk(string * tag) const {
125             /* number of bytes to extract from current component */
126             int cd = getK(p, I2) + I2 + C2;
127             int l = size() - cd;
128             tag->append(reinterpret_cast<const char *>(p + cd), l);
129         }
130         /** Get this item's tag as a block number (this block should not be at
131          *  level 0).
132          */
(gdb) frame 4
#4  0x0804d1c3 in main (argc=-1073755728, argv=0xbfffce94) at xapian-compact.cc:474
474                             cur.read_tag();
(gdb) print cur
No symbol "cur" in current context.
(gdb) print key
No symbol "key" in current context.
(gdb)

> ----- Original Message -----
> From: oscaruser at programmer.net
> To: xapian-discuss at lists.xapian.org
> Subject: Re: [Xapian-discuss] xapian-compact seg faulting & Re:	[Xapian-discuss] Error msg xapian-compact: The revision being read	has been discarded - you should call Xapian::Database::reopen() and	retry the operation
> Date: Tue, 20 Jun 2006 18:53:18 -0800
> 
> 
> Folks,
> 
> I tried copydatabase on all of the dbs to identify which db is 
> broken, then excluded these from retrying xapian-compact. Found 
> that after some time I received seg fault. I am studying the flint 
> structure to see if I can identify what the issue is -- any advise 
> welcomed.
> 
> Thanks,
> OSC
> 
> P.S. I tried shuffling the .portA and .portB data sets to recover 
> the busted dbs, but no luck.
> 
> gamma:/svr/hda1/omega/data# /home/oscar/xapian/bin/xapian-compact 
> -F -m /svr/hda1/omega/data/bsp0*/default 
> /index/omega/data/bsp0*/default /svr/hda1/xapian/default
> postlist: Reduced by 60.6251% 1056040K (1741920K -> 685880K)
> record: Reduced by 51.7574% 96480K (186408K -> 89928K)
> termlist: Reduced by 53.039% 590112K (1112600K -> 522488K)
> position ...Segmentation fault
> gamma:/svr/hda1/omega/data#
> 
> 
> > ----- Original Message -----
> > From: oscaruser at programmer.net
> > To: xapian-discuss at lists.xapian.org
> > Subject: Re: [Xapian-discuss] xapian-compact seg faulting & 
> > Re:	[Xapian-discuss] Error msg xapian-compact: The revision being 
> > read	has been discarded - you should call 
> > Xapian::Database::reopen() and	retry the operation
> > Date: Tue, 20 Jun 2006 12:54:54 -0800
> >
> >
> > xapian-compact with flint db's is still breaking. i tried to more 
> > safely manage the scriptindex process as it built the flint dbs, 
> > but seems that something went awry nonetheless.
> >
> > thanks
> >
> >
> > gamma:/index/omega/data# /home/oscar/xapian/bin/xapian-compact -F 
> > -m /svr/hda1/omega/data/bsp0*/default 
> > /index/omega/data/bsp0*/default /svr/hda1/xapian/default
> > postlist: Reduced by 60.6323% 1074104K (1771504K -> 697400K)
> > record: Reduced by 51.7614% 98032K (189392K -> 91360K)
> > termlist .../home/oscar/xapian/bin/xapian-compact: The revision 
> > being read has been discarded - you should call 
> > Xapian::Database::reopen() and retry the operation
> > gamma:/index/omega/data#
> >
> > > ----- Original Message -----
> > > From: oscaruser at programmer.net
> > > To: xapian-discuss at lists.xapian.org
> > > Subject: Re: [Xapian-discuss] xapian-compact seg faulting & > 
> > Re:	[Xapian-discuss] Error msg xapian-compact: The revision being 
> > > read	has been discarded - you should call > 
> > Xapian::Database::reopen() and	retry the operation
> > > Date: Wed, 14 Jun 2006 09:22:42 -0800
> > >
> > >
> > > OK I'll rerun and report back.
> > >
> > > Thanks
> > >
> > > > ----- Original Message -----
> > > > From: "Olly Betts" <olly at survex.com>
> > > > To: oscaruser at programmer.net
> > > > Subject: Re: [Xapian-discuss] xapian-compact seg faulting & 
> > Re: > > [Xapian-discuss] Error msg xapian-compact: The revision 
> > being > > read has been discarded - you should call > > 
> > Xapian::Database::reopen() and retry the operation
> > > > Date: Wed, 14 Jun 2006 01:13:08 +0100
> > > >
> > > >
> > > > On Tue, Jun 13, 2006 at 10:38:53AM -0800, oscaruser at programmer.net wrote:
> > > > > I am fairly confident that these issues are related to killing the
> > > > > scriptindex process ungracefully causing blocks that were queued for
> > > > > writing to disk to not get written.
> > > >
> > > > The update order is carefully designed such that if the blocks aren't
> > > > written, the new version doesn't go live and we stick with the old one.
> > > >
> > > > So I'm doubtful of this explanation.  If you think I'm wrong, see if
> > > > you can repeat the problem by interrupting an update...
> > > >
> > > > You didn't answer my question about whether this is a one-off incident
> > > > or whether it happens if you run the system again from scratch.
> > > >
> > > > Cheers,
> > > >      Olly


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/




More information about the Xapian-discuss mailing list