Indexer Issues in 5.1a SR1
Since changing to the stable versions of 5.1a I noticed that turning off the indexer was not reliable, at least according to the yellow indexer bar (which seemed to resume indexing directly after I turned it off etc - sorry no logs). Sometimes the yellow bar showed indexing while the Windows tray icon had it as paused or didn't show at all (sorry no screenshots).
Today, the indexer bar showed "6%" all the time for a seemingly small resource update - there is no indexing going on and there's no tray icon showing for indexer, but even after I clicked the bar away, the yellow dot with exclamation mark still shows:
It seems, there is an issue with the internal multi-threading of the indexer. The log has one process churning along over reindexing stuff, another adressing the display - and still doing so very wrongly while indexing has long been finished:
The log ends at roughly 18:15, the screenshot above was taken four hours later.
Have joy in the Lord! 
Comments
-
I have had similar issue on my vista 32bit laptop, but my win 8 64bit completed ok
Never Deprive Anyone of Hope.. It Might Be ALL They Have
0 -
SO.. I guess it got upset and trashed the index, it now says first-time indexing underway - seriously
it takes 2 days on this laptop - we are not amused
Never Deprive Anyone of Hope.. It Might Be ALL They Have
0 -
DominicM said:
I have had similar issue on my vista 32bit laptop, but my win 8 64bit completed ok
So maybe this is a Win 32bit issue?
I include further Logs, showing that indexer finished, but the yellow notification bar still had the indexing message which - as Logos.log shows - couldn't be braught to react on pause indexing click.
Have joy in the Lord!
0 -
DominicM said:
SO.. I guess it got upset and trashed the index, it now says first-time indexing underway - seriously
it takes 2 days on this laptop you shouldn't do this..... if your issue on the Vista machine was the same as mine, the index was fine and Logos only displayed an out-of-place message but wasn't indexing at all.
Have joy in the Lord!
0 -
Can't really be specific here. But I had some indexing issues since this latest release, and I've never had them before. Had to rebuild
0 -
NB.Mick said:
you shouldn't do this..... if your issue on the Vista machine was the same as mine, the index was fine and Logos only displayed an out-of-place message but wasn't indexing at all.
Yes got the out of place message, then got more downloads, and when completed I restarted Logos to install them in..
It then of its own choice started to index again and showed the first-time
Never Deprive Anyone of Hope.. It Might Be ALL They Have
0 -
NB.Mick said:
I include further Logs, showing that indexer finished, but the yellow notification bar still had the indexing message which - as Logos.log shows - couldn't be braught to react on pause indexing click.
The indexer "finished"--as in the process exited--but it never completed successfully. This left an "orphaned" indexing message in the app (and an incomplete index).
The crash appears to be a native crash, and didn't write an exception to the log file. If this occurs frequently for you, I'd be very interested in seeing a crash dump captured by ProcDump: http://wiki.logos.com/ProcDump
0 -
Bradley Grainger (Logos) said:
If this occurs frequently for you, I'd be very interested in seeing a crash dump captured by ProcDump: http://wiki.logos.com/ProcDump
This does occur frequently for me. My latest indexer log from today:
Indexer runs fine until the final merging postings.... step, then it closes. There is no indexer error or other indication of an issue, except that the log doesn't finish.
The point regarding procdum is that I had started the Logosindexer program from Procdump, but the program didn't write a *.dmp file
Earlier today, before installing Procdump, I had captured the logs: 4062.Logos Log Files.zip which also includes an older indexer log with more activity, but apparently the same ending.
I had somehow hoped that running the latest RC would fix the indexer issue, but apparently it didn't.
Mick
Have joy in the Lord!
0 -
NB.Mick said:
The point regarding procdum is that I had started the Logosindexer program from Procdump, but the program didn't write a *.dmp file
Unfortunately, you ran it with the "-h" switch, which only collects a dump if the program hangs. You need to use the "-e" switch, which collects a dump if the program crashes.
0 -
okay, I must have messed this switch up from trying to get procdump to run before. But here we go:
New Indexer log
5557.LogosIndexer.silent crash.log
The usual part at the end:
2013-11-10 01:36:18.7600 25 Info LibraryIndex 0 unindexed resources out of 6129 indexable resources; supplemental index count is 342.
2013-11-10 01:36:18.7730 25 Info LibraryIndex Merging supplemental index into main index.
2013-11-10 01:36:18.7730 25 Info LibraryIndex Merging indexes 'index' and 'supplemental' into index in C:\Users\Michael\AppData\Local\Logos4\Logos5\Data\1m4cn0eu.lr1\LibraryIndex
2013-11-10 01:36:19.1650 25 Info Indexer (Timed) Replacing lexicon 'index-build' with 'supplemental'
2013-11-10 01:37:23.0787 25 Info Indexer (1m 3.9s) Replacing lexicon 'index-build' with 'supplemental'
2013-11-10 01:37:27.8849 25 Info Indexer Merging document manager...
2013-11-10 01:38:00.8278 25 Info Indexer Merged document manager in 00:00:32.9433210
2013-11-10 01:38:06.8682 25 Info Indexer (Timed) Merging postings...That's what procdump says: it's a C0000006.IN_PAGE_ERROR
I tried to upload the dump, even split up in two zip files smaller than 5MB, but the forum software doesn't let me. I'll try to email it to you.
Have joy in the Lord!
0 -
Analysing the dump file shows that the primary error is "ExceptionCode: c0000006 (In-page I/O error)", and the details are "IO_ERROR: (NTSTATUS) 0xc000009c - STATUS_DEVICE_DATA_ERROR", which has the description "There are bad blocks (sectors) on the hard disk.".
Given this information, I would recommend a full-disk scan, possibly followed by replacing the hard disk. (In my personal experience, disks that start logging errors are on the way out and should be replaced while you can still read the data off them.)
0
