From hans.bolinder@REDACTED Thu Jul 1 10:27:49 2010 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 1 Jul 2010 10:27:49 +0200 Subject: [erlang-bugs] Funny behaviour from dets In-Reply-To: <594DB7712E254C5FA696BB49115A4E65@HALL> References: <594DB7712E254C5FA696BB49115A4E65@HALL> Message-ID: <19500.20869.830901.851826@ornendil.du.uab.ericsson.se> [John Hughes:] > I'm playing with dets and QuickCheck, and have encountered behaviour > that seems strange to me--although I'm not entirely clear on how > dets is supposed to behave if the table is modified during a > traversal, so I can't say for certain that this is a bug. It's a short-coming of Dets. There is a note about it in dets(3), safe_fixtable/2: It is not guaranteed that calls to first/1, next/2, select and match functions work as expected even if the table has been fixed; the limited support for concurrency implemented in Ets has not yet been implemented in Dets. Fixing a table currently only disables resizing of the hash list of the table. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From alex.demidenko@REDACTED Fri Jul 2 05:25:13 2010 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Fri, 2 Jul 2010 10:25:13 +0700 Subject: SSH-1.1.8, incomplete application reference dependence Message-ID: Erlang application ssh, use function from pulic_key, but inside ssh.app is no reference dependence from public_key. as a result, tools like Sinan, build invalid packages. PS Tested on Erlang 13b4, ssh-1.1.8. -- --------------------------------------------- With best regards, Alexander. From egil@REDACTED Fri Jul 2 14:30:19 2010 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 02 Jul 2010 14:30:19 +0200 Subject: [erlang-bugs] Failures of Erlang 14A with LDFLAGS="-Wl,--as-needed" In-Reply-To: <20100630165342.02025712@gentoo.org> References: <20100628143844.18f0ea64@gentoo.org> <20100630165342.02025712@gentoo.org> Message-ID: <4C2DDBDB.9050107@erix.ericsson.se> Hi Christian, Thank you for pointing out this issue and submitting a patch. I will include this fix in the (internal) pu-branch. Regards, Bj?rn-Egil Erlang/OTP On 2010-06-30 16:53, Christian Faulhammer wrote: > Hi, > > Christian Faulhammer: >> when building with above linker flags on Linux, a build failure >> appears as shown in the attached build.log. Similar failures have >> been fixed in the past already. > > Attached is a patch to fix this issue, courtesy of Samuli Suominen of > Gentoo project. > > V-Li > From knutbakke@REDACTED Tue Jul 6 08:58:57 2010 From: knutbakke@REDACTED (Knut Bakke) Date: Mon, 5 Jul 2010 23:58:57 -0700 (PDT) Subject: bug report: ets:select/2 hangs and consumer 100% CPU Message-ID: <759689.11884.qm@web65501.mail.ac4.yahoo.com> Version R13B03, R14A Slogan: "ets:select/2 hangs and consumer 100% CPU" Very rarely, like once very week on a 10 hrs running system pr day doing ets:select about 10 times a sec, the system locks up in 100% CPU with ets:select/2 never returning. The table is very small, about 100 items, could be less. Observations) 1) If the process with the hanging ets:select/2 is killed, the involved table is deleted and rebuild with the exact same content. Applying the same ets:select/2, same match spec, will cause a new hanging. 2) By deleting objects, one by one, the hang finally disappears (maybe after 20 objects have been deleted). 3) The table is only accessed though ONE erlang process. 4) The table is of type [public, ordered_set] We have captured one situation of a hang, writing out the match specification and dumping the ets table to file, using tab2file. The problem is reproducible by: 1) {ok,Tab}=ets:file2tab("EtsSelectHang_)20100628.txt"). %% Please let me know and I send the file. too big 2) ets:select(Tab, [{{{guard,true,'$1','_','_','_','_','$2','_',undefined},'$9'}, [{'<','$1',63444947604},{'/=','$2',this}], ['$_']}]). The problem is resolved by simply deleting all objects in the table, making ets:select/2 return immediately. I have not captured the return value. Could not enclose file needed in 1). To big according to ezmlm Observations 2) We have also captured ONE case where ets:select(Tab,Match,1) has returned ALL objects fo the Match. It should only return 1 object. Don't know if it's relevant for this case. Have no logs on that case. Thank you. -knut From adam.lindberg@REDACTED Tue Jul 6 13:21:48 2010 From: adam.lindberg@REDACTED (Adam Lindberg) Date: Tue, 6 Jul 2010 11:21:48 +0000 (GMT) Subject: Bug in HiPE compiled compiler In-Reply-To: <888503893.570941278415261322.JavaMail.root@zimbra> Message-ID: <850646195.570961278415308824.JavaMail.root@zimbra> Hi, The following module produces a compiler error in R13B03 and R13B04: -module(a). f() -> hipe is broken. The error is, just as expected: $> erlc a.erl a.erl:2: syntax error before: is However, if the compiler is HiPE compiled (with NATIVE_LIBS_ENABLED=yes), the following error occurs: $> erlc a.erl a.erl:none: internal error in parse_module; crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, {erl_parse,yeccpars0,5}, {epp,parse_file,1}, {epp,parse_file,1}, {epp,parse_file,3}, {compile,parse_module,1}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}]} Cheers, Adam From mikpe@REDACTED Tue Jul 6 14:12:05 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 6 Jul 2010 14:12:05 +0200 Subject: [erlang-bugs] Bug in HiPE compiled compiler In-Reply-To: <850646195.570961278415308824.JavaMail.root@zimbra> References: <888503893.570941278415261322.JavaMail.root@zimbra> <850646195.570961278415308824.JavaMail.root@zimbra> Message-ID: <19507.7573.301390.130255@pilspetsen.it.uu.se> Adam Lindberg writes: > Hi, > > The following module produces a compiler error in R13B03 and R13B04: > > -module(a). > f() -> hipe is broken. > > > The error is, just as expected: > $> erlc a.erl > a.erl:2: syntax error before: is > > > However, if the compiler is HiPE compiled (with NATIVE_LIBS_ENABLED=yes), the following error occurs: > > $> erlc a.erl > a.erl:none: internal error in parse_module; > crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, > {erl_parse,yeccpars0,5}, > {epp,parse_file,1}, > {epp,parse_file,1}, > {epp,parse_file,3}, > {compile,parse_module,1}, > {compile,'-internal_comp/4-anonymous-1-',2}, > {compile,fold_comp,3}]} I can't reproduce this with R14A on i686-linux. If you can still trigger the failure with R14A, please show us the complete sequence of steps needed to reproduce it. /Mikael From sverker@REDACTED Tue Jul 6 17:40:59 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 06 Jul 2010 17:40:59 +0200 Subject: [erlang-bugs] bug report: ets:select/2 hangs and consumer 100% CPU In-Reply-To: <759689.11884.qm@web65501.mail.ac4.yahoo.com> References: <759689.11884.qm@web65501.mail.ac4.yahoo.com> Message-ID: <4C334E8B.5090002@erix.ericsson.se> Knut Bakke wrote: > Version R13B03, R14A > > Slogan: "ets:select/2 hangs and consumer 100% CPU" > > Very rarely, like > once very week on a 10 hrs running system pr day doing ets:select about > 10 times a sec, the system locks up in 100% CPU > with ets:select/2 > never returning. > The table is very small, about 100 items, could be > less. > > Observations) > 1) If the process with the hanging ets:select/2 is killed, the involved > table is deleted and rebuild with the exact same content. Applying the > same ets:select/2, same match spec, will cause a new hanging. > 2) By deleting objects, one by one, the hang finally disappears (maybe after 20 objects have been > deleted). > 3) The table is only accessed though ONE erlang process. > 4) The table is of type [public, ordered_set] > > We have captured one > situation of a hang, writing out the match specification and dumping the ets table to file, using tab2file. > The problem is reproducible by: > 1) {ok,Tab}=ets:file2tab("EtsSelectHang_)20100628.txt"). %% Please let me know and I send the file. too big > 2) ets:select(Tab, > [{{{guard,true,'$1','_','_','_','_','$2','_',undefined},'$9'}, > [{'<','$1',63444947604},{'/=','$2',this}], ['$_']}]). > > The hanging is triggered by an ets object with [] as key. Empty lists are ok as keys, so this is bug. But it only happens in your case when the 1000th object from the end happens to be the one with empty list key. /Sverker, Erlang/OTP Ericsson From kostis@REDACTED Tue Jul 6 17:58:31 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 06 Jul 2010 18:58:31 +0300 Subject: [erlang-bugs] Bug in HiPE compiled compiler In-Reply-To: <19507.7573.301390.130255@pilspetsen.it.uu.se> References: <888503893.570941278415261322.JavaMail.root@zimbra> <850646195.570961278415308824.JavaMail.root@zimbra> <19507.7573.301390.130255@pilspetsen.it.uu.se> Message-ID: <4C3352A7.9020007@cs.ntua.gr> Mikael Pettersson wrote: > Adam Lindberg writes: > > Hi, > > > > The following module produces a compiler error in R13B03 and R13B04: > > > > -module(a). > > f() -> hipe is broken. > > > > > > The error is, just as expected: > > $> erlc a.erl > > a.erl:2: syntax error before: is > > > > > > However, if the compiler is HiPE compiled (with NATIVE_LIBS_ENABLED=yes), the following error occurs: > > > > $> erlc a.erl > > a.erl:none: internal error in parse_module; > > crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, > > {erl_parse,yeccpars0,5}, > > {epp,parse_file,1}, > > {epp,parse_file,1}, > > {epp,parse_file,3}, > > {compile,parse_module,1}, > > {compile,'-internal_comp/4-anonymous-1-',2}, > > {compile,fold_comp,3}]} > > I can't reproduce this with R14A on i686-linux. > > If you can still trigger the failure with R14A, please show us the > complete sequence of steps needed to reproduce it. The behaviour is reproducible. At least in my system that has kernel, stdlib, compiler and hipe all in native code (configure --enable-native-libs) the following sequence of commands shows the difference if one native compiles or not only one specific file. @hektor [~/.../otp] cd lib/stdlib/src @hektor [~/.../otp/lib/stdlib/src] erlc -W +debug_info -I../include -I../../kernel/include -o../ebin erl_parse.erl @hektor [~/.../otp/lib/stdlib/src] erlc a.erl ./a.erl:3: syntax error before: is @hektor [~/HiPE/otp/lib/stdlib/src] erlc -W +debug_info +native -I../include -I../../kernel/include -o../ebin erl_parse.erl @hektor [~/.../otp/lib/stdlib/src] erlc a.erl ./a.erl:none: internal error in parse_module; crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, {erl_parse,yeccpars0,5}, {epp,parse_file,1}, {epp,parse_file,1}, {epp,parse_file,3}, {compile,parse_module,1}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}]} Kostis From adam.lindberg@REDACTED Tue Jul 6 18:32:04 2010 From: adam.lindberg@REDACTED (Adam Lindberg) Date: Tue, 6 Jul 2010 16:32:04 +0000 (GMT) Subject: [erlang-bugs] Bug in HiPE compiled compiler In-Reply-To: <4C3352A7.9020007@cs.ntua.gr> Message-ID: <1012921073.573831278433924309.JavaMail.root@zimbra> I managed to pinpoint the error to erl_parse. If you compile only erl_parse without hipe it works as it should. Cheers, Adam ----- "Kostis Sagonas" wrote: > Mikael Pettersson wrote: > > Adam Lindberg writes: > > > Hi, > > > > > > The following module produces a compiler error in R13B03 and > R13B04: > > > > > > -module(a). > > > f() -> hipe is broken. > > > > > > > > > The error is, just as expected: > > > $> erlc a.erl > > > a.erl:2: syntax error before: is > > > > > > > > > However, if the compiler is HiPE compiled (with > NATIVE_LIBS_ENABLED=yes), the following error occurs: > > > > > > $> erlc a.erl > > > a.erl:none: internal error in parse_module; > > > crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, > > > {erl_parse,yeccpars0,5}, > > > {epp,parse_file,1}, > > > {epp,parse_file,1}, > > > {epp,parse_file,3}, > > > {compile,parse_module,1}, > > > > {compile,'-internal_comp/4-anonymous-1-',2}, > > > {compile,fold_comp,3}]} > > > > I can't reproduce this with R14A on i686-linux. > > > > If you can still trigger the failure with R14A, please show us the > > complete sequence of steps needed to reproduce it. > > The behaviour is reproducible. > > At least in my system that has kernel, stdlib, compiler and hipe all > in > native code (configure --enable-native-libs) the following sequence of > > commands shows the difference if one native compiles or not only one > specific file. > > @hektor [~/.../otp] cd lib/stdlib/src > @hektor [~/.../otp/lib/stdlib/src] erlc -W +debug_info -I../include > -I../../kernel/include -o../ebin erl_parse.erl > @hektor [~/.../otp/lib/stdlib/src] erlc a.erl > ./a.erl:3: syntax error before: is > @hektor [~/HiPE/otp/lib/stdlib/src] erlc -W +debug_info +native > -I../include -I../../kernel/include -o../ebin erl_parse.erl > @hektor [~/.../otp/lib/stdlib/src] erlc a.erl > ./a.erl:none: internal error in parse_module; > crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, > {erl_parse,yeccpars0,5}, > {epp,parse_file,1}, > {epp,parse_file,1}, > {epp,parse_file,3}, > {compile,parse_module,1}, > > {compile,'-internal_comp/4-anonymous-1-',2}, > {compile,fold_comp,3}]} > > Kostis From pguyot@REDACTED Wed Jul 7 00:13:29 2010 From: pguyot@REDACTED (Paul Guyot) Date: Wed, 7 Jul 2010 00:13:29 +0200 Subject: Segfault on crash dump with hipe Message-ID: Hello, There is a bug that causes a segmentation fault when dumping the crash log if hipe is enabled and there are native modules loaded. A fix is available here: git fetch git://github.com/pguyot/otp.git pg/fix-segfault-on-crash_dump-with-hipe http://github.com/pguyot/otp/commit/089e48ca0c0486393dd1e886aa18fc4b870b1e32 Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From kostis@REDACTED Wed Jul 7 09:44:31 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 07 Jul 2010 10:44:31 +0300 Subject: [erlang-bugs] Bug in HiPE compiled compiler In-Reply-To: <850646195.570961278415308824.JavaMail.root@zimbra> References: <850646195.570961278415308824.JavaMail.root@zimbra> Message-ID: <4C34305F.2060105@cs.ntua.gr> case atom_to_list(F) of "yeccpars2" ++ _ -> {syntax_error, Token}; "yeccgoto_" ++ SymbolL -> {ok,[{atom,_,Symbol}],_} = erl_scan:string(SymbolL), {missing_in_goto_table, Symbol, State} end. Adam Lindberg wrote: > Hi, > > The following module produces a compiler error in R13B03 and R13B04: > > -module(a). > f() -> hipe is broken. > > > The error is, just as expected: > $> erlc a.erl > a.erl:2: syntax error before: is > > > However, if the compiler is HiPE compiled (with NATIVE_LIBS_ENABLED=yes), the following error occurs: > > $> erlc a.erl > a.erl:none: internal error in parse_module; > crash reason: {function_clause,[{erl_parse,yeccpars2_6,7}, > {erl_parse,yeccpars0,5}, > {epp,parse_file,1}, > {epp,parse_file,1}, > {epp,parse_file,3}, > {compile,parse_module,1}, > {compile,'-internal_comp/4-anonymous-1-',2}, > {compile,fold_comp,3}]} I've investigated this issue. The good news is that there is no problem in the code generated by the hipe compiler. Instead, the problem is that the code of yeccpre.hrl heavily relies on generated exceptions having stack traces of particular forms, which is currently not something that native code guarantees. In parsetools/include/yeccpre.hrl there is code which reads: yecc_error_type(function_clause, [{?MODULE,F,[State,_,_,_,Token,_,_]} | _]) -> case atom_to_list(F) of "yeccpars2" ++ _ -> {syntax_error, Token}; "yeccgoto_" ++ SymbolL -> {ok,[{atom,_,Symbol}],_} = erl_scan:string(SymbolL), {missing_in_goto_table, Symbol, State} end. while the stack trace that native-compiled code generates has the form: yecc_error_type(function_clause, [{?MODULE,F,7} | _]) -> If one can live with uninformative syntax errors, one solution is to add such a clause for yecc_error_type/2 and return some other error terms for this case, which should then be handled in function yeccparse0/5. In other words, add a clause: yecc_error_type(function_clause, [{?MODULE,F,7} | _]) -> case atom_to_list(F) of "yeccpars2" ++ _ -> syntax_error; "yeccgoto_" ++ SymbolL -> {ok,[{atom,_,Symbol}],_} = erl_scan:string(SymbolL), {missing_in_goto_table, Symbol} end. This is relatively easy. Another solution is to add an attribute to yeccpre.hrl that prohibits native code compilation of this module: -compile(no_native). Perhaps this is the best solution for the time being. Of course, a better solution would be for native code to generate the exact same stack traces as BEAM code, but this is very complicated and will not happen soon (if at all). However, even if that were available, I still believe that writing Erlang code that relies on stack traces having a specific form is not kosher. I will let the OTP folks at Ericsson take a decision on what to do about this one. Kostis From raimo+erlang-bugs@REDACTED Wed Jul 7 11:27:08 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 7 Jul 2010 11:27:08 +0200 Subject: [erlang-bugs] Segfault on crash dump with hipe In-Reply-To: References: Message-ID: <20100707092708.GA21538@erix.ericsson.se> On Wed, Jul 07, 2010 at 12:13:29AM +0200, Paul Guyot wrote: > Hello, > > There is a bug that causes a segmentation fault when dumping the crash log if hipe is enabled and there are native modules loaded. > > A fix is available here: > git fetch git://github.com/pguyot/otp.git pg/fix-segfault-on-crash_dump-with-hipe Thank you! It will be included in 'pu'. Can you also line break your commit comments to say 76 columns in the future...? I will do it on this one. > > http://github.com/pguyot/otp/commit/089e48ca0c0486393dd1e886aa18fc4b870b1e32 > > Regards, > > Paul > -- > Semiocast http://semiocast.com/ > +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From tech@REDACTED Wed Jul 7 13:27:29 2010 From: tech@REDACTED (tech@REDACTED) Date: Wed, 7 Jul 2010 13:27:29 +0200 Subject: Strange Memory Allocation Crash Message-ID: <201007071327.30041.tech@erlfinsys.net> While try to do a quick check on which floats need to be rounded before trunking them to get valid results, I was able to crash the Erlang VM. I find it a bit strange as it happened rather quickly into something that I thought shouldn't be that intensive. I have tried this twice, and was wondering if this could be pointing to something else as a problem. Machine Info daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> uname -a Linux greyowl 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 GNU/Linux daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> erl --version Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] ============== CODE START -module(itest). -export([do/0]). do() -> do(0.0). do(100.0) -> done; do(Value) -> if trunc(Value * 100) =:= trunc(round(Value * 100)) -> do(Value + 0.01); true -> error_logger:info_msg("Value: ~p~n", [Value]), do(Value + 0.01) end. ============== CODE END The final result. (After 280 iterations of the function the following crash) =INFO REPORT==== 7-Jul-2010::11:33:07 === Value: 2.7999999999999843 Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 20672 bytes of memory (of type "heap"). Aborted The code is attached I am a bit at a loss as to where to start troubleshooting this :) -- ----- Mobile : +27 84 468 3138 Skype : danielschutte Office : +27 (0) 11 475 - 1654 +27 (0) 11 475 - 1664 +27 (0) 11 475 - 1674 +27 (0) 11 475 - 1639 ------------------------------------------------------- ------------------------------------------------------- From egil@REDACTED Wed Jul 7 14:11:17 2010 From: egil@REDACTED (=?ISO-8859-15?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 07 Jul 2010 14:11:17 +0200 Subject: [erlang-bugs] Strange Memory Allocation Crash In-Reply-To: <201007071327.30041.tech@erlfinsys.net> References: <201007071327.30041.tech@erlfinsys.net> Message-ID: <4C346EE5.4040804@erix.ericsson.se> The error_logger can't consume the info messages you send at the rate that that tight loop produces them. erl_crash.dump: <0.5.0> error_logger Garbing (limited info) 27440736 182452560 7557980 Regards, Bj?rn-Egil Erlang/OTP On 2010-07-07 13:27, tech@REDACTED wrote: > > > While try to do a quick check on which floats need to be rounded before > trunking them to get valid results, I was able to crash the Erlang VM. I find > it a bit strange as it happened rather quickly into something that I thought > shouldn't be that intensive. I have tried this twice, and was wondering if > this could be pointing to something else as a problem. > > Machine Info > daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> uname -a > Linux greyowl 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 x86_64 > x86_64 x86_64 GNU/Linux > daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> erl --version > Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > > ============== CODE START > > -module(itest). > -export([do/0]). > > do() -> > do(0.0). > > do(100.0) -> > done; > do(Value) -> > if trunc(Value * 100) =:= trunc(round(Value * 100)) -> > do(Value + 0.01); > true -> > error_logger:info_msg("Value: ~p~n", [Value]), > do(Value + 0.01) > end. > > ============== CODE END > > The final result. (After 280 iterations of the function the following crash) > > =INFO REPORT==== 7-Jul-2010::11:33:07 === > Value: 2.7999999999999843 > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 20672 bytes of memory (of type "heap"). > Aborted > > > The code is attached > > I am a bit at a loss as to where to start troubleshooting this :) > From egil@REDACTED Wed Jul 7 14:15:59 2010 From: egil@REDACTED (=?ISO-8859-15?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 07 Jul 2010 14:15:59 +0200 Subject: [erlang-bugs] Strange Memory Allocation Crash In-Reply-To: <4C346EE5.4040804@erix.ericsson.se> References: <201007071327.30041.tech@erlfinsys.net> <4C346EE5.4040804@erix.ericsson.se> Message-ID: <4C346FFF.4050604@erix.ericsson.se> On 2010-07-07 14:11, Bj?rn-Egil Dahlberg wrote: > The error_logger can't consume the info messages you send at the rate > that that tight loop produces them. > > erl_crash.dump: > <0.5.0> error_logger Garbing (limited info) 27440736 182452560 7557980 That is 7557980 messages in the msq-queue. To answer your question, use the crashdump viewer to examine crash dump you just got. Eshell V5.8.1 (abort with ^G) 1> crashdump_viewer:start(). WebTool is available at http://localhost:8888/ Or http://127.0.0.1:8888/ // Bj?rn-Egil > > Regards, > Bj?rn-Egil > Erlang/OTP > > On 2010-07-07 13:27, tech@REDACTED wrote: >> >> >> While try to do a quick check on which floats need to be rounded before >> trunking them to get valid results, I was able to crash the Erlang VM. >> I find >> it a bit strange as it happened rather quickly into something that I >> thought >> shouldn't be that intensive. I have tried this twice, and was >> wondering if >> this could be pointing to something else as a problem. >> >> Machine Info >> daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> uname -a >> Linux greyowl 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 >> x86_64 >> x86_64 x86_64 GNU/Linux >> daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> erl --version >> Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] >> [async-threads:0] >> [hipe] [kernel-poll:false] >> >> >> ============== CODE START >> >> -module(itest). >> -export([do/0]). >> >> do() -> >> do(0.0). >> >> do(100.0) -> >> done; >> do(Value) -> >> if trunc(Value * 100) =:= trunc(round(Value * 100)) -> >> do(Value + 0.01); >> true -> >> error_logger:info_msg("Value: ~p~n", [Value]), >> do(Value + 0.01) >> end. >> >> ============== CODE END >> >> The final result. (After 280 iterations of the function the following >> crash) >> >> =INFO REPORT==== 7-Jul-2010::11:33:07 === >> Value: 2.7999999999999843 >> >> Crash dump was written to: erl_crash.dump >> eheap_alloc: Cannot allocate 20672 bytes of memory (of type "heap"). >> Aborted >> >> >> The code is attached >> >> I am a bit at a loss as to where to start troubleshooting this :) >> > From sverker@REDACTED Wed Jul 7 14:52:51 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 07 Jul 2010 14:52:51 +0200 Subject: [erlang-bugs] Strange Memory Allocation Crash In-Reply-To: <4C346FFF.4050604@erix.ericsson.se> References: <201007071327.30041.tech@erlfinsys.net> <4C346EE5.4040804@erix.ericsson.se> <4C346FFF.4050604@erix.ericsson.se> Message-ID: <4C3478A3.9070304@erix.ericsson.se> And this of course spins out of control because do(100.0) -> done; never matches exactly. do(N) when N >= 100.0 -> done; should put an end to the madness. /Sverker Bj?rn-Egil Dahlberg wrote: > On 2010-07-07 14:11, Bj?rn-Egil Dahlberg wrote: >> The error_logger can't consume the info messages you send at the rate >> that that tight loop produces them. >> >> erl_crash.dump: >> <0.5.0> error_logger Garbing (limited info) 27440736 182452560 7557980 > > That is 7557980 messages in the msq-queue. > To answer your question, use the crashdump viewer to examine crash > dump you just got. > > Eshell V5.8.1 (abort with ^G) > 1> crashdump_viewer:start(). > WebTool is available at http://localhost:8888/ > Or http://127.0.0.1:8888/ > > // Bj?rn-Egil > > >> >> Regards, >> Bj?rn-Egil >> Erlang/OTP >> >> On 2010-07-07 13:27, tech@REDACTED wrote: >>> >>> >>> While try to do a quick check on which floats need to be rounded before >>> trunking them to get valid results, I was able to crash the Erlang VM. >>> I find >>> it a bit strange as it happened rather quickly into something that I >>> thought >>> shouldn't be that intensive. I have tried this twice, and was >>> wondering if >>> this could be pointing to something else as a problem. >>> >>> Machine Info >>> daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> uname -a >>> Linux greyowl 2.6.31.12-0.2-default #1 SMP 2010-03-16 21:25:39 +0100 >>> x86_64 >>> x86_64 x86_64 GNU/Linux >>> daniel@REDACTED:~/sdb/work/gf_olympus/troy/trunk/tmp> erl --version >>> Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] >>> [async-threads:0] >>> [hipe] [kernel-poll:false] >>> >>> >>> ============== CODE START >>> >>> -module(itest). >>> -export([do/0]). >>> >>> do() -> >>> do(0.0). >>> >>> do(100.0) -> >>> done; >>> do(Value) -> >>> if trunc(Value * 100) =:= trunc(round(Value * 100)) -> >>> do(Value + 0.01); >>> true -> >>> error_logger:info_msg("Value: ~p~n", [Value]), >>> do(Value + 0.01) >>> end. >>> >>> ============== CODE END >>> >>> The final result. (After 280 iterations of the function the following >>> crash) >>> >>> =INFO REPORT==== 7-Jul-2010::11:33:07 === >>> Value: 2.7999999999999843 >>> >>> Crash dump was written to: erl_crash.dump >>> eheap_alloc: Cannot allocate 20672 bytes of memory (of type "heap"). >>> Aborted >>> >>> >>> The code is attached >>> >>> I am a bit at a loss as to where to start troubleshooting this :) >>> >> > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From schuett@REDACTED Wed Jul 7 16:50:32 2010 From: schuett@REDACTED (Thorsten Schuett) Date: Wed, 7 Jul 2010 16:50:32 +0200 Subject: Diaylzer in R14A with opaque types Message-ID: <201007071650.33020.schuett@zib.de> Hi, when I run dialyzer of R14A on the attached code, it complains about the new_neighborhood/1 function: nodelist.erl:12: Invalid type specification for function nodelist:new_neighborhood/1. The success typing is (_) -> {[any(),...]} However, when I change the type nodelist() from opaque to non-opaque (see comment), dialyzer accepts the code. The types seem to be correct. The problem seems to be with nested opaque types. Thorsten -module(nodelist). -export([new_neighborhood/1]). -export_type([nodelist/0, neighborhood/0]). -type(node_type() :: node_type). -opaque(nodelist() :: [node_type()]). % change to -type -opaque(neighborhood() :: {nodelist()}). -spec new_neighborhood(Node::node_type()) -> neighborhood(). new_neighborhood(Node) -> {[Node]}. From kostis@REDACTED Mon Jul 12 23:56:34 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 13 Jul 2010 00:56:34 +0300 Subject: [erlang-bugs] Diaylzer in R14A with opaque types In-Reply-To: <201007071650.33020.schuett@zib.de> References: <201007071650.33020.schuett@zib.de> Message-ID: <4C3B8F92.1000104@cs.ntua.gr> Thorsten Schuett wrote: > Hi, > > when I run dialyzer of R14A on the attached code, it complains about the > new_neighborhood/1 function: > nodelist.erl:12: Invalid type specification for function > nodelist:new_neighborhood/1. The success typing is (_) -> {[any(),...]} > > However, when I change the type nodelist() from opaque to non-opaque (see > comment), dialyzer accepts the code. The types seem to be correct. The problem > seems to be with nested opaque types. Indeed. Thanks for reporting this! The problem has been fixed (thanks to Maria Christakis) and the fix will appear in R14B and on github soon. Kostis From dale.gallagher@REDACTED Wed Jul 14 15:55:49 2010 From: dale.gallagher@REDACTED (Dale Gallagher) Date: Wed, 14 Jul 2010 15:55:49 +0200 Subject: Compile error related to flex, while building Erlang/OTP R14A Message-ID: Hi there System info: Slackware 13.1 Linux 2.6.33.4 SMP x86 GCC 4.4.4 Flex 2.5.35 Perl 5.10.1 Snippet from build, showing error: http://pb.rbfh.de/23xDeRY4qDtmX Let me know if you require further detail. Thanks Dale From pguyot@REDACTED Sat Jul 17 15:07:22 2010 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 17 Jul 2010 15:07:22 +0200 Subject: fix of hipe crashes in gc Message-ID: <928AF5E2-AB0D-4102-9628-B3E4DBE3353D@kallisys.net> Hello, I have been experiencing crashes in the garbage collector when running erlang with natively compiled modules, and especially with OTP configured with --enable-native-libs. This has been discussed before, including by others: http://www.erlang.org/cgi-bin/ezmlm-cgi/4/50033 http://www.erlang.org/cgi-bin/ezmlm-cgi/4/39462 http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1583 I finally got a reproduceable case and nailed the bug down. The bug was introduced in R12B-0, when the function erts_gc_after_bif_call was updated to take 4 parameters but the assembly glue code was not updated to pass proper values for the third and fourth parameters. A fix is available here: git fetch git://github.com/pguyot/otp.git pg/fix-hipe-crash-in-gc_after_bif http://github.com/pguyot/otp/commit/c42ba9962d7e83accec797c56e5480a2d0b6281a Please note that I only tested it on x86 and amd64 platforms. Regards, Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From mikpe@REDACTED Sat Jul 17 15:56:29 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Sat, 17 Jul 2010 15:56:29 +0200 Subject: [erlang-patches] fix of hipe crashes in gc In-Reply-To: <928AF5E2-AB0D-4102-9628-B3E4DBE3353D@kallisys.net> References: <928AF5E2-AB0D-4102-9628-B3E4DBE3353D@kallisys.net> Message-ID: <19521.46733.210179.226719@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > I have been experiencing crashes in the garbage collector when running erlang with natively compiled modules, and especially with OTP configured with --enable-native-libs. > > This has been discussed before, including by others: > http://www.erlang.org/cgi-bin/ezmlm-cgi/4/50033 No test case was ever provided, though in hindsight the "arity=" should have caught my eye. > http://www.erlang.org/cgi-bin/ezmlm-cgi/4/39462 Missed that one. Nothing in $Subject or the first two messages indicated native code, so the third message was likely ignored. Again, "arity=" in the third message is the crucial hint. > http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1583 That one was apparently resolved as being a different problem. Nothing there indicates that ertc_gc_after_bif_call was involved. > > I finally got a reproduceable case and nailed the bug down. The bug was introduced in R12B-0, when the function erts_gc_after_bif_call was updated to take 4 parameters but the assembly glue code was not updated to pass proper values for the third and fourth parameters. > > A fix is available here: > > git fetch git://github.com/pguyot/otp.git pg/fix-hipe-crash-in-gc_after_bif > http://github.com/pguyot/otp/commit/c42ba9962d7e83accec797c56e5480a2d0b6281a Thanks for identifying the cause. The fix looks reasonable, but can you please post it with git-send-email or somesuch, there are coding style details I want you to fix but I cannot accurately describe them without the text of the patch itself. /Mikael (Not directed at you personally, but this is a good example IMO of how the Erlang adaptation of git has failed. Not providing patches inline (together with git links) makes it difficult to review them and discuss specific details. In contrast, the Linux kernel community gets this right.) From pguyot@REDACTED Sat Jul 17 18:32:15 2010 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 17 Jul 2010 18:32:15 +0200 Subject: [erlang-patches] fix of hipe crashes in gc In-Reply-To: <19521.46733.210179.226719@pilspetsen.it.uu.se> References: <928AF5E2-AB0D-4102-9628-B3E4DBE3353D@kallisys.net> <19521.46733.210179.226719@pilspetsen.it.uu.se> Message-ID: Mikael, Thank you for your quick reply. Le 17 juil. 2010 ? 15:56, Mikael Pettersson a ?crit : >> http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1583 > > That one was apparently resolved as being a different problem. > Nothing there indicates that ertc_gc_after_bif_call was involved. It's in the stack trace (element 4). Unlike the other crash logs, the parameters are not displayed, but I suspect it's the same bug. > Thanks for identifying the cause. The fix looks reasonable, but can you > please post it with git-send-email or somesuch, there are coding style > details I want you to fix but I cannot accurately describe them without > the text of the patch itself. I sent the patch in a separate e-mail (I wanted to change the subject line with --compose, but failed). Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From khirin@REDACTED Sun Jul 18 08:13:40 2010 From: khirin@REDACTED (Evgeny Khirin) Date: Sun, 18 Jul 2010 09:13:40 +0300 Subject: filename:join breaks Windows UNC paths Message-ID: <201007180913.40475.khirin@zahav.net.il> Hello, "Normalize" feature of filename:join breaks Windows UNC paths: filename:join("//host/share", "file") returns "/host/share/file" on Windows instead "//host/share/file". Patch below fixes the problem. Regards, Evgeny. ------------------- patch -------------------------------- diff --git a/lib/stdlib/src/filename.erl b/lib/stdlib/src/filename.erl index 01c06e4..8da54ef 100644 --- a/lib/stdlib/src/filename.erl +++ b/lib/stdlib/src/filename.erl @@ -316,6 +316,10 @@ join(Name1, Name2) when is_atom(Name2) -> %% It is the responsibility of the caller to ensure that RelativeName %% is relative. +join1([$/, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, RelativeName, [], win32)]; +join1([$/, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, RelativeName, [], win32)]; +join1([$\\, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, RelativeName, [], win32)]; +join1([$\\, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, RelativeName, [], win32)]; join1([UcLetter, $:|Rest], RelativeName, [], win32) when is_integer(UcLetter), UcLetter >= $A, UcLetter =< $Z -> join1(Rest, RelativeName, [$:, UcLetter+$a-$A], win32); ------------------- patch -------------------------------- From kruber@REDACTED Tue Jul 20 11:47:43 2010 From: kruber@REDACTED (Nico Kruber) Date: Tue, 20 Jul 2010 11:47:43 +0200 Subject: strange behaviour of ets:tab2list with empty lists as key Message-ID: <201007201147.48428.kruber@zib.de> Hi, I see some strange behaviour of the ets:tab2list/1 function sometimes: running R13B04 and using empty lists, i.e. [], as keys in an ets table results in ets:tab2list (sometimes) duplicating the list. See the test_empty() function of the attached file. Regards, Nico Kruber -------------- next part -------------- A non-text attachment was scrubbed... Name: ets_SUITE.erl Type: text/x-erlang Size: 808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sverker@REDACTED Tue Jul 20 13:50:20 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 20 Jul 2010 13:50:20 +0200 Subject: [erlang-bugs] strange behaviour of ets:tab2list with empty lists as key In-Reply-To: <201007201147.48428.kruber@zib.de> References: <201007201147.48428.kruber@zib.de> Message-ID: <4C458D7C.7020106@erix.ericsson.se> Nico Kruber wrote: > Hi, > I see some strange behaviour of the ets:tab2list/1 function sometimes: running > R13B04 and using empty lists, i.e. [], as keys in an ets table results in > ets:tab2list (sometimes) duplicating the list. See the test_empty() function > of the attached file. > > Regards, > Nico Kruber > Sounds like the same root problem as this one: http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1895:201007:gfodmnfdfedjeipbeldc I will merge that fix into dev branch for R14B. /Sverker, Erlang/OTP From rickard@REDACTED Wed Jul 21 18:10:26 2010 From: rickard@REDACTED (Rickard Olsson) Date: Wed, 21 Jul 2010 17:10:26 +0100 Subject: lists:concat/1 spec inconsistent with implementation or bug in Dialyzer? Message-ID: Hi, When running Dialyzer on the code below I get the following messages: "The call lists:concat([['a,...],...]) breaks the contract ([concat_thing()]) -> string()" and "Function unused_function/1 will never be called" Test code: -export([parse/0]). parse()-> concat(), unused_function(a). concat() -> lists:concat([[a]]). unused_function(A) -> A. The line: "lists:concat([[a]])." runs fine in the shell, but seems to cause the dialyzer to stop, which I assume is the reason it warns that unused_function/1 will never be used, even though it is used. If the arity is changed to 0 and the arguments removed from the call, the warning seems to disapear though. Is it a bug in the lists:concat/1's spec or in Dialyzer? Running: openSUSE 11.0 (X86-64) Erlang R14A (erts-5.8) [source] [64-bit] Dialyzer v2.3.0 Regards, Rickard Olsson Erlang Solutions From pguyot@REDACTED Thu Jul 22 18:20:32 2010 From: pguyot@REDACTED (Paul Guyot) Date: Thu, 22 Jul 2010 18:20:32 +0200 Subject: internal error in native_compile Message-ID: <91821F1F-9BCD-4810-88B0-07DACEE732BF@kallisys.net> Hello, I am experiencing a strange error when compiling with +native the following module: ---------------------------- -module(hipe_crash). -export([f/6]). f(A, B, C, D, E, L) -> lists:foldl(fun (X, P) -> AVar = case A of 0 -> 1 / D; N -> N / (C - B) end, BVar = case E of atom1 -> 1.0; atom2 -> 0.8; _ -> E end, CVar = case X of atom1 -> 0.1 * AVar; _ -> 1.0 end, P * BVar * CVar end, 1, L). ---------------------------- I couldn't restrict the code further. For example, the error does not happen without the atom2 case line for BVar. With +native, I get: =ERROR REPORT==== 22-Jul-2010::18:17:53 === Error: [hipe:867]: ERROR: {function_clause, [{proplists,get_bool,2}, {global_group, global_groups_removed,1}]} =ERROR REPORT==== 22-Jul-2010::18:17:53 === Error in process <0.30.0> with exit value: {{hipe,868,{function_clause,[{proplists,get_bool,2},{global_group,global_groups_removed,1}]}},[{hipe,finalize_fun_sequential,3},{hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} /Junk/tmp/hipe_crash.erl:none: internal error in native_compile; crash reason: {{hipe,868, {function_clause, [{proplists,get_bool,2}, {global_group,global_groups_removed,1}]}}, [{hipe,finalize_fun_sequential,3}, {hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} With +native +'{hipe, [verbose]}', I get: EXITED with reason {function_clause,[{hipe_icode_fp,assert_assigned,[[{30,{icode_variable,40,fvar,[]}}]]},{hipe_icode_fp,bindings_are_assigned,1},{hipe_icode_fp,filter_map,3},{hipe_icode_fp,transform_block,2},{hipe_icode_fp,cfg,1},{hipe_main,icode_ssa_type,4},{hipe_main,icode_ssa,4},{hipe_main,compile_icode,5}]} @hipe:868 =ERROR REPORT==== 22-Jul-2010::18:17:13 === Error: [hipe:867]: ERROR: {function_clause, [{hipe_icode_fp,assert_assigned, [[{30, {icode_variable,40,fvar, []}}]]}, {hipe_icode_fp, bindings_are_assigned,1}, {hipe_icode_fp,filter_map,3}, {hipe_icode_fp,transform_block,2}, {hipe_icode_fp,cfg,1}, {hipe_main,icode_ssa_type,4}, {hipe_main,icode_ssa,4}, {hipe_main,compile_icode,5}]} /Junk/tmp/hipe_crash.erl:none: internal error in native_compile; crash reason: {{hipe,868, {function_clause, [{hipe_icode_fp,assert_assigned, [[{30,{icode_variable,40,fvar,[]}}]]}, {hipe_icode_fp,bindings_are_assigned,1}, {hipe_icode_fp,filter_map,3}, {hipe_icode_fp,transform_block,2}, {hipe_icode_fp,cfg,1}, {hipe_main,icode_ssa_type,4}, {hipe_main,icode_ssa,4}, {hipe_main,compile_icode,5}]}}, [{hipe,finalize_fun_sequential,3}, {hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} This is with an R14A OTP installation configured with --enable-native-libs. Any idea? Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From scvalex@REDACTED Thu Jul 22 18:36:36 2010 From: scvalex@REDACTED (=?ISO-8859-2?Q?Alexandru_Scvor=FEov?=) Date: Thu, 22 Jul 2010 17:36:36 +0100 (BST) Subject: [erlang-bugs] SSL Problems with R14A Message-ID: Hi, I'm having a bit of trouble using SSL in R14A. Here's the same code, run under R13B03 and R14A. % /opt/erlang/bin/erl Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.4 (abort with ^G) 1> code:which(ssl). "/opt/erlang/lib/erlang/lib/ssl-3.10.7/ebin/ssl.beam" 2> ssl:start(). ok 3> {ok, Socket} = ssl:connect("smtp.gmail.com", 465, [{active,false}], 1000). {ok,{sslsocket,5,<0.45.0>}} 4> ssl:recv(Socket, 0, 1000). {ok,"220 mx.google.com ESMTP n17sm3656484weq.30 "} % erl Erlang R14A (erts-5.8) [source] [rq:1] [async-threads:0] [hipe] Eshell V5.8 (abort with ^G) 1> code:which(ssl). "/usr/lib/erlang/lib/ssl-4.0/ebin/ssl.beam" 2> ssl:start(). ok 3> {ok, Socket} = ssl:connect("smtp.gmail.com", 465, [{active, false}], 1000). {ok,{sslsocket,new_ssl,<0.51.0>}} 4> ssl:recv(Socket, 0, 1000). =ERROR REPORT==== 21-Jul-2010::23:02:45 === SSL: decipher_error: ./ssl_record.erl:680:Fatal error: bad record mac {error,"bad record mac"} As you can see, it works fine under under R13B03, but fails with a "bad record mac" error on R14A. Any ideas on what might be causing this? Cheers, Alex From tuncer.ayaz@REDACTED Thu Jul 22 22:06:38 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 22 Jul 2010 22:06:38 +0200 Subject: [erlang-bugs] SSL Problems with R14A In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 6:36 PM, Alexandru Scvor?ov wrote: > Hi, > > I'm having a bit of trouble using SSL in R14A. > > Here's the same code, run under R13B03 and R14A. > > % /opt/erlang/bin/erl > Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] > [kernel-poll:false] > > Eshell V5.7.4 ?(abort with ^G) > 1> code:which(ssl). > "/opt/erlang/lib/erlang/lib/ssl-3.10.7/ebin/ssl.beam" > 2> ssl:start(). > ok > 3> {ok, Socket} = ssl:connect("smtp.gmail.com", 465, [{active,false}], > 1000). > {ok,{sslsocket,5,<0.45.0>}} > 4> ssl:recv(Socket, 0, 1000). > {ok,"220 mx.google.com ESMTP n17sm3656484weq.30 > "} > > > > > % erl > Erlang R14A (erts-5.8) [source] [rq:1] [async-threads:0] [hipe] > > Eshell V5.8 ?(abort with ^G) > 1> code:which(ssl). > "/usr/lib/erlang/lib/ssl-4.0/ebin/ssl.beam" > 2> ssl:start(). > ok > 3> {ok, Socket} = ssl:connect("smtp.gmail.com", 465, [{active, false}], > 1000). > {ok,{sslsocket,new_ssl,<0.51.0>}} > 4> ssl:recv(Socket, 0, 1000). > > =ERROR REPORT==== 21-Jul-2010::23:02:45 === > SSL: decipher_error: ./ssl_record.erl:680:Fatal error: bad record mac > {error,"bad record mac"} > > > > As you can see, it works fine under under R13B03, but fails with a "bad > record mac" error on R14A. > > Any ideas on what might be causing this? I think it's the same issue as in http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:52313:201007:mohnjgfideamidobdnhk From scvalex@REDACTED Fri Jul 23 00:52:21 2010 From: scvalex@REDACTED (=?ISO-8859-2?Q?Alexandru_Scvor=FEov?=) Date: Thu, 22 Jul 2010 23:52:21 +0100 (BST) Subject: [erlang-bugs] SSL Problems with R14A In-Reply-To: References: Message-ID: On Thu, 22 Jul 2010, Tuncer Ayaz wrote: > I think it's the same issue as in > http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:52313:201007:mohnjgfideamidobdnhk > I don't think so. The error isn't raised by the padding checks (as in that bug); it's raised when checking the Mac against the MacHash. I don't claim to know what's happening but it appears to be miscalculating a checksum. Cheers, Alex From mikage@REDACTED Fri Jul 23 09:24:54 2010 From: mikage@REDACTED (Mikage Sawatari) Date: Fri, 23 Jul 2010 16:24:54 +0900 Subject: IE8 doesn't work with the new ssl module Message-ID: Hello, The new ssl module in Erlang/OTP R14A can't communicate with Internet Explorer 8. The problem doesn't arise with Firefox nor Google Chrome. It can be reproduced by the following steps: 1. Place the attached cert.pem and key.pem to some directory. 2. In that directory, do the following: $ mkdir htdocs $ echo "Hello world." > htdocs/a.txt $ erl Erlang R14A (erts-5.8) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8 (abort with ^G) 1> inets:start(). ok 2> inets:start(httpd, [ 2> {server_name,"localhost"}, 2> {port,8888}, 2> {document_root,"htdocs"}, 2> {server_root,"."}, 2> {socket_type, essl}, 2> {ssl_certificate_file,"cert.pem"}, 2> {ssl_certificate_key_file,"key.pem"}]). {ok,<0.46.0>} 3. Open https://localhost:8888/a.txt with IE8. 4. The following error occurs: 3> =ERROR REPORT==== 23-Jul-2010::15:59:35 === SSL: decipher_error: ./ssl_record.erl:680:Fatal error: bad record mac -- ----------------------------------------------------------------------- SAWATARI Mikage (SANO Taku) -------------- next part -------------- A non-text attachment was scrubbed... Name: key.pem Type: application/octet-stream Size: 887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cert.pem Type: application/octet-stream Size: 1594 bytes Desc: not available URL: From mikpe@REDACTED Fri Jul 23 12:58:59 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 23 Jul 2010 12:58:59 +0200 Subject: [erlang-bugs] internal error in native_compile In-Reply-To: <91821F1F-9BCD-4810-88B0-07DACEE732BF@kallisys.net> References: <91821F1F-9BCD-4810-88B0-07DACEE732BF@kallisys.net> Message-ID: <19529.30195.101274.676787@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > I am experiencing a strange error when compiling with +native the following module: > > ---------------------------- > -module(hipe_crash). > -export([f/6]). > > f(A, B, C, D, E, L) -> > lists:foldl(fun (X, P) -> > AVar = case A of > 0 -> 1 / D; > N -> N / (C - B) > end, > BVar = case E of > atom1 -> 1.0; > atom2 -> 0.8; > _ -> E > end, > CVar = case X of > atom1 -> 0.1 * AVar; > _ -> 1.0 > end, > P * BVar * CVar > end, 1, L). > ---------------------------- > > I couldn't restrict the code further. For example, the error does not happen without the atom2 case line for BVar. > > With +native, I get: > > =ERROR REPORT==== 22-Jul-2010::18:17:53 === > Error: [hipe:867]: ERROR: {function_clause, > [{proplists,get_bool,2}, > {global_group, > global_groups_removed,1}]} > > =ERROR REPORT==== 22-Jul-2010::18:17:53 === > Error in process <0.30.0> with exit value: {{hipe,868,{function_clause,[{proplists,get_bool,2},{global_group,global_groups_removed,1}]}},[{hipe,finalize_fun_sequential,3},{hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} > > /Junk/tmp/hipe_crash.erl:none: internal error in native_compile; > crash reason: {{hipe,868, > {function_clause, > [{proplists,get_bool,2}, > {global_group,global_groups_removed,1}]}}, > [{hipe,finalize_fun_sequential,3}, > {hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} > > With +native +'{hipe, [verbose]}', I get: > > EXITED with reason {function_clause,[{hipe_icode_fp,assert_assigned,[[{30,{icode_variable,40,fvar,[]}}]]},{hipe_icode_fp,bindings_are_assigned,1},{hipe_icode_fp,filter_map,3},{hipe_icode_fp,transform_block,2},{hipe_icode_fp,cfg,1},{hipe_main,icode_ssa_type,4},{hipe_main,icode_ssa,4},{hipe_main,compile_icode,5}]} @hipe:868 > > =ERROR REPORT==== 22-Jul-2010::18:17:13 === > Error: [hipe:867]: ERROR: {function_clause, > [{hipe_icode_fp,assert_assigned, > [[{30, > {icode_variable,40,fvar, > []}}]]}, > {hipe_icode_fp, > bindings_are_assigned,1}, > {hipe_icode_fp,filter_map,3}, > {hipe_icode_fp,transform_block,2}, > {hipe_icode_fp,cfg,1}, > {hipe_main,icode_ssa_type,4}, > {hipe_main,icode_ssa,4}, > {hipe_main,compile_icode,5}]} > /Junk/tmp/hipe_crash.erl:none: internal error in native_compile; > crash reason: {{hipe,868, > {function_clause, > [{hipe_icode_fp,assert_assigned, > [[{30,{icode_variable,40,fvar,[]}}]]}, > {hipe_icode_fp,bindings_are_assigned,1}, > {hipe_icode_fp,filter_map,3}, > {hipe_icode_fp,transform_block,2}, > {hipe_icode_fp,cfg,1}, > {hipe_main,icode_ssa_type,4}, > {hipe_main,icode_ssa,4}, > {hipe_main,compile_icode,5}]}}, > [{hipe,finalize_fun_sequential,3}, > {hipe,'-finalize_fun_concurrent/3-fun-3-',4}]} > > This is with an R14A OTP installation configured with --enable-native-libs. > > Any idea? Confirmed. You don't need --enable-native-libs, an R14A built without that option fails in the same way. You can work around it by adding the HiPE option no_inline_fp. /Mikael From tuncer.ayaz@REDACTED Sun Jul 25 16:14:06 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 25 Jul 2010 16:14:06 +0200 Subject: Wrong transform of eunit docs from edoc to html Message-ID: Part of lib/eunit/doc/overview.edoc happens to be transformed into mis-formatted html. Is this a problem in the edoc source or the transformation process? Is this a problem in xsltproc, edoc, or the edoc sources? The following source from lib/eunit/doc/overview.edoc --->8--- To make the descriptions simpler, we first list some definitions:
`Setup'`() -> (R::any())'
`SetupX'`(X::any()) -> (R::any())'
`Cleanup'`(R::any()) -> any()'
`CleanupX'`(X::any(), R::any()) -> any()'
`Instantiator'`((R::any()) -> Tests) | {with, [AbstractTestFun::((any()) -> any())]}'
`Where'`local | spawn | {spawn, Node::atom()}'
(these are explained in more detail further below.) --->8--- is transformed into the ill-formatted HTML ---8<---

