[erlang-bugs] R14B04 and R15A: Possible bug when compiling code using binary expressions with hipe

[Kostis Sagonas]

On 12/09/11 23:34, Magnus Klaar wrote:
> Hi!
>
> We found some code that successfully compiles to bytecode and behaves as
> expected using the beam interpreter but fails to compile using the hipe
> compiler. The code in questions is the 'cowboy_http' module in the
> cowboy web server. The code is available to browse online at
> https://github.com/extend/cowboy
>
> The module contains many occurances of <<..., Var/bits>> patterns.
> Replacing all occurances of "bits" with "binary" solves the problem. I
> tried this because the code is only working on character strings,
> matching out bitstrings doesn't make much sense to begin with. I have
> reproduced the error on 64bit builds of the R14B04 and R15A releases
> under GNU/Linux (Debian wheezy). I did not try older releases to check
> if it is a new issue.
>
> To reproduce the error. Execute the following steps on a system with
> either one of these releases installed....

Thanks for the bug report.  This was mote than enough information to 
reproduce the compiler crash and pinpoint where it occurs.  For the file 
that contains it, it happens in function word/2 and I suggest that for 
the time being you modify the first clause of that function to contain 
_/binary instead of _/bits.  This will bypass the problem and I think it 
will allow cowboy to be compiled to native code.


However, the native compiler crash should be fixed.  It really boils 
down to the following code:

   -module(cowboy).
   -export([f/1]).

   f(<<42, _/bits>> = B) -> B.

for which the BEAM compiler produces:

   label 1:
     {func_info,{atom,cowboy},{atom,f},1}
   label 2:
     {test,bs_start_match2,{f,1},[{x,0},1,0,{x,1}]}
     {test,bs_match_string,{f,1},[{x,1},8,<<"*">>]}
     return

This is obviously correct BEAM code, but I think it's suboptimal. I 
would have expected some lighter-weight instruction instead of a 
bs_match_string one, which presumably involves some loop in its 
implementation.  Bjorn what say you?

Anyway, the crash is not due to that.  It's due to this instruction not 
being followed by some other one, like a bs_check_unit or a 
bs_test_tail.  This confuses the native code compiler.

I will fix this, but I am afraid it's too late for R15B.

Kostis