segv on lookup?

[Fairlight]

Tried that.  No joy.

It's worse.  ALL of my callable tables using these files have started
segmentation violations, and apparently, using -db in dreport, all on 
index A, even though it's supposedly been rebuilt.  What's funny is that
dreport is reporting that the last line it's to work on is a lookup using
index A.  The strace backtraces, however, all point to the last thing done
before the segv being operations on fd 20, which points to the last file
opened, which was index.H.  That's a bit of a conflicting set of data
points...

None of the code has changed, so this pretty much has to be a data bug.
The question is, how the hell do I fix it?

Literally, the tables in question have been working for up to two weeks
(I've been developing multiple tables, progressively), and worked as
recently as an hour, hour and a half ago, without fail.  

Once I hit the first segv on one, all the rest have gone to hell, and I
haven't altered the codebase at all.  Which says it's not code...at least
not in the ones that were working.

I'm open to suggestions...

mark->

On Thu, Aug 08, 2013 at 04:40:07PM -0400, Doug Luurs thus spoke:
>    Try deleting your lockfile in that directory and add -e as well.
>    -----Original Message-----
>    From: filepro-list-bounces+doug.luurs=gmail.com at lists.celestial.com
>    [[1]mailto:filepro-list-bounces+doug.luurs=gmail.com at lists.celestial.co
>    m] On Behalf Of Fairlight
>    Sent: Thursday, August 08, 2013 4:36 PM
>    To: filePro Mailing List
>    Subject: Re: segv on lookup?
>    Top-post...
>    The table that's been working fine until just now?  Now it's started
>    doing a segv when called from the calling table that was working fine
>    before all the segv nonsense started.
>    An strace shows that it -may- be a corrupted index.
>    I've tried:  dxmaint pevent -ra
>    ...But it just brings up the dxmaint menu.  I thought it was supposed
>    to rebuild all indexes.
>    How do I force that rebuild?  I think it prudent to try, before
>    spending hours diagnosing something that may be a simple data
>    corruption, investigating it as a code issue.
>    mark->
>    On Thu, Aug 08, 2013 at 04:14:06PM -0400, Fairlight thus spoke:
>    > I'm at a loss as to what's going on here.  I haven't had any troubles
>    > with a CALLed table until now, when it's being called by a different
>    calling
>    > table.   Suddenly, it wants to segv without fail.
>    >
>    > Here's the lookup in the called table:
>    >
>    > lookup pstn = pevent  k=(ValKey)   i=A -npx
>    >
>    > That's what's segfaulting.
>    >
>    > The calling table is sitting on a record in a file that's just used
>    as
>    > "slots" to sit on while doing all work via lookups.  There's a lookup
>    > currently active on the pevent table at the time of segv, but it's
>    > non-protected.  This is the active lookup in question:
>    >
>    > lookup pstat = pevent  r=(ValKey)   -n
>    >
>    > Any clues?  The called table works flawlessly outside of this
>    context,
>    > when I'm just sitting in dreport on a record that has nothing to do
>    > with the pevent file.  The only time I'm running into trouble seems
>    to
>    > be in this new calling table, which has a greater-than lookup via an
>    > @rn index, cycling through all records and looking for the ones to
>    > process in a getnext loop.
>    >
>    > I'm not even sure that the two lookups are colliding to cause the
>    segv
>    > or not, honestly.  It's my primary guess, since it's the main
>    difference.
>    >
>    > filePro for Linux, 5.0.14R4
>    >
>    > mark->
>    > --
>    > Fairlight Consulting
>    > [2]http://www.fairlite.com
>    > fairlite at fairlite.com
>    > (502) 509-3840
>    --
>    Fairlight Consulting
>    [3]http://www.fairlite.com
>    fairlite at fairlite.com
>    (502) 509-3840
>    _______________________________________________
>    Filepro-list mailing list
>    Filepro-list at lists.celestial.com
>    Subscribe/Unsubscribe/Subscription Changes
>    [4]http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
>    --
> 
>    These commodities/technical data, including attachments, are controlled
>    under the United States Export Administration Regulations (EAR) and the
>    International Traffic in Arms Regulations (ITAR). This information may
>    not be exported to a foreign person, either in the U.S. or abroad,
>    without the proper authorization of the U.S. Department of State or the
>    U.S. Department of Commerce. Prior to distributing, please contact
>    Amphenol Borisch Technologies to obtain related information for
>    commodity classification and jurisdiction as well as end users.
> 
>    This E-mail, including any attachments, should be considered
>    confidential and proprietary information. Further, this information is
>    intended solely for use by the individual to whom it is addressed. If
>    you received this E-mail in error, please notify the sender, do not
>    disclose its contents to others, and delete it from your system.  Any
>    other use of this E-mail and/or attachments is prohibited.  This
>    message is not meant to constitute an electronic signature or intent to
>    contract electronically.
> 
> References
> 
>    Visible links
>    1. mailto:filepro-list-bounces+doug.luurs=gmail.com at lists.celestial.com
>    2. http://www.fairlite.com/
>    3. http://www.fairlite.com/
>    4. http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
>    Hidden links:
>    5. file://localhost/tmp/flt-mutt.html


-- 
Fairlight Consulting
http://www.fairlite.com
fairlite at fairlite.com
(502) 509-3840