segmentation violation in fp
Fairlight
fairlite at fairlite.com
Wed Aug 18 12:16:19 PDT 2004
Copying fpsupport on this as a bug report.
Is it just me, or did Patowic say:
> I'm seeing a segmentation violation in the following circumstances:
>
> I create an output processing table.
> I enter data into it, and save it.
> I then re-open it, delete all the contents, and resave it
> (I note that the size never goes under 3100 bytes, as well)
> Then, I try to reopen it for editing.
>
> fp 5.0.14 under SuSE 9.1.
> Can anyone else replicate this?
Replicated on SuSE 9.0 (latest errata installed as of 08/17/04) with
dcabe from 5.0.13D4. Also replicated on RH 7.2 with last EOL errata
available, also with 5.0.13D4. Under RHEL3 with 5.0.13D4 and 5.0.13R4 it
acts a bit differently, but still problematically,
Replication steps:
1) Create output processing table with dcabe. Filename: test
2) Created 2 lines of processing. Specifically in my case, a simple:
test::end:
::show "hi":
3) Saved file.
4) Entered dcabe again and blanked the two lines of code.
5) Saved file.
6) Tried to enter the processing table again and received an immediate segv
on RH 7.2 and SuSE 9.0 with a full Abort exit. Under RHEL3, both rcabe
and dcabe would "hang" at the point where you selected the table, clearing
the selection box as the last step before hanging, but never switching to
the processing editor screen. If you send a SIGINT, it will segv, then
go back to the 4-choice "type of table" menu of *cabe, but it's entirely
non-functional there. and SIGINT and SIGQUIT are useless at this point.
If you kill off your terminal session and come back, the process is still
hung, and you must manually kill it. The default SIGTERM will eliminate
the process and free the lock on the file. RHEL3 system is fully up to
date with all vendor-supplied errata.
I have a suspicion (though no proof) that the difference in behaviour may
be due to the kernel differences. RH 7.2 and SuSE 9.0 both use 2.4-based
kernels with the original 2.4 ABI/API. RHEL3, it seems, uses similar
kernel mods to those that appeared in RH9--namely the presence of NTPL and
the attendant ABI/API changes that were back-ported from the 2.6 kernel
into RH's 2.4.21 branch. That's my primary guess as to the differences in
behaviours between linux platforms, but I have zero evidence of this as a
causative distinction. I currently have no access to a pure 2.6 kernel
based system on which filePro is installed and on which I could test to try
and verify this assumption.
mark->
--
Fairlight-> ||| "Strung out in Heaven's high, | Fairlight Consulting
__/\__ ||| hitting an all time low..." -- |
<__<>__> ||| Bowie | http://www.fairlite.com
\/ ||| | info at fairlite.com
More information about the Filepro-list
mailing list