Opened 10 years ago

Closed 10 years ago

#345 closed defect (incomplete)

Xapian-compact crashes with std:length error during update

Reported by: Gingy Owned by: richard
Priority: normal Milestone:
Component: Other Version: 1.0.7
Severity: normal Keywords:
Cc: lveres@… Blocked By:
Blocking: Operating System: Linux

Description

Sometimes our update/rebuild process crashes with the following error:

terminate called after throwing an instance of 'std::length_error'           what():  basic_string::assign
www-daily/300_xapian_rebuild_produto: line 10: 28611 Aborted                 /usr/bin/xapian-compact $default_path/produto-$$-$database_identifier $default_path/produto_compact-$$-$database_identifier

This happens only on 1 of our 5 servers, however all servers does the same update/rebuild process with the same content at the same time. This server has 32bit architecture, while the others has 64bit.

Change History (10)

comment:1 follow-ups: Changed 10 years ago by richard

Please could you let us know which release of Xapian you are using.

The error is from xapian-compact: are you running it on a single or multiple databases? Which options to xapian-compact are you using?

Is this reliably repeatable? ie, do you have a test database which, when you run xapian-compact on it, always fails with this error. Is there any other output to xapian compact?

comment:2 in reply to: ↑ 1 Changed 10 years ago by Gingy

Replying to richard:

Please could you let us know which release of Xapian you are using.

1.0.7

The error is from xapian-compact: are you running it on a single or multiple databases?

We are building four different flint databases from one oracle database (on all servers).

Which options to xapian-compact are you using?

Building four different flint databases from one oracle database (on all servers).

Is this reliably repeatable? ie, do you have a test database which, when you run xapian-compact on it, always fails with this error.

unfortunately I'm unsure about this one. This happened for the third time today, and till this time the problem solved itself within a short time (don't know, why).

Is there any other output to xapian compact?

I'm afraid, I don't clearly understand this question. We use xapian-compact to compact a temp database into another database. The result database is in use.

comment:3 in reply to: ↑ 1 Changed 10 years ago by Gingy

Replying to richard:

Which options to xapian-compact are you using?

No other options.

/usr/bin/xapian-compact $default_path/produto-$$-$database_identifier $default_path/produto_compact-$$-$database_identifier

comment:4 follow-up: Changed 10 years ago by richard

If you are able to try with the latest Xapian release (1.0.11, released yesterday), please do. It's downloadable from the website. There's only one fix to xapian-compact listed in the ChangeLog? since 1.0.7 (and that was targetted at windows), but it would be good to know if any of the other changes have affected this.

Other ways of debugging this that you could try are to:

a) run the xapian-compact command under "gdb", and get a backtrace from the error. You should be able to do this just by prefixing the xapian-compact command with "gdb --args", then executing "run" from the gdb command line, and then "bt" when you're returned to the gdb command line after the error.

b) compile Xapian with debugging messages and assertions turned on (by supplying --enable-log and --enable-assertions to configure). See xapian-core/HACKING for details of this.

c) Is it possible to provide me with a copy of the source database which you pass to xapian-compact? I'd be happy to accept this privately, and delete it after investigation; one way might be to put it in a password protected location for me to download. Alternatively, if you're willing to give me a login to your server I could investigate the problem that way. My email is richard@…, if you want to follow this route.

comment:5 Changed 10 years ago by richard

  • Owner changed from olly to richard
  • Status changed from new to assigned

comment:6 in reply to: ↑ 4 Changed 10 years ago by Gingy

We have decided to give backtracing a try. Maybe it tells what the problem is (and this is the easyest for the first glance). I hope it gives usable result. If not, we try the new release, but it will take several days. I'll write after the tests.

comment:7 Changed 10 years ago by olly

  • Version set to 1.0.7

There's only one fix to xapian-compact listed in the ChangeLog since 1.0.7

There's no particular reason to think that this is in code specific to xapian-compact that I can currently see though.

But a backtrace should be enlightening even if it only tells us where this is happening.

Another possible thing to try is running xapian-compact under valgrind.

comment:8 Changed 10 years ago by olly

Any progress trying to track this down?

comment:9 Changed 10 years ago by Gingy

Nothing. We haven't encountered this error since then. Besides, we are out of 32bit servers. :) If this shows up in the future, I'll report it ASAP.

comment:10 Changed 10 years ago by olly

  • Resolution set to incomplete
  • Status changed from assigned to closed

OK, thanks for letting us know. I'm resolving this as "incomplete", at least for now. If you are able to reproduce this and produce a backtrace, please reopen this ticket and attach it!

Note: See TracTickets for help on using tickets.