From mikpelinux@REDACTED Fri Jan 2 12:42:15 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 2 Jan 2015 12:42:15 +0100 Subject: [erlang-bugs] Different handling of floating point underflows between Linux and Solaris-based OSes In-Reply-To: References: <21661.41965.287800.995905@gargle.gargle.HOWL> Message-ID: <21670.33815.132767.905377@gargle.gargle.HOWL> Corey Cossentino writes: > OK, finished running the tests on an OmniOS virtual machine. I'm not > completely sure how to interpret the results, but it looks like a lot > of tests are failing, in both the patched and unpatched version. > > The differences I can see between the two runs, based on the > index.html file that was generated: > tests.common_test_test - went from 1 failure to 3 with the code change > tests.tools_test - went from 1 failure to 2 with the code change > > Is there a file I should send over that would give more information? I don't remember exactly how the test suite results are logged, but if you could a) double-check that the failures are consistent (i.e., not Heisenbugs), and b) list the test cases that fail with the patch, and whatever output they produced that might indicate why they failed that'd be good. My guess is that the matherr() interface still needs to set the "pending exception" flag for some cases, presumably functions that otherwise return HUGE not HUGE_VAL and therefore don't get caught by the isfinite() check. If you need a quick workaround for the exceptions, you can rebuild otp with --disable-fp-exceptions; that will have the same effect as the patch, but as your test suite results show, support for your Solaris derivative may be slightly inadequate. /Mikael > > On Fri, Dec 26, 2014 at 1:07 PM, Mikael Pettersson wrote: > > Corey Cossentino writes: > > > I sent this yesterday but it doesn't look like it went through, so > > > apologies if anyone gets this twice. > > > > > > > > > Calculating math:pow(2, -1075) returns 0 on Linux, but causes an > > > exception on a Solaris-based system. This was causing some crashes in > > > RabbitMQ when it tries to calculate math:exp with inputs less than > > > -745.133. > > > > > > Using OTP 17.4 on OmniOS r151006. > > > > > > -- > > > > > > Erlang/OTP 17 [erts-6.3] [source] [smp:24:24] [async-threads:10] > > > [hipe] [kernel-poll:false] > > > > > > Eshell V6.3 (abort with ^G) > > > 1> math:pow(2, -1074.999). > > > 5.0e-324 > > > 2> math:pow(2, -1074) * math:pow(2, -1). > > > 0.0 > > > 3> math:pow(2, -1075). > > > ** exception error: an error occurred when evaluating an arithmetic > > > expression > > > in function math:pow/2 > > > called as math:pow(2,-1075) > > > 4> math:exp(-745). > > > 5.0e-324 > > > 5> math:exp(-746). > > > ** exception error: an error occurred when evaluating an arithmetic > > > expression > > > in function math:exp/1 > > > called as math:exp(-746) > > > > I can reproduce this on Solaris 10 / SPARC. > > > > I have reviewed the situation with matherr() on Linux/glibc and Solaris 10, > > and I believe a reasonable resolution is to remove the #if !NO_FPE_SIGNALS > > block in matherr(), so it reduces to a single "return 1;". > > > > There are problems with checking math routine results for errors in general, > > and the matherr() interface in particular. > > > > 1. The VM relies on !isfinite() to detect if a math routine failed. > > This appears to work on most systems, but there is a potential problem > > in how various systems and libm implementations behave: while most > > return HUGE_VAL (== INFINITY) on overflows, some return HUGE which is > > a large but finite value. Solaris' cc -Xt does the latter, but gcc on > > Solaris does the former. On my glibc-based Linux systems, matherr(3) > > lists HUGE as the return value on overflows for some routines, but my > > tests indicate that HUGE_VAL is returned instead, which while good is > > inconsistent with parts of the documentation. > > > > It's entirely possible that other libm implementations also return HUGE > > rather than HUGE_VAL on overflows, which thoroughly breaks our !isfinite() > > test. On Linux there are at least 3 non-glibc libc/libm implementations, > > and who knows what's in all those *BSD variants. > > > > 2. matherr(), when properly enabled, is called also in situations the VM does > > not consider to be errors, in particular the underflow case you reported. > > When FP exceptions also are enabled, matherr() sets the FP exception flag, > > causing underflows to erroneously trigger errors. > > > > However, on systems where plain HUGE is returned for overflows, matherr() > > + FP exceptions may be the only viable way of detecting those errors. > > > > 3. As you discovered, matherr() isn't enabled by default on Linux. > > > > As long as we limit ourselves to systems that consistently return HUGE_VAL > > on overflows, as Linux/glibc and Solaris w/ gcc do, we don't need matherr() > > to detect errors, which is why having it just return 1 should be Ok. > > > > Can you run the emulator test suite on your Solaris system, first with > > vanilla 17.4 and then with the proposed code change, and check that the > > test suite results are the same? > > > > /Mikael -- From n.oxyde@REDACTED Sat Jan 3 14:50:14 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 3 Jan 2015 14:50:14 +0100 Subject: [erlang-bugs] inets stand_alone mode In-Reply-To: <53DF524A.2020507@ericsson.com> References: <53D94975.1020107@gmail.com> <53DF524A.2020507@ericsson.com> Message-ID: <0F204248-AF7B-48F7-B745-26A394987223@gmail.com> Le 4 ao?t 2014 ? 11:28, Ingela Anderton Andin a ?crit : > Hi! > > On 07/30/2014 09:37 PM, Michael Truog wrote: >> Hi, >> >> I ran into a problem that exists in 17.1.2 with inets between inets mode >> and stand_along mode with httpc: >> >> This works: >> 1> application:start(inets). >> ok >> 2> inets:start(httpc, [{profile, foobar}], inets). >> {ok,<0.53.0>} >> 3> inets:start(httpc, [{profile, foobar}], inets). >> {error,{already_started,<0.53.0>}} >> >> This is the problem (unable to use a try/catch to get the exit, since >> that is within an inets process): >> 1> inets:start(httpc, [{profile, foobar}], stand_alone). >> {ok,<0.35.0>} >> 2> inets:start(httpc, [{profile, foobar}], stand_alone). > > > You are trying to start the same profile twice that will not work fine. > You can start a profile and then access that profile from different processes, but you can only start a profile once. A profile should be viewed in the same way as an incognito windows in chrome. > > > Regards Ingela Erlang/OTP Team - Ericsson AB > > >> >> =ERROR REPORT==== 30-Jul-2014::12:24:22 === >> ** Generic server <0.35.0> terminating >> ** Last message in was {'EXIT',<0.33.0>, >> {'EXIT', >> {badarg, >> [{ets,new, >> [stand_alone_foobar__session_db, >> [public,set,named_table,{keypos,2}]], >> []}, >> {httpc_manager,do_init,2, >> [{file,"httpc_manager.erl"},{line,421}]}, >> {httpc_manager,init,1, >> [{file,"httpc_manager.erl"},{line,406}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,306}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,239}]}]}}} >> ** When Server state == {state,[],stand_alone_foobar__handler_db, >> {cookie_db,undefined,16402}, >> stand_alone_foobar__session_db,stand_alone_foobar, >> {options, >> {undefined,[]}, >> {undefined,[]}, >> 0,2,5,120000,2,disabled,false,inet,default, >> default,[]}} >> ** Reason for termination == >> ** {'EXIT',{badarg,[{ets,new, >> [stand_alone_foobar__session_db, >> [public,set,named_table,{keypos,2}]], >> []}, >> {httpc_manager,do_init,2, >> [{file,"httpc_manager.erl"},{line,421}]}, >> {httpc_manager,init,1, >> [{file,"httpc_manager.erl"},{line,406}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,306}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,239}]}]}} >> ** exception exit: {'EXIT', >> {badarg, >> [{ets,new, >> [stand_alone_foobar__session_db, >> [public,set,named_table,{keypos,2}]], >> []}, >> {httpc_manager,do_init,2, >> [{file,"httpc_manager.erl"},{line,421}]}, >> {httpc_manager,init,1, >> [{file,"httpc_manager.erl"},{line,406}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,306}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,239}]}]}} >> >> I am not sure if this was a known issue, but it should be a bug, since >> it seems valid that two standalone Erlang processes might use the same >> httpc profile data in ets. >> >> Thanks, >> Michael Still, shouldn't a proper already_started error be returned instead of crashing in the middle of nowhere? Regards, Anthony. From rabbe.fogelholm@REDACTED Tue Jan 13 09:24:46 2015 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Tue, 13 Jan 2015 09:24:46 +0100 Subject: [erlang-bugs] Typo in http://www.erlang.org/doc/man/ssh.html#daemon-3 In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <54B4D64E.9040303@ericsson.com> The page http://www.erlang.org/doc/man/ssh.html#daemon-3 has the phrase "If the subsystems option in not present...." which should be "If the subsystems option is not present...." _______________ Rabbe fogelholm, Ericsson, Stockholm From rabbe.fogelholm@REDACTED Tue Jan 13 09:28:57 2015 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Tue, 13 Jan 2015 09:28:57 +0100 Subject: [erlang-bugs] Missing right curly bracket in http://www.erlang.org/doc/man/ssh.html#daemon-3 In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <54B4D749.2010408@ericsson.com> The page http://www.erlang.org/doc/man/ssh.html#daemon-3 has the line {subsystems, [subsystem_spec()] which ought to be {subsystems, [subsystem_spec()]} _______________ Rabbe fogelholm, Ericsson, Stockholm From henrik@REDACTED Tue Jan 13 11:41:09 2015 From: henrik@REDACTED (Henrik Nord) Date: Tue, 13 Jan 2015 11:41:09 +0100 Subject: [erlang-bugs] Missing right curly bracket in http://www.erlang.org/doc/man/ssh.html#daemon-3 In-Reply-To: <54B4D749.2010408@ericsson.com> References: <53B543D2.9070909@ninenines.eu> <54B4D749.2010408@ericsson.com> Message-ID: <54B4F645.4070701@erlang.org> Thanks! Will fix On 2015-01-13 09:28, Rabbe Fogelholm wrote: > The page > > http://www.erlang.org/doc/man/ssh.html#daemon-3 > > has the line > > {subsystems, [subsystem_spec()] > > which ought to be > > {subsystems, [subsystem_spec()]} > > _______________ > Rabbe fogelholm, Ericsson, Stockholm > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP From marcus@REDACTED Tue Jan 13 10:55:03 2015 From: marcus@REDACTED (Marcus Arendt) Date: Tue, 13 Jan 2015 10:55:03 +0100 Subject: [erlang-bugs] Missing right curly bracket in http://www.erlang.org/doc/man/ssh.html#daemon-3 In-Reply-To: <54B4D749.2010408@ericsson.com> References: <53B543D2.9070909@ninenines.eu> <54B4D749.2010408@ericsson.com> Message-ID: <54B4EB77.5030202@erlang.org> Thanks for reporting! This has now been fixed. regards Marcus On 2015-01-13 09:28, Rabbe Fogelholm wrote: > The page > > http://www.erlang.org/doc/man/ssh.html#daemon-3 > > has the line > > {subsystems, [subsystem_spec()] > > which ought to be > > {subsystems, [subsystem_spec()]} > > _______________ > Rabbe fogelholm, Ericsson, Stockholm > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs On 2015-01-13 09:24, Rabbe Fogelholm wrote:> The page > > http://www.erlang.org/doc/man/ssh.html#daemon-3 > > has the phrase "If the subsystems option in not present...." > > which should be > > "If the subsystems option is not present...." > > _______________ > Rabbe fogelholm, Ericsson, Stockholm > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From louis-philippe.gauthier@REDACTED Wed Jan 14 00:34:43 2015 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Wed, 14 Jan 2015 07:34:43 +0800 Subject: [erlang-bugs] hipe_mfait_lock Message-ID: Hi erlang-bugs, I couple of months ago I tried running our full application using HiPE. I ran into several issues, some manageable, some not... The most problematic issue was due to locking, specifically, the hipe_mfait_lock (you can see the lock counter output in the gist bellow). https://gist.github.com/lpgauth/2b3220f4bceeed6f62d0 Looking at the code it's obvious that this is a known problem... the following comment was added when the lock was added in 2010. "XXX: Redesign apply et al to avoid those updates." https://github.com/erlang/otp/blob/maint/erts/emulator/hipe/hipe_bif0.c#L1218 Unfortunately, I'm don't know the runtime enough to start patching it... so instead I'm reporting it. Thanks, LP -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Wed Jan 14 17:27:22 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 14 Jan 2015 17:27:22 +0100 Subject: [erlang-bugs] hipe_mfait_lock In-Reply-To: References: Message-ID: <54B698EA.9090701@erix.ericsson.se> One quite simple improvement is to change the hipe_mfait_lock to be a read-write mutex (erts_smp_rwmtx_t). And then do read-lock at lookup and exclusive write-lock only when inserting a new entry in the table. I don't think that requires much knowledge about the VM to pull off ;-) . /Sverker, Erlang/OTP On 01/14/2015 12:34 AM, Louis-Philippe Gauthier wrote: > Hi erlang-bugs, > I couple of months ago I tried running our full application using HiPE. I > ran into several issues, some manageable, some not... The most problematic > issue was due to locking, specifically, the hipe_mfait_lock (you can see > the lock counter output in the gist bellow). > > https://gist.github.com/lpgauth/2b3220f4bceeed6f62d0 > > Looking at the code it's obvious that this is a known problem... the > following comment was added when the lock was added in 2010. > > "XXX: Redesign apply et al to avoid those updates." > https://github.com/erlang/otp/blob/maint/erts/emulator/hipe/hipe_bif0.c#L1218 > > Unfortunately, I'm don't know the runtime enough to start patching it... so > instead I'm reporting it. > > Thanks, > LP > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabbe.fogelholm@REDACTED Wed Jan 14 17:52:22 2015 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Wed, 14 Jan 2015 17:52:22 +0100 Subject: [erlang-bugs] Suspicious callback when using an SFTP server-side file handler In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <54B69EC6.70500@ericsson.com> I have set up an SFTP service, using OTP SSH, where I configure a custom ssh_sftpd_file_api module. The service is started with a subsystem_spec() roughly like this: {"sftp", {mySftpd, [{cwd,"/aaa/bbb"}, {root,"/aaa/bbb"}, {file_handler,myStfpdHandler}, {sftpd_vsn,3}]}} The callbacks generally pass paths that are filesystem-absolute. For example, when myStfpdHandler:is_dir/2 is called the passed path may look like "/aaa/bbb/xxx/somefile.txt" This happens when the callback occurs due to an SFTP client call like this, ls /xxx However, if I instead make the following SFTP client command get /xxx/somefile.txt the path passed to is_dir/2 is instead "/xxx/somefile.txt" This path does not make sense? The default callback module calls filelib:is_dir/1 with the passed path, which is bound to be false all the time. So, I suspect that there may be a bug, although not a very serious one: The "get" operation succeeds despite the peculiar call. Anyway, for the passed path to be useful in is_dir/2 it ought to be filesystem-absolute all the time, just like the argument name suggests. _______________ Rabbe fogelholm, Ericsson, Stockholm From louis-philippe.gauthier@REDACTED Thu Jan 15 01:07:14 2015 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Thu, 15 Jan 2015 08:07:14 +0800 Subject: [erlang-bugs] hipe_mfait_lock In-Reply-To: <54B698EA.9090701@erix.ericsson.se> References: <54B698EA.9090701@erix.ericsson.se> Message-ID: Hi Sverker, That's not a bad idea, I'll try that approach! Thanks, LP On Thu, Jan 15, 2015 at 12:27 AM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > One quite simple improvement is to change the hipe_mfait_lock to be a > read-write mutex (erts_smp_rwmtx_t). > And then do read-lock at lookup and exclusive write-lock only when > inserting a new entry in the table. > > I don't think that requires much knowledge about the VM to pull off ;-) . > > /Sverker, Erlang/OTP > > > > > On 01/14/2015 12:34 AM, Louis-Philippe Gauthier wrote: > > Hi erlang-bugs, > I couple of months ago I tried running our full application using HiPE. I > ran into several issues, some manageable, some not... The most problematic > issue was due to locking, specifically, the hipe_mfait_lock (you can see > the lock counter output in the gist bellow). > https://gist.github.com/lpgauth/2b3220f4bceeed6f62d0 > > Looking at the code it's obvious that this is a known problem... the > following comment was added when the lock was added in 2010. > > "XXX: Redesign apply et al to avoid those updates."https://github.com/erlang/otp/blob/maint/erts/emulator/hipe/hipe_bif0.c#L1218 > > Unfortunately, I'm don't know the runtime enough to start patching it... so > instead I'm reporting it. > > Thanks, > LP > > > > > _______________________________________________ > erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabbe.fogelholm@REDACTED Mon Jan 19 08:56:04 2015 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Mon, 19 Jan 2015 08:56:04 +0100 Subject: [erlang-bugs] Typo in http://www.erlang.org/doc/apps/ssh/ssh.pdf In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <54BCB894.3060009@ericsson.com> The document http://www.erlang.org/doc/apps/ssh/ssh.pdf has the mistyped word 'privilages', should be 'privileges', in chapter 1.3.3. Rabbe Fogelholm, Ericsson, Stockholm From marcus@REDACTED Mon Jan 19 09:30:34 2015 From: marcus@REDACTED (Marcus Arendt) Date: Mon, 19 Jan 2015 09:30:34 +0100 Subject: [erlang-bugs] Typo in http://www.erlang.org/doc/apps/ssh/ssh.pdf In-Reply-To: <54BCB894.3060009@ericsson.com> References: <53B543D2.9070909@ninenines.eu> <54BCB894.3060009@ericsson.com> Message-ID: <54BCC0AA.5030504@erlang.org> Thanks! Fixed now. Regards Marcus Erlang/OTP On 2015-01-19 08:56, Rabbe Fogelholm wrote: > The document > > http://www.erlang.org/doc/apps/ssh/ssh.pdf > > has the mistyped word 'privilages', should be 'privileges', > in chapter 1.3.3. > > Rabbe Fogelholm, Ericsson, Stockholm > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From nico.kruber@REDACTED Tue Jan 20 14:24:30 2015 From: nico.kruber@REDACTED (Nico Kruber) Date: Tue, 20 Jan 2015 14:24:30 +0100 Subject: [erlang-bugs] Common Test problems with includes since 17.4 Message-ID: <5534528.FObQ9azk4v@csr-pc40.zib.de> Since Erlang 17.4 Common Test seems to have problems with included .hrl files outside of the folder the unit test resides in (even when passing the appropriate "include" option). The make process succeeds but when the test is actually run, a badarg is thrown: EXIT, reason {{badarg,{tree,macro,{attr,0,[],none},{macro, {var,0,'RT'},none}}}, [{erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6188}]}, {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}, {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6159}]}, {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}]} == Steps to reproduce === * copy the attached test_SUITE.erl into a test folder and put test_SUITE.hrl into a sub-folder named "include" * run any of these two commands: ct_run -include "include" -suite test_SUITE CT_INCLUDE_PATH=include ct_run -suite test_SUITE => if the .hrl file is put into the test folder, everything is fine though Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: test_SUITE.erl Type: text/x-erlang Size: 202 bytes Desc: not available URL: -------------- next part -------------- -define(RT, rt_chord). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From daniel.goertzen@REDACTED Tue Jan 20 22:52:40 2015 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 20 Jan 2015 15:52:40 -0600 Subject: [erlang-bugs] system_info(nif_version) does not work Message-ID: The documentation at... http://www.erlang.org/doc/man/erlang.html#system_info-1 ... says I can get nif version information with erlang:system_info(nif_version). This does not work. See output below: $ erl Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0.1 (abort with ^G) 1> erlang:system_info(nif_version). ** exception error: bad argument in function erlang:system_info/1 called as erlang:system_info(nif_version) 2> I need nif version information because I am looking at NIF modules written in Rust. I will run a short escript to collect config information for the Rust build. As a work around I will look at other version information available though system_info() and make inferences about the NIF major/minor numbers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Tue Jan 20 23:25:53 2015 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 20 Jan 2015 17:25:53 -0500 Subject: [erlang-bugs] system_info(nif_version) does not work In-Reply-To: References: Message-ID: On Tue, Jan 20, 2015 at 4:52 PM, Daniel Goertzen wrote: > The documentation at... > > http://www.erlang.org/doc/man/erlang.html#system_info-1 > > ... says I can get nif version information with > erlang:system_info(nif_version). This does not work. See output below: > > > > $ erl > Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.0.1 (abort with ^G) > 1> erlang:system_info(nif_version). > ** exception error: bad argument > in function erlang:system_info/1 > called as erlang:system_info(nif_version) > 2> > > Looks like this was added for 17.4. I tried it on 17.3 just to be sure, and got the same failure you did. But for 17.4: $ erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false] Eshell V6.3 (abort with ^G) 1> erlang:system_info(nif_version). "2.7" --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Wed Jan 21 10:44:53 2015 From: peppe@REDACTED (Peter Andersson) Date: Wed, 21 Jan 2015 10:44:53 +0100 Subject: [erlang-bugs] Common Test problems with includes since 17.4 In-Reply-To: <5534528.FObQ9azk4v@csr-pc40.zib.de> References: <5534528.FObQ9azk4v@csr-pc40.zib.de> Message-ID: <54BF7515.2090308@erlang.org> Thanks for the report Nico. I'll take a look at this and get back to you asap. Best, Peter Ericsson AB, Erlang/OTP On 2015-01-20 14:24, Nico Kruber wrote: > Since Erlang 17.4 Common Test seems to have problems with included .hrl files > outside of the folder the unit test resides in (even when passing the > appropriate "include" option). The make process succeeds but when the test is > actually run, a badarg is thrown: > > EXIT, reason {{badarg,{tree,macro,{attr,0,[],none},{macro, > {var,0,'RT'},none}}}, > [{erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6188}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6159}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}]} > > == Steps to reproduce === > > * copy the attached test_SUITE.erl into a test folder and put test_SUITE.hrl > into a sub-folder named "include" > * run any of these two commands: > ct_run -include "include" -suite test_SUITE > CT_INCLUDE_PATH=include ct_run -suite test_SUITE > > => if the .hrl file is put into the test folder, everything is fine though > > > > Nico > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Wed Jan 21 13:53:31 2015 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 21 Jan 2015 06:53:31 -0600 Subject: [erlang-bugs] system_info(nif_version) does not work In-Reply-To: References: Message-ID: Oops, I didn't realize this was new. Time for me to update. Sorry for the distraction. Thanks, Dan. On Tue, Jan 20, 2015 at 4:25 PM, Steve Vinoski wrote: > > > On Tue, Jan 20, 2015 at 4:52 PM, Daniel Goertzen < > daniel.goertzen@REDACTED> wrote: > >> The documentation at... >> >> http://www.erlang.org/doc/man/erlang.html#system_info-1 >> >> ... says I can get nif version information with >> erlang:system_info(nif_version). This does not work. See output below: >> >> >> >> $ erl >> Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3] >> [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V6.0.1 (abort with ^G) >> 1> erlang:system_info(nif_version). >> ** exception error: bad argument >> in function erlang:system_info/1 >> called as erlang:system_info(nif_version) >> 2> >> >> > Looks like this was added for 17.4. I tried it on 17.3 just to be sure, > and got the same failure you did. But for 17.4: > > $ erl > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] > [async-threads:10] [kernel-poll:false] > > Eshell V6.3 (abort with ^G) > 1> erlang:system_info(nif_version). > "2.7" > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.kruber@REDACTED Wed Jan 21 15:19:30 2015 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 21 Jan 2015 15:19:30 +0100 Subject: [erlang-bugs] Erlang problems with big binaries Message-ID: <3387692.DfdkJuKrSd@csr-pc40.zib.de> I'd like to 'bor' (binary or) a big binary but the result is an empty list(?!) Smaller binaries work as expected. Steps to reproduce (at least on Erlang 17.4): A=erlang:term_to_binary(lists:seq(1000000,2200000)). B=erlang:term_to_binary(lists:seq(1000001,2200001)). ASize=erlang:bit_size(A). BSize=erlang:bit_size(B). <> = A. <> = B. XNr = ANr bor BNr. <>. Please note that printing the actual values of A or B is not a good idea ;) and so would XNr but including it directly into a binary fails with the same error: "** exception error: bad argument" <<(ANr bor BNr):BSize>>. Regards Nico Kruber -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From mikpelinux@REDACTED Wed Jan 21 16:45:57 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 21 Jan 2015 16:45:57 +0100 Subject: [erlang-bugs] Erlang problems with big binaries In-Reply-To: <3387692.DfdkJuKrSd@csr-pc40.zib.de> References: <3387692.DfdkJuKrSd@csr-pc40.zib.de> Message-ID: <21695.51637.878061.191990@gargle.gargle.HOWL> Nico Kruber writes: > I'd like to 'bor' (binary or) a big binary but the result is an empty list(?!) > Smaller binaries work as expected. > > Steps to reproduce (at least on Erlang 17.4): > > A=erlang:term_to_binary(lists:seq(1000000,2200000)). > B=erlang:term_to_binary(lists:seq(1000001,2200001)). > ASize=erlang:bit_size(A). > BSize=erlang:bit_size(B). > <> = A. > <> = B. > XNr = ANr bor BNr. > <>. > > > Please note that printing the actual values of A or B is not a good idea ;) > and so would XNr but including it directly into a binary fails with the same > error: "** exception error: bad argument" > <<(ANr bor BNr):BSize>>. I can confirm the [] result, in both 17.4 and r15b03-1. Running these steps in a debug-enabled otp 17.4 on x86_64 results in: 7> XNr = ANr bor BNr. beam/erl_arith.c:1078:erts_bor() Assertion failed: ((arg1) != ((~((Uint) 0) << 6) | ((0x3 << 4) | ((0x2 << 2) | 0x3)))) Abort so the [] result is probably due to insufficient type checking. I'll take a look, unless someone beats me to it. From mikpelinux@REDACTED Wed Jan 21 19:13:26 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 21 Jan 2015 19:13:26 +0100 Subject: [erlang-bugs] Erlang problems with big binaries In-Reply-To: <3387692.DfdkJuKrSd@csr-pc40.zib.de> References: <3387692.DfdkJuKrSd@csr-pc40.zib.de> Message-ID: <21695.60486.701770.770429@gargle.gargle.HOWL> Nico Kruber writes: > I'd like to 'bor' (binary or) a big binary but the result is an empty list(?!) > Smaller binaries work as expected. > > Steps to reproduce (at least on Erlang 17.4): > > A=erlang:term_to_binary(lists:seq(1000000,2200000)). > B=erlang:term_to_binary(lists:seq(1000001,2200001)). > ASize=erlang:bit_size(A). > BSize=erlang:bit_size(B). > <> = A. > <> = B. > XNr = ANr bor BNr. > <>. > > > Please note that printing the actual values of A or B is not a good idea ;) > and so would XNr but including it directly into a binary fails with the same > error: "** exception error: bad argument" > <<(ANr bor BNr):BSize>>. The problem is that erts/emulator/beam/big.c:big_norm() contains: if ((arity = BIG_NEED_SIZE(xl)-1) > BIG_ARITY_MAX) return NIL; /* signal error (too big) */ where BIG_ARITY_MAX is 0x7ffff, but: 1) this is an implementation restriction which can, as this case proves, be exceeded by simple application code, and 2) erts_{band,bor,bxor}() check for this with ASSERT(is_not_nil(...)), but that's wrong since this is about input validation and implementation limits not fundamental logic, and it's ineffective for release builds. These three functions need to turn this case into a system limit exception, just like a lot of other places in erl_arith.c already do. (Well, at least _bor() and _bxor() do, perhaps _band() doesn't need to.) /Mikael From mikpelinux@REDACTED Wed Jan 21 19:28:30 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 21 Jan 2015 19:28:30 +0100 Subject: [erlang-bugs] Erlang problems with big binaries In-Reply-To: <21695.60486.701770.770429@gargle.gargle.HOWL> References: <3387692.DfdkJuKrSd@csr-pc40.zib.de> <21695.60486.701770.770429@gargle.gargle.HOWL> Message-ID: <21695.61390.931602.148032@gargle.gargle.HOWL> Mikael Pettersson writes: > Nico Kruber writes: > > I'd like to 'bor' (binary or) a big binary but the result is an empty list(?!) > > Smaller binaries work as expected. > > > > Steps to reproduce (at least on Erlang 17.4): > > > > A=erlang:term_to_binary(lists:seq(1000000,2200000)). > > B=erlang:term_to_binary(lists:seq(1000001,2200001)). > > ASize=erlang:bit_size(A). > > BSize=erlang:bit_size(B). > > <> = A. > > <> = B. > > XNr = ANr bor BNr. > > <>. > > > > > > Please note that printing the actual values of A or B is not a good idea ;) > > and so would XNr but including it directly into a binary fails with the same > > error: "** exception error: bad argument" > > <<(ANr bor BNr):BSize>>. > > The problem is that erts/emulator/beam/big.c:big_norm() contains: > > if ((arity = BIG_NEED_SIZE(xl)-1) > BIG_ARITY_MAX) > return NIL; /* signal error (too big) */ > > where BIG_ARITY_MAX is 0x7ffff, but: > > 1) this is an implementation restriction which can, as this > case proves, be exceeded by simple application code, and > > 2) erts_{band,bor,bxor}() check for this with ASSERT(is_not_nil(...)), > but that's wrong since this is about input validation and implementation > limits not fundamental logic, and it's ineffective for release builds. > > These three functions need to turn this case into a system limit > exception, just like a lot of other places in erl_arith.c already do. > (Well, at least _bor() and _bxor() do, perhaps _band() doesn't need to.) Actually, it's worse than I thought. Observe: 1> A=erlang:term_to_binary(lists:seq(1000000,2200000)). <<131,108,0,18,79,129,98,0,15,66,64,98,0,15,66,65,98,0,15, 66,66,98,0,15,66,67,98,0,15,...>> 2> ASize=erlang:bit_size(A). 48000096 3> <> = A. <<131,108,0,18,79,129,98,0,15,66,64,98,0,15,66,65,98,0,15, 66,66,98,0,15,66,67,98,0,15,...>> 4> ANr band ANr. big_norm: xl 750002 arity 0xb71b2 > 0x7ffff beam/erl_arith.c:1050:erts_band() Assertion failed: ((arg1) != ((~((Uint) 0) << 6) | ((0x3 << 4) | ((0x2 << 2) | 0x3)))) Abort So band:ing a bignum with itself (which by definition requires no more bits than the input bignum) triggers the limit check. I also get errors for trivial ops like ANr - 1. Looks like <> = A can construct invalid bignums. From eric.pailleau@REDACTED Wed Jan 21 19:49:07 2015 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Wed, 21 Jan 2015 19:49:07 +0100 Subject: [erlang-bugs] system_info(nif_version) does not work Message-ID: <6ixk0dqw1wx0vs2j1782ofdo.1421866147513@email.android.com> Hi, not really a distraction, but a very common problem. As I already wrote in a former mail, documentation do not give the first version where a function or a function argument is available. was not really a problem in the past when API was stable, but now a concern with functions inflation. it might be clever, in addition of -spec , a -since or somewhat. This way it would be easier to a tool, dialyzer or other to say what is the minimal erlang version needed by the code. A big work, but could be done by community, I guess. MHO. ? Envoy? depuis mon mobile ? Eric Daniel Goertzen a ?crit?: >Oops, I didn't realize this was new. Time for me to update. Sorry for the >distraction. > >Thanks, >Dan. > >On Tue, Jan 20, 2015 at 4:25 PM, Steve Vinoski wrote: > >> >> >> On Tue, Jan 20, 2015 at 4:52 PM, Daniel Goertzen < >> daniel.goertzen@REDACTED> wrote: >> >>> The documentation at... >>> >>> http://www.erlang.org/doc/man/erlang.html#system_info-1 >>> >>> ... says I can get nif version information with >>> erlang:system_info(nif_version). This does not work. See output below: >>> >>> >>> >>> $ erl >>> Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3] >>> [async-threads:10] [hipe] [kernel-poll:false] >>> >>> Eshell V6.0.1 (abort with ^G) >>> 1> erlang:system_info(nif_version). >>> ** exception error: bad argument >>> in function erlang:system_info/1 >>> called as erlang:system_info(nif_version) >>> 2> >>> >>> >> Looks like this was added for 17.4. I tried it on 17.3 just to be sure, >> and got the same failure you did. But for 17.4: >> >> $ erl >> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] >> [async-threads:10] [kernel-poll:false] >> >> Eshell V6.3 (abort with ^G) >> 1> erlang:system_info(nif_version). >> "2.7" >> >> --steve >> > >_______________________________________________ >erlang-bugs mailing list >erlang-bugs@REDACTED >http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Wed Jan 21 22:59:10 2015 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 21 Jan 2015 22:59:10 +0100 Subject: [erlang-bugs] system_info(nif_version) does not work In-Reply-To: <6ixk0dqw1wx0vs2j1782ofdo.1421866147513@email.android.com> References: <6ixk0dqw1wx0vs2j1782ofdo.1421866147513@email.android.com> Message-ID: <54C0212E.6010202@wanadoo.fr> Thinking to this ... -since erlang:system_info(nif_version) -> "17.4". -spec erlang:system_info (allocated_areas) -> [ tuple() ]; snip --- snip (nif_version) -> string(); snip --- snip (wordsize | {wordsize, internal} | {wordsize, external}) -> 4 | 8. This could also be pickup by doc generation, BTW... Le 21/01/2015 19:49, Eric Pailleau a ?crit : > Hi, > not really a distraction, but a very common problem. As I already wrote > in a former mail, documentation do not give the first version where a > function or a function argument is available. was not really a problem > in the past when API was stable, but now a concern with functions inflation. > it might be clever, in addition of -spec , a -since or somewhat. > This way it would be easier to a tool, dialyzer or other to say what is > the minimal erlang version needed by the code. A big work, but could be > done by community, I guess. > MHO. From peppe@REDACTED Wed Jan 21 23:54:48 2015 From: peppe@REDACTED (Peter Andersson) Date: Wed, 21 Jan 2015 23:54:48 +0100 Subject: [erlang-bugs] Common Test problems with includes since 17.4 In-Reply-To: <5534528.FObQ9azk4v@csr-pc40.zib.de> References: <5534528.FObQ9azk4v@csr-pc40.zib.de> Message-ID: <54C02E38.9070102@erlang.org> Hi Nico, I know what's causing the error now. There's a problem with some recently introduced code in the erl->html converter in Common Test. We'll have this fixed shortly! Best, Peter Ericsson AB, Erlang/OTP On 2015-01-20 14:24, Nico Kruber wrote: > Since Erlang 17.4 Common Test seems to have problems with included .hrl files > outside of the folder the unit test resides in (even when passing the > appropriate "include" option). The make process succeeds but when the test is > actually run, a badarg is thrown: > > EXIT, reason {{badarg,{tree,macro,{attr,0,[],none},{macro, > {var,0,'RT'},none}}}, > [{erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6188}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6159}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}]} > > == Steps to reproduce === > > * copy the attached test_SUITE.erl into a test folder and put test_SUITE.hrl > into a sub-folder named "include" > * run any of these two commands: > ct_run -include "include" -suite test_SUITE > CT_INCLUDE_PATH=include ct_run -suite test_SUITE > > => if the .hrl file is put into the test folder, everything is fine though > > > > Nico > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.aloi@REDACTED Thu Jan 22 09:01:17 2015 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Thu, 22 Jan 2015 09:01:17 +0100 Subject: [erlang-bugs] Sorting order in documentation page is awkward Message-ID: The following page list Erlang/OTP major releases in ascending order and minor releases in descending order. R16 sits between R7 and R8. http://www.erlang.org/documentation.html May I suggest descending order is used for everything, so that the further you go down in the page, the further in the past you go? Kind regards, Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.kruber@REDACTED Fri Jan 23 12:50:09 2015 From: nico.kruber@REDACTED (Nico Kruber) Date: Fri, 23 Jan 2015 12:50:09 +0100 Subject: [erlang-bugs] Common Test problems with includes since 17.4 In-Reply-To: <54C02E38.9070102@erlang.org> References: <5534528.FObQ9azk4v@csr-pc40.zib.de> <54C02E38.9070102@erlang.org> Message-ID: <15459112.HWeEvvLCd6@nico-pc.lan> Thank you Peter, please tell my when you commit the patch and I'll integrate it into the openSUSE packages so I can run tests again (at the moment I'm symlinking all hrl files from my external include directory into the test directory as a workaround) Nico On Wednesday 21 Jan 2015 23:54:48 Peter Andersson wrote: > Hi Nico, > > I know what's causing the error now. There's a problem with some > recently introduced code in the erl->html converter in Common Test. > We'll have this fixed shortly! > > Best, > Peter > > Ericsson AB, Erlang/OTP > > On 2015-01-20 14:24, Nico Kruber wrote: > > Since Erlang 17.4 Common Test seems to have problems with included .hrl > > files outside of the folder the unit test resides in (even when passing > > the appropriate "include" option). The make process succeeds but when the > > test is actually run, a badarg is thrown: > > > > EXIT, reason {{badarg,{tree,macro,{attr,0,[],none},{macro, > > {var,0,'RT'},none}}}, > > [{erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6188}]}, > > > > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}, > > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6159}]}, > > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > > {erl_syntax,concrete_list,1, [{file,"erl_syntax.erl"},{line,6192}]}, > > {erl_syntax,concrete,1,[{file,"erl_syntax.erl"},{line,6162}]}]} > > > > == Steps to reproduce === > > > > * copy the attached test_SUITE.erl into a test folder and put > > test_SUITE.hrl into a sub-folder named "include" > > * run any of these two commands: > > ct_run -include "include" -suite test_SUITE > > CT_INCLUDE_PATH=include ct_run -suite test_SUITE > > > > => if the .hrl file is put into the test folder, everything is fine though > > > > > > > > Nico > > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From aronisstav@REDACTED Fri Jan 23 14:38:16 2015 From: aronisstav@REDACTED (Stavros Aronis) Date: Fri, 23 Jan 2015 14:38:16 +0100 Subject: [erlang-bugs] erl -make has unexpected return value when it fails Message-ID: Hello! Uncommon as it may be, "erl -make" is a valid way to make small projects that use an Emakefile. However, it can be the case that such a command fails: $ erl -pa ebin -make Recompile: src/packets src/packets.erl:1: parameterized modules are no longer supported src/packets.erl:10: variable 'PacketVer' is unbound Contrary to other 'make' tools, this failure is *not* reflected in the return value of "erl -make": $ echo $? 0 A simple way to fix this would be to add a function (say 'make:all_and_exit/0') which matches the return value of 'make:all/0' and exits with the correct code and also modify erlexec.c to call that function instead of 'make:all/0'. Would such a patch be acceptable? Best regards, Stavros Aronis -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Fri Jan 23 15:14:37 2015 From: magnus@REDACTED (Magnus Henoch) Date: Fri, 23 Jan 2015 14:14:37 +0000 Subject: [erlang-bugs] erl -make has unexpected return value when it fails In-Reply-To: (Stavros Aronis's message of "Fri, 23 Jan 2015 14:38:16 +0100") References: Message-ID: Stavros Aronis writes: > Hello! > > Uncommon as it may be, "erl -make" is a valid way to make small projects > that use an Emakefile. However, it can be the case that such a command > fails: > > $ erl -pa ebin -make > Recompile: src/packets > src/packets.erl:1: parameterized modules are no longer supported > src/packets.erl:10: variable 'PacketVer' is unbound > > Contrary to other 'make' tools, this failure is *not* reflected in the > return value of "erl -make": > > $ echo $? > 0 > > A simple way to fix this would be to add a function (say > 'make:all_and_exit/0') which matches the return value of 'make:all/0' and > exits with the correct code and also modify erlexec.c to call that function > instead of 'make:all/0'. > > Would such a patch be acceptable? I submitted such a patch a while ago, but never heard anything back: http://erlang.org/pipermail/erlang-patches/2009-March/000390.html Feel free to turn it into a pull request :) Regards, Magnus From mikpelinux@REDACTED Sat Jan 24 20:17:05 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 24 Jan 2015 20:17:05 +0100 Subject: [erlang-bugs] Erlang problems with big binaries In-Reply-To: <21695.61390.931602.148032@gargle.gargle.HOWL> References: <3387692.DfdkJuKrSd@csr-pc40.zib.de> <21695.60486.701770.770429@gargle.gargle.HOWL> <21695.61390.931602.148032@gargle.gargle.HOWL> Message-ID: <21699.61361.763074.484148@gargle.gargle.HOWL> Mikael Pettersson writes: > Mikael Pettersson writes: > > Nico Kruber writes: > > > I'd like to 'bor' (binary or) a big binary but the result is an empty list(?!) > > > Smaller binaries work as expected. > > > > > > Steps to reproduce (at least on Erlang 17.4): > > > > > > A=erlang:term_to_binary(lists:seq(1000000,2200000)). > > > B=erlang:term_to_binary(lists:seq(1000001,2200001)). > > > ASize=erlang:bit_size(A). > > > BSize=erlang:bit_size(B). > > > <> = A. > > > <> = B. > > > XNr = ANr bor BNr. > > > <>. > > > > > > > > > Please note that printing the actual values of A or B is not a good idea ;) > > > and so would XNr but including it directly into a binary fails with the same > > > error: "** exception error: bad argument" > > > <<(ANr bor BNr):BSize>>. > > > > The problem is that erts/emulator/beam/big.c:big_norm() contains: > > > > if ((arity = BIG_NEED_SIZE(xl)-1) > BIG_ARITY_MAX) > > return NIL; /* signal error (too big) */ > > > > where BIG_ARITY_MAX is 0x7ffff, but: > > > > 1) this is an implementation restriction which can, as this > > case proves, be exceeded by simple application code, and > > > > 2) erts_{band,bor,bxor}() check for this with ASSERT(is_not_nil(...)), > > but that's wrong since this is about input validation and implementation > > limits not fundamental logic, and it's ineffective for release builds. > > > > These three functions need to turn this case into a system limit > > exception, just like a lot of other places in erl_arith.c already do. > > (Well, at least _bor() and _bxor() do, perhaps _band() doesn't need to.) > > Actually, it's worse than I thought. Observe: > > 1> A=erlang:term_to_binary(lists:seq(1000000,2200000)). > <<131,108,0,18,79,129,98,0,15,66,64,98,0,15,66,65,98,0,15, > 66,66,98,0,15,66,67,98,0,15,...>> > 2> ASize=erlang:bit_size(A). > 48000096 > 3> <> = A. > <<131,108,0,18,79,129,98,0,15,66,64,98,0,15,66,65,98,0,15, > 66,66,98,0,15,66,67,98,0,15,...>> > 4> ANr band ANr. > big_norm: xl 750002 arity 0xb71b2 > 0x7ffff > beam/erl_arith.c:1050:erts_band() Assertion failed: ((arg1) != ((~((Uint) 0) << 6) | ((0x3 << 4) | ((0x2 << 2) | 0x3)))) > Abort > > So band:ing a bignum with itself (which by definition requires no more > bits than the input bignum) triggers the limit check. I also get errors > for trivial ops like ANr - 1. > > Looks like <> = A can construct invalid bignums. In the general case, this calls erl_bits.c:erts_bs_get_integer_2(), which calls big.c:bytes_to_big(). Nothing here enforces the BIG_ARITY_MAX limit. However, most arithmetic does, via big_norm(). Also, I personally think BIG_ARITY_MAX is way too small -- we can build both tuples and binaries much larger than that. I'm thinking bytes_to_big() needs to mirror big_norm()'s error checking behaviour, and erts_bs_get_integer_2() needs to check for an error return (NIL) from bytes_to_big() and return THE_NON_VALUE in that case (after restoring p->htop). From jose.valim@REDACTED Wed Jan 28 23:04:34 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 28 Jan 2015 23:04:34 +0100 Subject: [erlang-bugs] file:delete/1 is inconsistent across OS Message-ID: file:delete/1 is able to remove read-only files on Mac OS X (and I assume Unix) but it is unable to do so Windows. On Windows, it returns {:error, :eacces}. After manually adding owner write permission to the file, even via Erlang API, I am able delete it on Windows too. Verified on Erlang/OTP 17 [erts-6.3]. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Jan 29 09:14:46 2015 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Thu, 29 Jan 2015 09:14:46 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: Pinging this thread for feedback. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Fri, Jul 4, 2014 at 5:10 PM, Jos? Valim wrote: > Hello everyone, > > I have found the documentation or implementation file:read/2 to be > misleading when working with unicode devices in binary mode. I will use > file:read_line/1 in the examples below but the issue applies to > file:read/2, file:pread/1 and etc. > > $ echo "h?llo" > foo > > $ erl > 1> {ok, F} = file:open("foo", [binary, unicode]). > {ok,<0.34.0>} > 2> {ok, Bin} = file:read_line(F). > {ok,<<"h?llo\n">>} > 3> <>. > <<104,233,108,108,111,10, 0>> > > > Not the result is not the one desired because I expected a binary > containing <<"h?llo\n"/utf8>>, or more explicitly, I expected it to contain > the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 as > result. With char lists, we would get "h?llo\n" but the function will fail > for any codepoint > 255. > > Note this behaviour also happens if I use file:read_line/1 on any other IO > device set to unicode (like standard_io). > > The trouble I have with the function is that it is aimed to byte-oriented > but it only really works for latin1 files. If you have a unicode file, the > behaviour seems to be broken for binaries, and it only works for a limited > range of codepoints when using char lists. > > It is interesting to notice those functions use the old {get_line, Prompt} > messages which, according to the I/O protocol guide > , should not > exist beyond R15B (section 1.3). The same section above suggests to > translate {get_line, Prompt} to {get_line, latin1, Prompt} which seems to > be the root cause of the issues above: those functions were never meant to > work with unicode devices. > > Unless I am terribly wrong, I can think of some ways to fix those > functions: > > 1. Keep its dual aspect of returning bytes and/or characters but fix the > bug when working with unicode. This means the {get_line, Prompt} should > rather translate to {get_line, EncodingOfTheIODevice, Prompt} > > 2. Make them crash if the encoding of the device is not latin1. This means > we translate {get_line, Prompt} to {get_line, latin1, Prompt} only if the > encoding of the device is latin1. > > 3. Make it always work at the byte level, regardless of the encoding of > the IO device. This would require assigning new meaning to the {get_line, > Prompt} message, so I believe it is not going to happen (although it would > be a useful feature in my opinion). > > Given that the original IO messages were never meant to work with unicode, > maybe 2) is the best way to go here. Both 1) and 2) would require a small > amendment to the current I/O protocol advice but I would argue it is > necessary to fix the current limitations/bugs when working with unicode. > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Jan 29 11:04:06 2015 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 29 Jan 2015 11:04:06 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: Hi, I agree that it is difficult to know which functions in 'file' or 'io' to use and if the file should be opened as unicode or not. Without reading the docs in all detail, it's easy to assume that since file:open takes an encoding option, the rest of the functions in the module can handle all encodings. The docs say The rule of thumb is that the file module should be used for files opened for bytewise access ({encoding,latin1}) and the io module should be used when accessing files with any other encoding (e.g. {encoding,uf8}). and using io:get_line/2 works, but maybe the very first step could be to make the note above stand out more proeminently in the docs? Also, a simple step that can be done right away is to let file:read_line return the same error message as firle: read: {error,{no_translation,unicode,latin1}} which describes exactly what the problem is. {error, collect_line} isn't even a documented error message. best regards, Vlad On Thu, Jan 29, 2015 at 9:14 AM, Jos? Valim wrote: > Pinging this thread for feedback. > > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > On Fri, Jul 4, 2014 at 5:10 PM, Jos? Valim < > jose.valim@REDACTED> wrote: > >> Hello everyone, >> >> I have found the documentation or implementation file:read/2 to be >> misleading when working with unicode devices in binary mode. I will use >> file:read_line/1 in the examples below but the issue applies to >> file:read/2, file:pread/1 and etc. >> >> $ echo "h?llo" > foo >> >> $ erl >> 1> {ok, F} = file:open("foo", [binary, unicode]). >> {ok,<0.34.0>} >> 2> {ok, Bin} = file:read_line(F). >> {ok,<<"h?llo\n">>} >> 3> <>. >> <<104,233,108,108,111,10, 0>> >> >> >> Not the result is not the one desired because I expected a binary >> containing <<"h?llo\n"/utf8>>, or more explicitly, I expected it to contain >> the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 as >> result. With char lists, we would get "h?llo\n" but the function will fail >> for any codepoint > 255. >> >> Note this behaviour also happens if I use file:read_line/1 on any other >> IO device set to unicode (like standard_io). >> >> The trouble I have with the function is that it is aimed to byte-oriented >> but it only really works for latin1 files. If you have a unicode file, the >> behaviour seems to be broken for binaries, and it only works for a limited >> range of codepoints when using char lists. >> >> It is interesting to notice those functions use the old {get_line, >> Prompt} messages which, according to the I/O protocol guide >> , should not >> exist beyond R15B (section 1.3). The same section above suggests to >> translate {get_line, Prompt} to {get_line, latin1, Prompt} which seems to >> be the root cause of the issues above: those functions were never meant to >> work with unicode devices. >> >> Unless I am terribly wrong, I can think of some ways to fix those >> functions: >> >> 1. Keep its dual aspect of returning bytes and/or characters but fix the >> bug when working with unicode. This means the {get_line, Prompt} should >> rather translate to {get_line, EncodingOfTheIODevice, Prompt} >> >> 2. Make them crash if the encoding of the device is not latin1. This >> means we translate {get_line, Prompt} to {get_line, latin1, Prompt} only if >> the encoding of the device is latin1. >> >> 3. Make it always work at the byte level, regardless of the encoding of >> the IO device. This would require assigning new meaning to the {get_line, >> Prompt} message, so I believe it is not going to happen (although it would >> be a useful feature in my opinion). >> >> Given that the original IO messages were never meant to work with >> unicode, maybe 2) is the best way to go here. Both 1) and 2) would require >> a small amendment to the current I/O protocol advice but I would argue it >> is necessary to fix the current limitations/bugs when working with unicode. >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkjan@REDACTED Sat Jan 31 10:36:04 2015 From: dirkjan@REDACTED (Dirkjan Ochtman) Date: Sat, 31 Jan 2015 10:36:04 +0100 Subject: [erlang-bugs] =?utf-8?q?Conflicting_types_for_=E2=80=98ethr=5Fnat?= =?utf-8?q?ive=5Fdw=5Fatomic=5Ft=E2=80=99_on_armv7a-hardfloat-linux?= =?utf-8?q?-gnueabi?= Message-ID: Hi there, I'm the package maintainer for Erlang on Gentoo. Recently, I got this bug report: https://bugs.gentoo.org/show_bug.cgi?id=537570 Apparently, with gcc-4.8.4, there's this problem: In file included from ../include/internal/gcc/ethread.h:48:0, from ../include/internal/ethread.h:368, from beam/erl_threads.h:264, from beam/erl_smp.h:27, from beam/sys.h:434, from beam/export.h:24, from armv7a-hardfloat-linux-gnueabi/erl_pbifs.c:9: ../include/internal/gcc/ethr_dw_atomic.h:81:3: error: conflicting types for ?ethr_native_dw_atomic_t? } ethr_native_dw_atomic_t; I looked around the source tree a bit, but since the erl_pbifs.c seems to be generated by a Perl script and my Perl skills aren't so strong, I couldn't really figure out the problem. Cheers, Dirkjan P.S. I'm not subscribed to erlang-bugs, please CC me on any replies.