Seg Violation on Linux

Kenneth Brody kenbrody at bestweb.net
Mon Nov 7 18:26:45 PST 2005


Quoting Nancy Palmquist (Mon, 07 Nov 2005 20:55:43 -0500):
[...]
> >>Trying using the -t option and increasing the token size.
> >
> > She said the problem is in rclerk, which is unaffected by the "-t"
> > series of flags, as it's running precompiled tok files.
[...]
> I have been messing with it and any other setting for the tok flags
> seems to make it worse.  I looked at the long variables and deleted a
> few that were not used and it seems to squeak by with no error.

You may have simply moved the error to a non-critical region of memory.

> I tried in dclerk and rclerk versions.  Changing the TOK sizes did seem
> to affect the rclerk but I have tested so many things maybe that is not
> exactly right.

Do "strings rclerk | grep TOK" to verify for yourself that none of the
PFTOK* variables exist within it.

[...]
> I have the biggest work happening in a call table with local
> environment.  Aren't those variables lost and put back into the free
> space when the call is ended????

Yes, but it will cause memory to be arranged differently than if the
call had not taken place.

> As one of my tests, I moved the call table that was crashing at the time
> to the bottom of the input table and the results were similar.
>
> As one test I changes a long variable to a dummy variable (both were
> undefined in length) and it improved the results - it still crashed but
> the crash was closer to the end of the processing.

Here is the description of a post-5.0.14 fix that is related to calls
and declared variables:

    If you have DECLAREd GLOBAL variables in the automatic and/or the
    input/output table, and then CALL another table which DECLAREs
    addtional GLOBAL variables, such that the total number of such
    variables crosses a multiple-of-32 boundary, and then from within
    the main input/output table execute a non-dash lookup to the main
    file, filePro may crash.

Does this sound like it may be your situation?

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com


More information about the Filepro-list mailing list