[m-rev.] for review: fix bug #161

Julien Fischer jfischer at opturion.com
Mon May 20 15:43:21 AEST 2013



On Mon, 20 May 2013, Paul Bone wrote:

> On Mon, May 20, 2013 at 01:42:47PM +1000, Julien Fischer wrote:
>>
>> Fix bug #161.
>>
>> In C grades, closing a file stream multiple times can lead to a segmentation
>> fault on some systems (e.g. Linux), whereas on others (e.g. Mac OS X) an
>> io.error exception is thrown.  (The difference is due to differences in the
>> semantics of fclose.)  Try to avoid the former case by checking that the
>> stream handle is non-NULL before we attempt to close it.  (mercury_close
>> zeros
>> out the relevant bits of the MercuryFile structure when we close a stream
>> so,
>> the stream handle is set to NULL the first time we close the stream.)
>>
>> library/io.m:
>>   As above.
>>
>
> Try to wrap the text in the log message a little better.  Or is this Gmail
> making life hard?

Gmail; if you know how to stop it doing that then let me know.

> Other than that the patch is fine.

I have encountered another interesting problem in attempting to produce
a test case for this.   The following program attempts to catch the
exception thrown when we call io.close_output/3 twice in a row on the
same file handle:

     io.open_output("bug161b.txt", OpenResult, !IO),
     (
         OpenResult = ok(File),
         ( try [io(!IO)] (
             io.close_output(File, !IO),
             io.close_output(File, !IO)
           )
         then
             true
         catch Error ->
             Msg = io.error_message(Error),
             io.write_string(Msg, !IO),
             io.nl(!IO)
         )
     ;
         OpenResult = error(_)
     ).

On Linux, it works in hlc.gc, but in asm_fast.gc it causes a
segmentation fault after the code in the catch goal has been executed.
I'm looking into this at the moment.

Cheers
Julien.



More information about the reviews mailing list