From pascal.brisset@REDACTED Fri Apr 21 00:44:56 2006 From: pascal.brisset@REDACTED (Pascal Brisset) Date: Fri, 21 Apr 2006 00:44:56 +0200 Subject: erlc bug: no_bs_match_state (OTP-R10B-10 / compiler-4.3.12) Message-ID: <20060420224456.35E719AA83@smtp1-g19.free.fr> Erlc crashes on the attached erlang module with this error: | bug_bin: function foo/1+13: | Internal consistency check failed - please report this bug. | Instruction: {bs_restore,0} | Error: no_bs_match_state: This message comes from lib/compiler/src/beam_validator.erl, which performs a kind of abstract interpretation on the beam code. In particular, it keeps track of internal variables of the virtual machine that are used for the implementation of pattern-matching on binaries. The validity of these variables is stored in (Vst#vst.current)#st.bsm throughout the control flow analysis. Looking at the generated beam code with erlc -S: 10 {function, foo, 1, 2}. 11 {label,1}. 12 {func_info,{atom,bug_bin},{atom,foo},1}. 13 {label,2}. 14 {test,bs_start_match,{f,1},[{x,0}]}. 15 {bs_save,0}. 16 {test,bs_get_binary, 17 {f,3}, 18 [{atom,all},8,{field_flags,[aligned,unsigned,big]},{x,1}]}. 19 {test,bs_test_tail,{f,3},[0]}. 20 {bs_init2,{f,3},0,0,2,{field_flags,[]},{x,2}}. 21 {test,is_ne,{f,3},[{x,1},{x,2}]}. 22 {move,{atom,ok},{x,0}}. 23 return. 24 {label,3}. 25 {bs_restore,0}. 26 {test,bs_test_tail,{f,1},[0]}. 27 {move,{atom,ok},{x,0}}. 28 return. Lines 20-21 implement the guard Rest/=<<>>. An empty binary is created and compared to register X1, which contains Rest. beam_validator considers bsm to be invalid after bs_init2, presumably in accordance with this comment: %%% The bsm field is reset to 'undefined' by instructions that may cause a %%% a garbage collection (might move the binary) and/or context switch %%% (may invalidate the save points). As a consequence, when beam_validator examines the control flow from line 21 to line 25, it decides that bs_restore cannot execute safely. The problem also occurs whenever a guard allocates memory; for example "foo(<>) when Rest/=[0]". I'm not sure how this should be fixed. The GC could scan the pointers in erts_mb and erts_save_mb. Or the allocator could be prevented from relocating data while a binary match is in progress. Maybe earlier versions of erlc also generate "unsafe" code which goes unnoticed because they don't have beam_validator. Or maybe there is no risk at all and the validator is too strict. Credit for isolating this problem goes to Florent and Christophe at Cellicium. -- Pascal -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug_bin.erl URL: From bjorn@REDACTED Fri Apr 21 08:56:31 2006 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 21 Apr 2006 08:56:31 +0200 Subject: erlc bug: no_bs_match_state (OTP-R10B-10 / compiler-4.3.12) In-Reply-To: <20060420224456.35E719AA83@smtp1-g19.free.fr> References: <20060420224456.35E719AA83@smtp1-g19.free.fr> Message-ID: Pascal Brisset writes: > > The problem also occurs whenever a guard allocates memory; > for example "foo(<>) when Rest/=[0]". > > I'm not sure how this should be fixed. The GC could scan the > pointers in erts_mb and erts_save_mb. Or the allocator could > be prevented from relocating data while a binary match is in > progress. We have re-designed the bit syntax matching instructions in R11B to resolve this issue (and a few others). > > Maybe earlier versions of erlc also generate "unsafe" code which > goes unnoticed because they don't have beam_validator. Or maybe > there is no risk at all and the validator is too strict. > Yes, earlier version of the Erlang compiler did generate unsafe code. The beam_validator is right. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matte.az@REDACTED Mon Apr 24 16:34:35 2006 From: matte.az@REDACTED (Matteo Azzali) Date: Mon, 24 Apr 2006 16:34:35 +0200 Subject: complete incopatibility with glibc-2.4 Message-ID: <444CE1FB.6080401@libero.it> Latest erlang ( 10.2.10 ) The configure scripts giving me lib/erl_interface/config.log get an error for not finding pthread/mit/pthread.h and then nptl/pthread.h . After this the whole process of configure "explode" and system crash. The whole report is at gentoo bugzilla at: http://bugs.gentoo.org/show_bug.cgi?id=131094 Regards, Matteo From jahakala@REDACTED Tue Apr 25 16:28:29 2006 From: jahakala@REDACTED (Jani Hakala) Date: Tue, 25 Apr 2006 17:28:29 +0300 Subject: complete incopatibility with glibc-2.4 In-Reply-To: <444CE1FB.6080401@libero.it> (Matteo Azzali's message of "Mon, 24 Apr 2006 16:34:35 +0200") References: <444CE1FB.6080401@libero.it> Message-ID: <87wtddvieq.fsf@pingviini.kortex.jyu.fi> Matteo Azzali writes: > Latest erlang ( 10.2.10 ) > The configure scripts giving me lib/erl_interface/config.log get an > error for not finding > > pthread/mit/pthread.h and then nptl/pthread.h . > > After this the whole process of configure "explode" and system crash. > > The whole report is at gentoo bugzilla at: > http://bugs.gentoo.org/show_bug.cgi?id=131094 > Are you able to reproduce the problem using a stable kernel? 2.6.16 is something that is not considered stable, 2.6.12.x should be stable. I think a system crash is more likely caused by a problem with the kernel than with the glibc. Jani Hakala From matte.az@REDACTED Tue Apr 25 21:16:11 2006 From: matte.az@REDACTED (Matteo Azzali) Date: Tue, 25 Apr 2006 21:16:11 +0200 Subject: complete incopatibility with glibc-2.4 In-Reply-To: <87wtddvieq.fsf@pingviini.kortex.jyu.fi> References: <444CE1FB.6080401@libero.it> <87wtddvieq.fsf@pingviini.kortex.jyu.fi> Message-ID: <444E757B.8050804@libero.it> I couldn't try a so big rollback for a couple of causes: 1)The older 2.6.x kernel here is 2.6.14 , 2.6.12 was here before last summer.... 2)My system is changed too much in these 10-12 months, drivers headers and udev. However would be really strange if it's the kernel, since 860 packages here are compiling and working fine.... If you think you/we might find useful other logs of the system before it crashes, I can upload/send everything you might want. Matteo Jani Hakala wrote: > Matteo Azzali writes: > > >> Latest erlang ( 10.2.10 ) >> The configure scripts giving me lib/erl_interface/config.log get an >> error for not finding >> >> pthread/mit/pthread.h and then nptl/pthread.h . >> >> After this the whole process of configure "explode" and system crash. >> >> The whole report is at gentoo bugzilla at: >> http://bugs.gentoo.org/show_bug.cgi?id=131094 >> >> > Are you able to reproduce the problem using a stable kernel? > 2.6.16 is something that is not considered stable, 2.6.12.x should be > stable. > > I think a system crash is more likely caused by a problem with the > kernel than with the glibc. > > Jani Hakala > >