|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000356||mercury||Bug||public||2014-08-30 10:30||2014-08-31 11:11|
|Platform||x86_64-pc-linux-gnu||OS||Ubuntu||OS Version||14.04 'Trusty'|
|Target Version||Fixed in Version|
|Summary||0000356: mmc exception thrown from instmap.m line 600|
|Description||Okay, I'm still going through it all, I'm just floored that I got mmc to spit out a runtime error.|
Uncaught Mercury exception:
Software Error: hlds.instmap: predicate `hlds.instmap.instmapping_set_vars_corresponding'/4: Unexpected: not_reached
Here's a pastebin of the source I was working on: http://pastebin.com/Z6Fau9b3
The lines that I was editing (trying to get the switch to infer as det) when mmc started to throw exceptions are 682 - 684. The entire clause is pasted for convenience.
lua_pcall(L, A) = R :-
impure Result = lua_pcall(L, A, 0),
( Result = returned(R) % line 682
; Result = returned_error(Error), throw(Error)
; unexpected($module, $pred, "Invalid result value. (WTF?)") % line 684
Using if-> calls rather than raw disjuncts originally triggered this. I'm going to be focusing on trying to re-arrange this clause in a manner that does not cause mmc to toss cookies.
I've located the exception I've triggered in the source, instmap.m line 600, although I don't know the inner workings of the compiler to begin knowing how to interpret it.
expect(negate(unify(Inst, not_reached)), $module, $pred, "not_reached"),
Note: I also compiled the same code under asm_fast.gc.trseg and got the same response.
|Steps To Reproduce||I've created a branch from my project with my code in the exact state it was in when I produced this issue:|
I was able to produce this with the line
mmc --make testluaMR
with both asm_fast.gc.trseg.debug.stseg and asm_fast.gc.trseg
emphasis placed on the options I'm using in Mercury.options
|Additional Information||I'm at a loss. This library is in mid-development, and as such, it's very unstable ... I'm a long way from making a stable release. Please let me know if there's any kind of information that might help provide more light on this.|
|Tags||No tags attached.|
I forgot to mention that this was all on mercury 14.01
These are the availible grades I have installed are:
Last edited: 2014-08-30 11:27
I think I found my mistake in api.m
line 251: :- impure func lua_pcall(lua, int) = int.
should be: :- impure func lua_pcall(lua, int) = lua_result.
I'm not experienced with C ... but C's laziness as to true type safety is making me lazy as to casts between equivalent C types.
the actual lua.h's lua_pcall returns an int, and I've defined several DU types related to the output of lua_pcall:
:- type lua_result
:- type lua_error
---> lua_error(error_type, string).
:- type error_type
:- pragma foreign_enum("C", error_type/0,
no_error - "0",
runtime_error - "LUA_ERRRUN",
syntax_error - "LUA_ERRSYNTAX",
memory_error - "LUA_ERRMEM",
unhandled_error - "LUA_ERRERR"
I'm still not sure what's exactly is causing the runtime error, but my code, in terms of what I've linked in the branch in the reproduction section, treats mercury code type safety as if it were C type safety (with certain implicit casts assumed).
To be specific, I beleive that the runtime error was produced by my inadvertant attempt to implicitly cast int.int to luaMR.api.lua_result.
Okay, I've corrected the type saftey issue I've found in api.m, but I'm still producing the same runtime error from mmc.
Here's the corrected branch: https://github.com/C4Cypher/Apollo-lander/tree/mmc_exception_thrown_instmap2
The compiler abort is actually coming when the compiler is mode checking trail_to_func in state.m; specifically, when it is mode checking the unification that binds F to the lambda goal on line 236 of state.m. As far as I can tell, it has nothing to do with the code in api.m.
The call that leads to the compiler abort is in modecheck_unify.m at line 440.
The not_reached inst belongs to R (var6), which is a nonlocal of the lambda expression.
|trail_to_func is the function causing the compiler to abort. Changing the code in any number of ways will work around the issue.|
Interesting, and yeah, looking at this now, I failed at logic in a strange manner
trail_to_func(Trail) = Func :- % Trail := discriminated union
( wtf_goal(Trail, Func) ) -> Func = ( lambada_goal ) ; unexpected($module, $pred, "derp").
What I actually intended was to bind Func to lambada_goal, iff wtf_goal fails to bind Func to a ho value.
What my pred actually did was, on some branches, bind Func to a ho value of type impure func(lua::in) = (int::out), and then on success, unify Func again with another lambada of that same type.
I can correct this, thanks both of you for pointing out where things were going pear shaped. Thanks again for what has otherwise been an absolutely awsome compiler.
Last edited: 2014-08-31 11:11
I'd like to thank the team for the quick response and the assistance.
I'm not certain what caused the runtime error, but I was able to rewrite my code in a manner that the compiler likes.
trail_to_func(unique_state(L, _, T)) = F :-
require_complete_switch [T] some [R]
( T = lua_func(F0) -> F = F0
; T = empty_trail ->
F = ( impure func(_::in) = (0::out) is det :- true )
; T = c_function(C) ->
impure lua_pushcfunction(L, C),
semipure R = lua_toref(L, index(-1)),
impure lua_pop(L, 1),
F = ref_to_func(R)
; T = ref(R) ->
F = ref_to_func(R)
; unexpected($module, $pred,
"Unknown lua_trail value provided.")
Given that I've found something that works, from my end, I consider the matter closed, however, if there's any way I can assist, please let me know.
|2014-08-30 10:30||C4Cypher||New Issue|
|2014-08-30 10:39||C4Cypher||Note Added: 0000769|
|2014-08-30 11:23||C4Cypher||Note Added: 0000770|
|2014-08-30 11:27||C4Cypher||Note Edited: 0000770||View Revisions|
|2014-08-30 11:52||C4Cypher||Note Added: 0000771|
|2014-08-30 12:16||zs||Note Added: 0000772|
|2014-08-30 12:20||wangp||Note Added: 0000773|
|2014-08-30 12:59||C4Cypher||Note Added: 0000774|
|2014-08-31 11:09||C4Cypher||Note Added: 0000775|
|2014-08-31 11:10||C4Cypher||Note Edited: 0000775||View Revisions|
|2014-08-31 11:11||C4Cypher||Note Edited: 0000775||View Revisions|