From ali.sabil@REDACTED Tue Sep 4 10:28:14 2012 From: ali.sabil@REDACTED (Ali Sabil) Date: Tue, 4 Sep 2012 10:28:14 +0200 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: <4F019493.30308@erlang.org> References: <4F019493.30308@erlang.org> Message-ID: Any news on this? I have experienced problems with sendfile in R15B1, where all IO on the node got blocked. Thanks, Ali On Mon, Jan 2, 2012 at 12:27 PM, Lukas Larsson wrote: > Hello, > > Thanks for reporting this. The bug does, as Tuncer said, not appear if you > run with async-threads. I've identified the issue and I'm working on a > solution. While waiting for the fix I recommend all to use async-threads in > a VM running sendfile as it is less prone to race-conditions and should be > faster. > > Lukas > > > On 29/12/11 17:26, Magnus Klaar wrote: > > Hi! > > I'm encountered the following errors while testing a module using > file:sendfile/2. It appears to be quite rare. 17 errors were logged for > 11000 requests sent to the server. This is using "Erlang R15B (erts-5.9) > [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]" > running on "Linux $(hostname) 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC > 2011 x86_64 GNU/Linux". > > =ERROR REPORT==== 29-Dec-2011::16:55:15 === > driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) by > tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before stop_select > was called for driver efile > > > =ERROR REPORT==== 29-Dec-2011::16:55:20 === > driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) by > tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before stop_select > was called for driver efile > > > The code is not merged into the main project yet and test is rather ad-hoc, > I'm defaulting to not providing it unless you specifically ask for it. Let > me know if you need and I'll write a summary for downloading and running it > if the error messages are not informative enough. > > MVH Magnus > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From lukas@REDACTED Tue Sep 4 12:27:42 2012 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 4 Sep 2012 12:27:42 +0200 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: References: <4F019493.30308@erlang.org> Message-ID: <5045D79E.8010109@erlang.org> Hello, This specific issue was fixed in R15B01. So if you are experiencing any other issues it is might be something different. What OS are you running? And do you have any code which consistently reproduces the issue? Lukas On 04/09/12 10:28, Ali Sabil wrote: > Any news on this? I have experienced problems with sendfile in R15B1, > where all IO on the node got blocked. > > Thanks, > Ali > > On Mon, Jan 2, 2012 at 12:27 PM, Lukas Larsson wrote: >> Hello, >> >> Thanks for reporting this. The bug does, as Tuncer said, not appear if you >> run with async-threads. I've identified the issue and I'm working on a >> solution. While waiting for the fix I recommend all to use async-threads in >> a VM running sendfile as it is less prone to race-conditions and should be >> faster. >> >> Lukas >> >> >> On 29/12/11 17:26, Magnus Klaar wrote: >> >> Hi! >> >> I'm encountered the following errors while testing a module using >> file:sendfile/2. It appears to be quite rare. 17 errors were logged for >> 11000 requests sent to the server. This is using "Erlang R15B (erts-5.9) >> [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]" >> running on "Linux $(hostname) 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC >> 2011 x86_64 GNU/Linux". >> >> =ERROR REPORT==== 29-Dec-2011::16:55:15 === >> driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) by >> tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before stop_select >> was called for driver efile >> >> >> =ERROR REPORT==== 29-Dec-2011::16:55:20 === >> driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) by >> tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before stop_select >> was called for driver efile >> >> >> The code is not merged into the main project yet and test is rather ad-hoc, >> I'm defaulting to not providing it unless you specifically ask for it. Let >> me know if you need and I'll write a summary for downloading and running it >> if the error messages are not informative enough. >> >> MVH Magnus >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From ali.sabil@REDACTED Tue Sep 4 13:24:55 2012 From: ali.sabil@REDACTED (Ali Sabil) Date: Tue, 4 Sep 2012 13:24:55 +0200 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: <5045D79E.8010109@erlang.org> References: <4F019493.30308@erlang.org> <5045D79E.8010109@erlang.org> Message-ID: On Tue, Sep 4, 2012 at 12:27 PM, Lukas Larsson wrote: > Hello, > > This specific issue was fixed in R15B01. So if you are experiencing any > other issues it is might be something different. > > What OS are you running? And do you have any code which consistently > reproduces the issue? > The node was running on an Ubuntu 12.04 LTS x86_64, the problem occurred when the node was under high io load. Unfortunately I don't have any simple test case, as this occurred 2 months ago on some production servers, but I will try to reproduce it and send you a test suite. Thanks, Ali > Lukas > > > On 04/09/12 10:28, Ali Sabil wrote: >> >> Any news on this? I have experienced problems with sendfile in R15B1, >> where all IO on the node got blocked. >> >> Thanks, >> Ali >> >> On Mon, Jan 2, 2012 at 12:27 PM, Lukas Larsson wrote: >>> >>> Hello, >>> >>> Thanks for reporting this. The bug does, as Tuncer said, not appear if >>> you >>> run with async-threads. I've identified the issue and I'm working on a >>> solution. While waiting for the fix I recommend all to use async-threads >>> in >>> a VM running sendfile as it is less prone to race-conditions and should >>> be >>> faster. >>> >>> Lukas >>> >>> >>> On 29/12/11 17:26, Magnus Klaar wrote: >>> >>> Hi! >>> >>> I'm encountered the following errors while testing a module using >>> file:sendfile/2. It appears to be quite rare. 17 errors were logged for >>> 11000 requests sent to the server. This is using "Erlang R15B (erts-5.9) >>> [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]" >>> running on "Linux $(hostname) 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 >>> UTC >>> 2011 x86_64 GNU/Linux". >>> >>> =ERROR REPORT==== 29-Dec-2011::16:55:15 === >>> driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) by >>> tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before >>> stop_select >>> was called for driver efile >>> >>> >>> =ERROR REPORT==== 29-Dec-2011::16:55:20 === >>> driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) by >>> tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before >>> stop_select >>> was called for driver efile >>> >>> >>> The code is not merged into the main project yet and test is rather >>> ad-hoc, >>> I'm defaulting to not providing it unless you specifically ask for it. >>> Let >>> me know if you need and I'll write a summary for downloading and running >>> it >>> if the error messages are not informative enough. >>> >>> MVH Magnus >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > From zerthurd@REDACTED Wed Sep 5 14:58:30 2012 From: zerthurd@REDACTED (Maxim Treskin) Date: Wed, 5 Sep 2012 19:58:30 +0700 Subject: [erlang-bugs] Bug in R15B02 dialyzer Message-ID: Hello I have such error when try to run dialyzer: =ERROR REPORT==== 5-Sep-2012::19:54:31 === Error in process <0.1020.0> with exit value: {badarg,[{ets,insert,[1052701,[{{out,{glc_session,connect,2}},{{glc_session,connect,2},{glc_session,handle_call,3}}},{{in,{glc_session,handle_call,3}},{{glc_session,connect,2},{glc_session,handle_call,3}}}]],[]},{digraph,do_insert_edge... dialyzer: Analysis failed with error: {badarg,[{ets,insert,[1052701,[{{out,...},{...}},{{...},...}]],[]}, {digraph,do_insert_edge,5,[{file,[...]},{line,...}]}, {dialyzer_callgraph,digraph_add_edge,3,[{file,...},{...}]}, {dialyzer_callgraph,digraph_add_edges,2,[{...}|...]}, {dialyzer_behaviours,translate_callgraph,3,[...]}, {dialyzer_dataflow,analyze_module,5,...}, {dialyzer_dataflow,get_warnings,...}, {dialyzer_succ_typings,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 1.05 secs Removing edges... done in 0.04 secs make: *** [dialyze] Error 1 make dialyze 297,49s user 9,86s system 249% cpu 2:03,39 total -- Max Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From xinfeng.liu@REDACTED Wed Sep 5 17:29:25 2012 From: xinfeng.liu@REDACTED (XinFeng Liu) Date: Wed, 5 Sep 2012 23:29:25 +0800 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 Message-ID: Hi, I'm trying CouchDB (version 1.2) on Solaris 11 Sparc, but running CouchDB testsuite in browser caused erlang process core dumped. I tried both erlang 14B04 and 15B01. After investigation, I found it occurred when couchDB restarted itself. During restarting, erlang unloaded crypto.so then reloaded it into a different address, but openssl library libcrypto.so still using the old call back address of crypto_alloc() in lib/crypto/c_src/crypto.c. In fact, crypto_alloc() is shown as a local function from "nm" command. The temporary workaround is modifying crypto.c: replace CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, crypto_free); to: CRYPTO_set_mem_functions(enif_alloc, enif_realloc, enif_free); I'm not sure it is erlang bug or bug of openssl for solaris, please help clarify? The detailed logs are below: ==================== core dump stack (using Solaris mdb utility): ------------------------ ffbff038 0xfe7e6c48(64, fcd77cc4, ce, fcd96000, fcc53a18, 400) <===== illegal address of function ffbff098 libcrypto.so.1.0.0`EVP_DigestInit_ex+0x1d8(ffbff20c, fcda3218, 1e000, d000, ae124, d218) ffbff0f8 libcrypto.so.1.0.0`ssleay_rand_bytes+0x360(4c84e4, 3, 2784, 7b, fcd98770, 2400) ffbff228 libcrypto.so.1.0.0`ssleay_rand_pseudo_bytes+8(4c84e4, d, ffbff2e8, 0, 0 , fccdde58) ffbff288 crypto.so`rand_bytes_1+0x2c(ffbff3a4, 1, 46ce00, 4c84a1, 46ce00, 8) ffbff2f0 process_main+0x33a0(1f3110, 46de40, 46ce00, 46ce00, fef35440, 555440) ffbff3e0 erl_start+0x4a4(17d4d0, ffbff7ac, 17d6a8, 0, 0, ffbff97a) ffbff6e8 main+0xc(0, ffbff7ac, ffbff838, 1f3510, 0, ff0e0180) ffbff748 _start+0x5c(0, 0, 0, 0, 0, 0) Before core dump, 0xfe7e6c48 was: > 0xfe7e6c48::dis crypto.so`crypto_alloc: or %o7, %g0, %g1 Before core dump, crypto.so was loaded to the address starting 0xfe7e0000 : > ::mappings!grep crypto fcc00000 fcd86000 186000 /lib/libcrypto.so.1.0.0 fcd96000 fcda8000 12000 /lib/libcrypto.so.1.0.0 fcdb0000 fcdb4000 4000 /lib/libcrypto.so.1.0.0 fe7e0000 fe7e8000 8000 /opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so fe7f6000 fe7fa000 4000 /opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so After reloading crypto.so, it was loaded to the address starting 0xfef30000 : > ::mappings!grep crypto fcc00000 fcd86000 186000 /lib/libcrypto.so.1.0.0 fcd96000 fcda8000 12000 /lib/libcrypto.so.1.0.0 fcdb0000 fcdb4000 4000 /lib/libcrypto.so.1.0.0 fef30000 fef38000 8000 /opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so fef46000 fef4a000 4000 /opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so And the old address of crypto.so (0xfe7e0000 to fe7fa000) was unmapped: ... fe78c000 fe78e000 2000 /lib/libnvpair.so.1 fe7d0000 fe7d2000 2000 fe800000 fe810000 10000 fe820000 fe822000 2000 fe830000 fe840000 10000 /usr/lib/libidmap.so.1 ... Thanks, Xinfeng Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From xinfeng.liu@REDACTED Thu Sep 6 05:50:52 2012 From: xinfeng.liu@REDACTED (XinFeng Liu) Date: Thu, 6 Sep 2012 11:50:52 +0800 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 In-Reply-To: References: Message-ID: I also tried another workaround in lib/crypto/c_src/crypto.c: add CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, crypto_free); in reload(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) before "return 0;" The couchDB testsuite runs fine. Is this way O.K.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nico.k@REDACTED Thu Sep 6 11:31:09 2012 From: lists.nico.k@REDACTED (Nico Kruber) Date: Thu, 06 Sep 2012 11:31:09 +0200 Subject: [erlang-bugs] Bug in R15B02 dialyzer In-Reply-To: References: Message-ID: <2074903.H8y3x6AZZS@csr-pc40.zib.de> same here (running dialyzer from R15B02 on the Scalaris sources): Scalaris> make dialyzer /usr/lib64/erlang/bin/dialyzer -Dhave_toke -Dtid_not_builtin - Dwith_export_type_support -DNO_FILE_SENDFILE -Dhave_cthooks_support - Dhave_callback_support -Werror_handling -Wrace_conditions -Wunmatched_returns -I include/ -I contrib/yaws/include/ -I contrib/log4erl/include/ --src -c src src/*/ test/unittest_helper.erl test/tester*.erl test/mockup*.erl test/erl_id_trans.erl test/measure_util.erl test/scalaris_cth.erl --no_native Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes Proceeding with analysis... =ERROR REPORT==== 6-Sep-2012::11:26:27 === Error in process <0.7223.0> with exit value: {badarg,[{ets,insert,[4947997, [{{out,{comm_logger,dump,0}},{{comm_logger,dump,0}, {comm_logger,handle_call,3}}},{{in,{comm_logger,handle_call,3}}, {{comm_logger,dump,0},{comm_logger,handle_call,3}}}]],[]}, {digraph,do_insert_edge,5,[{... =ERROR REPORT==== 6-Sep-2012::11:26:29 === Error in process <0.7224.0> with exit value: {badarg,[{ets,select,[4943900, [{{'$1','_','_','_'},[],['$1']}]],[]},{digraph,edges,1,[{file,"digraph.erl"}, {line,315}]},{dialyzer_races,fixup_race_list,3,[{file,"dialyzer_races.erl"}, {line,323}]},{dialyzer_races,race,1,[{file,"dialyzer_races.erl"},{line... =ERROR REPORT==== 6-Sep-2012::11:26:29 === Error in process <0.7194.0> with exit value: {badarg,[{ets,select_trap, [{4943900,829,0,<<0 bytes>>,[{{tx_tp,update_db_or_forward,6}, {tx_tlog,get_entry_key,1}},{{rt_simple,check,5},{fd,update_subscriptions,2}}, {{rm_tman,crashed_node,2},{rm_tman,update_nodes,4}}, {{gen_component,on_gc_msg... dialyzer: Analysis failed with error: {badarg,[{ets,insert,[4947997,[{{out,...},{...}},{{...},...}]],[]}, {digraph,do_insert_edge,5,[{file,[...]},{line,...}]}, {dialyzer_callgraph,digraph_add_edge,3,[{file,...},{...}]}, {dialyzer_callgraph,digraph_add_edges,2,[{...}|...]}, {dialyzer_behaviours,translate_callgraph,3,[...]}, {dialyzer_dataflow,analyze_module,5,...}, {dialyzer_dataflow,get_warnings,...}, {dialyzer_succ_typings,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 5.92 secs Removing edges... done in 0.19 secs make: *** [dialyzer] Error 1 On Wednesday 05 Sep 2012 19:58:30 Maxim Treskin wrote: > Hello > > I have such error when try to run dialyzer: > > =ERROR REPORT==== 5-Sep-2012::19:54:31 === > Error in process <0.1020.0> with exit value: > {badarg,[{ets,insert,[1052701,[{{out,{glc_session,connect,2}},{{glc_session, > connect,2},{glc_session,handle_call,3}}},{{in,{glc_session,handle_call,3}},{ > {glc_session,connect,2},{glc_session,handle_call,3}}}]],[]},{digraph,do_inse > rt_edge... > > > dialyzer: Analysis failed with error: > {badarg,[{ets,insert,[1052701,[{{out,...},{...}},{{...},...}]],[]}, > {digraph,do_insert_edge,5,[{file,[...]},{line,...}]}, > {dialyzer_callgraph,digraph_add_edge,3,[{file,...},{...}]}, > {dialyzer_callgraph,digraph_add_edges,2,[{...}|...]}, > {dialyzer_behaviours,translate_callgraph,3,[...]}, > {dialyzer_dataflow,analyze_module,5,...}, > {dialyzer_dataflow,get_warnings,...}, > {dialyzer_succ_typings,...}]} > Last messages in the log cache: > Reading files and computing callgraph... done in 1.05 secs > Removing edges... done in 0.04 secs > make: *** [dialyze] Error 1 > make dialyze 297,49s user 9,86s system 249% cpu 2:03,39 total From kostis@REDACTED Thu Sep 6 14:03:23 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 06 Sep 2012 14:03:23 +0200 Subject: [erlang-bugs] Bug in R15B02 dialyzer In-Reply-To: <2074903.H8y3x6AZZS@csr-pc40.zib.de> References: <2074903.H8y3x6AZZS@csr-pc40.zib.de> Message-ID: <5048910B.3020307@cs.ntua.gr> On 09/06/2012 11:31 AM, Nico Kruber wrote: > same here (running dialyzer from R15B02 on the Scalaris sources): > > Scalaris> make dialyzer > /usr/lib64/erlang/bin/dialyzer -Dhave_toke -Dtid_not_builtin - > Dwith_export_type_support -DNO_FILE_SENDFILE -Dhave_cthooks_support - > Dhave_callback_support -Werror_handling -Wrace_conditions -Wunmatched_returns > -I include/ -I contrib/yaws/include/ -I contrib/log4erl/include/ --src -c src > src/*/ test/unittest_helper.erl test/tester*.erl test/mockup*.erl > test/erl_id_trans.erl test/measure_util.erl test/scalaris_cth.erl --no_native > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > =ERROR REPORT==== 6-Sep-2012::11:26:27 === > Error in process<0.7223.0> with exit value: {badarg,[{ets,insert,[4947997, > [{{out,{comm_logger,dump,0}},{{comm_logger,dump,0}, > {comm_logger,handle_call,3}}},{{in,{comm_logger,handle_call,3}}, > {{comm_logger,dump,0},{comm_logger,handle_call,3}}}]],[]}, > {digraph,do_insert_edge,5,[{... The race condition detection in dialyzer in R15B02 unfortunately has a problem in many cases (at least in all cases where behaviours are also involved). We already have a patch for this, which we are testing in large code bases to make sure there are no issues left, and we will notify this thread for its existence when it gets ready. In the meantime, I suggest NOT to use the option -Wrace_conditions (which is off by default). We are pretty confident that the crashes you experience are due to this. Kostis From bjorn.bylander@REDACTED Thu Sep 6 13:57:33 2012 From: bjorn.bylander@REDACTED (=?iso-8859-1?Q?Bj=F6rn_Bylander?=) Date: Thu, 6 Sep 2012 11:57:33 +0000 Subject: [erlang-bugs] edoc doesn't process Wiki style headings when using CR+LF line endings in overview.edoc Message-ID: <387B1A2784121C48B75C2C72548A52CD253E115C@exsrv.ls.local> Hi, I've come to the conclusion that EDoc doesn't correctly process Wiki style headings when using CR+LF line endings in the overview file (overview.edoc). Operating System: Microsoft Windows 7 64-bit. Erlang/OTP release: both R15B01 and R15B02. Haven't tried on earlier releases. Invoking EDoc with the code below in an overview.edoc using CR+LF as line endings results in the Contents heading being rendered as "

== Contents ==

" while, using only LF as line ending, it's rendered as "

Contents

". Also, if the "blah blah" is removed and CR+LF is used, nothing is rendered apart from the standard header and footer. Example overview.edoc contents: @doc blah blah == Contents ==
  1. {@section Introduction}
  2. {@section Outroduction}
== Introduction == This is a nice introduction... == Introduction == and here's the outroduction. @end Best regards, Bj?rn Bylander From lists.nico.k@REDACTED Thu Sep 6 14:43:18 2012 From: lists.nico.k@REDACTED (Nico Kruber) Date: Thu, 06 Sep 2012 14:43:18 +0200 Subject: [erlang-bugs] Bug in R15B02 dialyzer In-Reply-To: <5048910B.3020307@cs.ntua.gr> References: <2074903.H8y3x6AZZS@csr-pc40.zib.de> <5048910B.3020307@cs.ntua.gr> Message-ID: <1614154.C4sXyEalIZ@csr-pc40.zib.de> On Thursday 06 Sep 2012 14:03:23 Kostis Sagonas wrote: > On 09/06/2012 11:31 AM, Nico Kruber wrote: > > same here (running dialyzer from R15B02 on the Scalaris sources): > > > > Scalaris> make dialyzer > > /usr/lib64/erlang/bin/dialyzer -Dhave_toke -Dtid_not_builtin - > > Dwith_export_type_support -DNO_FILE_SENDFILE -Dhave_cthooks_support - > > Dhave_callback_support -Werror_handling -Wrace_conditions > > -Wunmatched_returns -I include/ -I contrib/yaws/include/ -I > > contrib/log4erl/include/ --src -c src src/*/ test/unittest_helper.erl > > test/tester*.erl test/mockup*.erl > > test/erl_id_trans.erl test/measure_util.erl test/scalaris_cth.erl > > --no_native> > > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > > Proceeding with analysis... > > > > =ERROR REPORT==== 6-Sep-2012::11:26:27 === > > Error in process<0.7223.0> with exit value: > > {badarg,[{ets,insert,[4947997, > > [{{out,{comm_logger,dump,0}},{{comm_logger,dump,0}, > > {comm_logger,handle_call,3}}},{{in,{comm_logger,handle_call,3}}, > > {{comm_logger,dump,0},{comm_logger,handle_call,3}}}]],[]}, > > {digraph,do_insert_edge,5,[{... > > The race condition detection in dialyzer in R15B02 unfortunately has a > problem in many cases (at least in all cases where behaviours are also > involved). We already have a patch for this, which we are testing in > large code bases to make sure there are no issues left, and we will > notify this thread for its existence when it gets ready. > > In the meantime, I suggest NOT to use the option -Wrace_conditions > (which is off by default). We are pretty confident that the crashes you > experience are due to this. I can confirm, that removing "-Wrace_conditions" solves the problem for us... Nico From luc.tanguay@REDACTED Thu Sep 6 15:47:14 2012 From: luc.tanguay@REDACTED (luc.tanguay@REDACTED) Date: Thu, 6 Sep 2012 09:47:14 -0400 Subject: [erlang-bugs] edoc doesn't process Wiki style headings when using CR+LF line endings in overview.edoc In-Reply-To: <387B1A2784121C48B75C2C72548A52CD253E115C@exsrv.ls.local> References: <387B1A2784121C48B75C2C72548A52CD253E115C@exsrv.ls.local> Message-ID: <462990D3EDDFE5458F928506D32D40C95CD75C5D96@MBX05.bell.corp.bce.ca> Same thing on Windows XP and R14B02. Removing all the LF (i.e. ^M) in my overview.edoc (in Emacs), the Wiki headings show properly. To open the file in "unix" mode in emacs: C-x RET c unix RET C-x C-f overview.edoc Luc -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Bj?rn Bylander Sent: September 6, 2012 07:58 To: erlang-bugs@REDACTED Subject: [erlang-bugs] edoc doesn't process Wiki style headings when using CR+LF line endings in overview.edoc Hi, I've come to the conclusion that EDoc doesn't correctly process Wiki style headings when using CR+LF line endings in the overview file (overview.edoc). Operating System: Microsoft Windows 7 64-bit. Erlang/OTP release: both R15B01 and R15B02. Haven't tried on earlier releases. Invoking EDoc with the code below in an overview.edoc using CR+LF as line endings results in the Contents heading being rendered as "

== Contents ==

" while, using only LF as line ending, it's rendered as "

Contents

". Also, if the "blah blah" is removed and CR+LF is used, nothing is rendered apart from the standard header and footer. Example overview.edoc contents: @doc blah blah == Contents ==
  1. {@section Introduction}
  2. {@section Outroduction}
== Introduction == This is a nice introduction... == Introduction == and here's the outroduction. @end Best regards, Bj?rn Bylander _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From sverker.eriksson@REDACTED Thu Sep 6 18:27:44 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 6 Sep 2012 18:27:44 +0200 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 In-Reply-To: References: Message-ID: <5048CF00.40801@erix.ericsson.se> XinFeng Liu wrote: > Hi, > I'm trying CouchDB (version 1.2) on Solaris 11 Sparc, but running CouchDB > testsuite in browser caused erlang process core dumped. I tried both erlang > 14B04 and 15B01. > After investigation, I found it occurred when couchDB restarted itself. During > restarting, erlang unloaded crypto.so then reloaded it into a different address, > but openssl library libcrypto.so still using the old call back address > of crypto_alloc() in lib/crypto/c_src/crypto.c. In fact, crypto_alloc() is > shown as a local function from "nm" command. > > The temporary workaround is modifying crypto.c: > replace CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, crypto_free); > to: > CRYPTO_set_mem_functions(enif_alloc, enif_realloc, enif_free); > > I'm not sure it is erlang bug or bug of openssl for solaris, please help clarify? > This is crypto trying to do something which openssl does not support. The workaround you suggested using enif_alloc instead of crypto_alloc seems like a good start if it solves your problem. There are however other callbacks for locking (see CRYPTO_set_locking_callback) that maybe could cause the same kind of problem. The root problem is that openssl does not support "unregistering" of callbacks. The solution is probably some feature that would allow a NIF library to be kept in memory and be reused if/when the erlang module is loaded again. XinFeng Liu wrote: > I also tried another workaround in lib/crypto/c_src/crypto.c: > add > CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, crypto_free); > in reload(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) before > "return 0;" > The couchDB testsuite runs fine. > Is this way O.K.? > > This I don't understand at all. reload() in crypto.c should only be called if the module is upgraded, not if it is unloaded and later loaded again. /Sverker, Erlang/OTP From sverker.eriksson@REDACTED Fri Sep 7 11:05:38 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 7 Sep 2012 11:05:38 +0200 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 In-Reply-To: References: <5048CF00.40801@erix.ericsson.se> Message-ID: <5049B8E2.9020008@erix.ericsson.se> Dave Cottlehuber wrote: > On 6 September 2012 18:27, Sverker Eriksson > wrote: > >> XinFeng Liu wrote: >> >>> Hi, >>> I'm trying CouchDB (version 1.2) on Solaris 11 Sparc, but running CouchDB >>> testsuite in browser caused erlang process core dumped. I tried both erlang >>> 14B04 and 15B01. >>> After investigation, I found it occurred when couchDB restarted itself. >>> During restarting, erlang unloaded crypto.so then reloaded it into a >>> different address, but openssl library libcrypto.so still using the old call >>> back address of crypto_alloc() in lib/crypto/c_src/crypto.c. In fact, >>> crypto_alloc() is shown as a local function from "nm" command. >>> >>> The temporary workaround is modifying crypto.c: >>> replace CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, >>> crypto_free); >>> to: >>> CRYPTO_set_mem_functions(enif_alloc, enif_realloc, >>> enif_free); >>> >>> I'm not sure it is erlang bug or bug of openssl for solaris, please help >>> clarify? >>> >>> >> This is crypto trying to do something which openssl does not support. >> >> The workaround you suggested using enif_alloc instead of crypto_alloc seems >> like a good start if it solves your problem. There are however other >> callbacks for locking (see CRYPTO_set_locking_callback) that maybe could >> cause the same kind of problem. >> >> The root problem is that openssl does not support "unregistering" of >> callbacks. The solution is probably some feature that would allow a NIF >> library to be kept in memory and be reused if/when the erlang module is >> loaded again. >> >> >> >> >> XinFeng Liu wrote: >> >>> I also tried another workaround in lib/crypto/c_src/crypto.c: >>> add >>> CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc, crypto_free); >>> in reload(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) before >>> "return 0;" >>> The couchDB testsuite runs fine. >>> Is this way O.K.? >>> >>> >>> >> This I don't understand at all. >> reload() in crypto.c should only be called if the module is upgraded, not if >> it is unloaded and later loaded again. >> >> /Sverker, Erlang/OTP >> > > The CouchDB test suite does init:restart() several times, does that make sense? > > A+ > Dave > No, init:restart() should not cause a module upgrade. It should delete and purge the module and then load it again (when its first called upon) as if it had never been loaded before. @XinFeng Liu: Are you really sure that reload() is called? If so, then I would be interested in how it got there. Put a call to abort() in reload() and inspect the core dump for example. /Sverker, Erlang/OTP From xinfeng.liu@REDACTED Fri Sep 7 11:56:00 2012 From: xinfeng.liu@REDACTED (XinFeng Liu) Date: Fri, 7 Sep 2012 17:56:00 +0800 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 In-Reply-To: <5048CF00.40801@erix.ericsson.se> References: <5048CF00.40801@erix.ericsson.se> Message-ID: This I don't understand at all. > reload() in crypto.c should only be called if the module is upgraded, not > if it is unloaded and later loaded again. > > /Sverker, Erlang/OTP > > Thanks for pointing this. I'm sorry I made a wrong conclusion for the workaround in modifying reload() function. I wronly modfied reload() in 15B02. I have some new findings on this issue: I find the latest 15B02 (without any modification) does not cause core dump in running couchDB test suite. Digging this issue further, there's a subtle difference between 15B02 and 15B01 in crypto.so. In 15B01, crypto.so explicitly link libssl.so, while in 15B02 it does not. And more importantly, the libssl.so built by Sun/Oracle seems built with "-z nodelete" meaning RTLD_NODELETE. ("elfdump -d" can show that). In 15B01, loading crypto.so causes libssl.so to be loaded, since libssl.so depends on libcrypto.so, libcrypto.so is somehow promoted to RTLD_NODELETE (using solaris runtime LD debugger can show this). So, libcrypto.so is unloadable in dlclose(). In 15B02, when running couchDB test suite, unloading crypto.so causes libcrypto.so unloaded too, then later reloading both crypto.so and libcrypto.so would not cause previous problem. A new question, each time loading crypto.so will cause load() to be called, then it means CRYPTO_set_mem_functions() should be called again, I assume it should correctly set the callback funcs. But from instruction-level tracing and the src, it simply returned in line 129 because "!allow_customize" is true. (dbx) stepi t@REDACTED (l@REDACTED) stopped in CRYPTO_set_mem_functions at 0xfd053b0c 0xfd053b0c: CRYPTO_set_mem_functions+0x0034: retl 125 int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *, size_t), 126 void (*f)(void *)) 127 { 128 if (!allow_customize) 129 return 0; 130 if ((m == 0) || (r == 0) || (f == 0)) 131 return 0; 132 malloc_func=m; malloc_ex_func=default_malloc_ex; 133 realloc_func=r; realloc_ex_func=default_realloc_ex; 134 free_func=f; 135 malloc_locked_func=m; malloc_locked_ex_func=default_malloc_locked_ex; 136 free_locked_func=f; 137 return 1; 138 } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Fri Sep 7 15:03:31 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 7 Sep 2012 15:03:31 +0200 Subject: [erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11 In-Reply-To: References: <5048CF00.40801@erix.ericsson.se> Message-ID: <5049F0A3.1060008@erix.ericsson.se> XinFeng Liu wrote: > This I don't understand at all. > > reload() in crypto.c should only be called if the module is upgraded, not if > it is unloaded and later loaded again. > > /Sverker, Erlang/OTP > > Thanks for pointing this. I'm sorry I made a wrong conclusion for the workaround > in modifying reload() function. I wronly modfied reload() in 15B02. > > Good to know. > I have some new findings on this issue: > I find the latest 15B02 (without any modification) does not cause core dump in > running couchDB test suite. Digging this issue further, there's a subtle > difference between 15B02 and 15B01 in crypto.so. > In 15B01, crypto.so explicitly link libssl.so, while in 15B02 it does not. > > From R15B02 README: OTP-10064 Remove unnecessary dependency to libssl from crypto NIF library. This dependency was introduced by accident in R14B04. > And more importantly, the libssl.so built by Sun/Oracle seems built with "-z > nodelete" meaning RTLD_NODELETE. ("elfdump -d" can show that). > In 15B01, loading crypto.so causes libssl.so to be loaded, since libssl.so > depends on libcrypto.so, libcrypto.so is somehow promoted to RTLD_NODELETE > (using solaris runtime LD debugger can show this). So, libcrypto.so is > unloadable in dlclose(). > In 15B02, when running couchDB test suite, unloading crypto.so causes > libcrypto.so unloaded too, then later reloading both crypto.so and libcrypto.so > would not cause previous problem. > > Ok, so it seems that removing the unnecessary dependency to libssl.se in R15B02 happened to act as a workaround for your problem as that caused libcrypto.so to be unloaded and thereby forgetting its old obsolete callbacks into crypto. > A new question, each time loading crypto.so will cause load() to be called, then > it means CRYPTO_set_mem_functions() should be called again, I assume it should > correctly set the callback funcs. But from instruction-level tracing and the > src, it simply returned in line 129 because "!allow_customize" is true. > > (dbx) stepi > t@REDACTED (l@REDACTED) stopped in CRYPTO_set_mem_functions at 0xfd053b0c > 0xfd053b0c: CRYPTO_set_mem_functions+0x0034: retl > > 125 int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *, > size_t), > 126 void (*f)(void *)) > 127 { > 128 if (!allow_customize) > 129 return 0; > 130 if ((m == 0) || (r == 0) || (f == 0)) > 131 return 0; > 132 malloc_func=m; malloc_ex_func=default_malloc_ex; > 133 realloc_func=r; realloc_ex_func=default_realloc_ex; > 134 free_func=f; > 135 malloc_locked_func=m; > malloc_locked_ex_func=default_malloc_locked_ex; > 136 free_locked_func=f; > 137 return 1; > 138 } > Yes, I've seen this to. It looks like a simple way that openssl uses to "protect" itself against re-registering of callbacks that it does not support. Looking at the openssl code, 'allow_customize' seems to be set to false at the first memory allocation. This means that if you try to (re)set memory callbacks *after* doing something that allocated memory, CRYPTO_set_mem_functions() will fail by returning 0. crypto.c ignores this failure however and that's part of this problem I guess. I have written a work ticket regarding the more general problem of NIF libraries that do not support unloading. Your solution seems to be running R15B02. Another even safer solution could be to build crypto with static linking to openssl (configure flag --disable-dynamic-ssl-lib). /Sverker, Erlang/OTP From emile@REDACTED Thu Sep 13 18:10:08 2012 From: emile@REDACTED (Emile Joubert) Date: Thu, 13 Sep 2012 17:10:08 +0100 Subject: [erlang-bugs] Non-ASCII xref paths fail In-Reply-To: <20532.45949.159951.922598@ornendil.otp.ericsson.se> References: <50259823.1090502@rabbitmq.com> <20532.45949.159951.922598@ornendil.otp.ericsson.se> Message-ID: <50520560.1060400@rabbitmq.com> Hi Hans, On 22/08/12 11:25, Hans Bolinder wrote: >> xref_utils:is_string/2 enforces the overly conservative upper limit of >> 126 in character codes. > > We'll include a simple fix in the upcoming R15B02. I've tried with R15B02 and regrettably see the same problem. While the included test for otp_10192 in xref_SUITE passes, attempts to use xref with non-ASCII paths still fail. -Emile From adam.golya@REDACTED Mon Sep 17 08:19:05 2012 From: adam.golya@REDACTED (=?ISO-8859-1?B?wWThbSBH82x5YQ==?=) Date: Mon, 17 Sep 2012 08:19:05 +0200 Subject: [erlang-bugs] ERTS_DIST_MSG_DBG flag bug Message-ID: Hi, I can't complie branch maint with CFLAGS="-D ERTS_DIST_MSG_DBG". $ sudo CFLAGS="-D ERTS_DIST_MSG_DBG" ./configure $ sudo make ... beam/dist.c: In function ?dist_msg_dbg?: beam/dist.c:70:5: error: too many arguments to function ?erts_decode_dist_ext_size? beam/external.h:178:6: note: declared here make[3]: *** [obj/x86_64-unknown-linux-gnu/opt/smp/dist.o] Error 1 make[3]: Leaving directory `/home/golya/ewc/erlangbuild/git/otp/erts/emulator' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/golya/ewc/erlangbuild/git/otp/erts/emulator' make[1]: *** [smp] Error 2 make[1]: Leaving directory `/home/golya/ewc/erlangbuild/git/otp/erts' make: *** [emulator] Error 2 $ git branch * maint I made little change, and its works: $ git diff diff --git a/erts/emulator/beam/dist.c b/erts/emulator/beam/dist.c index 025258e..b08db7b 100644 --- a/erts/emulator/beam/dist.c +++ b/erts/emulator/beam/dist.c @@ -67,7 +67,7 @@ dist_msg_dbg(ErtsDistExternal *edep, char *what, byte *buf, int sz) { byte *extp = edep->extp; Eterm msg; - Sint size = erts_decode_dist_ext_size(edep, 0); + Sint size = erts_decode_dist_ext_size(edep); if (size < 0) { erts_fprintf(stderr, "DIST MSG DEBUG: erts_decode_dist_ext_size(%s) failed:\n", Regards, ?d?m -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Tue Sep 18 07:55:46 2012 From: norton@REDACTED (Joseph Wayne Norton) Date: Tue, 18 Sep 2012 14:55:46 +0900 Subject: [erlang-bugs] dialyzer: Analysis failed with error: {function_clause, [{erl_types, inf_tuples_in_sets, ... Message-ID: <2FEA9BF0-4634-407B-9210-BF7A907C5345@lovely.email.ne.jp> We stumbled upon a bug with dialyzer (R15B02). Please see the attached Erlang module - a small counterexample. regards, - Joe N. $ dialyzer -n --plt ~/.dialyzer_plt.R15B02 ebin/foo.beam Proceeding with analysis... =ERROR REPORT==== 18-Sep-2012::14:40:49 === Error in process <0.38.0> with exit value: {function_clause,[{erl_types,inf_tuples_in_sets,[[{c,tuple_set,[{3,[{c,tuple,[{c,atom,[inet],unknown},{c,tuple_set,[{4,[{c,tuple,[{c,number,{int_rng,0,255},integer},{c,number,{int_rng,0,255},integer},{c,number,{int_rng... dialyzer: Analysis failed with error: {function_clause,[{erl_types,inf_tuples_in_sets, [[{c,tuple_set,[...],...}], [{c,tuple,...},{c,...}], [],opaque], [{file,"erl_types.erl"},{line,2453}]}, {erl_types,inf_tuple_sets,4,[{file,[...]},{line,...}]}, {erl_types,inf_tuple_sets,3,[{file,...},{...}]}, {erl_types,t_inf,3,[{...}|...]}, {dialyzer_contracts,'-check_contract/2-lc$^3/1-3-',2,[...]}, {dialyzer_contracts,check_contract,2,...}, {dialyzer_contracts,'-check_contracts/3-fun-0-',...}, {dict,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 0.06 secs Removing edges... done in 0.01 secs -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.erl Type: application/octet-stream Size: 2167 bytes Desc: not available URL: From erlang@REDACTED Tue Sep 18 09:56:26 2012 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Sep 2012 09:56:26 +0200 Subject: [erlang-bugs] Bug in code:lib_dir Message-ID: If I set ERL_LIBS as follows export ERL_LIBS=/home/joe/deps and deps is as follows /deps/a/src /include From erlang@REDACTED Tue Sep 18 10:14:53 2012 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Sep 2012 10:14:53 +0200 Subject: [erlang-bugs] bug in code:lib_dir Message-ID: > code:lib_dir(b) {error,bad_name} Fails if the b sub-directory does not contain an ebin directory. This means things like include_lib("b/include/foo.hrl") will fail even though the file b/include/foo.hrl exists. Suppose I have a directory structure like this: /home/joe/deps/a/src /include /ebin /b/src /include/foo.hrl a and b are Erlang applications - note that b has no ebin directory Then I say > export ERL_LIBS=/home/joe/deps > erl Then > code:lib_dir(a). "/home/joe/deps/a/" But > code:lib_dir(b) {error,bad_name} Now suppose a.erl contains the line -include_lib("b/include/foo.hrl") I'll now get an error. The code server calls lib_dib(b) to resolve the file name reference. This fails and the system concludes (incorrectly) that b/include/foo.hrl does not exist. If I add an empty ebin directory to b then the error goes away. If you create src, ebin, include directories by hand you will never see this error. But if you use rebar then the ebin directory is not created when you do > rebar create-app appid= The ebin directory is created when you first run rebar compile. So recursive includes (a includes b/include and b includes a/include) can possibly fail if no ebin directory is created. Cheers /Joe From serge@REDACTED Tue Sep 18 13:57:32 2012 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 18 Sep 2012 07:57:32 -0400 Subject: [erlang-bugs] bug in code:lib_dir In-Reply-To: References: Message-ID: <505861AC.9040102@aleynikov.org> Joe, When I wrote the code supporting ERL_LIBS that got included in the code server (*), it was explicitly designed to iteratively check for paths only containing "ebin" child directories (see the code_server:get_user_lib_dirs_1/0) before adding them to the loader path. Therefore I wouldn't consider the behavior you mentioned to be a bug but rather a feature. Initially I wrote it in a way that checked for directories containing "*.app" files, and included those. However, I found cases when certain libraries didn't come with "*.app" files, but merely contained "ebin/*.beam" bytecode files, so the ebin directory checking was more reliable and conventional. In your case, since 'b' application doesn't seem to have neither b.app nor b/ebin. Should it be considered a valid code path (there's nothing to load for the code server)? If so, what is the right selection criteria that would avoid bloating the loader's path? Serge (*) http://www-rohan.sdsu.edu/doc/R12B/lib/kernel-2.12.3/doc/html/notes.html On 9/18/2012 4:14 AM, Joe Armstrong wrote: > > code:lib_dir(b) > {error,bad_name} > > Fails if the b sub-directory does not contain an ebin directory. > This means things like include_lib("b/include/foo.hrl") will fail > even though the file b/include/foo.hrl exists. > > > Suppose I have a directory structure like this: > > /home/joe/deps/a/src > /include > /ebin > /b/src > /include/foo.hrl > > > a and b are Erlang applications - note that b has no ebin directory > > Then I say > > > export ERL_LIBS=/home/joe/deps > > erl > > Then > > > code:lib_dir(a). > "/home/joe/deps/a/" > > But > > > code:lib_dir(b) > {error,bad_name} > > Now suppose a.erl contains the line > > -include_lib("b/include/foo.hrl") > > I'll now get an error. The code server calls lib_dib(b) to resolve > the file name > reference. This fails and the system concludes (incorrectly) that > b/include/foo.hrl does not > exist. > > If I add an empty ebin directory to b then the error goes away. > > If you create src, ebin, include directories by hand you will never > see this error. > > But if you use rebar then the ebin directory is not created when you do > > rebar create-app appid= > > The ebin directory is created when you first run rebar compile. > > So recursive includes (a includes b/include and b includes > a/include) can possibly > fail if no ebin directory is created. > > Cheers > > /Joe > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From pan@REDACTED Tue Sep 18 16:52:22 2012 From: pan@REDACTED (pan@REDACTED) Date: Tue, 18 Sep 2012 16:52:22 +0200 Subject: [erlang-bugs] ERTS_DIST_MSG_DBG flag bug In-Reply-To: References: Message-ID: Hi! While this define is not something you can set in configure, i.e. it's only for hard debugging during development, it's still nice to have it fixed. Thanx! /Patrik, OTP On Mon, 17 Sep 2012, ?d?m G?lya wrote: > Hi, > > I can't complie branch maint with CFLAGS="-D ERTS_DIST_MSG_DBG". > > $ sudo CFLAGS="-D ERTS_DIST_MSG_DBG" ./configure > > $ sudo make > ... > beam/dist.c: In function ?dist_msg_dbg?: > beam/dist.c:70:5: error: too many arguments to function > ?erts_decode_dist_ext_size? > beam/external.h:178:6: note: declared here > make[3]: *** [obj/x86_64-unknown-linux-gnu/opt/smp/dist.o] Error 1 > make[3]: Leaving directory > `/home/golya/ewc/erlangbuild/git/otp/erts/emulator' > make[2]: *** [opt] Error 2 > make[2]: Leaving directory > `/home/golya/ewc/erlangbuild/git/otp/erts/emulator' > make[1]: *** [smp] Error 2 > make[1]: Leaving directory `/home/golya/ewc/erlangbuild/git/otp/erts' > make: *** [emulator] Error 2 > > $ git branch > * maint > > I made little change, and its works: > > $ git diff > diff --git a/erts/emulator/beam/dist.c b/erts/emulator/beam/dist.c > index 025258e..b08db7b 100644 > --- a/erts/emulator/beam/dist.c > +++ b/erts/emulator/beam/dist.c > @@ -67,7 +67,7 @@ dist_msg_dbg(ErtsDistExternal *edep, char *what, byte > *buf, int sz) > { > byte *extp = edep->extp; > Eterm msg; > - Sint size = erts_decode_dist_ext_size(edep, 0); > + Sint size = erts_decode_dist_ext_size(edep); > if (size < 0) { > erts_fprintf(stderr, > "DIST MSG DEBUG: erts_decode_dist_ext_size(%s) > failed:\n", > > Regards, > ?d?m > From erlang@REDACTED Tue Sep 18 20:54:03 2012 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Sep 2012 20:54:03 +0200 Subject: [erlang-bugs] bug in code:lib_dir In-Reply-To: <505861AC.9040102@aleynikov.org> References: <505861AC.9040102@aleynikov.org> Message-ID: On Tue, Sep 18, 2012 at 1:57 PM, Serge Aleynikov wrote: > Joe, > > When I wrote the code supporting ERL_LIBS that got included in the code > server (*), it was explicitly designed to iteratively check for paths > only containing "ebin" child directories (see the > code_server:get_user_lib_dirs_1/0) before adding them to the loader > path. Therefore I wouldn't consider the behavior you mentioned to be a > bug but rather a feature. > > Initially I wrote it in a way that checked for directories containing > "*.app" files, and included those. However, I found cases when certain > libraries didn't come with "*.app" files, but merely contained > "ebin/*.beam" bytecode files, so the ebin directory checking was more > reliable and conventional. > > In your case, since 'b' application doesn't seem to have neither b.app > nor b/ebin. Should it be considered a valid code path (there's nothing > to load for the code server)? If so, what is the right selection > criteria that would avoid bloating the loader's path? Well the problem is that code:lib_dir(a) is called when the compiler tries to compile a file containing an include_lib directive like -include_lib("a/include/foo.hrl"). If there really is a file called "a/include/foo.hrl" then it seems rather harsh to fail the compilation. rebar in particular only creates an ebin direction as a result of a compile - I googled a bit and found many cases where a missing include file message was worrying people - and I think this was the reason. In the project I was looking at this bug occurred and was fixed with a work-around. I'm not sure about "code loader path bloat" if you trust the LIB_DIRS env variable is correctly set. I'm not sure if you recursively scan all directories below the LIB_DIRS but I guess just one level would be ok. The problem also happens (I think) if git doesn't remake an empty ebin directory. The problem is in find_lib_dir (line 637) of epp.erl Actually the compile error message could be more helpful can't find include lib "aaa/include/d.yrl" It's true - but confused me for a hour - why could't it find this file - ERL_LIBS had aaa in it's path - if the message had been can't find include lib "aaa/include/d.yrl" (possible reason aaa/ebin is missing) I would have guessed what was going wrong. The root of the problem is that you can't identify app directories - sooner or later this must be fixed - I think there should be a proper manifest.json (or something) in top level of the app - this and only this would identify this as an app. Until then we need various work-arounds. Probably easiest to change epp so is calls something other than code:lib_dir when resolving the filename Cheers /Joe > > Serge > > (*) http://www-rohan.sdsu.edu/doc/R12B/lib/kernel-2.12.3/doc/html/notes.html > > On 9/18/2012 4:14 AM, Joe Armstrong wrote: >> > code:lib_dir(b) >> {error,bad_name} >> >> Fails if the b sub-directory does not contain an ebin directory. >> This means things like include_lib("b/include/foo.hrl") will fail >> even though the file b/include/foo.hrl exists. >> >> >> Suppose I have a directory structure like this: >> >> /home/joe/deps/a/src >> /include >> /ebin >> /b/src >> /include/foo.hrl >> >> >> a and b are Erlang applications - note that b has no ebin directory >> >> Then I say >> >> > export ERL_LIBS=/home/joe/deps >> > erl >> >> Then >> >> > code:lib_dir(a). >> "/home/joe/deps/a/" >> >> But >> >> > code:lib_dir(b) >> {error,bad_name} >> >> Now suppose a.erl contains the line >> >> -include_lib("b/include/foo.hrl") >> >> I'll now get an error. The code server calls lib_dib(b) to resolve >> the file name >> reference. This fails and the system concludes (incorrectly) that >> b/include/foo.hrl does not >> exist. >> >> If I add an empty ebin directory to b then the error goes away. >> >> If you create src, ebin, include directories by hand you will never >> see this error. >> >> But if you use rebar then the ebin directory is not created when you do >> > rebar create-app appid= >> >> The ebin directory is created when you first run rebar compile. >> >> So recursive includes (a includes b/include and b includes >> a/include) can possibly >> fail if no ebin directory is created. >> >> Cheers >> >> /Joe >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> From mononcqc@REDACTED Tue Sep 18 21:39:03 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 18 Sep 2012 15:39:03 -0400 Subject: [erlang-bugs] bug in code:lib_dir In-Reply-To: References: <505861AC.9040102@aleynikov.org> Message-ID: <5058CDD7.80902@ferd.ca> It sounds like you could solve the problem quite easily by adding an app file to your directory, transforming it into a library application, assuming the following project structure: lib_dir/ebin/my_app.app lib_dir/include/my_app.hrl where my_app.app looks as follows: {application, my_app, [{description, "useful header files for Joe"}, {vsn, "1.0.0"}, {modules, []}]}. This should give you an entirely empty library application -- with no beam code, but a .app file is present. This makes it visible to ERL_LIBS, usable as a dependency with rebar, visible and manageable in releases, etc. On 12-09-18 2:54 PM, Joe Armstrong wrote: > On Tue, Sep 18, 2012 at 1:57 PM, Serge Aleynikov wrote: >> Joe, >> >> When I wrote the code supporting ERL_LIBS that got included in the code >> server (*), it was explicitly designed to iteratively check for paths >> only containing "ebin" child directories (see the >> code_server:get_user_lib_dirs_1/0) before adding them to the loader >> path. Therefore I wouldn't consider the behavior you mentioned to be a >> bug but rather a feature. >> >> Initially I wrote it in a way that checked for directories containing >> "*.app" files, and included those. However, I found cases when certain >> libraries didn't come with "*.app" files, but merely contained >> "ebin/*.beam" bytecode files, so the ebin directory checking was more >> reliable and conventional. >> >> In your case, since 'b' application doesn't seem to have neither b.app >> nor b/ebin. Should it be considered a valid code path (there's nothing >> to load for the code server)? If so, what is the right selection >> criteria that would avoid bloating the loader's path? > Well the problem is that code:lib_dir(a) is called when > the compiler tries to compile a file containing an include_lib > directive like > > -include_lib("a/include/foo.hrl"). > > If there really is a file called "a/include/foo.hrl" then it seems > rather harsh to fail the compilation. > > rebar in particular only creates an ebin direction as a result of a > compile - I googled a bit and found many cases where a > missing include file message was worrying people - and I think this > was the reason. In the project I was looking at > this bug occurred and was fixed with a work-around. > > I'm not sure about "code loader path bloat" if you trust > the LIB_DIRS env variable is correctly set. I'm not sure if > you recursively scan all directories below the LIB_DIRS > but I guess just one level would be ok. > > The problem also happens (I think) if git doesn't remake an > empty ebin directory. > > The problem is in find_lib_dir (line 637) of epp.erl > > Actually the compile error message could be more helpful > > can't find include lib "aaa/include/d.yrl" > > It's true - but confused me for a hour - why could't it find > this file - ERL_LIBS had aaa in it's path - if the message had been > > can't find include lib "aaa/include/d.yrl" > (possible reason aaa/ebin is missing) > > I would have guessed what was going wrong. > > The root of the problem is that you can't identify app directories - > sooner or later this must be fixed - I think > there should be a proper manifest.json (or something) in > top level of the app - this and only this would identify this as an app. > > Until then we need various work-arounds. Probably easiest > to change epp so is calls something other than code:lib_dir > when resolving the filename > > Cheers > > /Joe > > > > > >> Serge >> >> (*) http://www-rohan.sdsu.edu/doc/R12B/lib/kernel-2.12.3/doc/html/notes.html >> >> On 9/18/2012 4:14 AM, Joe Armstrong wrote: >>> > code:lib_dir(b) >>> {error,bad_name} >>> >>> Fails if the b sub-directory does not contain an ebin directory. >>> This means things like include_lib("b/include/foo.hrl") will fail >>> even though the file b/include/foo.hrl exists. >>> >>> >>> Suppose I have a directory structure like this: >>> >>> /home/joe/deps/a/src >>> /include >>> /ebin >>> /b/src >>> /include/foo.hrl >>> >>> >>> a and b are Erlang applications - note that b has no ebin directory >>> >>> Then I say >>> >>> > export ERL_LIBS=/home/joe/deps >>> > erl >>> >>> Then >>> >>> > code:lib_dir(a). >>> "/home/joe/deps/a/" >>> >>> But >>> >>> > code:lib_dir(b) >>> {error,bad_name} >>> >>> Now suppose a.erl contains the line >>> >>> -include_lib("b/include/foo.hrl") >>> >>> I'll now get an error. The code server calls lib_dib(b) to resolve >>> the file name >>> reference. This fails and the system concludes (incorrectly) that >>> b/include/foo.hrl does not >>> exist. >>> >>> If I add an empty ebin directory to b then the error goes away. >>> >>> If you create src, ebin, include directories by hand you will never >>> see this error. >>> >>> But if you use rebar then the ebin directory is not created when you do >>> > rebar create-app appid= >>> >>> The ebin directory is created when you first run rebar compile. >>> >>> So recursive includes (a includes b/include and b includes >>> a/include) can possibly >>> fail if no ebin directory is created. >>> >>> Cheers >>> >>> /Joe >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From serge@REDACTED Wed Sep 19 01:33:26 2012 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 18 Sep 2012 19:33:26 -0400 Subject: [erlang-bugs] bug in code:lib_dir In-Reply-To: <5058CDD7.80902@ferd.ca> References: <505861AC.9040102@aleynikov.org> <5058CDD7.80902@ferd.ca> Message-ID: <505904C6.9020507@aleynikov.org> +1. On 9/18/2012 3:39 PM, Fred Hebert wrote: > It sounds like you could solve the problem quite easily by adding an app > file to your directory, transforming it into a library application, > assuming the following project structure: > > lib_dir/ebin/my_app.app > lib_dir/include/my_app.hrl > > where my_app.app looks as follows: > > {application, my_app, > [{description, "useful header files for Joe"}, > {vsn, "1.0.0"}, > {modules, []}]}. > > This should give you an entirely empty library application -- with no > beam code, but a .app file is present. This makes it visible to > ERL_LIBS, usable as a dependency with rebar, visible and manageable in > releases, etc. > > > On 12-09-18 2:54 PM, Joe Armstrong wrote: >> On Tue, Sep 18, 2012 at 1:57 PM, Serge Aleynikov >> wrote: >>> Joe, >>> >>> When I wrote the code supporting ERL_LIBS that got included in the code >>> server (*), it was explicitly designed to iteratively check for paths >>> only containing "ebin" child directories (see the >>> code_server:get_user_lib_dirs_1/0) before adding them to the loader >>> path. Therefore I wouldn't consider the behavior you mentioned to be a >>> bug but rather a feature. >>> >>> Initially I wrote it in a way that checked for directories containing >>> "*.app" files, and included those. However, I found cases when certain >>> libraries didn't come with "*.app" files, but merely contained >>> "ebin/*.beam" bytecode files, so the ebin directory checking was more >>> reliable and conventional. >>> >>> In your case, since 'b' application doesn't seem to have neither b.app >>> nor b/ebin. Should it be considered a valid code path (there's nothing >>> to load for the code server)? If so, what is the right selection >>> criteria that would avoid bloating the loader's path? >> Well the problem is that code:lib_dir(a) is called when >> the compiler tries to compile a file containing an include_lib >> directive like >> >> -include_lib("a/include/foo.hrl"). >> >> If there really is a file called "a/include/foo.hrl" then it seems >> rather harsh to fail the compilation. >> >> rebar in particular only creates an ebin direction as a result of a >> compile - I googled a bit and found many cases where a >> missing include file message was worrying people - and I think this >> was the reason. In the project I was looking at >> this bug occurred and was fixed with a work-around. >> >> I'm not sure about "code loader path bloat" if you trust >> the LIB_DIRS env variable is correctly set. I'm not sure if >> you recursively scan all directories below the LIB_DIRS >> but I guess just one level would be ok. >> >> The problem also happens (I think) if git doesn't remake an >> empty ebin directory. >> >> The problem is in find_lib_dir (line 637) of epp.erl >> >> Actually the compile error message could be more helpful >> >> can't find include lib "aaa/include/d.yrl" >> >> It's true - but confused me for a hour - why could't it find >> this file - ERL_LIBS had aaa in it's path - if the message had been >> >> can't find include lib "aaa/include/d.yrl" >> (possible reason aaa/ebin is missing) >> >> I would have guessed what was going wrong. >> >> The root of the problem is that you can't identify app directories - >> sooner or later this must be fixed - I think >> there should be a proper manifest.json (or something) in >> top level of the app - this and only this would identify this as an app. >> >> Until then we need various work-arounds. Probably easiest >> to change epp so is calls something other than code:lib_dir >> when resolving the filename >> >> Cheers >> >> /Joe >> >> >> >> >> >>> Serge >>> >>> (*) >>> http://www-rohan.sdsu.edu/doc/R12B/lib/kernel-2.12.3/doc/html/notes.html >>> >>> On 9/18/2012 4:14 AM, Joe Armstrong wrote: >>>> > code:lib_dir(b) >>>> {error,bad_name} >>>> >>>> Fails if the b sub-directory does not contain an ebin directory. >>>> This means things like include_lib("b/include/foo.hrl") will fail >>>> even though the file b/include/foo.hrl exists. >>>> >>>> >>>> Suppose I have a directory structure like this: >>>> >>>> /home/joe/deps/a/src >>>> /include >>>> /ebin >>>> /b/src >>>> /include/foo.hrl >>>> >>>> >>>> a and b are Erlang applications - note that b has no ebin directory >>>> >>>> Then I say >>>> >>>> > export ERL_LIBS=/home/joe/deps >>>> > erl >>>> >>>> Then >>>> >>>> > code:lib_dir(a). >>>> "/home/joe/deps/a/" >>>> >>>> But >>>> >>>> > code:lib_dir(b) >>>> {error,bad_name} >>>> >>>> Now suppose a.erl contains the line >>>> >>>> -include_lib("b/include/foo.hrl") >>>> >>>> I'll now get an error. The code server calls lib_dib(b) to resolve >>>> the file name >>>> reference. This fails and the system concludes (incorrectly) that >>>> b/include/foo.hrl does not >>>> exist. >>>> >>>> If I add an empty ebin directory to b then the error goes away. >>>> >>>> If you create src, ebin, include directories by hand you will never >>>> see this error. >>>> >>>> But if you use rebar then the ebin directory is not created when >>>> you do >>>> > rebar create-app appid= >>>> >>>> The ebin directory is created when you first run rebar compile. >>>> >>>> So recursive includes (a includes b/include and b includes >>>> a/include) can possibly >>>> fail if no ebin directory is created. >>>> >>>> Cheers >>>> >>>> /Joe >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From norton@REDACTED Sun Sep 23 15:51:19 2012 From: norton@REDACTED (Joseph Wayne Norton) Date: Sun, 23 Sep 2012 22:51:19 +0900 Subject: [erlang-bugs] dialyzer warning - The call erl_ddll:format_error(Err::{'open_error', _}) will never return ... Message-ID: <915B8BA1-DFA2-41E7-B663-61EAD8282329@lovely.email.ne.jp> The function specification for the erl_ddll:format_error builtin seems to be incomplete. To repeat this dialyzer warning, please see the attached file. thanks, - Joe N. $ erlc +debug_info foo.erl $ dialyzer foo.beam Checking whether the PLT ~/.dialyzer_plt.R15B02 is up-to-date... yes Proceeding with analysis... foo.erl:19: The call erl_ddll:format_error(Err::{'open_error',_}) will never return since it differs in the 1st argument from the success typing arguments: ('already_loaded' | 'inconsistent' | 'linked_in_driver' | 'load_cancelled' | 'not_loaded' | 'not_loaded_by_this_process' | 'not_pending' | 'permanent' | 'unloading') done in 0m9.45s done (warnings were emitted) $ erl --version Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.2 (abort with ^G) 1> -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.erl Type: application/octet-stream Size: 883 bytes Desc: not available URL: From andrew@REDACTED Mon Sep 24 22:18:28 2012 From: andrew@REDACTED (Andrew Thompson) Date: Mon, 24 Sep 2012 16:18:28 -0400 Subject: [erlang-bugs] Bug in ssl:controlling_process? Message-ID: <20120924201827.GA24401@hijacked.us> 3> {ok, S} = ssl:listen(0, [{certfile, "cert.pem"}]). {ok,{sslsocket,new_ssl, {#Port<0.667>, {config,{ssl_options,[],verify_none, {#Fun,[]}, false,false,undefined,1, "cert.pem", undefined, "cert.pem", undefined,[],undefined,[],undefined,undefined, [<<0,...>>,<<...>>|...], #Fun,true,...}, [], {socket_options,list,0,0,0,true}, [{packet_size,0}, {packet,0}, {header,0}, {active,false}, {mode,binary}], {gen_tcp,tcp,tcp_closed,tcp_error}}}}} 4> ssl:controlling_process(S, self()). ** exception error: no function clause matching ssl:controlling_process({sslsocket,new_ssl, {#Port<0.667>, {config,{ssl_options,[],verify_none, {#Fun,[]}, false,false,undefined,1, "cert.pem", undefined, "cert.pem", undefined,[],undefined,[],undefined,undefined, [<<0,57>>,<<0,...>>,<<...>>|...], #Fun,true,268435456,...}, [], {socket_options,list,0,0,0,true}, [{packet_size,0}, {packet,0}, {header,0}, {active,false}, {mode,binary}], {gen_tcp,tcp,tcp_closed,tcp_error}}}}, <0.36.0>) (ssl.erl, line 273) ssl:controlling_process reads as follows: controlling_process(#sslsocket{pid = Pid}, NewOwner) when is_pid(Pid) -> ssl_connection:new_user(Pid, NewOwner). But, in the sslsocket, pid is NOT a pid, it is that giant tuple containing state information. Doing a connect() seems to give me a pid in the sslsocket: ssl:connect("imap.gmail.com", 993, [{certfile, "cert.pem"}]). {ok,{sslsocket,new_ssl,<0.56.0>}} Yet, in the documentation, both listen() and connect() return type sslsocket() which is a what controlling_process is documented as taking as the first argument? Maybe a new clause of controlling process that looks like this: controlling_process(#sslsocket{pid = {ListenSocket, Config}}, NewOwner) -> #config{cb={CbModule, _, _, _}} = Config, CbModule:controlling_process(ListenSocket, NewOwner). Seems like that'd let you change the controlling process for 'listen sockets' as well, assuming the caller is the current owner? Andrew From aronisstav@REDACTED Wed Sep 26 11:12:33 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 26 Sep 2012 11:12:33 +0200 Subject: [erlang-bugs] dialyzer: Analysis failed with error: {function_clause, [{erl_types, inf_tuples_in_sets, ... In-Reply-To: <2FEA9BF0-4634-407B-9210-BF7A907C5345@lovely.email.ne.jp> References: <2FEA9BF0-4634-407B-9210-BF7A907C5345@lovely.email.ne.jp> Message-ID: Hi! I just submitted a patch containing a fix for this crash. git fetch git://github.com/aronisstav/otp.git dialyzer-fix Thanks for the report! Stavros On Tue, Sep 18, 2012 at 7:55 AM, Joseph Wayne Norton < norton@REDACTED> wrote: > > We stumbled upon a bug with dialyzer (R15B02). Please see the attached > Erlang module - a small counterexample. > > regards, > > - Joe N. > > > $ dialyzer -n --plt ~/.dialyzer_plt.R15B02 ebin/foo.beam > Proceeding with analysis... > =ERROR REPORT==== 18-Sep-2012::14:40:49 === > Error in process <0.38.0> with exit value: > {function_clause,[{erl_types,inf_tuples_in_sets,[[{c,tuple_set,[{3,[{c,tuple,[{c,atom,[inet],unknown},{c,tuple_set,[{4,[{c,tuple,[{c,number,{int_rng,0,255},integer},{c,number,{int_rng,0,255},integer},{c,number,{int_rng... > > > dialyzer: Analysis failed with error: > {function_clause,[{erl_types,inf_tuples_in_sets, > [[{c,tuple_set,[...],...}], > [{c,tuple,...},{c,...}], > [],opaque], > [{file,"erl_types.erl"},{line,2453}]}, > {erl_types,inf_tuple_sets,4,[{file,[...]},{line,...}]}, > {erl_types,inf_tuple_sets,3,[{file,...},{...}]}, > {erl_types,t_inf,3,[{...}|...]}, > > {dialyzer_contracts,'-check_contract/2-lc$^3/1-3-',2,[...]}, > {dialyzer_contracts,check_contract,2,...}, > {dialyzer_contracts,'-check_contracts/3-fun-0-',...}, > {dict,...}]} > Last messages in the log cache: > Reading files and computing callgraph... done in 0.06 secs > Removing edges... done in 0.01 secs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronisstav@REDACTED Wed Sep 26 11:13:42 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 26 Sep 2012 11:13:42 +0200 Subject: [erlang-bugs] Bug in R15B02 dialyzer In-Reply-To: <1614154.C4sXyEalIZ@csr-pc40.zib.de> References: <2074903.H8y3x6AZZS@csr-pc40.zib.de> <5048910B.3020307@cs.ntua.gr> <1614154.C4sXyEalIZ@csr-pc40.zib.de> Message-ID: Hi! I just submitted a patch containing a fix for this crash. git fetch git://github.com/aronisstav/otp.git dialyzer-fix Thanks for the report! Stavros On Thu, Sep 6, 2012 at 2:43 PM, Nico Kruber wrote: > On Thursday 06 Sep 2012 14:03:23 Kostis Sagonas wrote: > > On 09/06/2012 11:31 AM, Nico Kruber wrote: > > > same here (running dialyzer from R15B02 on the Scalaris sources): > > > > > > Scalaris> make dialyzer > > > /usr/lib64/erlang/bin/dialyzer -Dhave_toke -Dtid_not_builtin - > > > Dwith_export_type_support -DNO_FILE_SENDFILE -Dhave_cthooks_support - > > > Dhave_callback_support -Werror_handling -Wrace_conditions > > > -Wunmatched_returns -I include/ -I contrib/yaws/include/ -I > > > contrib/log4erl/include/ --src -c src src/*/ test/unittest_helper.erl > > > test/tester*.erl test/mockup*.erl > > > test/erl_id_trans.erl test/measure_util.erl test/scalaris_cth.erl > > > --no_native> > > > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... > yes > > > Proceeding with analysis... > > > > > > =ERROR REPORT==== 6-Sep-2012::11:26:27 === > > > Error in process<0.7223.0> with exit value: > > > {badarg,[{ets,insert,[4947997, > > > [{{out,{comm_logger,dump,0}},{{comm_logger,dump,0}, > > > {comm_logger,handle_call,3}}},{{in,{comm_logger,handle_call,3}}, > > > {{comm_logger,dump,0},{comm_logger,handle_call,3}}}]],[]}, > > > {digraph,do_insert_edge,5,[{... > > > > The race condition detection in dialyzer in R15B02 unfortunately has a > > problem in many cases (at least in all cases where behaviours are also > > involved). We already have a patch for this, which we are testing in > > large code bases to make sure there are no issues left, and we will > > notify this thread for its existence when it gets ready. > > > > In the meantime, I suggest NOT to use the option -Wrace_conditions > > (which is off by default). We are pretty confident that the crashes you > > experience are due to this. > > I can confirm, that removing "-Wrace_conditions" solves the problem for > us... > > > Nico > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.anderton.andin@REDACTED Wed Sep 26 14:35:13 2012 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Wed, 26 Sep 2012 14:35:13 +0200 Subject: [erlang-bugs] Bug in ssl:controlling_process? In-Reply-To: <20120924201827.GA24401@hijacked.us> References: <20120924201827.GA24401@hijacked.us> Message-ID: <5062F681.70402@erix.ericsson.se> Hi! I think you are right, we will add the missing clause. Regards Ingela Erlang/OTP team - Ericsson AB Andrew Thompson wrote: > 3> {ok, S} = ssl:listen(0, [{certfile, "cert.pem"}]). > {ok,{sslsocket,new_ssl, > {#Port<0.667>, > {config,{ssl_options,[],verify_none, > {#Fun,[]}, > false,false,undefined,1, > "cert.pem", > undefined, > "cert.pem", > undefined,[],undefined,[],undefined,undefined, > [<<0,...>>,<<...>>|...], > #Fun,true,...}, > [], > {socket_options,list,0,0,0,true}, > [{packet_size,0}, > {packet,0}, > {header,0}, > {active,false}, > {mode,binary}], > {gen_tcp,tcp,tcp_closed,tcp_error}}}}} > 4> ssl:controlling_process(S, self()). > ** exception error: no function clause matching ssl:controlling_process({sslsocket,new_ssl, > {#Port<0.667>, > {config,{ssl_options,[],verify_none, > {#Fun,[]}, > false,false,undefined,1, > "cert.pem", > undefined, > "cert.pem", > undefined,[],undefined,[],undefined,undefined, > [<<0,57>>,<<0,...>>,<<...>>|...], > #Fun,true,268435456,...}, > [], > {socket_options,list,0,0,0,true}, > [{packet_size,0}, > {packet,0}, > {header,0}, > {active,false}, > {mode,binary}], > {gen_tcp,tcp,tcp_closed,tcp_error}}}}, > <0.36.0>) (ssl.erl, line 273) > > ssl:controlling_process reads as follows: > > controlling_process(#sslsocket{pid = Pid}, NewOwner) when is_pid(Pid) -> > ssl_connection:new_user(Pid, NewOwner). > > But, in the sslsocket, pid is NOT a pid, it is that giant tuple containing > state information. > > Doing a connect() seems to give me a pid in the sslsocket: > > ssl:connect("imap.gmail.com", 993, [{certfile, "cert.pem"}]). > {ok,{sslsocket,new_ssl,<0.56.0>}} > > Yet, in the documentation, both listen() and connect() return type > sslsocket() which is a what controlling_process is documented as taking > as the first argument? > > Maybe a new clause of controlling process that looks like this: > > controlling_process(#sslsocket{pid = {ListenSocket, Config}}, NewOwner) -> > #config{cb={CbModule, _, _, _}} = Config, > CbModule:controlling_process(ListenSocket, NewOwner). > > Seems like that'd let you change the controlling process for 'listen > sockets' as well, assuming the caller is the current owner? > > Andrew > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From erlang@REDACTED Wed Sep 26 16:15:55 2012 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 26 Sep 2012 16:15:55 +0200 Subject: [erlang-bugs] bug in escript Message-ID: I think there is a bug in escript I have an escript in the same directory as escript, erlc etc. If I cd to this directory I cannot run the escript. But I can run it from any other directory /Joe From kostis@REDACTED Wed Sep 26 22:56:45 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 26 Sep 2012 22:56:45 +0200 Subject: [erlang-bugs] bug in escript In-Reply-To: References: Message-ID: <50636C0D.3070602@cs.ntua.gr> On 09/26/2012 04:15 PM, Joe Armstrong wrote: > I think there is a bug in escript > > I have an escript in the same directory as escript, erlc etc. > > If I cd to this directory I cannot run the escript. But I can run it > from any other directory Wild guess: You are probably running the escript as: $ my_escript and you do not have . in your path. Either add it (at the end) or use: $ ./my_escript Kostis From michael@REDACTED Thu Sep 27 13:19:43 2012 From: michael@REDACTED (Michael Gebetsroither) Date: Thu, 27 Sep 2012 13:19:43 +0200 Subject: [erlang-bugs] ssl:setopts hangs indefinitely Message-ID: <5064364F.30106@mgeb.org> Hello, We have a lot of gen_server processes locked up here and we suspect ssl:setopts is the cause. The erlang vm version used is R15B01 from debian, and i'm currently testing R15B02 packages from esl. (confirmed, R15B02 from esl also has this problem) The gen_server hang can be reproduced if we connect from a remote host over ssl to the server and remove the network plug, during communication. Though we couldn't reproduce the error with a local client. The hanging gen_server is the server process doing all the communication and housekeeping tasks on the socket. After applying our fix all locked up gen_server processes are gone, because they now terminate on the 2 seconds timeout wrapped around ssl:setopts. IMHO the problematic code part is ssl_connection.erl:242 from R15B02 git tag (thought it seems it is not the root cause, only the effect). # ssl_connection.erl:242 set_opts(ConnectionPid, Options) -> sync_send_all_state_event(ConnectionPid, {set_opts, Options}). # Backtrace of a hanging gen_server (testnode@REDACTED)4> Program counter: 0x00007f4318db94d0 (gen:do_call/4 + 576) CP: 0x0000000000000000 (invalid) arity = 0 0x00007f431b54b2f0 Return addr 0x00007f431386c4e8 (gen_fsm:sync_send_all_state_event/3 + 128) y(0) #Ref<0.0.65.195525> y(1) 'testnode@REDACTED' y(2) [] y(3) infinity y(4) {set_opts,[{active,once}]} y(5) '$gen_sync_all_state_event' y(6) <0.3933.0> 0x00007f431b54b330 Return addr 0x00007f431389aaa8 (ssl_connection:sync_send_all_state_event/3 + 64) y(0) infinity y(1) {set_opts,[{active,once}]} y(2) <0.3933.0> y(3) Catch 0x00007f431386c4e8 (gen_fsm:sync_send_all_state_event/3 + 128) 0x00007f431b54b358 Return addr 0x00007f4312fd78b8 (socket_handler:handle_info/2 + 1760) y(0) Catch 0x00007f431389aac8 (ssl_connection:sync_send_all_state_event/3 + 96) 0x00007f431b54b368 Return addr 0x00007f4318e43218 (gen_server:handle_msg/5 + 1680) y(0) {state,{sslsocket,new_ssl,<0.3933.0>}, ...} y(1) {handle_msg return data} # our fix was wrapping ssl:setopts ssl_setopts(SslSocket, Options) -> Ref = erlang:now(), PPid = self(), Pid = spawn_link(fun() -> ssl:setopts(SslSocket, Options), PPid ! {self(), Ref, ssl_setopts_successful} end), receive {Pid, Ref, ssl_setopts_successful} -> ok after ?SSL_SETOPTS_TIMEOUT -> erlang:exit({error, timeout, {ssl_setopts, Options}}) end. Michael Gebetsroither From jpeacock@REDACTED Thu Sep 27 19:12:27 2012 From: jpeacock@REDACTED (John Peacock) Date: Thu, 27 Sep 2012 13:12:27 -0400 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries Message-ID: <506488FB.6090507@messagesystems.com> According to the documentation: http://www.erlang.org/doc/man/crypto_app.html "The current implementation of the Erlang Crypto application is based on the OpenSSL package version 0.9.7 or higher." Unfortunately, the Openssl project released the original 0.9.7 2002-12-31 and the last release 0.9.7m 2007-02-23, so that statement is misleading at best. Since Openssl was not 100% API compliant for all of those releases (adding new functions in 0.9.7e and 0.9.7h) the docs need to be much more specific. We have an application that must support Solaris 10u6, which shipped with Openssl 0.9.7d (we cannot upgrade the system library and I'd rather not provide a thirdparty Openssl package). I am able to build erlang, but the crypto module fails to load due to missing symbols. So I have two questions: 1) Can anyone confirm that the crypto app actually supports 0.9.7e and newer (or indeed what is the earliest release that is actually supported)? 2) Would you accept a patch for crypt.c to stub out the unsupported 0.9.7[x] methods with atom_notsup (much like the HAVE_SHA### stuff is currently handled)? Thanks in advance... John From andrew@REDACTED Thu Sep 27 19:29:54 2012 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 27 Sep 2012 13:29:54 -0400 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries In-Reply-To: <506488FB.6090507@messagesystems.com> References: <506488FB.6090507@messagesystems.com> Message-ID: <20120927172954.GF15522@hijacked.us> One thing we've explored with Riak at Basho was statically linking erlang against a newer SSL, I believe the one that shipped (or still ships) with Solaris had some bugs that liked to segfault the VM. IIRC --disable-dynamic-ssl-lib will force a static linking of the SSL library you specify with --with-ssl=PATH. Andrew From jared@REDACTED Thu Sep 27 19:30:26 2012 From: jared@REDACTED (Jared Morrow) Date: Thu, 27 Sep 2012 11:30:26 -0600 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries In-Reply-To: <506488FB.6090507@messagesystems.com> References: <506488FB.6090507@messagesystems.com> Message-ID: John, I don't know if this helps you at all, but ran into the same problem on 10u9 when trying to build Riak for Solaris. We toiled with it for a while and ended up statically linking in a working OpenSSL library. We did something like the following. $ wget ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/openssl-0.9.8r.tar.gz $ ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared solaris64-x86_64-gcc $ make && make install # erlang $ ./configure --with-ssl=/usr/local/ssl/ --disable-dynamic-ssl-lib --enable-m64-build I know this is works around the problem and that might not be suitable for your, but that's what we ended up doing. -Jared On Thu, Sep 27, 2012 at 11:12 AM, John Peacock wrote: > According to the documentation: > > http://www.erlang.org/doc/man/**crypto_app.html > > "The current implementation of the Erlang Crypto application is based on > the OpenSSL package version 0.9.7 or higher." > > Unfortunately, the Openssl project released the original 0.9.7 2002-12-31 > and the last release 0.9.7m 2007-02-23, so that statement is misleading at > best. Since Openssl was not 100% API compliant for all of those releases > (adding new functions in 0.9.7e and 0.9.7h) the docs need to be much more > specific. > > We have an application that must support Solaris 10u6, which shipped with > Openssl 0.9.7d (we cannot upgrade the system library and I'd rather not > provide a thirdparty Openssl package). I am able to build erlang, but the > crypto module fails to load due to missing symbols. > > So I have two questions: > > 1) Can anyone confirm that the crypto app actually supports 0.9.7e and > newer (or indeed what is the earliest release that is actually supported)? > > 2) Would you accept a patch for crypt.c to stub out the unsupported > 0.9.7[x] methods with atom_notsup (much like the HAVE_SHA### stuff is > currently handled)? > > Thanks in advance... > > John > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpeacock@REDACTED Thu Sep 27 19:43:21 2012 From: jpeacock@REDACTED (John Peacock) Date: Thu, 27 Sep 2012 13:43:21 -0400 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries In-Reply-To: References: <506488FB.6090507@messagesystems.com> Message-ID: <50649039.1020205@messagesystems.com> On 09/27/2012 01:30 PM, Jared Morrow wrote: > I know this is works around the problem and that might not be suitable > for your, but that's what we ended up doing. Yeah, I don't that is a solution for us. We only use erlang to build Riak (which is the only piece we distribute), and we don't have control over our customers installed libraries. I can take this up with the product manager, but adding a static SSL library is likely going to make the erlang-compiled runtime binaries much bigger (though I wonder if it would be faster). John From Ingela.Anderton.Andin@REDACTED Fri Sep 28 11:00:01 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 28 Sep 2012 11:00:01 +0200 Subject: [erlang-bugs] ssl:setopts hangs indefinitely In-Reply-To: <5064364F.30106@mgeb.org> References: <5064364F.30106@mgeb.org> Message-ID: <50656711.2070507@ericsson.com> Hello! Hi maybe you could use observer application to investigate your scenario, it would be interesting to know what the ssl gen_fsm-process is doing as it is not answering the setopts-request. Use observer to find the pid and do erlang:process_info(Pid, [current_stacktrace]). Michael Gebetsroither wrote: > Hello, > > We have a lot of gen_server processes locked up here and we suspect ssl:setopts is the cause. > The erlang vm version used is R15B01 from debian, and i'm currently testing R15B02 packages from esl. > (confirmed, R15B02 from esl also has this problem) > > The gen_server hang can be reproduced if we connect from a remote host over ssl to the server and remove the network > plug, during communication. Though we couldn't reproduce the error with a local client. > The hanging gen_server is the server process doing all the communication and housekeeping tasks on the socket. > > After applying our fix all locked up gen_server processes are gone, because they now terminate on the 2 seconds timeout > wrapped around ssl:setopts. > > IMHO the problematic code part is ssl_connection.erl:242 from R15B02 git tag (thought it seems it is not the root cause, > only the effect). > > > # ssl_connection.erl:242 > set_opts(ConnectionPid, Options) -> > sync_send_all_state_event(ConnectionPid, {set_opts, Options}). > If a timeout is actually needed for setopts that could be easily accomplished by changing that line to Timeout = %% Some reasonable timeout value, sync_send_all_state_event(ConnectionPid, {set_opts, Options}, Timeout). But I am not sure I think that is the right thing to do! We need to understand the cause of the problem better. [...] Regards Ingela Erlang/OTP team - Ericsson AB From jpeacock@REDACTED Fri Sep 28 14:51:24 2012 From: jpeacock@REDACTED (John Peacock) Date: Fri, 28 Sep 2012 08:51:24 -0400 Subject: [erlang-bugs] erlang-bugs Digest, Vol 77, Issue 5 In-Reply-To: References: Message-ID: <50659D4C.8030008@messagesystems.com> On 09/27/2012 1:29 PM, Andrew Thompson wrote: > One thing we've explored with Riak at Basho was statically linking > erlang against a newer SSL, I believe the one that shipped (or still > ships) with Solaris had some bugs that liked to segfault the VM. The problem is that we are based in the US and ship internationally, so we would have to deal with the stupid/pointless munitions export restrictions if we were to ship OpenSSL code with our packages. So that isn't an option. John From jpeacock@REDACTED Fri Sep 28 15:02:05 2012 From: jpeacock@REDACTED (John Peacock) Date: Fri, 28 Sep 2012 09:02:05 -0400 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries In-Reply-To: <506488FB.6090507@messagesystems.com> References: <506488FB.6090507@messagesystems.com> Message-ID: <50659FCD.3020902@messagesystems.com> On 09/27/2012 01:12 PM, John Peacock wrote: > 2) Would you accept a patch for crypt.c to stub out the unsupported > 0.9.7[x] methods with atom_notsup (much like the HAVE_SHA### stuff is > currently handled)? It turns out that the only OpenSSL functionality newer than 0.9.7d that the crypto app requires is DES_ede3_cfb_encrypt (introduced in 0.9.7e), so the patch is quite simple (attached). That is still preliminary because I haven't tested it across all of our platforms. And I still cannot build Riak because at least one of the plugins (eleveldb) assumes GNU tar without probing, and so the build breaks. I'll send that patch to the Riak list directly... :-( John -------------- next part -------------- --- lib/crypto/c_src/crypto.c.orig 2012-04-01 14:15:00.000000000 -0400 +++ lib/crypto/c_src/crypto.c 2012-09-27 15:51:56.537208283 -0400 @@ -63,6 +63,9 @@ #if OPENSSL_VERSION_NUMBER >= 0x00908000L && !defined(OPENSSL_NO_SHA512) && defined(NID_sha512) # define HAVE_SHA512 #endif +#if OPENSSL_VERSION_NUMBER >= 0x0090705FL +# define HAVE_DES_ede3_cfb_encrypt +#endif #ifdef VALGRIND # include @@ -921,6 +924,7 @@ static ERL_NIF_TERM des_ede3_cbc_crypt(E static ERL_NIF_TERM des_ede3_cfb_crypt(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {/* (Key1, Key2, Key3, IVec, Text/Cipher, IsEncrypt) */ +#ifdef HAVE_DES_ede3_cfb_encrypt ErlNifBinary key1, key2, key3, ivec, text; DES_key_schedule schedule1, schedule2, schedule3; DES_cblock ivec_clone; /* writable copy */ @@ -942,6 +946,9 @@ static ERL_NIF_TERM des_ede3_cfb_crypt(E 8, text.size, &schedule1, &schedule2, &schedule3, &ivec_clone, (argv[5] == atom_true)); return ret; +#else + return atom_notsup; +#endif } static ERL_NIF_TERM aes_cfb_128_crypt(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) From daniel@REDACTED Sat Sep 29 15:27:21 2012 From: daniel@REDACTED (Daniel White) Date: Sat, 29 Sep 2012 23:27:21 +1000 Subject: [erlang-bugs] Patch: prevent crypto:info/0 from including undefined or unexported functions Message-ID: Noticed this when I was checking I hadn't missed anything while defining the generic HMAC interface. The patch below removes any bad functions and adds a test to ensure that only functions that are actually available can be returned by crypto:info/0. However, there are also a number of functions missing from the listing that I suspect should be included. So beyond this initial patch: 1. What is the purpose of this function given the existence of module_info(exports)? 2. Assuming a secondary list is necessary since it is a subset of exported functions, what is the deciding factor for including a function in FUNC_LIST? Again assuming that the function is necessary, and we are interested in maintaining consistency as the crypto module changes, two potential solutions come to mind: 1. Use module_info(exports) instead, and remove undesirable functions (e.g. start, stop) by way of a black list, 2. In the test suite, ensure that all exported functions are included in info. A list can be maintained here for exceptions (e.g. start, stop). Seems that the first has worse performance characteristics, and the second requires duplicate effort in maintenance. Patch info: git fetch git://github.com/danielwhite/otp.git fix-crypto-info-listing https://github.com/danielwhite/otp/compare/erlang:master...danielwhite:fix-crypto-info-listing https://github.com/danielwhite/otp/compare/erlang:master...danielwhite:fix-crypto-info-listing.patch Regards, -- Daniel White From essen@REDACTED Sat Sep 29 18:22:26 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 29 Sep 2012 18:22:26 +0200 Subject: [erlang-bugs] Smaaaaaaall error in the docs Message-ID: <50672042.7000606@ninenines.eu> Title of this page is wrong: http://www.erlang.org/doc/man/HiPE_app.html It's hipe, not snmp. :) -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From tuncer.ayaz@REDACTED Sat Sep 29 18:37:29 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 29 Sep 2012 18:37:29 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: On Mon, Aug 6, 2012 at 7:43 PM, Tuncer Ayaz wrote: > On Wed, May 16, 2012 at 4:54 PM, Tuncer Ayaz wrote: >> On Wed, 16 May 2012 01:24:21 +0200, Tuncer Ayaz wrote: >> >>> On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: >>> > On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: >>> > > >>> > > There seems to be a spec or Dialyzer regression in otp master >>> > > revealed when dialyzing rebar. >>> > >>> > Since Tuncer did not submit all the info he has, let me add that the >>> > behavior reported in his mail exists in the *master* branch of OTP >>> > and *not* in the maint branch which works correctly in rebar's code >>> > base. >>> >>> Forgot to test with maint, but will do. That's why it's not mentioned. >> >> Checked, maint results are the same as R15B01. >> >>> > It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's >>> > code is the same in these two branches, but it's most likely either >>> > due to some erroneous spec that was introduced/changed in the master >>> > branch or a problem in rebar's code base. >>> >>> Upon review of the rebar code which provokes the warnings, the >>> substantial changes to erl_bif_types seem like a good candidate for >>> further analysis (commits bd941f50 03715097 9d870a01). Maybe the >>> changes are not finished yet. >>> >>> > IMO, Tuncer should have checked the latter before filling the >>> > report. It would be nice if he did that. >>> >>> That's a good idea. I will git bisect rebar. >> >> Done, found no erroneous commit in rebar. > > Any update on this bug? Same problem with today's OTP_R15B02-603-gcccf365. http://erlang.org/pipermail/erlang-bugs/2012-May/002902.html From freeakk@REDACTED Sat Sep 29 18:52:20 2012 From: freeakk@REDACTED (Michael Uvarov) Date: Sat, 29 Sep 2012 20:52:20 +0400 Subject: [erlang-bugs] Smaaaaaaall error in the docs In-Reply-To: <50672042.7000606@ninenines.eu> References: <50672042.7000606@ninenines.eu> Message-ID: Here is another one. http://www.erlang.org/doc/man/edoc.html The EDoc documentation data for a module, expressed as an XML document in XMerL format. See the file edoc.dtd (dead link) for details. From tuncer.ayaz@REDACTED Sat Sep 29 18:55:14 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 29 Sep 2012 18:55:14 +0200 Subject: [erlang-bugs] make docs fails in git master Message-ID: At least as far back as the R15B02 release 'make docs' in the master branch fails: $ make docs /tmp/otp/master/make/emd2exml /tmp/otp/master/HOWTO/DTRACE.md DTRACE.xml (no error logger present) error: "Error in process <0.3.0> with exit value: {badarg,[{init,request,1,[]},{erl_prim_loader,prim_init,0,[]}, {erl_prim_loader,start_it,4,[]}]} " (no error logger present) error: "Error in process <0.2.0> with exit value: {badarg,[{erl_prim_loader,request,1,[]}, {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]} " {"init terminating in do_boot",{badarg,[{erl_prim_loader,request,1,[]}, {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () make[3]: *** [DTRACE.xml] Error 1 make[3]: Leaving directory `/tmp/otp/master/lib/runtime_tools/doc/src' make[2]: *** [docs] Error 2 make[2]: Leaving directory `/tmp/otp/master/lib/runtime_tools' make[1]: *** [docs] Error 2 make[1]: Leaving directory `/tmp/otp/master/lib' make: *** [docs] Error 2 Can anybody else reproduce this?