Seg Violation on Linux

[Nancy Palmquist]

Kenneth Brody wrote:
> 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.

In order to lock up 3 telnet sessions with one seg violation, I thought 
whatever memory I was hitting was certainly critical.


> 
> 
>>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?

There is no lookup dash involved.  One record in the current file, then 
I call table 1, call table 2, call table 3 (as many as 40 times) and/or 
call table 4 as many as 100 times.  (It is strange but the ones I was 
having the most trouble with were not the ones with the most calls, it 
was one with 9 and one with 20 calls.  So I could not say that the more 
I activated the call of table 3 the more likely it was to crash.)

Table 3 was where the crash was happening for the longest time.  After 
some adjustements (shrunk some arrays, shrunk some declared variables, 
etc.) I somehow got it to happen after all the calls were finished and 
when the last command was executed (EXIT).

I had a suggestion to get the 5.0.14 version and I did that install this 
morning on my test system.  That actually seems to have fixed the 
problem (cross my fingers) on the most part.  I tried to process my test 
sets and only one crashed (Back in Call table 3 after only 5 calls).  So 
I am almost there.

I have more testing to do to make sure all is solid but I delayed 
installation on the customer system until I got some resolution on this 
issue.  These are run to load data files received and if it hangs will 
be a real problem.  I wanted to be satisfied that I had done everything 
possible to stabilize the logic.

In my early tests, I did determine that some issues were caused by 
special case stuff for reading and processing the file.  But I have that 
all great now.

I will continue to test, but I am real close.  If I discover anything 
that could be reported as a bug, I will let you know.  This kind of 
error can be hard to pin down.



Nancy

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


-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com