[erlang-bugs] Dialyzer problems with zlib 1.2.10 and 1.2.11

Fri Jan 20 17:45:52 CET 2017

Correction: Bug exists since OTP-17.0.

(and i tags R16B02_yielding_binary_to_term and 
OTP_R16B03_yielding_binary_to_term)

/Sverker

On 01/20/2017 05:15 PM, Sverker Eriksson wrote:
> This is indeed a problem in Erlang VM code (shallow copy of inflate 
> state)
> that has existed since R16B03, but not caused actual problem until 
> zlib v1.2.9.
>
> Fix coming up. Here is a preliminary patch for the impatient.
>
> diff --git a/erts/emulator/beam/external.c 
> b/erts/emulator/beam/external.c
> index beed847..1c4fff5 100644
> --- a/erts/emulator/beam/external.c
> +++ b/erts/emulator/beam/external.c
> @@ -1431,6 +1431,10 @@ static B2TContext* b2t_export_context(Process* 
> p, B2TContext* src)
>      if (ctx->state >= B2TDecode && ctx->u.dc.next == &src->u.dc.res) {
>          ctx->u.dc.next = &ctx->u.dc.res;
>      }
> +    else if (ctx->state == B2TUncompressChunk) {
> +        int cres = inflateCopy(&ctx->u.uc.stream, &src->u.uc.stream);
> +        ASSERT(cres == Z_OK); (void)cres;
> +    }
>      hp = HAlloc(p, PROC_BIN_SIZE);
>      ctx->trap_bin = erts_mk_magic_binary_term(&hp, &MSO(p), context_b);
>      return ctx;
>
>
> /Sverker, Erlang/OTP
>
>
> On 01/20/2017 02:49 AM, Jeremy Huffman wrote:
>> I opened a Github issue with zlib. 
>> https://github.com/madler/zlib/issues/206.
>> Mark Adler (zlib maintainer's) response:
>>
>> "Isolating it to that commit points to a problem in the application 
>> code,
>> where it must be inadvertently stomping on the deflate state, e.g. 
>> with an
>> out-of-bounds write into memory, or perhaps that the code is trying 
>> to use
>> the deflate state after it has been closed. The only change that commit
>> made was to check the integrity of the deflate structure more 
>> thoroughly on
>> each call of a deflate* function."
>>
>> On Thu, Jan 19, 2017 at 2:11 PM, Michel Boaventura <
>> michel.boaventura@REDACTED> wrote:
>>
>>> Hi,
>>>
>>> I've done the bisect and find the culprit: https://github.com/
>>> madler/zlib/commit/b516b4bdd7c0c9f0858adfebf732089014f7b282. Before 
>>> this
>>> commit term_to_binary works and stop doing so afterwards. I will have a
>>> look at the changes and see if I can figure out what happened.
>>>
>>> Cheers,
>>>
>>>
>>> On 19 January 2017 at 16:15, Michel Boaventura <
>>> michel.boaventura@REDACTED> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm indeed using zlib 1.2.11 on my gentoo. I can't downgrade it, since
>>>> all the other versions were removed from portage.
>>>>
>>>> I will clone zlib repo and see if I can bisect the problem.
>>>>
>>>> Thanks!
>>>>
>>>> On 19 January 2017 at 15:45, Jeremy Huffman <jeremy@REDACTED>
>>>> wrote:
>>>>
>>>>> Yes it's exactly the same error message from dialyzer. And the 
>>>>> fact that
>>>>> he's getting it on Gentoo which builds from source suggests that 
>>>>> it is not
>>>>> simply a matter of recompiling the dependency chain, which was a 
>>>>> suggestion
>>>>> in the Arch board. There was another app in Arch that also had a 
>>>>> problem
>>>>> pinned on zlib 1.2.11.
>>>>>
>>>>>
>>>>> On Thu, Jan 19, 2017 at 11:33 AM Kostis Sagonas <kostis@REDACTED>
>>>>> wrote:
>>>>>
>>>>>> On 01/19/2017 03:42 AM, Jeremy Huffman wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I'm an Arch Linux user and picked up an update a few days ago that
>>>>>> broke
>>>>>>
>>>>>>> dialyzer. I bisected the last few days of updates and then narrowed
>>>>>> the
>>>>>>
>>>>>>> problem to zlib 1.2.10, which was released January 2nd. 1.2.11 was
>>>>>>> released on the 15th as an emergency bug fix and does not fix the
>>>>>>> problem. Reverting my system back to 1.2.8 (the previous version
>>>>>>> packaged for Arch) did resolve the issue.
>>>>>>> It seems doubtful this is an Erlang problem, but I doubt I'm 
>>>>>>> going to
>>>>>>> write a test program to demonstrate the problem to them.  I 
>>>>>>> thought I
>>>>>>> should at least report the issue in case others encounter it.
>>>>>>> To reproduce, one would need only install zlib 1.2.10 and then run:
>>>>>>> dialyzer --verbose --build_plt --apps erts --output_plt test.plt
>>>>>>> Output would be along the lines of:
>>>>>>> dialyzer: Could not get abstract code for file:
>>>>>>> /usr/lib/erlang/lib/erts-8.2/ebin/erlang.beam (please recompile it
>>>>>> with
>>>>>>
>>>>>>> +debug_info)
>>>>>>> There are also errors when simply trying to do success typing 
>>>>>>> analysis
>>>>>>> *using* any pre-existing PLT file, along lines of "this isn't a PLT
>>>>>>> file". The errors are not dependent upon the version of Erlang
>>>>>> installed
>>>>>>
>>>>>>> - at least anything I tried that was released on Arch in the 19.x
>>>>>> branch
>>>>>>
>>>>>>> will reproduce the problem.
>>>>>>> Anyway, I hope this report helps someone and I would be curious if
>>>>>>> anyone else reproduces it, or especially if they fail to 
>>>>>>> reproduce it.
>>>>>>
>>>>>>
>>>>>> Earlier today (yesterday?), there was the following question on the
>>>>>>
>>>>>> erlang-questions mailing list:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://erlang.org/pipermail/erlang-questions/2017-January/0
>>>>>> 91434.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am willing to bet that problem with binary_to_term is also 
>>>>>> caused by
>>>>>>
>>>>>> zlib troubles.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Perhaps Michel (cc:) can inform us about his zlib version.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kostis
>>>>>>
>>>>>>
>>>>
>>>> -- 
>>>> Michel Almada de Castro Boaventura
>>>> Analista de Sistemas
>>>> Laboratório de Software Livre - LSL
>>>>
>>>
>>>
>>> -- 
>>> Michel Almada de Castro Boaventura
>>> Analista de Sistemas
>>> Laboratório de Software Livre - LSL
>>>
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20170120/f59a821f/attachment.htm>