[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gm2] Re: FIO EOF fixed
From: |
Gaius Mulley |
Subject: |
Re: [Gm2] Re: FIO EOF fixed |
Date: |
Sat, 08 May 2010 15:39:24 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
SiTex Graphics <address@hidden> writes:
> Hi Gaius,
>
> I think I've found the problem: FIO.IsNoError() treats the new EOF
> state as an error:
>
> RETURN (fd#NIL) AND (fd^.state=successful)
>
> That is bad because according to the man page, the linux fread command
> simply returns 0 at the end of file and does not set the stream state
> to an error or set errno. When FIO.IsNoError returns FALSE at EOF,
> RTgen.checkErrno checks the errno which will be whatever was set by
> the last system call that failed. That explains the erratic behavior
> I was seeing, where some files loaded fine but others did not.
Hi Scott,
thanks for the analysis - yes it does appear so. I've made the change
below and I've had to modify a few other procedures inside FIO which
assumed IsNoError included (not eof). Also had to change a few pim
library implementations - I'm in the process of rebuilding gm2 and
running all regression tests. Once all the regressions pass I'll
commit the changes,
regards,
Gaius
>
> My quick fix is to modify IsNoError() so EOF is no longer an error:
>
> RETURN (fd#NIL) AND ((fd^.state=successful) OR (fd^.state=endoffile));
>
> which seems to work for our apps at least. I'm not sure how that
> might affect other parts of the file IO routines.
>
> Regards,
> Scott
>
>
>
> On Thu, May 6, 2010 at 11:24 PM, SiTex Graphics <address@hidden> wrote:
>> Hi Gaius,
>>
>> The behavior I reported for wraptime did indeed seem weird. I checked
>> to see whether the new .o files were properly installed and discovered
>> that the installed .o files were from January. I thought 'make
>> install' would automatically overwrite those (as it does for gm2 etc),
>> but apparently it does not.
>>
>> After removing the old .o files and re-running make install, wraptime
>> now behaves as expected.
>>
>> But IOChan.RawRead now generates an unexpected exception in our main
>> application. It only happens with some files, and so far I haven't
>> been able to reproduce the error in a standalone test. Attempting to
>> track down the exception source I tried the following after EXCEPT in
>> my wrapper procedure for RawRead:
>>
>> 1. EXCEPTION.GetMessage() doesn't return anything (and maybe even
>> generates a new exception?)
>>
>> 2. IOChan.IsChanException() returns FALSE
>>
>> 3. IOChan.DeviceError() returns 2
>>
>> -Scott
>>
>>
>> On Thu, May 6, 2010 at 7:35 AM, Gaius Mulley <address@hidden> wrote:
>>> SiTex Graphics <address@hidden> writes:
>>>
>>>> Hi Gaius,
>>>>
>>>> I'm going to cautiously say that the EOF code is working. I still
>>>> have the problem with short reads unless I use my own "vanilla"
>>>> compile of RTgen. The RTgen.o produced by the make process returns a
>>>> short read when the 16k buffer gets full and the file length is
>>>> greater than 16k but less than 32k. I can put together a test case if
>>>> that would help.
>>>
>>> Hi Scott,
>>>
>>> yes please - the more test code the better. I'm going to write some
>>> test code which reads exactly 16k and pushes a char back and then
>>> reads until eof and pushes a char back.
>>>
>>>> Also, although wraptime.c has the fix for seconds, I only get reliable
>>>> results for seconds by using a simple compile of wraptime.c instead of
>>>> the .o produced by the make process.
>>>
>>> weird - could you possibly capture the C preprocessor output of
>>> wraptime.c - you can do this by:
>>>
>>>
>>> $ cd build-4.1.2/gcc
>>> $ rm gm2/gm2-libs-iso/wraptime.o
>>> $ make gm2/gm2-libs-iso/wraptime.o
>>>
>>> <... lots of gcc command line info ...>
>>>
>>> now cut and paste this command line and repeat it but critically
>>> modify it by
>>>
>>> replacing '-c' by '-E'
>>>
>>> and altering the destination output to say
>>> -o cppwraptime.build
>>>
>>> if you can do the same for you private working compile of wraptime,
>>> say use:
>>> -o cppwraptime.local
>>>
>>> and email me these two files - hopefully I'll see enough differences.
>>> Probably a configure issue..
>>>
>>> regards,
>>> Gaius
>>>
>>
- [Gm2] FIO EOF fixed, Gaius Mulley, 2010/05/03
- [Gm2] Re: FIO EOF fixed, SiTex Graphics, 2010/05/03
- [Gm2] Re: FIO EOF fixed, Gaius Mulley, 2010/05/05
- Re: [Gm2] Re: FIO EOF fixed, Gaius Mulley, 2010/05/05
- Re: [Gm2] Re: FIO EOF fixed, SiTex Graphics, 2010/05/06
- Re: [Gm2] Re: FIO EOF fixed, Gaius Mulley, 2010/05/06
- Re: [Gm2] Re: FIO EOF fixed, SiTex Graphics, 2010/05/06
- Re: [Gm2] Re: FIO EOF fixed, SiTex Graphics, 2010/05/07
- Re: [Gm2] Re: FIO EOF fixed,
Gaius Mulley <=
- Re: [Gm2] Re: FIO EOF fixed, Gaius Mulley, 2010/05/10
- [Gm2] Re: FIO EOF fixed, john o goyo, 2010/05/06