To make the descriptions simpler, we first list some definitions: Setup() -> (R::any()) SetupX(X::any()) -> (R::any()) Cleanup(R::any()) -> any() CleanupX(X::any(), R::any()) -> any() Instantiator((R::any()) -> Tests) | {with, [AbstractTestFun::((any()) -> any())]} Wherelocal | spawn | {spawn, Node::atom()} (these are explained in more detail further below.)

--->8--- This is harder to read and also contains the faulty string 'Wherelocal'. I think it should be rather transformed into something like: ---8<---

To make the descriptions simpler, we first list some definitions: 

Setup() -> (R::any())

SetupX(X::any()) -> (R::any())

Cleanup(R::any()) -> any()

CleanupX(X::any(), R::any()) -> any()

Instantiator((R::any()) -> Tests | {with,
[AbstractTestFun::((any()) -> any())]}

Where local | spawn | {spawn, Node::atom()}
(these are explained in more detail further below.)

--->8--- From xramtsov@REDACTED Mon Jul 26 16:49:15 2010 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Tue, 27 Jul 2010 00:49:15 +1000 Subject: Erlang consumes memory suddenly Message-ID: <4C4DA06B.2060406@gmail.com> This is a cross-posting from erl-q@, sorry for annoying, but perhaps someone can help me in this list ;) Recently we played with emulator '+Musbct 5' flag in ejabberd to reduce memory consumption. All was fine in stress testing, so we tried it in production. Several hours everything was good but then suddenly Erlang started to consume RSS memory and finally we stopped it (due to out of RAM available). We monitor memory, so you can see the spike here: http://kuku.jabber.ru/~xram/ejabberd_memory-day.png As you can see, no processes/system memory was consumed. So my questions are: 1) Is this a bug or a feature? If this is a feature, is it possible to know what consumed memory? 2) If +Musbct option works incorrectly, then what option should we use to decrease the difference between erlang:memory(total) and RSS? Sometimes this difference reaches up to 2Gb of RSS. We are running R13B04, all linked-in drivers use driver_alloc/driver_free/driver_realloc (either directly or through provided memory callbacks). Currently we are trying +Musbct 20 :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From johnhommer@REDACTED Mon Jul 26 17:32:16 2010 From: johnhommer@REDACTED (andrei zavada) Date: Mon, 26 Jul 2010 18:32:16 +0300 Subject: standard ssh to erlang sshd gives default shell, not the one specified in ssh:daemon/3 Message-ID: <20100726183216.58169f6a@christian> Hi, Consider the case of starting ssh:daemon/3 with bespoke shell supplied as {shell, {Module, Function, Args}} in the proplist as its third parameter. Everything works as expected if I just do (using openssh-5.5_p1, the current version in Gentoo per this writing) $ ssh -p localhost My shell is now invoked and is happily serving commands. Once I try the same with a command-line parameter, i.e., $ ssh -p localhost fafa (expecting "fafa" to be passed to my shell function), the server hands "fafa" over to the Erlang standard shell, which prints: {error,{1,erl_parse,["syntax error before: ",[]]}} And, logically, appending a dot to "fafa" makes it a valid Erlang expression, which gets me a nice fafa The expected behaviour is that sshd accept the command and feed it to the custom shell the user specified in the Options proplist. This misbehaviour is verified in otp-12B-5, otp-13B04, as well as in otp-14A. All systems were tested on a Gentoo box (~amd64 arch), built from unpatched sources from erlang.org. Is this a bug, as I suppose it is? Regards Andrei Zavada From sam@REDACTED Wed Jul 28 06:11:51 2010 From: sam@REDACTED (Sam Bobroff) Date: Wed, 28 Jul 2010 14:11:51 +1000 Subject: SEGV during crash dump from bad application start Message-ID: <4C4FAE07.1010602@m5net.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, I've encountered what appears to be a bug in the following situation: * an application is being started by a boot script. * the application returns a bad result from application:start/2. What follows is either a very, very big crash dump file (erl_dump.crash) or beam.smp crashing with signal 11 (SEGV). I discovered it on R14A but it also appears in R13B04. I've replicated it on both Ubuntu Linux and Mac OSX (using Erlang built from source). My erl reports: Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Here's a Makefile that will replicate the problem (on my system it happens every time) (sorry if the line breaks get messed up): - ---begin--- .PHONY: crash crash: foo.beam foo.app erl -noshell -eval " \ FileContents = {release, \ {\"foo_rel\", \"A\"}, \ {erts, erlang:system_info(version)}, \ [{A, V} || {A, _, V} <- application:loaded_applications()] ++ [{foo, \"1\"}]}, \ {ok, Fd} = file:open(\"foo.rel\", [write]), \ ok = io:fwrite(Fd, \"~p.~n\", [FileContents]), \ ok = file:close(Fd), \ init:stop()." erl -noshell -eval "ok = systools:make_script(\"foo\", [no_module_tests]), init:stop()." erl -noshell +B -boot ./foo foo.erl: @echo "-module(foo)." > $@ @echo "-export([start/2])." >> $@ @echo "start(_, _) -> fubar." >> $@ foo.app: @echo '{application,foo, [{description,""}, {vsn,"1"}, {modules,[foo]}, {registered,[]}, {applications,[kernel,stdlib]}, {mod,{foo,[]}}]}.' > foo.app foo.beam: foo.erl erlc $< - ---end--- (Just save it as Makefile and run make.) I investigated the core file produced by Erlang and it seems to be uninitialized data causing dump_attributes (in break.c) to overrun the ptr argument. I don't have a proposed fix but it might help to know that adding these lines to beam_load.c: stp->code[MI_ATTR_SIZE] = 0; stp->code[MI_COMPILE_SIZE] = 0; To read_code_header() near line 1380 and these similar lines: code[MI_ATTR_SIZE] = 0; code[MI_COMPILE_SIZE] = 0; To erts_make_stub_module() near line 5200 prevent the crash. Peace, Sam. - -- Sam Bobroff | sam@REDACTED | M5 Networks Why does my email have those funny headers? Because I use PGP to sign my email (and you should too!): that's how you know it's really from me. See: http://en.wikipedia.org/wiki/Pretty_Good_Privacy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxPrgcACgkQm97/UHSa/AQMaACfRlIfLuS/88Ckl3dQyZE8aQcS BKMAni39R8tjuvILw7XLbRIy3ZxPcSFL =avwV -----END PGP SIGNATURE----- From mchris@REDACTED Wed Jul 28 10:06:44 2010 From: mchris@REDACTED (Maria Christakis) Date: Wed, 28 Jul 2010 11:06:44 +0300 Subject: [erlang-bugs] lists:concat/1 spec inconsistent with implementation or bug in Dialyzer? In-Reply-To: References: Message-ID: <4C4FE514.5000003@mail.ntua.gr> On 07/21/2010 07:10 PM, Rickard Olsson wrote: > Hi, > > When running Dialyzer on the code below I get the following messages: "The > call lists:concat([['a,...],...]) breaks the contract ([concat_thing()]) -> > string()" and "Function unused_function/1 will never be called" > > Test code: > > -export([parse/0]). > > parse()-> > concat(), > unused_function(a). > > concat() -> > lists:concat([[a]]). > > unused_function(A) -> > A. > > The line: "lists:concat([[a]])." runs fine in the shell, but seems to cause > the dialyzer to stop, which I assume is the reason it warns that > unused_function/1 will never be used, even though it is used. If the arity > is changed to 0 and the arguments removed from the call, the warning seems > to disapear though. > > Is it a bug in the lists:concat/1's spec or in Dialyzer? > > Running: > openSUSE 11.0 (X86-64) > Erlang R14A (erts-5.8) [source] [64-bit] > Dialyzer v2.3.0 > > Regards, > Rickard Olsson > Erlang Solutions > > In my opinion, this is not a bug in the spec and certainly not in Dialyzer. The lists:concat spec is: -type concat_thing() :: atom() | integer() | float() | string(). -spec concat([concat_thing()]) -> string(). The line: "lists:concat([[a]])." runs (i.e. does not crash) in the shell because the term [a] is assumed to be a string by the lists:concat function. However, Dialyzer is able to distinguish a string from a list of atoms and, since the spec declares that this function should only by used with [concat_thing()], emits a warning. In addition, the lists:concat function is supposed to return a list of characters (i.e. a string). This is not the case with the call "lists:concat([[a]])": > lists:concat([[a]]). [a] So it does not crash because it can also handle lists because it has to handle strings, but it does not behave correctly when it is given lists that do not contain characters. From ufm@REDACTED Sat Jul 31 23:34:52 2010 From: ufm@REDACTED (Fyodor Ustinov) Date: Sun, 01 Aug 2010 00:34:52 +0300 Subject: ssh daemon. Message-ID: <4C5496FC.7020804@ufm.su> Hello. Does anyone knows a solution for the problem described here? http://forum.trapexit.org/viewtopic.php?t=19197&highlight=&sid=6c98b4fc2d8b15a6a2bb4a0e2a87a08f