Dialyzer problems with zlib 1.2.10 and 1.2.11

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Dialyzer problems with zlib 1.2.10 and 1.2.11

Jeremy Huffman
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.

Regards,

Jeremy

_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Kostis Sagonas-2
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/091434.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
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Jeremy Huffman
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 <[hidden email]> 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/091434.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


_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Jeremy Huffman
Brilliant, I passed this along to the Arch thread and it was confirmed to be the same commit breaking manaplus. Obviously it is not breaking every zlib user but I'm sure will be widespread.



On Thu, Jan 19, 2017 at 2:11 PM Michel Boaventura <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/091434.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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Jeremy Huffman
In reply to this post by Jeremy Huffman
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/091434.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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Sverker Eriksson-4
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 <
[hidden email]> 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 <
[hidden email]> 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 [hidden email]
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 [hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs


_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Jeremy Huffman
Excellent - thanks so much !
On Fri, Jan 20, 2017 at 11:16 AM Sverker Eriksson <[hidden email]> 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 <

[hidden email]> 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 <

[hidden email]> 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 [hidden email]

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 [hidden email]

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

[hidden email]

http://erlang.org/mailman/listinfo/erlang-bugs













_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Reply | Threaded
Open this post in threaded view
|

Re: Dialyzer problems with zlib 1.2.10 and 1.2.11

Sverker Eriksson-4
In reply to this post by Sverker Eriksson-4

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 <
[hidden email]> 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 <
[hidden email]> 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 [hidden email]
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 [hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs




_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs


_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs