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

[Sverker Eriksson]

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

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