<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Here is a pull request that i think solved this problem.<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/erlang/otp/pull/690">https://github.com/erlang/otp/pull/690</a><br>
<br>
It would be good if you could test it out.<br>
The fix is both in the hipe compiler and in the VM,<br>
which means you have to rebuild both<br>
and then your own code with the new compiler.<br>
<br>
/Sverker, Erlang/OTP<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/02/2015 10:20 AM, Johannes Weißl
wrote:<br>
</div>
<blockquote cite="mid:20150402082002.GA28276@molb.org" type="cite">
<pre wrap="">Hi,
A short update: The reported HiPE bug is still present and reproducible
in OTP 17.5 and 18.0-rc1.
We had to modify the 'crash.erl' program a little bit after commits
5a7b211 and 7b10ff7 (this shows how fragile it is!), so I'm attaching
the latest version:
MD5 (crash.erl) = 41d0e4e8ed7039dc898a16135aa62bcb
MD5 (crash_it.escript) = f7756e997d9ca28f6d523086e8c37f91
MD5 (data.jsn) = a0ee43e0e63aea6f3c89c41cc3b5d378
To reproduce the bug, save all three files in one directory, make
'crash_it.escript' executable and run it. It compiles 'crash.erl'
with HiPE enabled, and produces a crash, which does not occur without
HiPE. See also the 'Details' section below for more information about
the bug.
Regards,
Johannes Weißl and Sebastian Egner
On Mon, Sep 09, 2013 at 02:20PM +0000, Sebastian Egner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>.
After a long and bloody fight, we have been able to isolate the problem to the degree
that it is sufficiently reproducible. See details below.
We strongly suspect that the problem is a genuine bug related to the binary matching
and the garbage collector. Whether the bug is hit depends on the memory contents
of previously allocated heap-allocated binaries.
Best regards,
Johannes Weissl and Sebastian Egner.
--
Details:
- The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again,
and after a wildly varying number of iterations (100-100000) the parser fails.
- To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn".
When the bug is hit, the program stops. This takes several seconds to minutes.
- The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>>
in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.)
- Surprisingly, we have not been able to reduce the program even more.
In particular, when randomize_memory/0 is not called, the problem is much less frequent.
- The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81).
- The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator.
This indicates that the bug is not related to the operating system platform.
- We have run the program in Valgrind and found conditionals that depend on uninitialised
values. Refer to "valgrind.out" for details.
Attachments:
MD5 (crash.erl) = 1f1507c8238e2136d9163314bcac0045
MD5 (crash_it) = 4061276b89dfc822cbfc22002f202358
MD5 (data.jsn) = c5b503cc61d76adc7dcb60832a123b99
MD5 (valgrind.out) = 2e6f67bf06b3df66c6daf728444b9b66
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-bugs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-bugs">http://erlang.org/mailman/listinfo/erlang-bugs</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>