http://blog.gmane.org/gmane.comp.lang.erlang.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2951 <pre>Hi. I run R14B02 on Windows 2K8 64-bit server (but Erlang is 32-bit). But looking at the latest code from GitHub, the problem is still there. When I try filelib:ensure_dir("Y:/toto.txt") and the drive "Y:" does not exist, the VM crashes after a few minutes with eheap_alloc cannot allocate 1425410620 bytes of memory (of type "heap"). Looking at the Erlang source code for ensure_dir/1, and if I'm reading it right, the endless loop is caused because the dirname in "Y:/toto.txt" is "Y:/" but "Y:/" is not considered a directory by do_is_dir/2. So a recursive call to ensure_dir/1 is done, and..... Is it really a bug? Luc --- Le cri du nourrisson est le résultat de plusieurs années de recherche dans le domaine du signal d'alarme. (Serge Bouchard) --- Luc Tanguay, ing./P.Eng. Bell Canada 671 De La Gauchetière 4e étage, Montréal H3B 2M8 514-786-6440 cell: 514-229-7585 _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> luc.tanguay< at >bell.ca 2012-05-23T04:07:23 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2946 <pre>Hi, I'm new here on the list, and I signed up to help to compile the version R15 on Solaris. The following procedure that I performed ... PS: In the past, I compiled a version R14B04, using the same procedure *-- Config* #uname -a SunOS HOST 5.10 Generic_142910-17 i86pc i386 i86pc # gcc --version gcc (GCC) 4.6.3 # autoconf --version autoconf (GNU Autoconf) 2.69 # echo $PATH /usr/sbin:/usr/bin:/usr/ccs/bin:/opt/csw/bin: *-- Procedure* cd /dados/install-src wget http://www.erlang.org/download/otp_src_R15B01.tar.gz gunzip otp_src_R15B01.tar.gz gtar -xvf otp_src_R15B01.tar cd /dados/install-src/otp_src_R15B01 export ERL_TOP=`pwd` echo $ERL_TOP ./otp_build autoconf ./configure --prefix=/opt gmake gmake install rm /usr/bin/erl rm /usr/bin/erlc ln -s /opt/bin/erl /usr/bin ln -s /opt/bin/erlc /usr/bin *-- Result* ./otp_build autoconf: Ok ./configure --prefix=/opt: Ok But, in gmake, we have: *...bla bla bla....* gcc -g -O3 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c hipe/hipe_x86.c -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86.o gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c hipe/hipe_x86_glue.S -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_glue.o m4 -DERTS_SMP=1 -DTARGET=i386-pc-solaris2.10 -DOPSYS=sol2 -DARCH=x86 hipe/hipe_x86_bifs.m4 &gt; i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S gcc -g -O2 -I/dados/install-src/otp_src_R15B01/erts/i386-pc-solaris2.10 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-tree-copyrename -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_PTHREAD_SEMANTICS -Ii386-pc-solaris2.10/opt/smp -Ibeam -Isys/unix -Isys/common -Ii386-pc-solaris2.10 -Izlib -Ipcre -Ihipe -I../include -I../include/i386-pc-solaris2.10 -I../include/internal -I../include/internal/i386-pc-solaris2.10 -c i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S -o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.S:2176:2: error: #endif without #if gmake[3]: *** [obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o] Error 1 gmake[3]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[1]: *** [smp] Error 2 gmake[1]: Leaving directory `/dados/install-src/otp_src_R15B01/erts' gmake: *** [emulator] Error 2 I tried deleting the "endif" spare in line 2176 (HAVE_nbif_emulate_fpe), but got another error linking: ...bla bla bla... obj/i386-pc-solaris2.10/opt/smp/hipe_mode_switch.o obj/i386-pc-solaris2.10/opt/smp/hipe_native_bif.o obj/i386-pc-solaris2.10/opt/smp/hipe_stack.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_glue.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_signal.o obj/i386-pc-solaris2.10/opt/smp/hipe_x86_stack.o obj/i386-pc-solaris2.10/opt/smp/efile_drv.o obj/i386-pc-solaris2.10/opt/smp/inet_drv.o obj/i386-pc-solaris2.10/opt/smp/zlib_drv.o obj/i386-pc-solaris2.10/opt/smp/ram_file_drv.o obj/i386-pc-solaris2.10/opt/smp/ttsl_drv.o -lsendfile -lrt -ldlpi -ldl -lm -lsocket -lnsl -lncurses -L../lib/internal/i386-pc-solaris2.10 -lkstat /dados/install-src/otp_src_R15B01/erts/emulator/zlib/obj/i386-pc-solaris2.10/opt/libz.a /dados/install-src/otp_src_R15B01/erts/emulator/pcre/obj/i386-pc-solaris2.10/opt/libepcre.a -lethread -lerts_internal_r -lpthread -lkstat -lrt Undefined first referenced symbol in file hipe_emulate_fpe obj/i386-pc-solaris2.10/opt/smp/hipe_x86_bifs.o ld: fatal: Symbol referencing errors. No output written to /dados/install-src/otp_src_R15B01/bin/i386-pc-solaris2.10/beam.smp gmake[3]: *** [/dados/install-src/otp_src_R15B01/bin/i386-pc-solaris2.10/beam.smp] Error 1 gmake[3]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/dados/install-src/otp_src_R15B01/erts/emulator' gmake[1]: *** [smp] Error 2 gmake[1]: Leaving directory `/dados/install-src/otp_src_R15B01/erts' gmake: *** [emulator] Error 2 Can anyone help me? </pre> Fabrício Dias 2012-05-19T18:28:46 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2945 <pre>Seems that me the only person who is using this functionality :). Anyway. I have a problem with cancel request when using a httpc to get data as a stream. My version of Erlang is R14B03, but after some digging in freshest code on github I have found the following interesting things in httpc_manager: % The thing 1. . It seems it is supposed that ets table will contain records #handler_info do_init(ProfileName, CookiesDir) -&gt; ... HandlerDbName = handler_db_name(ProfileName), ets:new(HandlerDbName, [protected, set, named_table, {keypos, #handler_info.id}]), ... . % The thing 2. . It seems it is supposed that ets table will contain a tuples of arity 3 handle_call({cancel_request, RequestId}, From, State) -&gt; ?hcri("cancel_request", [{request_id, RequestId}]), case ets:lookup(State#state.handler_db, RequestId) of [] -&gt; ...; [{_, Pid, _}] -&gt; httpc_handler:cancel(RequestId, Pid, From), {noreply, State#state{cancel = [{RequestId, Pid, From} | State#state.cancel]}} end; The arity of a tuple #handler_info is slightly not 3. </pre> Vyacheslav Vorobyov 2012-05-18T12:47:47 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2941 <pre>Tthere seems to be a spec or Dialyzer regression in otp master revealed when dialyzing rebar. Steps to reproduce: $ git clone git://github.com/basho/rebar.git &amp;&amp; cd rebar # assuming ~/.dialzer_plt is for otp master $ make check # otherwise, use custom PLT $ make debug &amp;&amp; dialyzer --plt otp_master_plt ebin You can ignore the extra warnings enabled via 'make check'. They make no difference. R15B01: rebar_utils.erl:154: Call to missing or unexported function escript:foldl/3 R16 (OTP_R15B01-386-g77c47cd): rebar_core.erl:440: The call rebar_core:apply_hook({_,{_,_}}) will never return since it differs in the 1st argument from the success typing arguments: ({_,{binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | non_neg_integer(),binary() | []) | {'re_pattern',_,_,_},_,_}}) rebar_ct.erl:64: Function run_test/3 has no local return rebar_ct.erl:91: Function check_log/1 will never be called rebar_ct.erl:113: Function show_log/1 will never be called rebar_deps.erl:287: Function require_source_engine/1 has no local return rebar_deps.erl:325: The pattern &lt;Dep, 0&gt; can never match the type &lt;#dep{},3&gt; rebar_deps.erl:355: Function download_source/2 will never be called rebar_deps.erl:411: Function update_source/2 will never be called rebar_deps.erl:443: Function source_engine_avail/1 has no local return rebar_deps.erl:447: Function source_engine_avail/2 has no local return rebar_deps.erl:450: The pattern 'true' can never match the type 'false' rebar_deps.erl:464: Function will never be called rebar_erlc_compiler.erl:272: Function compile_mib/3 has no local return rebar_erlydtl_compiler.erl:128: The pattern 'false' can never match the type 'true' rebar_erlydtl_compiler.erl:162: Function referenced_dtls/2 has no local return rebar_erlydtl_compiler.erl:163: The call rebar_erlydtl_compiler:referenced_dtls1([atom() | binary() | [atom() | [any()] | char()],...],Config::any(),set()) will never return since it differs in the 1st argument from the success typing arguments: ([],rebar_config:config(),set()) rebar_erlydtl_compiler.erl:167: Function referenced_dtls1/3 has no local return rebar_erlydtl_compiler.erl:175: The created fun has no local return rebar_erlydtl_compiler.erl:175: Fun application with arguments (Step::[atom() | binary() | [atom() | [any()] | char()],...]) will never return since it differs in the 1st argument from the success typing arguments: ([]) rebar_erlydtl_compiler.erl:175: The pattern [] can never match the type [atom() | binary() | [atom() | [any()] | char()],...] rebar_erlydtl_compiler.erl:186: Function will never be called rebar_erlydtl_compiler.erl:187: Function will never be called rebar_file_utils.erl:75: Function mv/2 has no local return rebar_file_utils.erl:123: Function xcopy_win32/2 has no local return rebar_neotoma_compiler.erl:88: The pattern 'false' can never match the type 'true' rebar_neotoma_compiler.erl:116: Function referenced_pegs/2 has no local return rebar_neotoma_compiler.erl:117: The call rebar_neotoma_compiler:referenced_pegs1([atom() | binary() | [atom() | [any()] | char()],...],Config::any(),set()) will never return since it differs in the 1st argument from the success typing arguments: ([],rebar_config:config(),set()) rebar_neotoma_compiler.erl:121: Function referenced_pegs1/3 has no local return rebar_neotoma_compiler.erl:129: The created fun has no local return rebar_neotoma_compiler.erl:129: Fun application with arguments (Step::[atom() | binary() | [atom() | [any()] | char()],...]) will never return since it differs in the 1st argument from the success typing arguments: ([]) rebar_neotoma_compiler.erl:129: The pattern [] can never match the type [atom() | binary() | [atom() | [any()] | char()],...] rebar_neotoma_compiler.erl:140: Function will never be called rebar_neotoma_compiler.erl:141: Function will never be called rebar_utils.erl:93: Function sh/2 has no local return rebar_utils.erl:154: Call to missing or unexported function escript:foldl/3 rebar_utils.erl:442: Function vcs_vsn_invoke/2 has no local return _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Tuncer Ayaz 2012-05-15T19:50:30 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2931 <pre>Not the behaviour I was expecting: Running Erlang Eshell V5.9.1 (abort with ^G) 1&gt; lists:suffix("ala", "a") false Is this a release-wide issue? - Beads http://tanglelabs.com/ _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Beads Land-Trujillo 2012-05-11T22:40:44 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2930 <pre>Hello, % 1. Good behavior {badrpc,{'EXIT', some_reson }} = rpc:call(node(),erlang,exit,[some_reson]). % 2. Bad behavior some_reson = rpc:call(node(),erlang,throw,[some_reson]). The second case describes an issue. It makes indistinguishable normal result from exception. </pre> Vyacheslav Vorobyov 2012-05-11T14:43:23 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2929 <pre>Hi. We have found recently an interesting behaviour: - erlang console generate "bad generator" exception for the code: 1&gt; [ {A,B} || {A,B} &lt;- aaa ]. ** exception error: bad generator aaa - if compiled, the code throw "function clause" exception: $ cat a.erl -module(a). -export([a/1]). a(List) -&gt; [ {A,B} || {A,B} &lt;- List ]. $ erl 1&gt; c(a). {ok,a} 2&gt; a:a(aaa). ** exception error: no function clause matching a:'-a/1-lc$^0/1-0-'(aaa) The reason is that new anonymous function is created to handle the list comprehension, but it expects only lists. So incorrect generator also would cause a "function clause" exception. I suppose that the reason of such an exception here is for the similarity with the lists:map, it also generates a "function clause" for unsupported arguments: 2&gt; lists:map(fun(A) -&gt; A end, aaa). ** exception error: no function clause matching lists:map(#Fun&lt;erl_eval.6.80247286&gt;,aaa) To my mind this behavior is not correct as somebody might expect "bad generator" exception and he will try to catch it, but instead another exception is thrown. Ivan _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Ivan Glushkov 2012-05-11T13:59:12 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2928 <pre>Hi, all. I just noticed that there was one part of my DTrace mega-patch for R1501 that was omitted ... and causes some icky problems for SystemTap. That change looked mostly like this: https://github.com/slfritchie/otp/commit/f4d2ff83f550244e5fa36472ad06231624b256cd ... and was included in the 5-part squished feature branch that was submitted to the OTP team for the R15B01 release. I assume that this particular kludge wasn't used because it is ugly? Well, granted, it's quite ugly. But it makes stuff *work*. From some small testing efforts with SystemTap 1.6, a kludge-less build does not work correctly. Nor does Solaris 10, though the loss of function is much smaller for Solaris 10 than for Linux's SystemTap. What is the tolerance level for this kind of ugliness for R15B02? I've started putting Erlang-triggered probes into Riak, but if the entire SystemTap-using community cannot get those probes to work, then the value of adding the probes is significantly diminished. -Scott _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Scott Lystig Fritchie 2012-05-10T20:57:19 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2925 <pre>Guys, ct_run does not return a non-zero exit status on failure. This is needed to integrate well in any make based environment, which includes many of the continuous integration systems out there. There are work arounds for this, but I think this is something that should probably at the source. Eric _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Eric Merritt 2012-05-09T14:51:57 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2920 <pre>Hi all, I made an erlang port driver that simply does the following: - initializes with a start() method - creates a socket, binds on port 5555 and invokes listen on it on a listen method - invoke driver_select for said socket with ERL_DRV_READ set - the port driver declares a ready_input on the ErlDrvEntry structure - on linux, when i connect to port 5555, the ready_input fires up correctly - on windows, i get nothing, no handler is fired up i tried with a bunch of different erlang versions including the latest (R15B01) and keep getting the same problem is there something i'm missing? is there some special directive that should be issued for windows? i'm attaching this simple port driver along with the vs2010 solution that i'm using for building it (located in build-aux\msvc) any help would be greatly appreciated Luis Rascão _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Luis Rascão 2012-05-06T19:22:45 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2919 <pre>Errors in Common Test 1.6.1 - cth_surefire.erl cth_surefire.erl has a two errors : 1. " on_tc_fail( TC, Res, State)" should be "on_tc_fail(_Tc, Res, State)", as the TC causes a bad match on inside the function with regards to the TC record. this causes surefire results to generate .xml which indicate passed tests when in actual fact the tests have failed. 2. failures in "init_per_suite" cause "on_tc_skip" to be called which is correct up until "on_tc_skip" is called for "end_per_suite" as well. This also means that "post_end_per_suite" is never called, which is the problem. As "post_end_per_suite" takes all test cases results and places in State#state{ test_suites ). This is important as the xml generation on terminate iterates thru the test suites. here's a fix : on_tc_skip(Tc, Res, State) -&gt; TCs = State#state.test_cases, [TC | RestTCs ] = TCs, {CurTC, CurRestTCs} = case TC#testcase.failure of passed -&gt; {TC, RestTCs}; _OtherFailure -&gt; Name = atom_to_list(Tc), NTC = new_tc_rec(Name, State#state{timer = now()}), {NTC, TCs} end, NewTC = CurTC#testcase{ failure = {skipped, lists:flatten(io_lib:format("~p",[Res])) } }, NewState = State#state{ test_cases = [NewTC | CurRestTCs]}, case Tc of end_per_suite -&gt; Suite = get_suite(NewState, TCs), AltState = NewState#state{ test_cases = [], test_suites = [Suite | NewState#state.test_suites]}, AltState; _Other -&gt; NewState end. / Jovan Sean Dippenaar - Aeonmind Enterprises _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Jóvan Sean Dippenaar 2012-05-05T12:01:14 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2916 <pre>Hello, binary:compile_pattern/1 spec makes dialyzer unhappy. This minimal module shows it. -module(binary_compile_dialyzer_issue). -export([test/0]). test() -&gt; binary:split(&lt;&lt;&gt;&gt;, binary:compile_pattern(&lt;&lt;&gt;&gt;), []). Dialyzer output is $ dialyzer -q binary_compile_dialyzer_issue.erl binary_compile_dialyzer_issue.erl:5: Function test/0 has no local return binary_compile_dialyzer_issue.erl:6: The call binary:split(#{}#,{'ac',binary()} | {'bm',binary()},[]) does not have a term of type binary() | [binary()] | binary:cp() (with opaque subterms) as 2nd argument If I understand it right /usr/lib/erlang/lib/hipe-3.9.1/cerl/erl_bif_types.erl:4672 t_binary_compiled_pattern() -&gt; t_tuple([t_sup(t_atom('bm'), t_atom('ac')), t_binary()]). should return opaque type. Unfortunately I seems not skilled enough to provide patch. Best regards </pre> Hynek Vychodil 2012-05-04T12:09:38 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2908 <pre> I'm playing around with release_handler, since it's a holiday, and I need something fun to do… Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1&gt; Appup = filename:join([code:lib_dir(stdlib), "ebin", "stdlib.appup"]). "/usr/lib/erlang/lib/stdlib-1.18/ebin/stdlib.appup" 2&gt; rp(file:consult(Appup)). {ok,[{"1.18", [{&lt;&lt;"1\\.18(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}, {&lt;&lt;"1\\.17(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}, {&lt;&lt;"1\\.16(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}], [{&lt;&lt;"1\\.18(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}, {&lt;&lt;"1\\.17(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}, {&lt;&lt;"1\\.16(\\.[0-9]+)*"&gt;&gt;,[restart_new_emulator]}]}]} ok 3&gt; release_handler:upgrade_script(stdlib,code:lib_dir(stdlib)). ** exception throw: {version_not_in_appup,"1.18"} in function release_handler:find_script/4 (release_handler.erl, line 501) in call from release_handler:upgrade_script/2 (release_handler.erl, line 439) Ok, an odd practice to try to upgrade an app to itself, but it was just a test. The thing to note is that release_handler:upgrade_script/2 ends up calling release_handler:find_script/4, which looks like this: find_script(App, Dir, OldVsn, UpOrDown) -&gt; Appup = filename:join([Dir, "ebin", atom_to_list(App)++".appup"]), case file:consult(Appup) of {ok, [{NewVsn, UpFromScripts, DownToScripts}]} -&gt; Scripts = case UpOrDown of up -&gt; UpFromScripts; down -&gt; DownToScripts end, case lists:keysearch(OldVsn, 1, Scripts) of {value, {_OldVsn, Script}} -&gt; {NewVsn, Script}; false -&gt; throw({version_not_in_appup, OldVsn}) end; {error, enoent} -&gt; throw(no_appup_found); {error, Reason} -&gt; throw(Reason) end. It tries to find the OldVsn using lists:keysearch/3, which can't possibly work, given the kind of .appup found in a modern OTP. Apologies for not just fixing it and submitting a patch, but there has to be a limit even to holiday fun. BR, Ulf W Ulf Wiger, Co-founder &amp; Developer Advocate, Feuerlabs Inc. http://feuerlabs.com _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Ulf Wiger 2012-05-01T10:49:47 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2905 <pre>erlc does not recognize the option that sets the number of schedulers (+S N or +S N:M or +SN). Actually, it crashes badly in this case. .../SomePath/R15B01/bin/erlc +S1 foo.erl bad term: S1 Runtime error: {{nocatch,error}, [{erl_compile,make_term,1, [{file,"erl_compile.erl"},{line,219}]}, {erl_compile,compile1,3, [{file,"erl_compile.erl"},{line,129}]}, {erl_compile,compiler_runner,1, [{file,"erl_compile.erl"},{line,82}]}]} It would be nice to fix this. Kostis _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Kostis Sagonas 2012-04-25T21:33:57 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2900 <pre>When gen_server, gen_fsm, etc., make a call to one of the behaviour callback functions, these calls are protected by a construct on the following form (simplified): case catch Mod:some_callback(...) of ... {'EXIT',Reason} -&gt; exit(Reason); Other -&gt; exit({bad_return_value, Other}) end When a callback terminates with an exception of type 'error' or 'exit', this sort of does the expected thing (although it converts error exceptions to exit exceptions, which might or might not be intended). But if the callback terminates due to an uncaught throw(Term), it is treated as if the callback had returned Term. At best, this is an undocumented and horrible way of letting you write callback functions that can do things like throw({reply, Reply, NewState}) for nonlocal return out of a deep recursion and back to the gen_server code. But I'd like to think that it's simply unintended behaviour. (Nothing I could see in the OTP documentation describes what the gen_server is supposed to do with exceptions thrown from a callback.) The annoyance this causes is that if you use throw(X) for anything within the callback (or in library code called by the callback) and you don't make sure to wrap your callback in something that catches all throws, any such uncaught exception will result in the gen_server process terminating with the confusing reason {bad_return_value, X} (and no stack trace to indicate where X was thrown from). If it can be agreed that this is a bug that should be fixed (and how), we could submit a patch. /Richard Carlsson and Samuel Rivas _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Richard Carlsson 2012-04-25T08:43:55 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2892 <pre>Hi, I've found a but that if Erlang is installed in a path with spaces then _epmd_ fails to start when started automatically by _erl_. You can still start epmd manually. Platform where the bug happens: Linux &amp; Mac (where I tested at least). How to reproduce: Install Erlang in a path with spaces like "/tmp/path with spaces/" Start Erlang like this: erl -sname foo You will get this error: sh: /tmp/path: No such file or directory {error_logger,{{2012,4,22},{11,50,7}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,econnrefused}},[{inet_tcp_dist,listen,1,[{file,"inet_tcp_dist.erl"},{line,70}]},{net_kernel,start_protos,4,[{file,"net_kernel.erl"},{line,1314}]},{net_kernel,start_protos,3,[{file,"net_kernel.erl"},{line,1307}]},{net_kernel,init_node,2,[{file,"net_kernel.erl"},{line,1197}]},{net_kernel,init,1,[{file,"net_kernel.erl"},{line,357}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}]} {error_logger,{{2012,4,22},{11,50,7}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,&lt;0.19.0&gt;},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,320}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,[net_sup,kernel_sup,&lt;0.9.0&gt;]},{messages,[]},{links,[#Port&lt;0.53&gt;,&lt;0.16.0&gt;]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,474}],[]]} {error_logger,{{2012,4,22},{11,50,7}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfargs,{net_kernel,start_link,[[a,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2012,4,22},{11,50,7}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2012,4,22},{11,50,7}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) If you DTrace it like this for example: sudo dtruss -f ./erts-5.9.1/bin/erl -boot ./releases/2.8.1/start_clean -sname a You will see that the error happens in this system call: execve("/tmp/path\0", 0x10C204BD0, 0x10C2049E0) = -1 Err#2 Which I think is part of this file: erts/emulator/sys/unix/sys.c In the Mac is quite common to have User home folders in path with spaces. I've found this while trying to create an Erlang release and distribute it via inside a Mac.app The bug happens in R15B01 so I guess it also appears in earlier versions. Also perhaps if epmd is not running for whatever the reason maybe Erlang could give a more meaningful error. Regards, Alvaro </pre> Alvaro Videla 2012-04-22T09:56:37 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2891 <pre>Hi! Windows ssh client PuTTY show message "Disconnected: Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 0" while working with erlang ssh daemon. Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [kernel-poll:false] WBR, Fyodor. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Fyodor Ustinov 2012-04-22T08:58:08 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2889 <pre>Hi, While attempting to perform an unattended installation of the 64bit R15B01 Windows version of Erlang we discovered a possible flaw with the VC++ redistributable version checking. If you pre-install vcredist_x64.exe and run the Erlang installer with the "/S" flag for silent install, then a dialogue pops up to ask whether you wish to repair or remove the x64 redistributable. If you pre-install both vcredist_x86.exe and vcredist_x64.exe and run the Erlang installer with the "/S" flag then the installation completes silently. This seems unexpected and might be considered a bug. </pre> Emile Joubert 2012-04-18T14:16:36 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2887 <pre>Hi, I don't know if it is a bug but I get very annoying SASL error messages as below when I use net_adm:ping() : ---8&lt;---------------------------------------------------- =ERROR REPORT==== 15-Apr-2012::19:07:44 === ** System running to use fully qualified hostnames ** ** Hostname localhost is illegal ** ---8&lt;---------------------------------------------------- because I have in my /etc/hosts ---8&lt;---------------------------------------------------- 127.0.0.1 localhost ---8&lt;---------------------------------------------------- I understand that hostnames known by Erlang should be fully qualified when node is starting with -name but I wonder why it cares about shortnames and especially to localhost because : the strange thing is that when I change to : ---8&lt;---------------------------------------------------- 127.0.0.1 mylocalhost ---8&lt;---------------------------------------------------- I do not have the messages, even if it is not fully qualified too ... Regards _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> PAILLEAU Eric 2012-04-15T17:27:34 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2886 <pre>I am having problems using erlang ssh against an OpenSSH server. I am establishing an ssh connection and then in a freshly spawned process I will do this... command(Conn, Cmd) -&gt; {ok,Chan} = ssh_connection:session_channel(Conn, infinity), success = ssh_connection:exec(Conn, Chan, Cmd, infinity), ... receive data messages until eof... ssh_connection:close(Conn, Chan), ok. I run about 6 of these commands sequentially (new process for each), and most of the time OpenSSH gets angry with me and drops the whole connection. The error given is... &lt;barrage of debug messages talking about shutting down channel 1&gt; channel_by_id: 1: bad id: channel free Disconnecting: Received oclose for nonexistent channel 1. But.... if I add a delay before the close() everything seems to work perfectly: command(Conn, Cmd) -&gt; {ok,Chan} = ssh_connection:session_channel(Conn, infinity), success = ssh_connection:exec(Conn, Chan, Cmd, infinity), ... receive data messages until eof... timer:delay(1000), ssh_connection:close(Conn, Chan), ok. Dan. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Daniel Goertzen 2012-04-13T21:28:54 http://comments.gmane.org/gmane.comp.lang.erlang.bugs/2885 <pre>Cannot compile helloWorld with -on_load directive and 'native' flag. Issue reproduceable in R14B04, R15B01. Looks like similar problem has been already fixed two years ago: https://github.com/pguyot/otp/tree/pg/hipe_crash_with_on_load a.erl --------------------- -module(a). -on_load(init/0). -export([init/0]). init() -&gt; ok. --------------------- And try to compile it... $&gt; erl Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) 1&gt; c(a, [native,{hipe,[verbose]}]). &lt;HiPE (v 3.9.1)&gt; Compiling: a &lt;HiPE (v 3.9.1)&gt; Options: [verbose,icode_range,icode_ssa_const_prop, icode_ssa_copy_prop,icode_type,icode_inline_bifs, rtl_lcm,rtl_ssa,rtl_ssa_const_prop,spillmin_color, use_indexing,remove_comments,concurrent_comp, binary_opt,inline_fp,pmatch,peephole,verbose]. &lt;HiPE (v 3.9.1)&gt; EXITED with reason {'trans_fun/2',on_load} &lt; at &gt;hipe_beam_to_icode:1104 a.erl:none: internal error in native_compile; crash reason: {{badmatch, {'EXIT', {{hipe_beam_to_icode,1104,{'trans_fun/2',on_load}}, [{hipe_beam_to_icode,trans_fun,2, [{file,"hipe_beam_to_icode.erl"},{line,1104}]}, {hipe_beam_to_icode,trans_fun,2, [{file,"hipe_beam_to_icode.erl"},{line,254}]}, {hipe_beam_to_icode,trans_mfa_code,5, [{file,"hipe_beam_to_icode.erl"},{line,125}]}, {hipe_beam_to_icode,trans_beam_function_chunk,2, [{file,"hipe_beam_to_icode.erl"},{line,110}]}, {hipe_beam_to_icode,'-module/2-lc$^1/1-1-',2, [{file,"hipe_beam_to_icode.erl"},{line,106}]}, {hipe,get_beam_icode,4, [{file,"hipe.erl"},{line,602}]}, {hipe,'-run_compiler_1/3-fun-0-',4, [{file,"hipe.erl"},{line,662}]}]}}}, [{hipe,get_beam_icode,4,[{file,"hipe.erl"},{line,601}]}, {hipe,'-run_compiler_1/3-fun-0-',4, [{file,"hipe.erl"},{line,662}]}]} =ERROR REPORT==== 13-Apr-2012::02:07:52 === Error in process &lt;0.43.0&gt; with exit value: {{badmatch,{'EXIT',{{hipe_beam_to_icode,1104,{'trans_fun/2',on_load}},[{hipe_beam_to_icode,trans_fun,2,[{file,"hipe_beam_to_icode.erl"},{line,1104}]},{hipe_beam_to_icode,trans_fun,2,[{file,"hipe_beam_to_icode.erl"},{line,254}]},{hipe_beam_to_icode... error _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Konstantin Nikiforov 2012-04-13T15:00:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.erlang.bugs