http://permalink.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://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2954 <pre> I think we have found the root cause and can reproduce the corresponding problem if you have just the 32-bit VC++ redistributable installed the Erlang installer will think it does not need to intall the 64-bit VC++ redistributable and install an Erlang that will not start. The root cause we have found is that the installer runs in 32-bit mode and hence Windows does not show it the same system directory as an 64-bit application will see. Luckily there is a mapped fake directory where the installer can see the hidden 64-bit system directory. A fix for this will most likely make it into R15B02. </pre> Raimo Niskanen 2012-05-25T09:40:44 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2953 <pre> I am now digging into this. Can you search for msvcr100.dll under C:\WINDOWS on your malfunctioning installation (pre-installed vcredist_x64.exe) to see where it is installed? Your help is much appreciated. </pre> Raimo Niskanen 2012-05-23T15:49:11 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2952 <pre>Hi! Thanks for reporting this! The following patch[1] should solve the problem. I'll let it run through our tests and then merge it to maint. Thanks, Lukas [1] diff --git a/lib/stdlib/src/filelib.erl b/lib/stdlib/src/filelib.erl index d532cea..b098d4c 100644 --- a/lib/stdlib/src/filelib.erl +++ b/lib/stdlib/src/filelib.erl &lt; at &gt;&lt; at &gt; -264,6 +264,9 &lt; at &gt;&lt; at &gt; ensure_dir(F) -&gt; case do_is_dir(Dir, file) of true -&gt; ok; + false when Dir =:= F -&gt; + %% Protect against infinite loop + {error,einval}; false -&gt; ensure_dir(Dir), case file:make_dir(Dir) of On 23/05/12 06:07, luc.tanguay&lt; at &gt;bell.ca wrote: _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Lukas Larsson 2012-05-23T08:11:43 http://permalink.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</pre> luc.tanguay< at >bell.ca 2012-05-23T04:07:23 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2950 <pre>Hi, You are correct. This is indeed a bug. Thanks for pointing it out. I will try to have a fix in R15B02. Regards, /BMK On 05/18/2012 02:47 PM, Vyacheslav Vorobyov wrote: _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Micael Karlberg 2012-05-21T16:55:29 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2949 <pre> This is not the first time that this is reported. The question is why the configure script doesn't report some error if the m4 found in the path is not GNU m4, which is required. Perhaps somebody who is knowledgeable about configure scripts can investigate this and provide some appropriate patch (test for GNU m4) so that Solaris users do not experience such compilation errors. Kostis _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Kostis Sagonas 2012-05-20T18:03:55 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2948 <pre>Uowww....it works... I changed path to: export PATH=/usr/sbin:/usr/bin:/opt/csw/bin:/opt/csw/i386-pc-solaris2.9/bin # Links #ln -s /opt/csw/bin/gcc /usr/bin #ln -s /opt/csw/bin/autoconf /usr/bin #ln -s /opt/csw/gnu/m4 /usr/bin #ln -s /opt/csw/i386-pc-solaris2.9/bin/ar /usr/bin #ln -s /opt/csw/i386-pc-solaris2.9/bin/ld /usr/bin -bash-3.00# uname -a SunOS HOST 5.10 Generic_142910-17 i86pc i386 i86pc -bash-3.00# echo $PATH /usr/sbin:/usr/bin:/opt/csw/bin:/opt/csw/i386-pc-solaris2.9/bin -bash-3.00# gcc --version gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -bash-3.00# autoconf --version autoconf (GNU Autoconf) 2.69 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt;, &lt;http://gnu.org/licenses/exceptions.html This is free software: you are free to change and</pre> Fabrício Dias 2012-05-20T17:56:15 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2947 <pre> Make sure m4 is a link to GNU m4, not /usr/ccs/bin/m4, then try again in a clean unpack of the sources (i.e., rm -rf the old source dir first, do not try a 'make clean' because that just doesn't work). If that still fails, email me a copy of the offending hipe_x86_bifs.S file and I'll have a look. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Mikael Pettersson 2012-05-20T10:54:58 http://permalink.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_O</pre> Fabrício Dias 2012-05-19T18:28:46 http://permalink.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</pre> Vyacheslav Vorobyov 2012-05-18T12:47:47 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2944 <pre> Checked, maint results are the same as R15B01. Done, found no erroneous commit in rebar. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Tuncer Ayaz 2012-05-16T14:54:55 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2943 <pre> Forgot to test with maint, but will do. That's why it's not mentioned. 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. That's a good idea. I will git bisect rebar. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Tuncer Ayaz 2012-05-15T23:24:21 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2942 <pre> 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. 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. IMO, Tuncer should have checked the latter before filling the report. It would be nice if he did that. Kostis _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Kostis Sagonas 2012-05-15T20:24:34 http://permalink.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 re</pre> Tuncer Ayaz 2012-05-15T19:50:30 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2940 <pre> I am not saying its a good idea mind you, but could you not catch the exception where its propagated and reraise it in the client with erlang:raise/3. Again, let me reiterate that I am *not* proposing this as a solution, I would really need to think out the repercussions before doing that. I think we are agreeing here. I thought that catch was actually deprecated. After going and looking I realize that it is not. Not only that, but the docs don't seem to mention that its a bad idea. This also sounds like a problem that needs to be fixed, perhaps actual deprecation and removal of catch? That sounds reasonable to me. _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Eric Merritt 2012-05-14T15:39:11 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2939 <pre> The problem with that is that once you propagate the exception to the caller you loose the stack trace. Also throwing outside a catching construct is an error in the called side, that should't propagate as valid return to the calling side. I've come across many instances of these problem trying to use throws as exceptions. We (me and Richard Carlsson reported a possible bug to the list as OTP behaviour callbacks do the same thing, and recently we saw the same problem in dynamic pages in yaws (though that has already been fixed by Steve Vinoski). The underlying issue is that catch and try-catch have really different behaviour concerning throws. I'd like to think that catch is legacy and shouldn't be used, as that enables developers to use throw as it is defined in http://www.erlang.se/workshop/2004/exception.pdf. That is, an uncaught exception behaves as a no_catch error, with a proper stack trace. This way, throws can be used both as non-local returns and as exceptions. However, there seem to be lots of c</pre> Samuel 2012-05-14T15:23:45 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2938 <pre>Just to throw my 2c and agree with the original poster. Regardless of whether exceptions are encouraged or not, the fact is that thrown exceptions are a documented part of the language, and for rpc:call not to return some indicator of the excepted state is broken. I would equate this to the use of 'catch'. The argument against that use that you can't tell valid return values from thrown return values. The solution is "don't use catch, use one of the try forms". That same argument would seem to apply here. However, In this case there is no form that propagates the exception in any way. Perhaps some additional rpc:call_&lt;x&gt; or rpc:&lt;x&gt;_call needs to be added that either propagates the exception as an exception (problematic I know) or wraps all values in a tuple in the normal erlang way. `{ok, &lt;valid-result&gt;}` or `{exit | throw | error, &lt;thrown-value&gt;}`. On Mon, May 14, 2012 at 9:17 AM, Vyacheslav Vorobyov &lt;vjache&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ erlang-bugs mailing list erlang</pre> Eric Merritt 2012-05-14T14:31:47 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2937 <pre>Let me disagree with "erlang:throw/1 does not generate an exception". Am I wrong addressing you to http://www.erlang.org/doc/reference_manual/errors.html#id81437. I think it does generate exception of class 'throw' ;-) About "We don't throw errors in erlang.", probably yes, but we also don't want to loose (hide) information when using rpc:call. Information about HOW value returned. Currently rpc:call provides us with doubtful "service" it decides for us that normally returned value and thrown one are "equally good". 2012/5/14 Robert Virding &lt;robert.virding&lt; at &gt;erlang-solutions.com&gt;: </pre> Vyacheslav Vorobyov 2012-05-14T14:17:42 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2936 <pre>Well, a "nonlocal return" is also an exception. It's just a different class of exception than exits and errors. The question here is whether the rpc really ought to catch the trow and convert it to a regular return value, as done currently, or if it should let the caller know for sure that the code terminated with a throw. The documentation for rpc:call() just says that you should get {badrpc, Reason} "if the call fails". And exactly what Reason is in this case is not specified further. Turns out, it's whatever you got from "catch apply(M,F,As)" if that yields {'EXIT',...}, so if the rpc failed with an error, you get a stack trace, but if it failed with an exit, you don't get a stack trace. This is all rather messy. /Richard On 2012-05-14 08:33, Robert Virding wrote: _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Richard Carlsson 2012-05-14T09:12:13 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2935 <pre>erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See http://www.erlang.org/doc/man/erlang.html#throw-1 We don't throw errors in erlang. :-) Robert ----- Original Message ----- _______________________________________________ erlang-bugs mailing list erlang-bugs&lt; at &gt;erlang.org http://erlang.org/mailman/listinfo/erlang-bugs </pre> Robert Virding 2012-05-14T06:33:24 http://permalink.gmane.org/gmane.comp.lang.erlang.bugs/2934 <pre>---------- Forwarded message ---------- From: Vyacheslav Vorobyov &lt;vjache&lt; at &gt;gmail.com&gt; Date: 2012/5/11 Subject: rpc:call hide throw To: erlang-bugs&lt; at &gt;erlang.org 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. -- Best Regargs,      Vyacheslav </pre> Vyacheslav Vorobyov 2012-05-12T20:53:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.erlang.bugs