Re: Dialyzer problems with zlib 1.2.10 and 1.2.11
Jeremy Huffman <[email protected]> Thu, 19 Jan 2017 20:49:46 -0500
| Newsgroups | gmane.comp.lang.erlang.bugs |
|---|---|
| Message-ID | <CAH37v0==2nquw9J9y+htmckHCfjpnxXuG+HF0mZuzeU4Q2kGVQ@mail.gmail.com> |
--===============3974485758082634577== Content-Type: multipart/alternative; boundary=001a11444b52594cf105467cdd56 --001a11444b52594cf105467cdd56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I opened a Github issue with zlib. https://github.com/madler/zlib/issues/20= 6. 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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> >> wrote: >> >>> Yes it's exactly the same error message from dialyzer. And the fact tha= t >>> 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 sugges= tion >>> in the Arch board. There was another app in Arch that also had a proble= m >>> pinned on zlib 1.2.11. >>> >>> >>> On Thu, Jan 19, 2017 at 11:33 AM Kostis Sagonas <[email protected]> >>> 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 t= o >>>> >>>> > 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 analys= is >>>> >>>> > *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 i= t. >>>> >>>> >>>> >>>> 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=C3=B3rio de Software Livre - LSL >> > > > > -- > Michel Almada de Castro Boaventura > Analista de Sistemas > Laborat=C3=B3rio de Software Livre - LSL > --001a11444b52594cf105467cdd56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I opened a Github issue with zlib. <a href=3D"https://gith= ub.com/madler/zlib/issues/206">https://github.com/madler/zlib/issues/206</a= >. Mark Adler (zlib maintainer's) response:<div><br></div><div>"<s= pan style=3D"color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfo= nt,"segoe ui",helvetica,arial,sans-serif,"apple color emoji&= quot;,"segoe ui emoji","segoe ui symbol";font-size:14px= ">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 mad= e was to check the integrity of the deflate structure more thoroughly on ea= ch call of a deflate* function."</span></div></div><div class=3D"gmail= _extra"><br><div class=3D"gmail_quote">On Thu, Jan 19, 2017 at 2:11 PM, Mic= hel Boaventura <span dir=3D"ltr"><<a href=3D"mailto:michel.boaventura@gm= ail.com" target=3D"_blank">[email protected]</a>></span> wrote= :<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div= >I've done the bisect and find the culprit:=C2=A0<a href=3D"https://git= hub.com/madler/zlib/commit/b516b4bdd7c0c9f0858adfebf732089014f7b282" target= =3D"_blank">https://github.com/<wbr>madler/zlib/commit/<wbr>b516b4bdd7c0c9f= 0858adfebf73208<wbr>9014f7b282</a>. 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.</div><div><br></div><div>Cheers,</div><div= ><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmai= l_extra"><br><div class=3D"gmail_quote">On 19 January 2017 at 16:15, Michel= Boaventura <span dir=3D"ltr"><<a href=3D"mailto:michel.boaventura@gmail= .com" target=3D"_blank">[email protected]</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><di= v>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.</div><div><br></div= ><div>I will clone zlib repo and see if I can bisect the problem.</div><div= ><br></div><div>Thanks!</div></div><div class=3D"gmail_extra"><div><div cla= ss=3D"m_1941915932271898603h5"><br><div class=3D"gmail_quote">On 19 January= 2017 at 15:45, Jeremy Huffman <span dir=3D"ltr"><<a href=3D"mailto:jere= [email protected]" target=3D"_blank">[email protected]</a>></s= pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div><div class=3D"m_1941915932271898603m_-2202150234236710351HOEnZb"><= div class=3D"m_1941915932271898603m_-2202150234236710351h5"><div><br></div>= <div><br><div class=3D"gmail_quote"><div>On Thu, Jan 19, 2017 at 11:33 AM K= ostis Sagonas <<a href=3D"mailto:[email protected]" target=3D"_blank">ko= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 0= 1/19/2017 03:42 AM, Jeremy Huffman wrote:<br class=3D"m_1941915932271898603= m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>> Hi,<br clas= s=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485159gmail= _msg"><br>><br class=3D"m_1941915932271898603m_-2202150234236710351m_-30= 24271280197485159gmail_msg"><br>> I'm an Arch Linux user and picked = up an update a few days ago that broke<br class=3D"m_1941915932271898603m_-= 2202150234236710351m_-3024271280197485159gmail_msg"><br>> dialyzer. I bi= sected the last few days of updates and then narrowed the<br class=3D"m_194= 1915932271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>= > problem to zlib 1.2.10, which was released January 2nd. 1.2.11 was<br = class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485159g= mail_msg"><br>> released on the 15th as an emergency bug fix and does no= t fix the<br class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271= 280197485159gmail_msg"><br>> problem. Reverting my system back to 1.2.8 = (the previous version<br class=3D"m_1941915932271898603m_-22021502342367103= 51m_-3024271280197485159gmail_msg"><br>> packaged for Arch) did resolve = the issue.<br class=3D"m_1941915932271898603m_-2202150234236710351m_-302427= 1280197485159gmail_msg"><br>><br class=3D"m_1941915932271898603m_-220215= 0234236710351m_-3024271280197485159gmail_msg"><br>> It seems doubtful th= is is an Erlang problem, but I doubt I'm going to<br class=3D"m_1941915= 932271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>>= write a test program to demonstrate the problem to them.=C2=A0 I thought I= <br class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485= 159gmail_msg"><br>> should at least report the issue in case others enco= unter it.<br class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271= 280197485159gmail_msg"><br>><br class=3D"m_1941915932271898603m_-2202150= 234236710351m_-3024271280197485159gmail_msg"><br>> To reproduce, one wou= ld need only install zlib 1.2.10 and then run:<br class=3D"m_19419159322718= 98603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>><br cla= ss=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485159gmai= l_msg"><br>> dialyzer --verbose --build_plt --apps erts --output_plt tes= t.plt<br class=3D"m_1941915932271898603m_-2202150234236710351m_-30242712801= 97485159gmail_msg"><br>><br class=3D"m_1941915932271898603m_-22021502342= 36710351m_-3024271280197485159gmail_msg"><br>> Output would be along the= lines of:<br class=3D"m_1941915932271898603m_-2202150234236710351m_-302427= 1280197485159gmail_msg"><br>><br class=3D"m_1941915932271898603m_-220215= 0234236710351m_-3024271280197485159gmail_msg"><br>> dialyzer: Could not = get abstract code for file:<br class=3D"m_1941915932271898603m_-22021502342= 36710351m_-3024271280197485159gmail_msg"><br>> /usr/lib/erlang/lib/erts-= 8.2/e<wbr>bin/erlang.beam (please recompile it with<br class=3D"m_194191593= 2271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>> += debug_info)<br class=3D"m_1941915932271898603m_-2202150234236710351m_-30242= 71280197485159gmail_msg"><br>><br class=3D"m_1941915932271898603m_-22021= 50234236710351m_-3024271280197485159gmail_msg"><br>> There are also erro= rs when simply trying to do success typing analysis<br class=3D"m_194191593= 2271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>> *= using* any pre-existing PLT file, along lines of "this isn't a PLT= <br class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485= 159gmail_msg"><br>> file". The errors are not dependent upon the ve= rsion of Erlang installed<br class=3D"m_1941915932271898603m_-2202150234236= 710351m_-3024271280197485159gmail_msg"><br>> - at least anything I tried= that was released on Arch in the 19.x branch<br class=3D"m_194191593227189= 8603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>> will re= produce the problem.<br class=3D"m_1941915932271898603m_-220215023423671035= 1m_-3024271280197485159gmail_msg"><br>><br class=3D"m_194191593227189860= 3m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>> Anyway, I = hope this report helps someone and I would be curious if<br class=3D"m_1941= 915932271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>&= gt; anyone else reproduces it, or especially if they fail to reproduce it.<= br class=3D"m_1941915932271898603m_-2202150234236710351m_-30242712801974851= 59gmail_msg"><br><br class=3D"m_1941915932271898603m_-2202150234236710351m_= -3024271280197485159gmail_msg"><br>Earlier today (yesterday?), there was th= e following question on the<br class=3D"m_1941915932271898603m_-22021502342= 36710351m_-3024271280197485159gmail_msg"><br>erlang-questions mailing list:= <br class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485= 159gmail_msg"><br><br class=3D"m_1941915932271898603m_-2202150234236710351m= _-3024271280197485159gmail_msg"><br>=C2=A0 =C2=A0<a href=3D"http://erlang.o= rg/pipermail/erlang-questions/2017-January/091434.html" rel=3D"noreferrer" = class=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485159g= mail_msg" target=3D"_blank">http://erlang.org/pipermail/e<wbr>rlang-questio= ns/2017-January/0<wbr>91434.html</a><br class=3D"m_1941915932271898603m_-22= 02150234236710351m_-3024271280197485159gmail_msg"><br><br class=3D"m_194191= 5932271898603m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>I a= m willing to bet that problem with binary_to_term is also caused by<br clas= s=3D"m_1941915932271898603m_-2202150234236710351m_-3024271280197485159gmail= _msg"><br>zlib troubles.<br class=3D"m_1941915932271898603m_-22021502342367= 10351m_-3024271280197485159gmail_msg"><br><br class=3D"m_194191593227189860= 3m_-2202150234236710351m_-3024271280197485159gmail_msg"><br>Perhaps Michel = (cc:) can inform us about his zlib version.<br class=3D"m_19419159322718986= 03m_-2202150234236710351m_-3024271280197485159gmail_msg"><br><br class=3D"m= _1941915932271898603m_-2202150234236710351m_-3024271280197485159gmail_msg">= <br>Kostis<br class=3D"m_1941915932271898603m_-2202150234236710351m_-302427= 1280197485159gmail_msg"><br></blockquote></div></div> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><= /div><span class=3D"m_1941915932271898603HOEnZb"><font color=3D"#888888">--= <br><div class=3D"m_1941915932271898603m_-2202150234236710351gmail_signatu= re" data-smartmail=3D"gmail_signature">Michel Almada de Castro Boaventura<b= r>Analista de Sistemas<br>Laborat=C3=B3rio de Software Livre - LSL</div> </font></span></div> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class= =3D"m_1941915932271898603gmail_signature" data-smartmail=3D"gmail_signature= ">Michel Almada de Castro Boaventura<br>Analista de Sistemas<br>Laborat=C3= =B3rio de Software Livre - LSL</div> </div> </div></div></blockquote></div><br></div> --001a11444b52594cf105467cdd56-- --===============3974485758082634577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ erlang-bugs mailing list [email protected] http://erlang.org/mailman/listinfo/erlang-bugs --===============3974485758082634577==--