2024-12-10 09:15 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000161mercuryBugpublic2013-05-21 16:51
Reporterpbone 
Assigned Tojuliensf 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusassignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000161: Calling io.seen/2 twice in a row can crash the runtime with a segfault.
DescriptionThe following program crashes the runtime with a segfault.

:- module main.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.

:- implementation.

main(!IO) :- seen(!IO), seen(!IO).
 
This was reported via the #mercury IRC channel on the Freenode IRC network.
I'm waiting for the user to tell me what version of Mercury they're using and which grade they're using. I havn't attempted to reproduce this myself.

TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000514

juliensf (administrator)

With rotd-2013-05-17, in the hlc.gc grade (on Mac OS X 10.8) it gives me:

    Uncaught Mercury exception:
    io_error("error closing file: Bad address")

which seems fine. Did the original user ever get back to you about what they were using?

~0000515

juliensf (administrator)

I do however get the seg fault in both asm_fast.gc and hlc.gc grades on x86_64 Linux.
(Mercury 13.05-beta-2013-05-02)

~0000516

juliensf (administrator)

The right fix here IMO, is to change mercury_close so that it checks that the file pointer it is attempting
to close is non-NULL before attempting to close it. (After calling MR_CLOSE the first time, we NULL out
the file pointer, so this should be enough to fix the multiple io.seen/2 case.)

~0000517

pbone (administrator)

I don't remember, or was never told what version/grade the user was using. In any case I agree with your conclusion.

~0000519

juliensf (administrator)

I'll add a fix for this sometime during this week.

~0000523

juliensf (administrator)

I've committed a fix that avoids the segmentation fault that occurs when closing the same file stream multiple times (the actual issue here). There appears to be in an issue on the asm_fast.gc grades on Linux with handling the exception that now occurs. I am still investigating this.
+Notes

-Issue History
Date Modified Username Field Change
2010-09-08 16:45 pbone New Issue
2011-02-08 16:28 pbone Status new => assigned
2011-02-08 16:28 pbone Assigned To => pbone
2013-05-17 16:49 juliensf Note Added: 0000514
2013-05-17 16:51 juliensf Note Added: 0000515
2013-05-17 17:10 juliensf Note Added: 0000516
2013-05-18 12:51 pbone Note Added: 0000517
2013-05-19 17:59 juliensf Note Added: 0000519
2013-05-19 17:59 juliensf Assigned To pbone => juliensf
2013-05-21 16:51 juliensf Note Added: 0000523
+Issue History