You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was seeing this issue in step9 tests and simplified it down to the following test file (vala-memory-corruption.mal):
(try* (nth () 1) (catch* e (prn "e:" e)))
(try* (list 1) (catch* e (prn "e:" e)))
(try* (throw "e") (catch* e (do (prn "e:" e) 7)))
(try* (do (try* "t1" (catch* e "c1")) (throw "e1")) (catch* e "c2"))
(try* (try* (throw "e1") (catch* e (throw "e2"))) (catch* e "c2"))
(try* (map throw (list "my err")) (catch* e e))
(try* (eval (read-string "(+ 1")) (catch* e (prn :e e)))
;; This fails
(map (fn* (x) (list? x)) (list 1 2 3))
;=>(false false false)
Note that it is very sensitive to exactly the content above. If you duplicate or remove any of the try/catch or modify them in any significant way then the problem in the last test goes away (fairly strong indication of memory corruption).
Run the test above in self-hosted mode (vala stepA running mal step9) like this:
@sgtatham Since you contributed the vala implementation, any chance you want to take a look at this? If it's not immediately obvious, I would probably try and leverage valgrind (unless vala has a more bespoke memory leak debug program).
The text was updated successfully, but these errors were encountered:
I'm sorry to say that I haven't touched Vala since then! I wrote a Vala implementation of mal because it seemed like a good way to learn the language in the first place, which I wanted to do in order to work on an existing program written in it. But then I gave up on the thing I wanted to do to that program. In order to debug this, I'd have to relearn a lot of stuff from scratch.
I agree valgrind or ASan is probably a good place to start, because Vala compiles down to C using the GLib APIs.
I was seeing this issue in step9 tests and simplified it down to the following test file (
vala-memory-corruption.mal
):Note that it is very sensitive to exactly the content above. If you duplicate or remove any of the try/catch or modify them in any significant way then the problem in the last test goes away (fairly strong indication of memory corruption).
Run the test above in self-hosted mode (vala stepA running mal step9) like this:
@sgtatham Since you contributed the vala implementation, any chance you want to take a look at this? If it's not immediately obvious, I would probably try and leverage valgrind (unless vala has a more bespoke memory leak debug program).
The text was updated successfully, but these errors were encountered: