[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