segv on lookup? [solved]

[Richard Kreiss]

Top post,

I k ow that Ken disagrees with me on this, delete the auto indexes and then rebuild them. 

Ken will tell you that when a odd ex is rebuilt, the index is emptied and then rebuilt. I have found when I have had similar problems on a windows system the delete and rebuild solved the problem. This is probably due to the index being rebuild in a new loa cation on the drive or something similar. 

You may want to run the indexing program supplied with the fp install. Then edit out the portion which has the indexes for the file in question to a new file. Run this after deleting the indexes. 

Richard
Sent from my iPhone

On Aug 8, 2013, at 2:34 PM, Fairlight <fairlite at fairlite.com> wrote:

> On Thu, Aug 08, 2013 at 05:08:31PM -0400, Kenneth Brody thus spoke:
>>> An strace shows that it -may- be a corrupted index.
>> 
>> I was going to suggest that as a possibility.
> 
> Now a proven certainty.
> 
>> That's what the "-ra" flag does -- rebuild all auto indexes.  If you
>> don't also include "-e" to exit afterwards, you will be returned to
>> the dxmaint menu.
> 
> Got that...now.
> 
>> How many indexes are in "pevent", and how many records are in the
>> file?  Is it possible that it simply rebuilt the indexes so quickly
>> that you didn't see it happen?
> 
> A..I were there.  Now it's A..H.  
> 
> The problem has gone away since I deleted index I, which was built on @rn.
> I was having issues trying to cycle through -every- record in the database,
> so I figured an @rn search for greater than, starting with "1" would work.
> 
> Turns out, not so much.
> 
> I'd tried deleting key/data, no joy.  Things that worked two weeks ago were
> still broken.
> 
> As I said, the strace indicated fd20 was the last file descriptor ever used
> before segv.  It didn't actually seem to do anything with I...at least
> before the crash.  But I was checking the last events before crash time on
> any given processing table.
> 
> When I realised H was the last accessed, and I had an index I, I looked at
> what it was, and it was the @rn index.  I deleted that, and lo and behold,
> everything instantly started working.
> 
> I know damned well that @rn is supposed to be dangerous as hell.  I also
> know devs who swear by it.  I'm pretty sure I'm never going to use it
> again.  Actually, it makes no sense to have an index built on @rn (at least
> strictly on @rn) when you can do a record number lookup.  Before I'd
> instituted the record number lookup, I'd been doing a search on that index
> with a key field, and it failed on me.  I rewrote the lookup and that's
> when everything went to hell in a handcart.
> 
> Love the way filePro crashes on a lookup to index A, when the problem is
> actually in index I.  And that's not even the error reporting...that's what
> -db was showing me about processing.  *boggle*
> 
> Anyway, it seems solved for now.  Thanks to all who rendered assistance!
> 
> mark->
> -- 
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list