File Pro And Bus Errors

[Nancy Palmquist]

Brian K. White wrote:
> 
> ----- Original Message ----- From: "Nancy Palmquist" <nlp at vss3.com>
> To: "J. Ryan Kelley" <ryan.kelley at trinitytransport.com>
> Cc: "fplist3" <Filepro-list at lists.celestial.com>
> Sent: Wednesday, July 06, 2005 9:43 AM
> Subject: Re: File Pro And Bus Errors
> 
> 
>> J. Ryan Kelley wrote:
>>
>>>
>>>
>>> Steve Wiltsie wrote:
>>>
>>>> ----- Original Message ----- From: "J. Ryan Kelley" 
>>>> <ryan.kelley at trinitytransport.com>
>>>> To: "fplist3" <Filepro-list at lists.celestial.com>
>>>> Sent: Wednesday, July 06, 2005 7:07 AM
>>>> Subject: File Pro And Bus Errors
>>>>
>>>>
>>>>
>>>>> Good Morning,
>>>>>
>>>>> I've been working with Filepro for about 8 months now after recently
>>>>> graduating from college with a degree in Computer Science.  I've had
>>>>> experiences working with everything from C, and C++ to Fortran, to 
>>>>> Lisp,
>>>>> and countless other languages, however never with FilePro until I
>>>>> started at my current position.  When I first started working with
>>>>> Filepro, I'll admit, I was impressed with how easy it was to step 
>>>>> in and
>>>>> start working.  In fact, I was doing some programming in my first few
>>>>> hours on my first day.  The primary thing that I have found unsettling
>>>>> from day one, however, is the presence of the dreaded Bus Error.  I'm
>>>>> quite familiar with Bus Errors (aka Segmentation Faults) from my days
>>>>> working in C, where attempting to access a memory location you don't
>>>>> have permissions to access would cause this problem and dump you out.
>>>>> It was usually caused by an improperly indexed array, or an erroneous
>>>>> pointer.  This all made sense in C because of how low level it was,
>>>>> giving you direct access to the memory.
>>>>>
>>>>> Filepro, at least relative to C, is much more high level.  There is no
>>>>> point at which you are attempting to manipulate the system memory
>>>>> directly so these Bus Errors should cease to exist, unless being 
>>>>> caused
>>>>> by a compiler/interpreter.  When I've questioned co-workers and other
>>>>> filepro developers in the past about what causes these errors, and how
>>>>> they can be avoided, I always get one reply, "Remove your comments."
>>>>> When I was first told this, I disputed it, and disputed it.  After 
>>>>> all,
>>>>> in all (or at least i thought all) compilers/interpreters comments are
>>>>> completely disregarded and treated as if they were simply white space.
>>>>> Sadly, I have seen several instances in which removing some 
>>>>> comments can
>>>>> remedy these errors.  In my opinion, comments are a very important 
>>>>> part
>>>>> of the code itself, especially when working in a system with several
>>>>> developers who need to be able to easily digest what another 
>>>>> programmer
>>>>> was attempting to do.  For a comment to attempt to access an
>>>>> unauthorized memory location is illogical, and I'm assuming that there
>>>>> is a better explanation for all of this.  As the days wear on, the bus
>>>>> errors seem to become more and more prevalent and are creating some
>>>>> serious issues that take me away from my daily duties.  Can anyone
>>>>> provide some helpful insight onto this problem, do comments really 
>>>>> cause
>>>>> Bus Errors?  If So why and how?  Is there a patch in the works? and 
>>>>> what
>>>>> else in FilePro can cause these nasty errors.
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>
>>>>
>>>> Ryan,
>>>>
>>>> Sorry you are getting "bus errors" in filePro.  However, you have 
>>>> failed to
>>>> provide anyone with enough information to help you.  For example:  what
>>>> version of filePro are you using?  is there an update available to a 
>>>> later
>>>> release of the same version you are using?  what operating system(s) 
>>>> are
>>>> involved?  do the systems get bus errors running anything else?
>>>>
>>>> I have been working in filePro doing development for my business 
>>>> customers
>>>> for over 20 years and I don't think this has been a problem I've 
>>>> seen for a
>>>> long, long time.  I think you have another problem that is showing 
>>>> itself
>>>> when filePro is running or you are running a very old version on a new
>>>> operating system.
>>>>
>>>> That's my 2 cents worth.
>>>>
>>>> Steve Wiltsie
>>>> microCONCEPTS Div. multi/user/inc.        Since 1981
>>>> (812) 474-0127                          Fax: (812) 474-0147
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Steve,
>>>
>>> Thanks for the quick reply.  I'm running on FP 5.0.13R4 on Solaris 
>>> 9.  We see no bus errors outside of filepro, although this server 
>>> runs only a few other applications such as a fax server.  We see 
>>> these bus errors at different times, sometimes, before the processing 
>>> even appears to begin, and other times after certain fields are 
>>> updated, the fields will be updated, but some automatic indexes may 
>>> need to be rebuilt to reflect the change because of a bus error.
>>>
>>> Thanks,
>>
>>
>> This error may be related to a corrupt file.  It could be the edits, 
>> screenss, automatic, input or output processing.  Since you say it 
>> seems to happen sometimes before you hit processing.  Do the following:
>>
>> Remove or rename the processing both auto and input (make a safe copy 
>> of course),  Remove all indexes (each and every one - document the 
>> indexes before).  Then try the file and see if it functions correctly 
>> for access , update and add (without the programming it might hot be 
>> fully functional but you will be able to tell if it is giving you bus 
>> errors.
>>
>> Then add back the indexes, create them from scratch.  and try the file 
>> again.  If it still works - add back the auto processing .  See if it 
>> still works.  (WRITE commands in the auto table could cause the 
>> problem you indicate.)
>>
>> Finally, put back the input/output processing and try it again.  If it 
>> crashes, now it will indicate the processing is causing it.
>>
>> Run the processing in debug mode and follow it till it crashes.  That 
>> will tell you where to look in the code.
>>
>> I have had crashes in the past from stuff like ab(5,.0) which was 
>> typed by mistake ab(5,.o).  Or conflicts with labels, array names, 
>> lookup names, selection table names, long variables.
>>
>> FilePro can check for syntax specific things but some errors can not 
>> be anticipated.  Those tend to cause the Bus Error type crashes.
>>
>> I have seen bad edit tables (local or global) or exceeding the 200 
>> limit can cause a crash.  (local + global edits can not exceed 200)
>>
>> Good luck,
>>
>> These are a real pain.  But there is a cause and if you persist you 
>> will track it down.
> 
> 
> 
> Pretty good hints Nancy, especially when you know some facts that 
> neither J, Ryan nor his senior co-developer Tim Fischer may be aware of 
> because their history doesn't go back much further than when that 
> Solaris box was put in. I however can say that the app they are running 
> never got bus errors on the ReadHat 7.x box it started out and ran for 
> about a year on, nor on the SCO 5.0.6 box it was moved to and ran for 
> another year or two. The bus errors arrived with the migration to Solaris.
> 
> How/why this ties in with your commens so well is, The original linux 
> install really was a platform change from our SCO development box, and 
> then a year or so later a platform change back to SCO, and neither of 
> those involved the xfer program or an endianness change. switching 
> between linux/sco/freebsd requires nothing but simple file transfer of 
> any type you like. tar/ftp, rsync, etc...
> 
> Switching to Solaris was a big project that was pretty difficult. I 
> didn't do it but I helped by answering questions and providing possible 
> work-arounds for Tim when the official way didn't work. Things like 
> using dd to byte-swap an output format or screen or other file that xfer 
> simply ignored.
> 
> I think the recommendation to take a known misbehaving file and copy it 
> and start re-creating it's parts from scratch is a solid one.

I suggest this because even on a working system with no problems I have 
seen a file go bad.  Storage is not perfect.  Now that I know more, it 
seems even more possible that one of the tables is corrupt.

I have even seen this with an old index built on @cd is in a file that 
is using 4.8 or better and has never been rebuilt with a newer index 
maint.  I have seen this when the processes tables (if using 
rclerk/rreport) are tokenized correctly.  tokenize input/output with the 
proper automatic table.

You are certainly right this could be related to filepro on the Solaris 
but to get it fixed, you need to see if you can eliminate as much as 
possible.  Narrow the bug to something they can test.  This is just too 
general to make any meaningful report.

You may need to set up a test situation.  Strip out what doesn't matter 
and see what remains.  If it still crashes, maybe it will help Ken fix it.

But I have to add, that we all get these kinds of errors and most often 
I have been able to find the cause.  Other times, I found a way that 
works without finding the cause - usually lack of time to test once a 
working solution is found.

Nancy

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