BUG: Consistent Multiple Indexer Crashes

http://community.logos.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/106/3000.Indexer-Failures-1_2D00_4-LogosIndexer.zip

Bug: Consistent indexer crashes. Logos version 5.0a (5.0.1.0220)

Description:

I have spoken to Bradley previously about frequent indexer crashes on my system. Having raised the spectre of something system specific I stopped reporting the problem for awhile and then after doing a total index rebuild the problem dissappeared. Probably because I had no new resources to index since upgrading to L5 silver (Nov 20).
I downloaded some resources on Nov 24 and I've been crashing ever since.

It's back with a vengeance.

Steps to reproduce

All I need to do is start the indexer either with a system restart or an L5 restart.

Actual Result

The indexer consistently crashes at nearly the same spot. At first it was all at 42% - then I traced the potential problem to BAR magazine 01:01 and hid the resource (Below). Now it's crashing closer to 50%.

Hardware issues: Fixed.

I kept silent thinking that perhaps Bradley was right and I just needed to find the problem on my system (He was right of course). True to Bradley's earlier thoughts I ran some deeply intensive RAM stress tests and found that one of my RAM chips was bad, but only under extreme stress testing. So I tossed it, replaced it and repeated the deep level RAM tests using the same built in DELL utility. RAM now passes just fine.

Indexer consistent crashing:

Over the last week or so, with no system changes outside of installing L5.0a (5.0.1.0220) and downloading some of the freebies on Nov 24 the crashing has been increasing terribly.

Failure 1 enclosed was on LLS:05GK (Electrum Greek) - This was almost immediately after the process started and may have been due to me typing rebuild index in the program. I can not confirm this.

Failure 2 enclosed was on LLS:12.10.2105 (BAR 02:01)

Failure 3 enclosed was on LLS:12.10.2106 (BAR 02:02)

At this point I will note that several instances prior to these logs that I have kept were ALL crashing on BAR 01:01 and BAR 01:02. so I had hidden the BAR 01:* resources in response to that.

Seeing that BAR resources are at least marking when in the process I am crashing the indexer i figured I would just hide all of Biblical Archaelogy review for a test of the indexer.

So without the indexer running I used multiple hide on all of BAR and restarted Logos to initiate the indexer.

Failure 4 The report enclosed indicates it was on LLS:12.10.2700 Archaeology Odyssey 01:01
is there a broader issue with the BAR resources that is incompatable?

In each case Windows spits out an error message like this one:

Problem signature:
Problem Event Name: APPCRASH
Application Name: LogosIndexer.exe
Application Version: 5.0.1.220
Application Timestamp: 50ac35f0
Fault Module Name: Libronix.DigitalLibrary.Logos.dll
Fault Module Version: 5.0.1.220
Fault Module Timestamp: 50ac35ea
Exception Code: c0000005
Exception Offset: 0012a86f
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Expected Result

I expect the indexer to complete a full cycle, whether partial or complete without crashing.

Find more posts tagged with

Comments

Tonya J Ross

I will create a case for your logs and get it passed on to Development.

Bradley Grainger (Logos)

It looks like your library contains sa_3erev.lbxlls (LLS:29.71.5001 = Revelation, An Exegetical Study). This is a known corrupt resource. We have pulled it from our servers, but have not yet been able to rebuild and redistribute an updated replacement.

Please hide/delete this file and see if the indexing errors stop.

TCBlack

https://community.logos.com/discussion/comment/437162#Comment_437162

It looks like your library contains sa_3erev.lbxlls (LLS:29.71.5001 = Revelation, An Exegetical Study). This is a known corrupt resource. We have pulled it from our servers, but have not yet been able to rebuild and redistribute an updated replacement.

Please hide/delete this file and see if the indexing errors stop.

I will do exactly that.

However, I kept finding all of the Biblical Archaeology Society resources being the ones in the index log just before the crash. So I HID everything from BAS. And the indexer just now finished. including the resource you mention.

So... under your advise I removed MS Mills' revelation book just now too.

Restarted Logos before remembering to upload my successful indexer log just in case it had contained something useful. It was overwritten.

I would like to restore the BAS material. I'm assuming it is safe to do so?

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/437229#Comment_437229

I would like to restore the BAS material. I'm assuming it is safe to do so?

There are no known problems with discovering and indexing these resources. If you do crash after unhiding them, we would want to investigate further.

TCBlack

https://community.logos.com/discussion/comment/437239#Comment_437239

I would like to restore the BAS material. I'm assuming it is safe to do so?

There are no known problems with discovering and indexing these resources. If you do crash after unhiding them, we would want to investigate further.

I've restored all the BAR resources. The download and indexing completed flawlessly.

I'm assuming that restoring the Mills resource won't hurt anything either since you've removed the corrupted one from the server...

So I restored the Mills resource at the end of it all. Of course nothing has downloaded until you get the rebuilt one out.

So my question is, why were the BAS resources the root of this? Is there some way that the flawed RAM stick corrupted the resource? Or more likely was the indexer doing the equivalent of a deep RAM test as it worked through some of the BAS resources?

In the end, removing and then restoring them fixed the problem - so somehow some of them had gotten corrupted on the disk.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/437526#Comment_437526

I've restored all the BAR resources. The download and indexing completed flawlessly.

I'm assuming that restoring the Mills resource won't hurt anything either since you've removed the corrupted one from the server...

So I restored the Mills resource at the end of it all. Of course nothing has downloaded until you get the rebuilt one out.

This is correct. Unhiding the resource should do nothing, because there is currently no available copy of this resource to download.

However, if your system did happen to scan a DVD or Libronix DLS\Resources folder that contained this file, it would be installed (because it's not hidden), and you would start crashing again.

So my question is, why were the BAS resources the root of this?

They weren't.

I haven't repro'd the crash recently, but it's likely that opening and indexing the Mills resource caused a buffer overflow (or similar) in the Indexer that corrupted its internal data structures without crashing it. Later on, while indexing a BAR resource, that corrupt data finally caused a deeper problem that actually crashed the indexer. The presence of the BAR resource in the log was most likely a red herring.

Tonya J Ross

https://community.logos.com/discussion/comment/437609#Comment_437609

You can now safely unhide and redownload the trouble resource. It has been set not to index, so operations which requires an index (such as searching) will not function for this resource.

Brisa Davis

A fixed resource has been shipped. As of 4.6b and 5.0b it has been set to index, so operations that require an index should be working with this resource.