Mercury Bugs - mercury
View Issue Details
0000161mercuryBugpublic2010-09-08 16:452013-05-21 16:51
Reporterpbone 
Assigned Tojuliensf 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusassignedResolutionopen 
PlatformOSOS Version
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

Notes
(0000514)
juliensf   
2013-05-17 16:49   
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   
2013-05-17 16:51   
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   
2013-05-17 17:10   
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   
2013-05-18 12:51   
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   
2013-05-19 17:59   
I'll add a fix for this sometime during this week.
(0000523)
juliensf   
2013-05-21 16:51   
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.

Issue History
2010-09-08 16:45pboneNew Issue
2011-02-08 16:28pboneStatusnew => assigned
2011-02-08 16:28pboneAssigned To => pbone
2013-05-17 16:49juliensfNote Added: 0000514
2013-05-17 16:51juliensfNote Added: 0000515
2013-05-17 17:10juliensfNote Added: 0000516
2013-05-18 12:51pboneNote Added: 0000517
2013-05-19 17:59juliensfNote Added: 0000519
2013-05-19 17:59juliensfAssigned Topbone => juliensf
2013-05-21 16:51juliensfNote Added: 0000523