From systemio@REDACTED Wed Feb 1 15:13:40 2012 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Wed, 01 Feb 2012 18:13:40 +0400 Subject: [erlang-bugs] =?utf-8?q?eunit_timeout_doesn=27t_work_properly?= Message-ID: My function works about 7 seconds. i test my function via {timeout,100,[{setup,S,C,F}]} and always get timeout after 5 seconds. BUT if i test my function via {timeout,1,[{setup,S,C,F}]} i will get timeout after a second. From roberto.aloi@REDACTED Wed Feb 1 17:28:58 2012 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Wed, 01 Feb 2012 16:28:58 -0000 (GMT) Subject: [erlang-bugs] eunit timeout doesn't work properly In-Reply-To: Message-ID: Hi, 5 seconds sounds like the typical default timeout for a gen_server. Are you sure it's the eunit test itself which is timing out and not some other part of the system? Could you please share some code? Roberto Aloi --- Erlang Solutions Ltd. www.erlang-solutions.com ----- Original Message ----- > My function works about 7 seconds. > i test my function via {timeout,100,[{setup,S,C,F}]} and always get > timeout after 5 seconds. > BUT if i test my function via {timeout,1,[{setup,S,C,F}]} i will get > timeout after a second. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From pan@REDACTED Wed Feb 1 17:50:37 2012 From: pan@REDACTED (pan@REDACTED) Date: Wed, 1 Feb 2012 17:50:37 +0100 Subject: [erlang-bugs] ssh daemon and encoding. In-Reply-To: <4F2801A3.5070206@trifork.com> References: <4F27E5D6.70500@ufm.su> <4F2801A3.5070206@trifork.com> Message-ID: Hi Erik! You are absolutely right about that 'user' and 'group' are used in different situations and that the names are utterly confusing. 'group' is used in *interactive shell sessions* and will determine unicode mode from LOCALE/terminal settings, while 'user' is for non interactive stdin/stdout (pipes, redirected files, dumb terminals etc), in which case you *have to* set unicode mode manually. Your first example will run the io:setopts before the group server is fully initialized, why you will get an unexpected behaviour. If you were to do the same when the interactive shell was actually started, the behaviour would be as expected. If opting to set unicode mode for an interactive session, set the LOCALE correctly. If running a non interactive session, use -oldshell or -noshell and do as in your second example. The problem reported however, was easilly found. It is due to that ssh_cli does not handle setting of unicode mode, which is a problem in the ssh application (that does not fully handle unicode). The internal protocol between io-server and ssh_cli will call ssh_cli:handle_msg({Pid,set_unicode_state,true},State), which is ignored by the ssh_cli code. Supporting unicode here could be done by simply expecting the terminal in the other end to support UTF8 characters if unicode mode was enabled, which would be the same behaviour as in the 'user' io-server. That however requires a fair amount of coding and the ssh application is far away from my jurisdiction :) Cheers, /Patrik, OTP On Tue, 31 Jan 2012, Erik S?e S?rensen wrote: > This is probably not related to SSH. > As was found out earlier on this list, the encoding behaviour (confusingly) > depends on how Erlang was started: > > $ erl -eval 'ok = io:setopts([{encoding, unicode}]), > io:format("~p~n", [io:getopts()]), init:stop().' > Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:8:8] [rq:8] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.8.4 (abort with ^G) > 1> [{expand_fun,#Fun}, > {echo,true}, > {binary,false}, > {encoding,latin1}] > $ erl -eval 'ok = io:setopts([{encoding, unicode}]), > io:format("~p~n", [io:getopts()]), init:stop().' -noinput > [{binary,false},{encoding,unicode}] > $ erl -eval 'ok = io:setopts([{encoding, unicode}]), > io:format("~p~n", [io:getopts()]), init:stop().' -noshell > [{binary,false},{encoding,unicode}] > > This has do do with the fact that in one case, the 'group' module handles > I/O, while in the other case it's the 'user' module. > (I don't know enough to say anything intelligent about why this is, why two > modules with overlapping functionality but different encoding behaviour > exist, or what their purposes are besides handling I/O.) > > On 31-01-2012 14:00, Fyodor Ustinov wrote: >> Hi! >> >> Unable to set encoding to unicode in ssh daemon session. >> >> ok = io:setopts([{expand_fun, fun expand_prompt/1}, {encoding, unicode}]), >> io:format("~p~n", [io:getopts()]) >> >> say: >> >> [{expand_fun,#Fun}, >> {echo,true}, >> {binary,false}, >> {encoding,latin1}] >> >> WBR, >> Fyodor. >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > -- > Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe > Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C | www.trifork.com > > From systemio@REDACTED Wed Feb 1 17:58:33 2012 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Wed, 01 Feb 2012 20:58:33 +0400 Subject: [erlang-bugs] =?utf-8?q?eunit_timeout_doesn=27t_work_properly?= In-Reply-To: References: Message-ID: here is the code in the module smoke_test_() -> S = fun() -> ok end, C = fun(_) -> ok end, F = fun(_) -> fun() -> timer:sleep(6000) end end, {timeout,100,[{setup,S,C,F}]}. and i start it via erlang shell: eunit:test([{inparallel,smoke}],[{report,{eunit_surefire,[{dir,"./Reports"}]}}]). it breaks after 5 seconds, in spite of i gave it a 100 seconds timeout. 01 ??????? 2012, 20:29 ?? Roberto Aloi : > Hi, > > 5 seconds sounds like the typical default timeout for a gen_server. > Are you sure it's the eunit test itself which is timing out and not some other part of the system? > > Could you please share some code? > > Roberto Aloi > --- > Erlang Solutions Ltd. > www.erlang-solutions.com > > ----- Original Message ----- > > My function works about 7 seconds. > > i test my function via {timeout,100,[{setup,S,C,F}]} and always get > > timeout after 5 seconds. > > BUT if i test my function via {timeout,1,[{setup,S,C,F}]} i will get > > timeout after a second. > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > From tuncer.ayaz@REDACTED Wed Feb 1 18:59:51 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 1 Feb 2012 18:59:51 +0100 Subject: [erlang-bugs] escript: interesting stack trace Message-ID: Running the following (simplified) erroneous piece of code as part of the rebar binary, a tiny escript, or erl shell gives mostly easy to follow stack traces. lists:append([{a,[b]},{c,[d]}]). I was only surprised to see win32reg:expand/1 on Linux and Darwin. Is this expected behaviour? The different stack traces are: as part of the rebar binary $ rebar compile {'EXIT',{badarg,[{erlang,memory,0,[]}, {escript,run,2,[]}, {escript,start,1,[]}, {erlang,memory,0,[]}]}} on the erl shell $ erl 1> lists:append([{a,[b]},{c,[d]}]). ** exception error: bad argument in function erl_eval:do_apply/6 in call from shell:exprs/7 in call from shell:eval_exprs/7 in call from shell:eval_loop/3 in call from erlang:memory/0 trivial escript $ cat append1.escript #!/usr/bin/env escript main(_) -> lists:append([{a,[b]},{c,[d]}]). $ ./append1.escript escript: exception error: bad argument in function erl_eval:local_func/5 in call from escript:interpret/4 in call from escript:start/1 in call from win32reg:expand/1 trivial escript in compile mode $ cat append2.escript #!/usr/bin/env escript -mode(compile). main(_) -> lists:append([{a,[b]},{c,[d]}]). $ ./append2.escript escript: exception error: bad argument in function escript:run/2 in call from escript:start/1 in call from win32reg:expand/1 From ufm@REDACTED Wed Feb 1 19:13:14 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Wed, 01 Feb 2012 20:13:14 +0200 Subject: [erlang-bugs] ssh daemon and encoding. In-Reply-To: References: <4F27E5D6.70500@ufm.su> <4F2801A3.5070206@trifork.com> Message-ID: <4F2980BA.1060108@ufm.su> On 01.02.2012 18:50, pan@REDACTED wrote: > Hi Erik! Can I expect that it will be seen as a bug and corrected in the next version? > > You are absolutely right about that 'user' and 'group' are used in > different situations and that the names are utterly confusing. 'group' > is used in *interactive shell sessions* and will determine unicode > mode from LOCALE/terminal settings, while 'user' is for non > interactive stdin/stdout (pipes, redirected files, dumb terminals > etc), in which case you *have to* set unicode mode manually. Your > first example will run the io:setopts before the group server is fully > initialized, why you will get an unexpected behaviour. If you were to > do the same when the interactive shell was actually started, the > behaviour would be as expected. > > If opting to set unicode mode for an interactive session, set the > LOCALE correctly. If running a non interactive session, use -oldshell > or -noshell and do as in your second example. > > The problem reported however, was easilly found. It is due to that > ssh_cli does not handle setting of unicode mode, which is a problem in > the ssh application (that does not fully handle unicode). The internal > protocol between io-server and ssh_cli will call > ssh_cli:handle_msg({Pid,set_unicode_state,true},State), which is > ignored by the ssh_cli code. Supporting unicode here could be done by > simply expecting the terminal in the other end to support UTF8 > characters if unicode mode was enabled, which would be the same > behaviour as in the 'user' io-server. That however requires a fair > amount of coding and the ssh application is far away from my > jurisdiction :) > > Cheers, > /Patrik, OTP > > > On Tue, 31 Jan 2012, Erik S?e S?rensen wrote: > >> This is probably not related to SSH. >> As was found out earlier on this list, the encoding behaviour >> (confusingly) depends on how Erlang was started: >> >> $ erl -eval 'ok = io:setopts([{encoding, unicode}]), >> io:format("~p~n", [io:getopts()]), init:stop().' >> Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:8:8] [rq:8] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Eshell V5.8.4 (abort with ^G) >> 1> [{expand_fun,#Fun}, >> {echo,true}, >> {binary,false}, >> {encoding,latin1}] >> $ erl -eval 'ok = io:setopts([{encoding, unicode}]), >> io:format("~p~n", [io:getopts()]), init:stop().' -noinput >> [{binary,false},{encoding,unicode}] >> $ erl -eval 'ok = io:setopts([{encoding, unicode}]), >> io:format("~p~n", [io:getopts()]), init:stop().' -noshell >> [{binary,false},{encoding,unicode}] >> >> This has do do with the fact that in one case, the 'group' module >> handles I/O, while in the other case it's the 'user' module. >> (I don't know enough to say anything intelligent about why this is, >> why two modules with overlapping functionality but different encoding >> behaviour exist, or what their purposes are besides handling I/O.) >> >> On 31-01-2012 14:00, Fyodor Ustinov wrote: >>> Hi! >>> >>> Unable to set encoding to unicode in ssh daemon session. >>> >>> ok = io:setopts([{expand_fun, fun expand_prompt/1}, {encoding, >>> unicode}]), >>> io:format("~p~n", [io:getopts()]) >>> >>> say: >>> >>> [{expand_fun,#Fun}, >>> {echo,true}, >>> {binary,false}, >>> {encoding,latin1}] >>> >>> WBR, >>> Fyodor. >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> -- >> Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe >> Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C | >> www.trifork.com >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Wed Feb 1 19:27:21 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 01 Feb 2012 19:27:21 +0100 Subject: [erlang-bugs] eunit timeout doesn't work properly In-Reply-To: References: Message-ID: <4F298409.1020400@gmail.com> On 02/01/2012 03:13 PM, systemio systemio wrote: > My function works about 7 seconds. > i test my function via {timeout,100,[{setup,S,C,F}]} and always get timeout after 5 seconds. > BUT if i test my function via {timeout,1,[{setup,S,C,F}]} i will get timeout after a second. Yes, the {timeout,1,...} applies to the whole subset of tests, in this case the setup and all the tests in it. The individual tests still get their default timeout of 5 seconds. If you reduce the timeout for the whole group to 1 second, then that will of course happen first and abort all the tests in the group, while in the first case it's one of the individual tests that times out first. Only when applied to a single test does {timeout,T,...} change the timeout of the test itself. I'm sorry that this is confusing. There should probably be a separate way of modifying the default timeout for all individual tests. /Richard From ingela@REDACTED Thu Feb 2 11:18:46 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 2 Feb 2012 11:18:46 +0100 Subject: [erlang-bugs] [Fwd: Re: ssh daemon and encoding.] Message-ID: <4F2A6306.6070406@erix.ericsson.se> Hi! Pressed the wrong reply-button! Regards Ingela -------------- next part -------------- An embedded message was scrubbed... From: Ingela Anderton Andin Subject: Re: [erlang-bugs] ssh daemon and encoding. Date: Thu, 02 Feb 2012 09:20:41 +0100 Size: 5205 URL: From samuelrivas@REDACTED Thu Feb 2 17:07:58 2012 From: samuelrivas@REDACTED (Samuel) Date: Thu, 2 Feb 2012 17:07:58 +0100 Subject: [erlang-bugs] eunit timeout doesn't work properly In-Reply-To: <4F298409.1020400@gmail.com> References: <4F298409.1020400@gmail.com> Message-ID: > I'm sorry that this is confusing. There should probably be a separate way of > modifying the default timeout for all individual tests. I've shot my feet a number of times with that issue, but I always came to think that even though it might be a bit confusing that you can set a shorter timeout for a set of thests than for the tests themselves and viceversa, once understood the behaviour is quite simple. Thus never saw a point in fixing that. However, the idea of modifying the default timeout could be handy, but I'm not sure it can contribute to eliminate that confusion ... Regards -- Samuel From andrew@REDACTED Thu Feb 2 18:58:18 2012 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 2 Feb 2012 12:58:18 -0500 Subject: [erlang-bugs] eunit timeout doesn't work properly In-Reply-To: <4F298409.1020400@gmail.com> References: <4F298409.1020400@gmail.com> Message-ID: <20120202175817.GB15126@hijacked.us> On Wed, Feb 01, 2012 at 07:27:21PM +0100, Richard Carlsson wrote: > I'm sorry that this is confusing. There should probably be a > separate way of modifying the default timeout for all individual > tests. I'd love to see eunit timeouts be improved. I think at Basho we complain about them at least once a week. Andrew From carlsson.richard@REDACTED Thu Feb 2 19:10:47 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 02 Feb 2012 19:10:47 +0100 Subject: [erlang-bugs] eunit timeout doesn't work properly In-Reply-To: <20120202175817.GB15126@hijacked.us> References: <4F298409.1020400@gmail.com> <20120202175817.GB15126@hijacked.us> Message-ID: <4F2AD1A7.3050704@gmail.com> On 2012-02-02 18:58, Andrew Thompson wrote: > On Wed, Feb 01, 2012 at 07:27:21PM +0100, Richard Carlsson wrote: >> I'm sorry that this is confusing. There should probably be a >> separate way of modifying the default timeout for all individual >> tests. > > I'd love to see eunit timeouts be improved. I think at Basho we complain > about them at least once a week. Ideas on the best way of setting timeouts are very welcome. /Richard From jimenezrick@REDACTED Mon Feb 6 21:54:12 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Mon, 6 Feb 2012 21:54:12 +0100 Subject: [erlang-bugs] Debugger crashes handling the breakpoints Message-ID: <20120206205412.GA845@viper.local> When I add some breakpoints in a module in the source code window, if I close that window and I open it again, all the breakpoints are lost, not shown in the sidebar nor in the `Break' menu. Also, when I open the source code window again (with all the breakpoints lost), if I hit on the menu `Break->Enable All' or `Break->Disable All' the debugger crashes with: dbg_wx_view:error {badmatch,false} I'm using R15B. Regards -- Ricardo (http://r.untroubled.be/) From dangud@REDACTED Tue Feb 7 08:57:49 2012 From: dangud@REDACTED (Dan Gudmundsson) Date: Tue, 7 Feb 2012 08:57:49 +0100 Subject: [erlang-bugs] R15B observer crash while refreshing the state of a stopped application In-Reply-To: <4EFB972B.3010805@wanadoo.fr> References: <4EFB91BD.2050500@wanadoo.fr> <4EFB972B.3010805@wanadoo.fr> Message-ID: Your observer issues should be fixed in the maint branch now. Thanks for the report. /Dan On Wed, Dec 28, 2011 at 11:24 PM, PAILLEAU Eric wrote: > Hello, > > I got another crash when refreshing the process' state of an application > that is temporary stopped. > > I think a test that the current application is still alive should be > performed before trying to refresh a vanished application. > > ----------------8<---------------------------------------------- > Child crashed exiting: ?<0.11300.0> {function_clause, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{proplists,get_value, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [initial_call,undefined,undefined], > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"proplists.erl"},{line,222}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{observer_lib,fill_info,2, > > [{file,"observer_lib.erl"},{line,122}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{observer_lib,fill_info,2, > > > [{file,"observer_lib.erl"},{line,127}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{observer_procinfo, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '-init_process_page/2-fun-0-',2, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"observer_procinfo.erl"}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{line,129}]}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{observer_procinfo, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '-handle_event/2-lc$^0/1-0-',1, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"observer_procinfo.erl"}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{line,98}]}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{observer_procinfo,handle_event,2, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"observer_procinfo.erl"}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{line,98}]}, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_object,handle_msg,5, > > > [{file,"wx_object.erl"},{line,394}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"proc_lib.erl"},{line,227}]}]} > > ----------------8<---------------------------------------------- > > best regards. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From vinodhg@REDACTED Thu Feb 16 06:21:26 2012 From: vinodhg@REDACTED (Vinod H G) Date: Thu, 16 Feb 2012 10:51:26 +0530 Subject: [erlang-bugs] ei_connect_xinit bug in windows? Message-ID: Hello, I was trying to connect c node using ei lib in windows. ei_connect_init and then ei_connect or ei_xconnect works fine. But when I use ei_xconnect_init, I am getting error while connecting. I found that WSAStartup was not called in this case, so socket connection failed. After calling initWinSock()) ei_connect_xinit worked. Why is the error even though identified, not fixed. Will it be fixed in the next version? Code snippet from ei_connect.c /* FIXME this code was enabled for 'erl'_connect_xinit(), why not here? */ #if 0 #ifdef __WIN32__ if (!initWinSock()) { EI_TRACE_ERR0("ei_connect_xinit","can't initiate winsock"); return ERL_ERROR; } #endif #endif Thanks & Regards, Vinod H. G. From robert.virding@REDACTED Fri Feb 17 10:54:41 2012 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 17 Feb 2012 09:54:41 -0000 (GMT) Subject: [erlang-bugs] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: If in my file I add the sepc: -spec set_var(PrefixExp, Val, State) -> State. I get the compiler errors, errors mind you, not warnings: src/luerl_eval.erl:332: type variable 'PrefixExp' is only used once (is unbound) src/luerl_eval.erl:332: type variable 'Val' is only used once (is unbound) but if I write it as: -spec set_var(_PrefixExp, _Val, State) -> State. then the compiler is happy and is quiet. If I write it as: -spec set_var(Val, Val, State) -> State. (which is wrongly from my point of view) or go all verbose and write: -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). (which doesn't really add any useful information) the compiler is again happy and silent. This is inconsistent and does not make sense for variables in a function spec. Either it is wrong, for some incomprehensible reason, to have singleton variables in a function spec, or it shouldn't matter what the variable names are. And why should adding a type, even the most general one, make a difference to the variable name usage. And why should the compiler be bothered with the function spec at all seeing it is doesn't use it and it is not part of the language. In my naive view of the the typing world my original spec says that set_var/3 takes three arguments of any type and returns a value of the same type as the third argument. Then why not just add type information and make the compiler happy? Well in my case it doesn't give me anything; it makes the spec much longer and there is nothing in a type which would give me more information than is in the variable names. Also dialyzer doesn't actually *need* the spec as it works it out by itself anyway. And the type of PrefixExp is a big hairy recursive type which I am happy to let dialyzer work out for me. Typer gives me a half-screen long type for it. I get the same behaviour when running dialyzer on the different versions. Again I don't understand why it behaves like that. Robert From magnus.henoch@REDACTED Fri Feb 17 12:49:09 2012 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Fri, 17 Feb 2012 11:49:09 -0000 (GMT) Subject: [erlang-bugs] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: There is a big difference between this: > -spec set_var(PrefixExp, Val, State) -> State. and this: > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). The argument and return value type specifications are either Type or Name::Type, so the first declaration says that the arguments are of _types_ PrefixExp, Val and State, while the second declaration says that all three arguments are of type any(). (As far as I know, argument names are ignored by the compiler and dialyzer, and only used by edoc.) Specifying a singleton variable as the _type_ of an argument is most likely not what the programmer meant, since it doesn't add any information, so to me it makes sense to have the compiler reject it. That specification could be written like this: -spec set_var(PrefixExp::any(), Val::any(), State::X) -> NewState::X. which specifies that State and NewState must have the same type, no matter which one. Hope this helps, -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From diego.llarrull@REDACTED Fri Feb 17 16:24:58 2012 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Fri, 17 Feb 2012 12:24:58 -0300 Subject: [erlang-bugs] Segmentation fault with ETS bag implementation in 64-bit Erlang Message-ID: <4F3E714A.3080407@tecso.coop> Hello everyone, I'm currently developing a distributed store written entirely in Erlang, and we are having a somewhat awkward problem: the app runs fine in 32-bit Erlang VMs but ALWAYS crashes in 64-bit Erlang VMs. We've tested 64-bit Erlang VMs running on Linux (XUbuntu 11.04/Fedora 15) 64-bit, OS X Lion 64-bit, and FreeBSD 8.2 64-bit with exactly the same result: a segmentation fault as soon as we try to to use the store. We managed to track down one bug, which was caused by inserting the same record twice, on a compressed, named ETS table with bag implementation. This causes, inexplicably, a segmentation fault which is solved my changing the Ets table to a set. To replicate the bug, the following code can be run: -module(segviola14). -compile(export_all). init() -> S = { {1316110174588445,1316110174588583}, {1316110174588445,1316110174588590} }, DB=ets:new(childName, [named_table, bag, compressed]), ets:insert(DB, S), io:format("guau!~n"), ets:insert(DB, S), io:format("guau!~n"). The output for this code is: > segviola14:init(). guau! Segmentation fault (core dumped) In 32-bit Erlang VMs this code works just fine. We are, however, having segmentation faults throught our code that make us think the bug affects a core area of the VM-code. 32-bit Erlang showed none of these problems, with everything running fine. Any ideas? Thank you all in advance. Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Feb 17 18:23:49 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 17 Feb 2012 18:23:49 +0100 Subject: [erlang-bugs] fun_info(F, env) always empty? Message-ID: Given the following code: -module(ff). -export([g/0]). f() -> X = 1, Y = 2, fun() -> X-Y end. g() -> F = f(), erlang:fun_info(F). If I compile and run it, I get some unexpected results: Eshell V5.9 (abort with ^G) 1> c(ff). {ok,ff} 2> ff:g(). [{pid,<0.31.0>}, {module,ff}, {new_index,0}, {new_uniq,<<64,51,168,35,51,43,131,196,64,237,179,79,226, 167,195,28>>}, {index,0}, {uniq,33660225}, {name,'-f/0-fun-0-'}, {arity,0}, {env,[]}, {type,local}] According to the documentation, fun_info(F, env) will always be empty for external funs. It *doesn't* say, of course, that it will *not* be empty for other types of fun, but it would seem a reasonable conclusion. What gives? BR, Ulf W From robert.virding@REDACTED Fri Feb 17 19:33:02 2012 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 17 Feb 2012 18:33:02 -0000 (GMT) Subject: [erlang-bugs] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: Yes, I know that. My comment was mainly about how variables are handled. It is not logical that the compiler complains about a variable being used once but not when used more than once. It also doesn't make sense that prefixing the variable name with a '_' makes the compiler keep quite. It seems like it is reusing some of the variable checking code for functions but generating errors instead of warnings. In my case just using variable names does add information, it tells me what it is. In the respect the actual type is unimportant, if I need to type check my functions dialyzer will do it for me without a type spec. Just giving it an appropriate name is enough. It is also a way of giving long names in the "documentation" which allows me to use short names in the code. Reusing the same name tells me it is the same type. In this respect it gives me as much information as your alternative and is shorter and more concise. Again the actual errors I get from the compiler don't make sense and I ask why the compiler should worry as it does not use the information at all. The type interpretation is actually very close to my usage and would work if it wasn't for the compiler errors, and the similar dialyzer errors. Robert ----- Original Message ----- > There is a big difference between this: > > > -spec set_var(PrefixExp, Val, State) -> State. > > and this: > > > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> > > State::any(). > > The argument and return value type specifications are either Type > or Name::Type, so the first declaration says that the arguments > are of _types_ PrefixExp, Val and State, while the second declaration > says that all three arguments are of type any(). (As far as I know, > argument names are ignored by the compiler and dialyzer, and only > used by edoc.) Specifying a singleton variable as the _type_ of an > argument is most likely not what the programmer meant, since it > doesn't add any information, so to me it makes sense to have the > compiler reject it. > > That specification could be written like this: > > -spec set_var(PrefixExp::any(), Val::any(), State::X) -> NewState::X. > > which specifies that State and NewState must have the same type, no > matter which one. > > Hope this helps, > -- > Magnus Henoch > Erlang Solutions Ltd > http://www.erlang-solutions.com/ > > From kostis@REDACTED Fri Feb 17 21:56:00 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 17 Feb 2012 22:56:00 +0200 Subject: [erlang-bugs] [erlang-questions] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: References: Message-ID: <4F3EBEE0.30008@cs.ntua.gr> On 02/17/2012 10:54 AM, Robert Virding wrote: > If in my file I add the sepc: > > -spec set_var(PrefixExp, Val, State) -> State. > > I get the compiler errors, errors mind you, not warnings: > > src/luerl_eval.erl:332: type variable 'PrefixExp' is only used once (is unbound) > src/luerl_eval.erl:332: type variable 'Val' is only used once (is unbound) > > but if I write it as: > > -spec set_var(_PrefixExp, _Val, State) -> State. > > then the compiler is happy and is quiet. If I write it as: > > -spec set_var(Val, Val, State) -> State. > > (which is wrongly from my point of view) or go all verbose and write: > > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). > > (which doesn't really add any useful information) the compiler is again happy and silent. > > This is inconsistent and does not make sense for variables in a function spec. Either it is wrong, for some incomprehensible reason, to have singleton variables in a function spec, or it shouldn't matter what the variable names are. And why should adding a type, even the most general one, make a difference to the variable name usage. And why should the compiler be bothered with the function spec at all seeing it is doesn't use it and it is not part of the language. > > In my naive view of the the typing world my original spec says that set_var/3 takes three arguments of any type and returns a value of the same type as the third argument. Then why not just add type information and make the compiler happy? Well in my case it doesn't give me anything; it makes the spec much longer and there is nothing in a type which would give me more information than is in the variable names. Also dialyzer doesn't actually *need* the spec as it works it out by itself anyway. And the type of PrefixExp is a big hairy recursive type which I am happy to let dialyzer work out for me. Typer gives me a half-screen long type for it. > > I get the same behaviour when running dialyzer on the different versions. Again I don't understand why it behaves like that. As others mentioned, in their most basic form, specs should contain *types*, not type variables. Continuing your example, the following is a valid spec: -spec set_var(exp(), val(), state()) -> state(). for some appropriate definitions of exp(), val() and state() types. I recommend that you write such specs. I would even go as far as say that you should stick to this kind of specs: specs that contain types and types alone. Of course, the benefits of writing the above spec are dependent on the precision of your type declarations. If you are lazy and map all three types to any(), something that the type language allows you to do, then of course you cannot expect much from the tools that take these specs into account, can you? (In such a case the spec is there mostly (only?) for documentation purposes. Personally, I am not interested in this type of specs; they have very little purpose.) Now, for convenience and for compatibility with what the edoc @spec language also allowed, we have retained the possibility that the user provides, perhaps selectively, *names* to argument positions and return results. So, you can write the above as: -spec set_var(PrefixExp::exp(), ImpValue::val(), state()) -> state(). Note that PrefixExp and ImpValue, i.e. whatever comes to the left of the :: symbol in the above, are *optional names* for arguments 1 and 2, not type variables. Type variables in specs come into the picture when you want to express (subtype or equality) relations between different argument positions or return values. (And by definition to express a relation you need to somehow use the same variable twice; personally I cannot think of a case where a singleton type variable is interesting.) For example, you may want to state in a more emphatic way that the third argument and the return result of the set_var/3 function are of the same type. You can do that as follows: -spec set_var(PrefixExp::exp(), ImpValue::val(), InState::ST) -> OutState::ST when ST::state(). (Note that the only type variable in the above is ST.) Another example of use of type variables is in functions like map/2. Since the type system is based on subtyping, you would need to write its spec as follows: -spec map(F::fun((X) -> Y), InL::[XE]) -> OutL::[YE] when X::term(), Y::term(), XE::term(), YE::term(), XL::X, YL::Y. or, even stricter, as: -spec map(F::fun((X) -> Y), InL::[X]) -> OutL::[Y] when X::term(), Y::term(). but I guess most people would find the above two ways of giving a spec for map/2 probably too verbose so we also allowed them to write simply: -spec map(fun((X) -> Y), [X]) -> [Y]. with the implicit assumption that for all type variables T that are not qualified by a subtype constraint, there is a constraint T::term() which is implicit. (Note that in this case, all type variables are not singletons.) Also, because we had a hunch that there may be Erlang programmers who have hard time grasping the subtleties of the type language (for example, they might be confusing type variables with argument and position names) and might make typos in specs, we decided to never allow type variables that are singleton. As I explained, such variables are not just unconstrained, but they are really not needed because they serve no purpose; instead type names do. I saw/see no reason for one to write a type variable just to name a position; if you think otherwise, please provide an example that makes sense. Till you do, you are not allowed to write MY_NAME for the type any(); if you want the type any() please write any(); if you want to name it appropriately, you are required to write MY_NAME::any() or its shorthand MY_NAME::_. I hope it is clear now. Kostis From sverker@REDACTED Fri Feb 17 22:58:59 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 17 Feb 2012 22:58:59 +0100 Subject: [erlang-bugs] Segmentation fault with ETS bag implementation in 64-bit Erlang In-Reply-To: <4F3E714A.3080407@tecso.coop> References: <4F3E714A.3080407@tecso.coop> Message-ID: <4F3ECDA3.2030809@erix.ericsson.se> Hi Diego, Thanks for the exemplary test code to provoke the bug. I get the same crash on my 64-bit machine. I think I found what it is. To be continued on Monday... /Sverker, Erlang/OTP, Ericsson Diego Llarrull wrote: > Hello everyone, > > I'm currently developing a distributed store written entirely in > Erlang, and we are having a somewhat awkward problem: the app runs > fine in 32-bit Erlang VMs but ALWAYS crashes in 64-bit Erlang VMs. > We've tested 64-bit Erlang VMs running on Linux (XUbuntu 11.04/Fedora > 15) 64-bit, OS X Lion 64-bit, and FreeBSD 8.2 64-bit with exactly the > same result: a segmentation fault as soon as we try to > to use the store. > > We managed to track down one bug, which was caused by inserting the > same record twice, on a compressed, named ETS table with bag > implementation. This causes, inexplicably, a segmentation fault which > is solved my changing the Ets table to a set. > > > To replicate the bug, the following code can be run: > > -module(segviola14). > -compile(export_all). > > init() -> > S = { > {1316110174588445,1316110174588583}, > {1316110174588445,1316110174588590} > }, > DB=ets:new(childName, [named_table, bag, compressed]), > ets:insert(DB, S), io:format("guau!~n"), > ets:insert(DB, S), io:format("guau!~n"). > > > The output for this code is: > >> segviola14:init(). > guau! > Segmentation fault (core dumped) > > > In 32-bit Erlang VMs this code works just fine. We are, however, > having segmentation faults throught our code that make us think the > bug affects a core area of the VM-code. 32-bit Erlang showed > none of these problems, with everything running fine. > > Any ideas? > > Thank you all in advance. > > > Diego > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From bgustavsson@REDACTED Sun Feb 19 08:46:56 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 19 Feb 2012 08:46:56 +0100 Subject: [erlang-bugs] fun_info(F, env) always empty? In-Reply-To: References: Message-ID: On Fri, Feb 17, 2012 at 6:23 PM, Ulf Wiger wrote: > > According to the documentation, fun_info(F, env) will always be empty for external funs. It *doesn't* say, of course, that it will *not* be empty for other types of fun, but it would seem a reasonable conclusion. > > What gives? You will see a non-empty empty environment if the fun has a non-empty environment. In your case, you will see it if you use the 'no_copt' option to disable constant propagation (among other optimizations) or if you rewrite f/0 like this: f() -> f(1, 2). f(X, Y) -> fun() -> X-Y end. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ulf@REDACTED Sun Feb 19 11:18:21 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 19 Feb 2012 11:18:21 +0100 Subject: [erlang-bugs] fun_info(F, env) always empty? In-Reply-To: References: Message-ID: <0592CA7D-6424-40CE-997A-A1E1A45F0263@feuerlabs.com> Ah, of course. Didn't consider that it could be the effect of constant propagation. :) Thanks. BR, Ulf W On 19 Feb 2012, at 08:46, Bj?rn Gustavsson wrote: > On Fri, Feb 17, 2012 at 6:23 PM, Ulf Wiger wrote: >> >> According to the documentation, fun_info(F, env) will always be empty for external funs. It *doesn't* say, of course, that it will *not* be empty for other types of fun, but it would seem a reasonable conclusion. >> >> What gives? > > You will see a non-empty empty environment if > the fun has a non-empty environment. > > In your case, you will see it if you use the 'no_copt' > option to disable constant propagation (among other > optimizations) or if you rewrite f/0 like this: > > f() -> > f(1, 2). > > f(X, Y) -> > fun() -> > X-Y > end. > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From sverker@REDACTED Mon Feb 20 14:01:59 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 20 Feb 2012 14:01:59 +0100 Subject: [erlang-bugs] Segmentation fault with ETS bag implementation in 64-bit Erlang In-Reply-To: <4F3ECDA3.2030809@erix.ericsson.se> References: <4F3E714A.3080407@tecso.coop> <4F3ECDA3.2030809@erix.ericsson.se> Message-ID: <4F424447.5020604@erix.ericsson.se> Here is a preliminary source patch: diff --git a/erts/emulator/beam/big.c b/erts/emulator/beam/big.c index 976f05c..8848741 100644 --- a/erts/emulator/beam/big.c +++ b/erts/emulator/beam/big.c @@ -1867,9 +1867,12 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int xsgn, Eterm *r) d = 0; for(i = xsz; --i >= 0;) d = (d << 8) | xp[i]; + if (++rsz == 1 && IS_USMALL(xsgn,d)) { + if (xsgn) d = -d; + return make_small(d); + } *rwp = d; rwp++; - rsz++; } return big_norm(r, rsz, (short) xsgn); } Sverker Eriksson wrote: > Hi Diego, > > Thanks for the exemplary test code to provoke the bug. I get the same > crash on my 64-bit machine. > > I think I found what it is. To be continued on Monday... > > /Sverker, Erlang/OTP, Ericsson > > Diego Llarrull wrote: >> Hello everyone, >> >> I'm currently developing a distributed store written entirely in >> Erlang, and we are having a somewhat awkward problem: the app runs >> fine in 32-bit Erlang VMs but ALWAYS crashes in 64-bit Erlang VMs. >> We've tested 64-bit Erlang VMs running on Linux (XUbuntu 11.04/Fedora >> 15) 64-bit, OS X Lion 64-bit, and FreeBSD 8.2 64-bit with exactly the >> same result: a segmentation fault as soon as we try to >> to use the store. >> >> We managed to track down one bug, which was caused by inserting the >> same record twice, on a compressed, named ETS table with bag >> implementation. This causes, inexplicably, a segmentation fault which >> is solved my changing the Ets table to a set. >> >> >> To replicate the bug, the following code can be run: >> >> -module(segviola14). >> -compile(export_all). >> >> init() -> >> S = { >> {1316110174588445,1316110174588583}, >> {1316110174588445,1316110174588590} >> }, >> DB=ets:new(childName, [named_table, bag, compressed]), >> ets:insert(DB, S), io:format("guau!~n"), >> ets:insert(DB, S), io:format("guau!~n"). >> >> The output for this code is: >> >>> segviola14:init(). >> guau! >> Segmentation fault (core dumped) >> >> >> In 32-bit Erlang VMs this code works just fine. We are, however, >> having segmentation faults throught our code that make us think the >> bug affects a core area of the VM-code. 32-bit Erlang showed >> none of these problems, with everything running fine. >> >> Any ideas? >> >> Thank you all in advance. >> >> >> Diego >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 onlyafly@REDACTED Tue Feb 21 09:26:33 2012 From: onlyafly@REDACTED (Kevin Albrecht) Date: Tue, 21 Feb 2012 09:26:33 +0100 Subject: [erlang-bugs] Unicode characters in binaries cause bad argument error In-Reply-To: References: Message-ID: According to section "Basic language support for Unicode " of the document "Using Unicode in Erlang" , this syntax can be used to enter Unicode characters in source code: "\x{400}". => [1024] This syntax also seems to work in binaries: <<"\x{00FF}"/utf8>>. => <<"??">> But then it fails when the hex value is greater than FF: <<"\x{0100}"/utf8>>. => ** exception error: bad argument Is this a bug or intended behavior? Regards, Kevin Albrecht From diego.llarrull@REDACTED Wed Feb 22 16:35:04 2012 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Wed, 22 Feb 2012 12:35:04 -0300 Subject: [erlang-bugs] Segmentation fault with ETS bag implementation in 64-bit Erlang In-Reply-To: <4F424447.5020604@erix.ericsson.se> References: <4F3E714A.3080407@tecso.coop> <4F3ECDA3.2030809@erix.ericsson.se> <4F424447.5020604@erix.ericsson.se> Message-ID: <4F450B28.2080504@tecso.coop> Hello Sverker, The patch indeed solved the mentioned bug and, since our app evidently made heavy use of this function, it works perfectly right now. Thank you very much for the (very) swift response and help. One final question, will this patch make it to any upcoming Erlang release? That would avoid the need to patch big.c on every deployment machine. Thanks again, Diego On 20/02/12 10:01, Sverker Eriksson wrote: > Here is a preliminary source patch: > > diff --git a/erts/emulator/beam/big.c b/erts/emulator/beam/big.c > index 976f05c..8848741 100644 > --- a/erts/emulator/beam/big.c > +++ b/erts/emulator/beam/big.c > @@ -1867,9 +1867,12 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int > xsgn, Eterm *r) > d = 0; > for(i = xsz; --i >= 0;) > d = (d << 8) | xp[i]; > + if (++rsz == 1 && IS_USMALL(xsgn,d)) { > + if (xsgn) d = -d; > + return make_small(d); > + } > *rwp = d; > rwp++; > - rsz++; > } > return big_norm(r, rsz, (short) xsgn); > } > > > Sverker Eriksson wrote: >> Hi Diego, >> >> Thanks for the exemplary test code to provoke the bug. I get the same >> crash on my 64-bit machine. >> >> I think I found what it is. To be continued on Monday... >> >> /Sverker, Erlang/OTP, Ericsson >> >> Diego Llarrull wrote: >>> Hello everyone, >>> >>> I'm currently developing a distributed store written entirely in >>> Erlang, and we are having a somewhat awkward problem: the app runs >>> fine in 32-bit Erlang VMs but ALWAYS crashes in 64-bit Erlang VMs. >>> We've tested 64-bit Erlang VMs running on Linux (XUbuntu >>> 11.04/Fedora 15) 64-bit, OS X Lion 64-bit, and FreeBSD 8.2 64-bit >>> with exactly the same result: a segmentation fault as soon as we try to >>> to use the store. >>> >>> We managed to track down one bug, which was caused by inserting the >>> same record twice, on a compressed, named ETS table with bag >>> implementation. This causes, inexplicably, a segmentation fault which >>> is solved my changing the Ets table to a set. >>> >>> >>> To replicate the bug, the following code can be run: >>> >>> -module(segviola14). >>> -compile(export_all). >>> >>> init() -> >>> S = { >>> {1316110174588445,1316110174588583}, >>> {1316110174588445,1316110174588590} >>> }, >>> DB=ets:new(childName, [named_table, bag, compressed]), >>> ets:insert(DB, S), io:format("guau!~n"), >>> ets:insert(DB, S), io:format("guau!~n"). >>> >>> The output for this code is: >>> >>>> segviola14:init(). >>> guau! >>> Segmentation fault (core dumped) >>> >>> >>> In 32-bit Erlang VMs this code works just fine. We are, however, >>> having segmentation faults throught our code that make us think the >>> bug affects a core area of the VM-code. 32-bit Erlang showed >>> none of these problems, with everything running fine. >>> >>> Any ideas? >>> >>> Thank you all in advance. >>> >>> >>> Diego >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> 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 >> > > -- Lic. Diego Llarrull Coop. Tecso Ltda. - Sarmiento 784 P1 (Rosario) Tel. (0341)4451480 - 5280080 / 5280020 From sverker@REDACTED Wed Feb 22 18:49:17 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 22 Feb 2012 18:49:17 +0100 Subject: [erlang-bugs] Segmentation fault with ETS bag implementation in 64-bit Erlang In-Reply-To: <4F450B28.2080504@tecso.coop> References: <4F3E714A.3080407@tecso.coop> <4F3ECDA3.2030809@erix.ericsson.se> <4F424447.5020604@erix.ericsson.se> <4F450B28.2080504@tecso.coop> Message-ID: <4F452A9D.3050904@erix.ericsson.se> Yes, a fix will be released as part of R15B01. Actually, the preliminary patch that I sent earlier was not complete. Integers larger than (1 bsl 55) may still provoke the same bug. Here is a better patch: diff --git a/erts/emulator/beam/big.c b/erts/emulator/beam/big.c index 976f05c..25ac790 100644 --- a/erts/emulator/beam/big.c +++ b/erts/emulator/beam/big.c @@ -1844,6 +1844,7 @@ dsize_t big_bytes(Eterm x) /* ** Load a bignum from bytes ** xsz is the number of bytes in xp +** *r is untouched if number fits in small */ Eterm bytes_to_big(byte *xp, dsize_t xsz, int xsgn, Eterm *r) { @@ -1852,7 +1853,7 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int xsgn, Eterm *r) ErtsDigit d; int i; - while(xsz >= sizeof(ErtsDigit)) { + while(xsz > sizeof(ErtsDigit)) { d = 0; for(i = sizeof(ErtsDigit); --i >= 0;) d = (d << 8) | xp[i]; @@ -1867,11 +1868,20 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int xsgn, Eterm *r) d = 0; for(i = xsz; --i >= 0;) d = (d << 8) | xp[i]; + if (++rsz == 1 && IS_USMALL(xsgn,d)) { + if (xsgn) d = -d; + return make_small(d); + } *rwp = d; rwp++; - rsz++; } - return big_norm(r, rsz, (short) xsgn); + if (xsgn) { + *r = make_neg_bignum_header(rsz); + } + else { + *r = make_pos_bignum_header(rsz); + } + return make_big(r); } /Sverker, Erlang/OTP Ericsson Diego Llarrull wrote: > Hello Sverker, > > The patch indeed solved the mentioned bug and, since our app evidently > made heavy use of this function, it works perfectly right now. > Thank you very much for the (very) swift response and help. > > One final question, will this patch make it to any upcoming Erlang > release? That would avoid the need to patch big.c on every deployment > machine. > > Thanks again, > > Diego > > On 20/02/12 10:01, Sverker Eriksson wrote: >> Here is a preliminary source patch: >> >> diff --git a/erts/emulator/beam/big.c b/erts/emulator/beam/big.c >> index 976f05c..8848741 100644 >> --- a/erts/emulator/beam/big.c >> +++ b/erts/emulator/beam/big.c >> @@ -1867,9 +1867,12 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int >> xsgn, Eterm *r) >> d = 0; >> for(i = xsz; --i >= 0;) >> d = (d << 8) | xp[i]; >> + if (++rsz == 1 && IS_USMALL(xsgn,d)) { >> + if (xsgn) d = -d; >> + return make_small(d); >> + } >> *rwp = d; >> rwp++; >> - rsz++; >> } >> return big_norm(r, rsz, (short) xsgn); >> } >> >> >> Sverker Eriksson wrote: >>> Hi Diego, >>> >>> Thanks for the exemplary test code to provoke the bug. I get the >>> same crash on my 64-bit machine. >>> >>> I think I found what it is. To be continued on Monday... >>> >>> /Sverker, Erlang/OTP, Ericsson >>> >>> Diego Llarrull wrote: >>>> Hello everyone, >>>> >>>> I'm currently developing a distributed store written entirely in >>>> Erlang, and we are having a somewhat awkward problem: the app runs >>>> fine in 32-bit Erlang VMs but ALWAYS crashes in 64-bit Erlang VMs. >>>> We've tested 64-bit Erlang VMs running on Linux (XUbuntu >>>> 11.04/Fedora 15) 64-bit, OS X Lion 64-bit, and FreeBSD 8.2 64-bit >>>> with exactly the same result: a segmentation fault as soon as we >>>> try to >>>> to use the store. >>>> >>>> We managed to track down one bug, which was caused by inserting the >>>> same record twice, on a compressed, named ETS table with bag >>>> implementation. This causes, inexplicably, a segmentation fault which >>>> is solved my changing the Ets table to a set. >>>> >>>> >>>> To replicate the bug, the following code can be run: >>>> >>>> -module(segviola14). >>>> -compile(export_all). >>>> >>>> init() -> >>>> S = { >>>> {1316110174588445,1316110174588583}, >>>> {1316110174588445,1316110174588590} >>>> }, >>>> DB=ets:new(childName, [named_table, bag, compressed]), >>>> ets:insert(DB, S), io:format("guau!~n"), >>>> ets:insert(DB, S), io:format("guau!~n"). >>>> >>>> The output for this code is: >>>> >>>>> segviola14:init(). >>>> guau! >>>> Segmentation fault (core dumped) >>>> >>>> >>>> In 32-bit Erlang VMs this code works just fine. We are, however, >>>> having segmentation faults throught our code that make us think the >>>> bug affects a core area of the VM-code. 32-bit Erlang showed >>>> none of these problems, with everything running fine. >>>> >>>> Any ideas? >>>> >>>> Thank you all in advance. >>>> >>>> >>>> Diego >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> 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 onlyafly@REDACTED Thu Feb 23 13:47:57 2012 From: onlyafly@REDACTED (Kevin Albrecht) Date: Thu, 23 Feb 2012 13:47:57 +0100 Subject: [erlang-bugs] Compile time concatenation of strings fails when they contain Unicode literals Message-ID: Compile time concatenation of string literals fails with a syntax error when they contain Unicode literals. Try the following on the Erlang shell or in a source file: "a" "b". => "ab" "a" "b\x{a740}". => * 1: syntax error before: '[' Regards, Kevin Albrecht http://www.kevinalbrecht.com/ From heinz@REDACTED Sat Feb 25 23:57:23 2012 From: heinz@REDACTED (Heinz N. Gies) Date: Sat, 25 Feb 2012 23:57:23 +0100 Subject: [erlang-bugs] erl nif utf8 bug Message-ID: <34E0FFB9-043B-4BFB-90FC-3E7DDA3393BC@licenser.net> I noticed that the nif functions in erlang don't handle utf8/16 correctly https://github.com/Licenser/erlniftest is an example of the problem. Regards, Heinz -- Heinz N. Gies heinz@REDACTED http://licenser.net From paul.joseph.davis@REDACTED Sun Feb 26 00:17:50 2012 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sat, 25 Feb 2012 17:17:50 -0600 Subject: [erlang-bugs] erl nif utf8 bug In-Reply-To: <34E0FFB9-043B-4BFB-90FC-3E7DDA3393BC@licenser.net> References: <34E0FFB9-043B-4BFB-90FC-3E7DDA3393BC@licenser.net> Message-ID: Couple things wrong here. Firstly, enif_inspect_iolist_as_binary is akin to iolist_to_binary. Specifically, it doesn't do any conversions from Unicode code points to binary. To see that in action: Eshell V5.8.5 (abort with ^G) 1> iolist_to_binary([910275]). ** exception error: bad argument in function iolist_to_binary/1 called as iolist_to_binary([910275]) The actual error here is that you're not checking return codes. enif_inspect_iolist_as_binary is returning an error that you're ignoring. Quick diff is: diff --git a/c_src/mymodule.c b/c_src/mymodule.c index af311d2..23c9bfc 100644 --- a/c_src/mymodule.c +++ b/c_src/mymodule.c @@ -33,7 +33,9 @@ static ERL_NIF_TERM mymodule_nif_bin_size(ErlNifEnv* env, int const ERL_NIF_TERM argv[]) { ErlNifBinary bin; - enif_inspect_iolist_as_binary(env, argv[1], &bin); + if(!enif_inspect_iolist_as_binary(env, argv[1], &bin)) { + return enif_make_badarg(env); + } return enif_make_int(env, bin.size); } On Sat, Feb 25, 2012 at 4:57 PM, Heinz N. Gies wrote: > I noticed that the nif functions in erlang don't handle utf8/16 correctly > > https://github.com/Licenser/erlniftest is an example of the problem. > > Regards, > Heinz > -- > Heinz N. Gies > heinz@REDACTED > http://licenser.net > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From paul.joseph.davis@REDACTED Sun Feb 26 01:50:57 2012 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sat, 25 Feb 2012 18:50:57 -0600 Subject: [erlang-bugs] erl nif utf8 bug In-Reply-To: <8CC60A68-7657-4473-9FB7-480DF99756C8@licenser.net> References: <34E0FFB9-043B-4BFB-90FC-3E7DDA3393BC@licenser.net> <8CC60A68-7657-4473-9FB7-480DF99756C8@licenser.net> Message-ID: The definition of iolist() is [char(), binary(), iolist()] which your example violates which is demonstrated by snippet I pasted using iolist_to_binary/1. If you check the docs to io:format/2 you'll notice that it accepts arbitrary term()'s not just iolist()'s which is why that works. On Sat, Feb 25, 2012 at 6:36 PM, Heinz N. Gies wrote: > Hi Paul, > thanks for the answer, of cause you are right. Yet I still don't think enif_inspect_iolist_as_binary should throw an error here since the iolist [910275] is a perfectly valid io list. > > 8> io:format("~ts~n", [[910275]]). > ?? (funky utf8 char) > ok > > > > Regards, > Heinz > -- > Heinz N. Gies > heinz@REDACTED > http://licenser.net > > On Feb 26, 2012, at 24:17, Paul Davis wrote: > >> Couple things wrong here. Firstly, enif_inspect_iolist_as_binary is >> akin to iolist_to_binary. Specifically, it doesn't do any conversions >> from Unicode code points to binary. To see that in action: >> >> Eshell V5.8.5 ?(abort with ^G) >> 1> iolist_to_binary([910275]). >> ** exception error: bad argument >> ? ? in function ?iolist_to_binary/1 >> ? ? ? ?called as iolist_to_binary([910275]) >> >> The actual error here is that you're not checking return codes. >> enif_inspect_iolist_as_binary is returning an error that you're >> ignoring. Quick diff is: >> >> diff --git a/c_src/mymodule.c b/c_src/mymodule.c >> index af311d2..23c9bfc 100644 >> --- a/c_src/mymodule.c >> +++ b/c_src/mymodule.c >> @@ -33,7 +33,9 @@ static ERL_NIF_TERM mymodule_nif_bin_size(ErlNifEnv* >> env, int ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const ERL_NIF_TERM >> argv[]) >> { >> ? ErlNifBinary bin; >> - ?enif_inspect_iolist_as_binary(env, argv[1], &bin); >> + ?if(!enif_inspect_iolist_as_binary(env, argv[1], &bin)) { >> + ? ?return enif_make_badarg(env); >> + ?} >> >> ? return enif_make_int(env, bin.size); >> } >> >> On Sat, Feb 25, 2012 at 4:57 PM, Heinz N. Gies wrote: >>> I noticed that the nif functions in erlang don't handle utf8/16 correctly >>> >>> https://github.com/Licenser/erlniftest is an example of the problem. >>> >>> Regards, >>> Heinz >>> -- >>> Heinz N. Gies >>> heinz@REDACTED >>> http://licenser.net >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs > From als@REDACTED Mon Feb 27 03:14:05 2012 From: als@REDACTED (Anthony Shipman) Date: Mon, 27 Feb 2012 13:14:05 +1100 Subject: [erlang-bugs] gen_sctp type spec error Message-ID: <201202271314.05447.als@iinet.net.au> -spec send(Socket, SndRcvInfo, Data) -> ok | {error, Reason} when Socket :: sctp_socket(), SndRcvInfo :: #sctp_sndrcvinfo{}, Data :: binary | iolist(), Reason :: term(). -spec send(Socket, Assoc, Stream, Data) -> ok | {error, Reason} when Socket :: sctp_socket(), Assoc :: #sctp_assoc_change{} | assoc_id(), Stream :: integer(), Data :: binary | iolist(), Reason :: term(). That should be binary() -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From als@REDACTED Mon Feb 27 03:53:59 2012 From: als@REDACTED (Anthony Shipman) Date: Mon, 27 Feb 2012 13:53:59 +1100 Subject: [erlang-bugs] supervisor global type problem (R15B) Message-ID: <201202271353.59072.als@iinet.net.au> The documentation says that a global name can be {global, atom()} via the type sup_name(). But the supervisor code starts a gen_server which accepts {global, term()}. Shouldn't the supervisor accept {global, term()} too? -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From devurandom@REDACTED Mon Feb 27 13:38:28 2012 From: devurandom@REDACTED (Dennis Schridde) Date: Mon, 27 Feb 2012 13:38:28 +0100 Subject: [erlang-bugs] Erlang R14B4 segfaults if /sys/devices/system/node is not readable Message-ID: <266071295.fc9Uf4N8M7@samson> Hello! I am using Erlang on a Gentoo/Hardened system, which restricts several things for security reasons. For example /sys/devices/system/node is only read and traversable (0700) by root, which makes erlexec segfault. I will describe how I reproduce the segfault and attach a backtrace. In the following the directory "otp" refers to "otp_src_R14B04", which was the one I started building Erlang in (the build process also never finishes due to this issue). otp/bootstrap/bin/erl was modified to set: --- ROOTDIR=$ERL_TOP/bootstrap BINDIR=$ERL_TOP/bin/ia64-unknown-linux-gnu --- The script I use to reproduce is: --- export ERL_TOP=`pwd`/otp export PATH=$ERL_TOP/bootstrap/bin:${PATH} echo "run -W +debug_info +warn_exported_vars +warn_missing_spec +warn_untyped_record -oebin misc/hipe_consttab.erl" > gdb.cmd gdb erlc -x gdb.cmd --- The segfault will happen in read_topology at common/erl_misc_utils.c:850. That line reads: nde = readdir(ndir); The issue comes from ndir which is set a few lines before: ndir = opendir(npath); The return value should be checked against NULL, because that is what opendir returns on error - errno will tell the details. It would be nice if you could provide a fallback method in case /sys/devices/system/node cannot be read. If you need any additional information, please ask. Kind regards, Dennis P.S: /sys/devices/system/cpu is readable by every user, so you could directly fallback to that. The fix would then be to replace following code, starting from line 836: if (realpath(ERTS_SYS_NODE_PATH, npath)) { got_nodes = 1; ndir = opendir(npath); } with: if (realpath(ERTS_SYS_NODE_PATH, npath)) { ndir = opendir(npath); if (ndir) { got_nodes = 1; } } P.P.S: Does this list silently discard emails from non-subscribers? I did not receive a is-in-moderation-queue confirmation when first sending this email while not being subscribed... -------------- next part -------------- process 13252 is executing new program: /bin/bash process 13252 is executing new program: ...otp/bin/ia64-unknown-linux-gnu/erlexec Program received signal SIGSEGV, Segmentation fault. 0x200004255b3143e0 in ?? () (gdb) bt full #0 0x200004255b3143e0 in ?? () No symbol table info available. #1 0x400007e64b577f80 in read_topology (cpuinfo=0x400007e64b5b1ba0) at common/erl_misc_utils.c:850 node_id = -1 npath = "/sys/devices/system/node", '\000' cpath = '\000' tpath = "cpu 169776 0 21892 550684 14211 123 524 0 0\ncpu0 58314 0 10054 300175 9556 123 396 0 0\ncpu1 111462 0 11838 250509 4655 0 128 0 0\nintr 1276499 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6"... fpath = '\000' , "\b-XK\346\a\000@", '\000' "\200, '\000\000\000\000\000\364V'\000\000\000\000\000\364V'", '\000' , "\005\000\000\000\000\000\000\000\000@(\000\000\000\000\000\000\300(\000\000\000\000\000\260\236(\000\000\000\000\000\000\347(\000\000\000\000\000\000@'\000\000\000\000\000\003", '\000' , "\f\000\000\000\000\000\300\312\v\000\000\000\000\000\300\312\v", '\000' , "\005\000\000\000\000\000\000\000\000\300\f\000\000\000\000\000\000\000\r\000\000\000\000\000\244\322\f\000\000\000\000\000\340\322\f\000\000\000\000\000\000\300\v\000\000\000\000\000\003", '\000' "\350, \330\016[%\004\000 ", '\000' , " \324"... ndir = 0x0 cdir = 0x0 nde = 0x0 ix = -1 res = 0 got_nodes = 1 no_nodes = 0 #2 0x400007e64b575260 in erts_cpu_info_update (cpuinfo=0x400007e64b5b1ba0) at common/erl_misc_utils.c:414 changed = 1 configured = 2 online = 2 available = 2 old_topology = 0x0 old_topology_size = 0 cpuset = {__bits = {3, 0 }} #3 0x400007e64b5745b0 in erts_cpu_info_create () at common/erl_misc_utils.c:232 cpuinfo = 0x400007e64b5b1ba0 #4 0x400007e64b566ea0 in main (argc=25, argv=0x60000ddcbe16fc48) at ./erlexec.c:458 haltAfterwards = 0 isdistributed = 0 no_epmd = 0 i = 1 s = 0x0 epmd_prog = 0x0 malloc_lib = 0x60000ddcbe16fb70 "" process_args = 1 print_args_exit = 0 print_qouted_cmd_exit = 0 cpuinfo = 0x0 emu_name = 0x0 reset_cerl_detached = 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sg2342@REDACTED Mon Feb 27 17:52:08 2012 From: sg2342@REDACTED (Stefan Grundmann) Date: Mon, 27 Feb 2012 16:52:08 +0000 Subject: [erlang-bugs] crash in ssl_session:valid_session/2 Message-ID: <20120227165208.7c268c8d@googlemail.com> environment: R14B04 description: the ssl session cache validation process (spawned every minute by the ssl_manager process) will crash and log: Error in process <0.1107.0> on node 'standalone@REDACTED' with exit value: {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} if #session.time_stamp is 'undefined' for an entry in the ssl_otp_session_cache table. such entries will exist (shortly) in the ssl_opt_session_cache table if a handshake failed with SSL: certify: ./ssl_connection.erl:1646:Fatal error: bad certificate or SSL: certify: ./ssl_connection.erl:1646:Fatal error: unknown ca and possibly others. best regards Stefan Grundmann From attila.r.nohl@REDACTED Mon Feb 27 20:47:34 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 27 Feb 2012 20:47:34 +0100 Subject: [erlang-bugs] crash in ssl_session:valid_session/2 In-Reply-To: <20120227165208.7c268c8d@googlemail.com> References: <20120227165208.7c268c8d@googlemail.com> Message-ID: 2012/2/27, Stefan Grundmann : > environment: R14B04 > > description: > > the ssl session cache validation process (spawned every minute by the > ssl_manager process) will crash and log: > > Error in process <0.1107.0> on node 'standalone@REDACTED' with exit value: > {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} > > if #session.time_stamp is 'undefined' for an entry in the > ssl_otp_session_cache table. > > such entries will exist (shortly) in the ssl_opt_session_cache table if > a handshake failed with > > SSL: certify: ./ssl_connection.erl:1646:Fatal error: bad certificate > or > SSL: certify: ./ssl_connection.erl:1646:Fatal error: unknown ca > and possibly others. I think this was fixed in R15B. From ingela@REDACTED Tue Feb 28 09:12:24 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 28 Feb 2012 09:12:24 +0100 Subject: [erlang-bugs] crash in ssl_session:valid_session/2 In-Reply-To: <20120227165208.7c268c8d@googlemail.com> References: <20120227165208.7c268c8d@googlemail.com> Message-ID: <4F4C8C68.6000309@erix.ericsson.se> Hi! This is a known bug that was fixed in ssl-5.0 (R15B) 1.1 SSL 5.0 Fixed Bugs and Malfunctions Invalidation handling of sessions could cause the time_stamp field in the session record to be set to undefined crashing the session clean up process. This did not affect the connections but would result in that the session table would grow. [...] Regards Ingela Erlang/OTP team - Ericsson AB Stefan Grundmann wrote: > environment: R14B04 > > description: > > the ssl session cache validation process (spawned every minute by the > ssl_manager process) will crash and log: > > Error in process <0.1107.0> on node 'standalone@REDACTED' with exit value: > {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} > > if #session.time_stamp is 'undefined' for an entry in the > ssl_otp_session_cache table. > > such entries will exist (shortly) in the ssl_opt_session_cache table if > a handshake failed with > > SSL: certify: ./ssl_connection.erl:1646:Fatal error: bad certificate > or > SSL: certify: ./ssl_connection.erl:1646:Fatal error: unknown ca > and possibly others. > > > > best regards > > Stefan Grundmann > > > > > > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From tuncer.ayaz@REDACTED Wed Feb 29 14:34:58 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 29 Feb 2012 14:34:58 +0100 Subject: [erlang-bugs] escript: interesting stack trace In-Reply-To: References: Message-ID: On Wed, Feb 1, 2012 at 6:59 PM, Tuncer Ayaz wrote: > Running the following (simplified) erroneous piece of code as part > of the rebar binary, a tiny escript, or erl shell gives mostly easy > to follow stack traces. > > lists:append([{a,[b]},{c,[d]}]). > > I was only surprised to see win32reg:expand/1 on Linux and Darwin. > Is this expected behaviour? > > The different stack traces are: > > as part of the rebar binary > $ rebar compile > {'EXIT',{badarg,[{erlang,memory,0,[]}, > ? ? ? ? ? ? ? ? {escript,run,2,[]}, > ? ? ? ? ? ? ? ? {escript,start,1,[]}, > ? ? ? ? ? ? ? ? {erlang,memory,0,[]}]}} > > on the erl shell > $ erl > 1> lists:append([{a,[b]},{c,[d]}]). > ** exception error: bad argument > ? ? in function ?erl_eval:do_apply/6 > ? ? in call from shell:exprs/7 > ? ? in call from shell:eval_exprs/7 > ? ? in call from shell:eval_loop/3 > ? ? in call from erlang:memory/0 > > trivial escript > $ cat append1.escript > #!/usr/bin/env escript > main(_) -> > ? ?lists:append([{a,[b]},{c,[d]}]). > $ ./append1.escript > escript: exception error: bad argument > ?in function ?erl_eval:local_func/5 > ?in call from escript:interpret/4 > ?in call from escript:start/1 > ?in call from win32reg:expand/1 > > trivial escript in compile mode > $ cat append2.escript > #!/usr/bin/env escript > -mode(compile). > main(_) -> > ? ?lists:append([{a,[b]},{c,[d]}]). > $ ./append2.escript > escript: exception error: bad argument > ?in function ?escript:run/2 > ?in call from escript:start/1 > ?in call from win32reg:expand/1 Seems to be fixed with otp.git OTP_R15B-415-gcc3122a (maint 15B01): %% with non-native compiled escript.beam $ ./append1.escript escript: exception error: bad argument in function erl_eval:local_func/5 in call from prim_file:write/2 $ ./append2.escript escript: exception error: bad argument in function prim_file:write/2 %% with native compiled escript.beam $ ./append1.escript escript: exception error: bad argument in function erl_eval:local_func/5 in call from escript:interpret/4 in call from escript:start/1 in call from prim_file:write/2 $ ./append2.escript escript: exception error: bad argument in function escript:run/2 in call from escript:start/1 in call from prim_file:write/2