From lukas@REDACTED Mon Jan 2 12:27:15 2012 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 2 Jan 2012 12:27:15 +0100 Subject: [erlang-bugs] Errors when using file:sendfile/2 In-Reply-To: References: Message-ID: <4F019493.30308@erlang.org> Hello, Thanks for reporting this. The bug does, as Tuncer said, not appear if you run with async-threads. I've identified the issue and I'm working on a solution. While waiting for the fix I recommend all to use async-threads in a VM running sendfile as it is less prone to race-conditions and should be faster. Lukas On 29/12/11 17:26, Magnus Klaar wrote: > Hi! > > I'm encountered the following errors while testing a module using > file:sendfile/2. It appears to be quite rare. 17 errors were logged > for 11000 requests sent to the server. This is using "Erlang R15B > (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] > [kernel-poll:false]" running on "Linux $(hostname) 3.0.0-1-amd64 #1 > SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux". > > =ERROR REPORT==== 29-Dec-2011::16:55:15 === > driver_select(0x000000000000032a, 107, ERL_DRV_READ ERL_DRV_USE, 1) by > tcp_inet driver #Port<0.4906> failed: fd=107 (re)selected before > stop_select was called for driver efile > > > =ERROR REPORT==== 29-Dec-2011::16:55:20 === > driver_select(0x0000000000000069, 106, ERL_DRV_READ ERL_DRV_USE, 1) by > tcp_inet driver #Port<0.5225> failed: fd=106 (re)selected before > stop_select was called for driver efile > > > The code is not merged into the main project yet and test is rather > ad-hoc, I'm defaulting to not providing it unless you specifically ask > for it. Let me know if you need and I'll write a summary for > downloading and running it if the error messages are not informative > enough. > > MVH Magnus > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rene.kijewski@REDACTED Mon Jan 2 23:35:39 2012 From: rene.kijewski@REDACTED (=?UTF-8?B?UmVuw6k=?= Kijewski) Date: Mon, 2 Jan 2012 23:35:39 +0100 Subject: [erlang-bugs] Unclean OTP build directory renders unusable httpc Message-ID: <20120102233539.6333a56c@rara> Hello, today upgraded to R15B (a67091debf20c972dd7ce1a8379fee6673fbe571). Before that httpc worked as expected, i.e. httpc:request("http://example.com/") returned some content. To upgrade I used the following commands: $ git fetch $ git checkout OTP_R15B $ ./otp_build setup -a --prefix=... --enable-threads --enable-smp-support \ $ --enable-kernel-poll --disable-sctp --enable-hipe $ make install in a git directory I previously compiled R14B04 and later R15A in. After upgrading I ran httpc:request("http://example.com/") which did not return. Even with the timeout option set to 1 the command just hang. With enabling httpc's trace, I got the attached information. I guess the important information is: (<0.41.0>) call httpc_manager:handle_info({'DOWN',#Ref<0.0.0.63>,process,<0.49.0>,{badrecord,request}}, {state,[],httpc_manager__handler_db, {cookie_db,undefined,16402}, httpc_manager__session_db,httpc_manager, {options,{undefined,[]}, 0,2,5,120000,2,disabled,trace,inet,default,default,[]}}) With a full build after cleaning the directory with $ git clean -xfd the problem is gone. Nevertheless I think there is something wrong with some Makefile. Best regards and a happy new year, Ren? -- Ren? Kijewski Freie Universit?t Berlin ASCII ribbon campaign _ Veterin?rmedizinische Bibliothek against HTML e-mail ( ) Oertzenweg 19b, 14163 Berlin against proprietary attachments X Tel.: 030 838 62652 www.asciiribbon.org / \ -------------- next part -------------- A non-text attachment was scrubbed... Name: trace.log Type: text/x-log Size: 19418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rene.kijewski@REDACTED Tue Jan 3 23:38:16 2012 From: rene.kijewski@REDACTED (Rene Kijewski) Date: Tue, 3 Jan 2012 23:38:16 +0100 Subject: [erlang-bugs] Unclean OTP build directory renders unusable httpc In-Reply-To: <4F02D9B0.1000402@erix.ericsson.se> References: <20120102233539.6333a56c@rara> <4F02D9B0.1000402@erix.ericsson.se> Message-ID: <20120103233816.10bc5071@lappy-ng.localdomain> Am Tue, 3 Jan 2012 11:34:24 +0100 schrieb Micael Karlberg : > I am not sure if you recompiled "on" a running system, but if so > that is most likely the cause. Hello Micael, no, Erlang was not running while compiling. Regard, Ren? -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From matthias@REDACTED Thu Jan 5 11:13:11 2012 From: matthias@REDACTED (Matthias Lang) Date: Thu, 5 Jan 2012 11:13:11 +0100 Subject: [erlang-bugs] Wrong EXIT status when shell startup fails In-Reply-To: <4EE0C638.7000400@corelatus.se> References: <4EE0C638.7000400@corelatus.se> Message-ID: <20120105101311.GA2514@corelatus.se> Here's a simpler test case: otp_src_R15B >bin/erl < /dev/null Eshell V5.9 (abort with ^G) 1> *** Terminating erlang (nonode@REDACTED) otp_src_R15B >echo $? 0 but that's expected: the shell is not failing, it's reaching eof and exiting normally since there isn't any more input to read, compare: > cat < /dev/null > echo $? 0 (The code which does the normal exit is shell.erl:server_loop()) The usual way to run Erlang with nothing connected to stdin is to pass the -noinput flag. Matt -------------------- On Thursday, December 08, Thomas Lange wrote: > There is a bug that occurs when Erlang is started with shell activated > but shell cannot be launched. When this happens, erlang terminates > with exit status 0, which is incorrect behavior. > > A typical example is when Erlang is started via a cron job. > > How to trigger bug: > > * Put both attached files in /tmp > * update crontest with path to your otp release > * compile crontest.erl > * run /tmp/crontest via cron > * cronjob should fail > > Example on system running debian squeeze and otp git HEAD: > ------------------------------------------ > k4:/tmp$ chmod +x crontest > k4:/tmp$ /u1/otp/bin/erlc crontest.erl > k4:/tmp$ ls -l crontest* > -rwxr-xr-x 1 tle tle 681 Dec 8 14:42 crontest > -rw-r--r-- 1 tle tle 536 Dec 8 14:45 crontest.beam > -rw-r--r-- 1 tle tle 83 Dec 8 14:42 crontest.erl > k4:/tmp$ ./crontest > Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> Erlang exit status 100. Normal result when everything is started ok. > > k4:/tmp$ crontab -e > crontab: installing new crontab > k4:/tmp$ crontab -l > # m h dom mon dow command > 47 14 * * * /tmp/crontest > > Syslog: > Dec 8 14:47:02 k4 /USR/SBIN/CRON[27923]: (CRON) error (grandchild #27924 failed with exit status 1) > > Cron daemon error mail contains: > ---------------- > Eshell V5.9 (abort with ^G) > 1> *** Terminating erlang (nonode@REDACTED) > Erlang exit status 0. Should never happen! > ---------------- > > /Thomas > -module(crontest). > > -export([go/0]). > > go() -> > timer:sleep(500), > halt(100). > #!/bin/sh > # Author: thomas@REDACTED > # Exercises an erlang bug when running this script via cron: > # > # When cron is starting erlang with shell activated, erlang dies > # with "*** Terminating erlang (nonode@REDACTED)" > # This is fine, but exit status is 0! This is wrong. > > # Replace with path to wanted otp version > OTP=/u1/otp > > # Start with shell activated > $OTP/bin/erl -s crontest go -pz /tmp > > # Copy exit value > exit_status=$? > > case $exit_status in > 100) > echo "Erlang exit status 100. Normal result when everything is started ok." > exit 0 > ;; > 0) > echo "Erlang exit status 0. Should never happen!" > exit 1; > ;; > *) > echo "Exit status $exit_status." > exit $exit_status > esac > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From systemio@REDACTED Thu Jan 12 18:56:44 2012 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Thu, 12 Jan 2012 21:56:44 +0400 Subject: [erlang-bugs] =?utf-8?q?eunit_multiple_calls_a_test_/_eunit_local?= =?utf-8?q?_works_incorrect_=28=3F=29?= Message-ID: here is a simple test in fs_tests.erl module test1_test_() -> ?debugFmt("Test ~p",[self()]) , S = fun() -> ?debugFmt("Setup ~p",[self()]) end, C = fun(_) -> ?debugFmt("Cleanup ~p",[self()]) end, F = fun(_) -> fun() -> ?debugFmt("Test Check ~p",[self()]) end end, {foreach,local,S,C,[F]}. Run test: eunit:test([{inparallel,fs}],[{report,{eunit_surefire,[{dir,"./Reports"}]}}]). Got: ./src/fs_tests.erl:85:<0.94.0>: Test <0.94.0> ./src/fs_tests.erl:85:<0.94.0>: Test <0.94.0> ./src/fs_tests.erl:85:<0.94.0>: Test <0.94.0> ./src/fs_tests.erl:86:<0.94.0>: Setup <0.94.0> ./src/fs_tests.erl:88:<0.96.0>: Test Check <0.96.0> ./src/fs_tests.erl:87:<0.94.0>: Cleanup <0.94.0> Test passed. ok 1. Why are there 3 Test <0.94.0>, i expect only one? 2. Why does Test Check <0.96.0> have another process id? My reasoning: eunit:test([{inparallel,fs}],[... is a general rule while {foreach,local,... is more specific - that is why i expect union process id. Run test (without inparallel): eunit:test([fs],[{report,{eunit_surefire,[{dir,"./Reports"}]}}]). Got: ./src/fs_tests.erl:85:<0.103.0>: Test <0.103.0> ./src/fs_tests.erl:85:<0.103.0>: Test <0.103.0> ./src/fs_tests.erl:86:<0.103.0>: Setup <0.103.0> ./src/fs_tests.erl:88:<0.103.0>: Test Check <0.103.0> ./src/fs_tests.erl:87:<0.103.0>: Cleanup <0.103.0> Test passed. ok Now Test Check has the same process id, but why are there already 2 Test <0.103.0>, i expect only one? ~ Thx From anders.nygren@REDACTED Fri Jan 13 01:34:02 2012 From: anders.nygren@REDACTED (Anders Nygren) Date: Thu, 12 Jan 2012 18:34:02 -0600 Subject: [erlang-bugs] release_handler:remove_file fails on symlinks Message-ID: Hi release_handler:remove_file fails if the file is a symlink. This causes release_handler:remove_release to fail halfway through removing the release, leaving the system in an inconsistent state. The reason is that file:read_file_info/1 is used to check if a file is a directory or a normal file. It seems to me like changing to file:read_link_info/1 fixes the problem. /Anders From ericbmerritt@REDACTED Mon Jan 16 17:28:52 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Mon, 16 Jan 2012 10:28:52 -0600 Subject: [erlang-bugs] Compiler Consistency Check Error In-Reply-To: References: Message-ID: I made a mistake of naming an internal function 'get'. Easy enough to fix, but the mistake actually causes the compiler to explode. The compiler asked me to submit the problem so here it is. In R15B the attached module consistently causes the compiled module to fail its consistency check. Thanks, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: test.erl Type: application/octet-stream Size: 265 bytes Desc: not available URL: From ericbmerritt@REDACTED Mon Jan 16 17:31:05 2012 From: ericbmerritt@REDACTED (Eric Merritt) Date: Mon, 16 Jan 2012 10:31:05 -0600 Subject: [erlang-bugs] Core Erlang Binary Literals in Clause Nodes Breaks the Compiler In-Reply-To: <1325547755.7537.12.camel@localhost.localdomain> References: <1325547755.7537.12.camel@localhost.localdomain> Message-ID: Guys, I believe this is a bug. I hope the included information sufficient and useful. If not I can provide some more programmably testable result. A binary literal in a pattern breaks the 'from_core' compiler. The erlang to core compiler does not produce binary literals for patterns, so I suspect this code has simply never been tested. Binary literals ({c_literal, [], <<"ok">>} for example) in the pattern part of a c_clause causes the compiler to error out. Here are two versions of the same AST one of which works, the other causes the compiler to error. You can compile both of these with compile:forms(AST, [binary, from_core]). Working AST: CerlAST = {c_module, [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], test}, [{c_var,[compiler_generated],{module_info,1}}, {c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {test,1}}, {c_var,[compiler_generated],{module_info,0}}], [], [{{c_var,[compiler_generated],{module_info,0}}, {c_fun, [compiler_generated], [], {c_call,[], {c_literal,[],erlang}, {c_literal,[],get_module_info}, [{c_literal,[],test}]}}}, {{c_var,[compiler_generated],{module_info,1}}, {c_fun, [compiler_generated], [{c_var,[],mdetail}], {c_call,[], {c_literal,[],erlang}, {c_literal,[],get_module_info}, [{c_literal,[],test},{c_var,[],mdetail}]}}}, {{c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {test,1}}, {c_fun, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], el}], {c_case, [4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_var, [4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], el}, [{c_clause, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_binary, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_bitstr, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 111}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 8}, {c_literal,[compiler_generated],1}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], integer}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [unsigned,big]}}, {c_bitstr, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 107}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 8}, {c_literal,[compiler_generated],1}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], integer}, {c_literal, [5, {file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [unsigned,big]}}]}], {c_literal, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], true}, {c_binary, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_bitstr, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 34}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 8}, {c_literal,[compiler_generated],1}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], integer}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [unsigned,big]}}]}}, {c_clause, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_var, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], '_GENSYM_727BDA1'}], {c_literal, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], true}, {c_literal, [8,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], foo}}]}}}]} Broken AST: CerlAST = {c_module, [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], test}, [{c_var,[compiler_generated],{module_info,1}}, {c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {test,1}}, {c_var,[compiler_generated],{module_info,0}}], [], [{{c_var,[compiler_generated],{module_info,0}}, {c_fun, [compiler_generated], [], {c_call,[], {c_literal,[],erlang}, {c_literal,[],get_module_info}, [{c_literal,[],test}]}}}, {{c_var,[compiler_generated],{module_info,1}}, {c_fun, [compiler_generated], [{c_var,[],mdetail}], {c_call,[], {c_literal,[],erlang}, {c_literal,[],get_module_info}, [{c_literal,[],test},{c_var,[],mdetail}]}}}, {{c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {test,1}}, {c_fun, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_var, [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], el}], {c_case, [4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_var, [4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], el}, [{c_clause, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_literal, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], <<"ok">>}], {c_literal, [5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], true}, {c_binary, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_bitstr, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 34}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], 8}, {c_literal,[compiler_generated],1}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], integer}, {c_literal, [6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [unsigned,big]}}]}}, {c_clause, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], [{c_var, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], '_GENSYM_727BDA1'}], {c_literal, [7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], true}, {c_literal, [8,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}], foo}}]}}}]} From gustav@REDACTED Tue Jan 17 11:10:26 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 17 Jan 2012 11:10:26 +0100 Subject: [erlang-bugs] release_handler:remove_file fails on symlinks In-Reply-To: References: Message-ID: <4F154912.5010808@erlang.org> Hi Anders! file:read_file_info/1 does indeed return {error,enoent}on symbolic directory links, causing release_handler:remove_file/1 to fail on such links, or on directories containing one. We will add a fix for this in the next release. Thank you for the report! Regards, Gustav Simonsson On 2012-01-13 01:34, Anders Nygren wrote: > Hi > release_handler:remove_file fails if the file is a symlink. This > causes release_handler:remove_release to fail > halfway through removing the release, leaving the system in an > inconsistent state. > > The reason is that file:read_file_info/1 is used to check if a file is > a directory or a normal file. > It seems to me like changing to file:read_link_info/1 fixes the problem. > > /Anders > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From bgustavsson@REDACTED Wed Jan 18 09:17:55 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 18 Jan 2012 09:17:55 +0100 Subject: [erlang-bugs] Compiler Consistency Check Error In-Reply-To: References: Message-ID: On Mon, Jan 16, 2012 at 5:28 PM, Eric Merritt wrote: > I made a mistake of naming an internal function 'get'. Easy enough to > fix, but the mistake actually causes the compiler to explode. The > compiler asked me to submit the problem so here it is. In R15B the > attached module consistently causes the compiled module to fail its > consistency check. Thanks for the bug report. We will fix the problem in R15B01. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From eric.pailleau@REDACTED Sun Jan 22 11:12:44 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 22 Jan 2012 11:12:44 +0100 Subject: [erlang-bugs] R15B : Included application missing. Master application starting at second try. Message-ID: <4F1BE11C.7050904@wanadoo.fr> When forgeting path to an included application (here myapp1 is an included application of myapp0 ), the master application do not start as expected, but start at second try. Is it a bug or intentional ? I didn't see this in documentation ... Did I miss something ? (below I forgot ' -pa /home/dev/myapp1/ebin ') --------------------------------------8<--------------------- $> erl -pa /home/dev/myapp0/ebin Erlang R15B (erts-5.9) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> application:start(myapp0). {error,{"no such file or directory","myapp1.app"}} <--- Expected 2> application:start(myapp0). =ERROR REPORT==== 22-Jan-2012::10:44:43 === from: myapp0 application: myapp1 config: default status: stopped reason: "Failed to start child." error: {{'EXIT', {undef, [{myapp1,start,[normal,[]],[]}, ( ... SNIP ... SNIP ...) =PROGRESS REPORT==== 22-Jan-2012::10:44:43 === application: myapp0 started_at: nonode@REDACTED --------------------------------------8<--------------------- From ulf@REDACTED Tue Jan 24 11:23:51 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 24 Jan 2012 11:23:51 +0100 Subject: [erlang-bugs] reltool upsetting the order of things Message-ID: As I'm standing knee-deep in rebar and retool fun, I've noticed that reltool doesn't seem to respect the given order of applications in the 'rel' config. It is perhaps a less known aspect of sys tools that it will do its best to preserve the application order in the .rel file, and only move apps as needed to account for application dependencies. There was a concrete reason for this too. Back in the days (here comes another history lesson), we discovered that there were some nasty error situations in mnesia, where the tables would never load. As we were building a system that really had to come up, no matter what, we created a little program that started *before* mnesia, and monitored table loading progress. It was vital that it started before mnesia, because if we decided to do a force_load to break a table loading deadlock, we had to ensure that other mnesia nodes didn't start going on-line at the same time. This was handled with a global lock in the application that started before mnesia. So this was a new (reverse) application dependency of sorts. We didn't want to hack mnesia's .app file, so we agreed with OTP (actually, I and Magnus Bj?rklund agreed - things were easier then), that the sorting function in systools_make should not change the order unless it really had to. The sorting function is here: https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L1243 (It says there that I wrote it. I thought it was Martin. But at least you can see that it's documented, sort of). Now, retool (after I've experimented with various settings), now filters the way I want, but then calls reltool_target:sort_apps/1 and *changes* the original order. I haven't studied the algorithm to figure out which order it prefers over mine, but I had already put the apps in the order I wanted. A few debug printouts from reltool_target:merge_apps/2 to illustrate: MergedApps2("setup") = [stdlib,kernel,sasl,setup] Embedded("setup") = [] Sorted("setup") = [kernel,stdlib,setup,sasl] I maintain that reltool doesn't have to sort the list, since systools does whatever sorting is needed. Indeed, reltool should *refrain* from upsetting the original order. If it has added applications to the list, it should add those at the end. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Tue Jan 24 23:28:27 2012 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 24 Jan 2012 17:28:27 -0500 Subject: [erlang-bugs] reltool upsetting the order of things In-Reply-To: References: Message-ID: <20120124222826.GH25666@hijacked.us> On Tue, Jan 24, 2012 at 11:23:51AM +0100, Ulf Wiger wrote: > > As I'm standing knee-deep in rebar and retool fun, I've noticed that reltool doesn't seem to respect the given order of applications in the 'rel' config. > I've also been bitten by this and would welcome a fix. Andrew From mattevans123@REDACTED Wed Jan 25 17:20:18 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 25 Jan 2012 11:20:18 -0500 Subject: [erlang-bugs] Observer table viewer crash Message-ID: Hi When I use the table viewer, select a table (any table) and "Edit->Refresh Interval" I get the following error. I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh Interval" from the table list window. The crash happens immediately, the dialog doesn't even open. Thanks Matt Child crashed exiting: <0.17131.1> {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]}, undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"}, {line,374}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]}(plexxi@REDACTED)13> =ERROR REPORT==== 25-Jan-2012::08:14:38 ===** wx object server <0.17134.1> terminating ** Last message in was {wx,402, {wx_ref,268,wxFrame,[]}, [], {wxCommand,command_menu_selected,[],0,0}}** When Server state == {state, {wx_ref,220,wxListCtrl,[]}, {wx_ref,268,wxFrame,[]}, {wx_ref,294,wxListCtrl,[]}, {wx_ref,285,wxStatusBar,[]}, {wx_ref,293,wxBoxSizer,[]}, {search,true, {wx_ref,295,wxBoxSizer,[]}, 'Search Area', {wx_ref,298,wxTextCtrl,[]}, {wx_ref,309,wxTextCtrl,[]}, {{wx_ref,300,wxRadioButton,[]}, {wx_ref,302,wxRadioButton,[]}, {wx_ref,304,wxCheckBox,[]}}, undefined}, undefined,plexxi@REDACTED,2,<0.17135.1>,ets, {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, set,1,none,false,false,undefined,undefined}, {attrs, {wx_ref,287,wxListItemAttr,[]}, {wx_ref,288,wxListItemAttr,[]}, {wx_ref,289,wxListItemAttr,[]}, {wx_ref,290,wxListItemAttr,[]}, {wx_ref,291,wxListItemAttr,[]}}, undefined}** Reason for termination == ** {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]},undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"},{line,374}]}, {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Wed Jan 25 19:06:27 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 25 Jan 2012 13:06:27 -0500 Subject: [erlang-bugs] Observer table viewer crash In-Reply-To: References: Message-ID: One additional point. I added the following tuple {true,20} to the "timer" parameter in the state record of observer_tv_table.erl It didn't crash. What is interesting though is that it refreshed the "parent" window, not the child window. Matt From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Wed, 25 Jan 2012 11:20:18 -0500 Subject: [erlang-bugs] Observer table viewer crash Hi When I use the table viewer, select a table (any table) and "Edit->Refresh Interval" I get the following error. I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh Interval" from the table list window. The crash happens immediately, the dialog doesn't even open. Thanks Matt Child crashed exiting: <0.17131.1> {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]}, undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"}, {line,374}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]}(plexxi@REDACTED)13> =ERROR REPORT==== 25-Jan-2012::08:14:38 ===** wx object server <0.17134.1> terminating ** Last message in was {wx,402, {wx_ref,268,wxFrame,[]}, [], {wxCommand,command_menu_selected,[],0,0}}** When Server state == {state, {wx_ref,220,wxListCtrl,[]}, {wx_ref,268,wxFrame,[]}, {wx_ref,294,wxListCtrl,[]}, {wx_ref,285,wxStatusBar,[]}, {wx_ref,293,wxBoxSizer,[]}, {search,true, {wx_ref,295,wxBoxSizer,[]}, 'Search Area', {wx_ref,298,wxTextCtrl,[]}, {wx_ref,309,wxTextCtrl,[]}, {{wx_ref,300,wxRadioButton,[]}, {wx_ref,302,wxRadioButton,[]}, {wx_ref,304,wxCheckBox,[]}}, undefined}, undefined,plexxi@REDACTED,2,<0.17135.1>,ets, {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, set,1,none,false,false,undefined,undefined}, {attrs, {wx_ref,287,wxListItemAttr,[]}, {wx_ref,288,wxListItemAttr,[]}, {wx_ref,289,wxListItemAttr,[]}, {wx_ref,290,wxListItemAttr,[]}, {wx_ref,291,wxListItemAttr,[]}}, undefined}** Reason for termination == ** {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]},undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"},{line,374}]}, {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Wed Jan 25 21:38:20 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 25 Jan 2012 15:38:20 -0500 Subject: [erlang-bugs] Observer table viewer crash - Patch??? In-Reply-To: References: , Message-ID: Ok, as well as the problem below it appears that observer_tv_table was missing the handle_info/2 for the atom refresh_interval. The patch attached to this email appears to fix this. Feel free to try it... Again, I'm using R15B on Ubuntu. Thanks Matt From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Wed, 25 Jan 2012 13:06:27 -0500 Subject: Re: [erlang-bugs] Observer table viewer crash One additional point. I added the following tuple {true,20} to the "timer" parameter in the state record of observer_tv_table.erl It didn't crash. What is interesting though is that it refreshed the "parent" window, not the child window. Matt From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Wed, 25 Jan 2012 11:20:18 -0500 Subject: [erlang-bugs] Observer table viewer crash Hi When I use the table viewer, select a table (any table) and "Edit->Refresh Interval" I get the following error. I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh Interval" from the table list window. The crash happens immediately, the dialog doesn't even open. Thanks Matt Child crashed exiting: <0.17131.1> {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]}, undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"}, {line,374}]}, {wx_object,handle_msg,5, [{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]}(plexxi@REDACTED)13> =ERROR REPORT==== 25-Jan-2012::08:14:38 ===** wx object server <0.17134.1> terminating ** Last message in was {wx,402, {wx_ref,268,wxFrame,[]}, [], {wxCommand,command_menu_selected,[],0,0}}** When Server state == {state, {wx_ref,220,wxListCtrl,[]}, {wx_ref,268,wxFrame,[]}, {wx_ref,294,wxListCtrl,[]}, {wx_ref,285,wxStatusBar,[]}, {wx_ref,293,wxBoxSizer,[]}, {search,true, {wx_ref,295,wxBoxSizer,[]}, 'Search Area', {wx_ref,298,wxTextCtrl,[]}, {wx_ref,309,wxTextCtrl,[]}, {{wx_ref,300,wxRadioButton,[]}, {wx_ref,302,wxRadioButton,[]}, {wx_ref,304,wxCheckBox,[]}}, undefined}, undefined,plexxi@REDACTED,2,<0.17135.1>,ets, {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, set,1,none,false,false,undefined,undefined}, {attrs, {wx_ref,287,wxListItemAttr,[]}, {wx_ref,288,wxListItemAttr,[]}, {wx_ref,289,wxListItemAttr,[]}, {wx_ref,290,wxListItemAttr,[]}, {wx_ref,291,wxListItemAttr,[]}}, undefined}** Reason for termination == ** {function_clause, [{observer_lib,interval_dialog, [{wx_ref,294,wxListCtrl,[]},undefined,10,300], [{file,"observer_lib.erl"},{line,40}]}, {observer_tv_table,handle_event,2, [{file,"observer_tv_table.erl"},{line,374}]}, {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: observer_tv_table.erl.patch Type: text/x-patch Size: 552 bytes Desc: not available URL: From dangud@REDACTED Thu Jan 26 08:35:07 2012 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 26 Jan 2012 08:35:07 +0100 Subject: [erlang-bugs] Observer table viewer crash - Patch??? In-Reply-To: References: Message-ID: Thanks for the bug reports (and patches). I did some late refactoring there, seems I broke a lot of things. I need to come up with away to automatically test at least the basic functionality. The timer was off by default for tables, I didn't want it to automatically refresh since the tables can so large. You think the tables should refresh automatically by default? /Dan On Wed, Jan 25, 2012 at 9:38 PM, Matthew Evans wrote: > Ok, as well as the problem below it appears that observer_tv_table was > missing the handle_info/2 for the atom refresh_interval. > > The patch attached to this email appears to fix this. > > Feel free to try it... > > Again, I'm using R15B on Ubuntu. > > Thanks > > Matt > > > ________________________________ > From: mattevans123@REDACTED > To: erlang-bugs@REDACTED > Date: Wed, 25 Jan 2012 13:06:27 -0500 > Subject: Re: [erlang-bugs] Observer table viewer crash > > One additional point. > > I added the following tuple {true,20} to the "timer" parameter in the state > record of observer_tv_table.erl > > It didn't crash. > > What is interesting though is that it refreshed the "parent" window, not the > child window. > > Matt > > ________________________________ > From: mattevans123@REDACTED > To: erlang-bugs@REDACTED > Date: Wed, 25 Jan 2012 11:20:18 -0500 > Subject: [erlang-bugs] Observer table viewer crash > > Hi > > When I use the table viewer, select a table (any table) and "Edit->Refresh > Interval" I get the following error. > > I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh > Interval" from the table list window. > > The crash happens immediately, the dialog doesn't even open. > > Thanks > > Matt > > > Child crashed exiting: ?<0.17131.1> {function_clause, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{observer_lib,interval_dialog, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{wx_ref,294,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,10,300], > > ?[{file,"observer_lib.erl"},{line,40}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {observer_tv_table,handle_event,2, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"observer_tv_table.erl"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {line,374}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_object,handle_msg,5, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"wx_object.erl"},{line,394}]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{file,"proc_lib.erl"},{line,227}]}]} > (plexxi@REDACTED)13> > =ERROR REPORT==== 25-Jan-2012::08:14:38 === > ** wx object server <0.17134.1> terminating > ** Last message in was {wx,402, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,268,wxFrame,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?[], > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wxCommand,command_menu_selected,[],0,0}} > ** When Server state == {state, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,220,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,268,wxFrame,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,294,wxListCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,285,wxStatusBar,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,293,wxBoxSizer,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {search,true, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,295,wxBoxSizer,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 'Search Area', > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,298,wxTextCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,309,wxTextCtrl,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {{wx_ref,300,wxRadioButton,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,302,wxRadioButton,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,304,wxCheckBox,[]}}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,plexxi@REDACTED,2,<0.17135.1>,ets, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set,1,none,false,false,undefined,undefined}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? {attrs, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,287,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,288,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,289,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,290,wxListItemAttr,[]}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {wx_ref,291,wxListItemAttr,[]}}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? undefined} > ** Reason for termination == > ** {function_clause, > ? ? ? ?[{observer_lib,interval_dialog, > ? ? ? ? ? ? [{wx_ref,294,wxListCtrl,[]},undefined,10,300], > ? ? ? ? ? ? [{file,"observer_lib.erl"},{line,40}]}, > ? ? ? ? {observer_tv_table,handle_event,2, > ? ? ? ? ? ? [{file,"observer_tv_table.erl"},{line,374}]}, > ? ? ? ? {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, > ? ? ? ? {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} > > > _______________________________________________ erlang-bugs mailing list > erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ erlang-bugs mailing list > erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From mattevans123@REDACTED Thu Jan 26 16:34:52 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 26 Jan 2012 10:34:52 -0500 Subject: [erlang-bugs] Observer table viewer crash - Patch??? In-Reply-To: References: , , , Message-ID: Hi, It should be off by default of course. But I found that by not setting the tuple {true,Time} or {false,Time} in observer_tv_table.erl would cause it to crash. In my case the tables are quite small, so having a refresh every 20 seconds is pretty painless. Of course, for large tables I can see that you might want to warn the user that it's a really bad idea. Thanks Matt > Date: Thu, 26 Jan 2012 08:35:07 +0100 > Subject: Re: [erlang-bugs] Observer table viewer crash - Patch??? > From: dangud@REDACTED > To: mattevans123@REDACTED > CC: erlang-bugs@REDACTED; erlang-patches@REDACTED > > Thanks for the bug reports (and patches). > > I did some late refactoring there, seems I broke a lot of things. > I need to come up with away to automatically test at least the basic > functionality. > > The timer was off by default for tables, I didn't want it to > automatically refresh since the > tables can so large. > > You think the tables should refresh automatically by default? > > /Dan > > On Wed, Jan 25, 2012 at 9:38 PM, Matthew Evans wrote: > > Ok, as well as the problem below it appears that observer_tv_table was > > missing the handle_info/2 for the atom refresh_interval. > > > > The patch attached to this email appears to fix this. > > > > Feel free to try it... > > > > Again, I'm using R15B on Ubuntu. > > > > Thanks > > > > Matt > > > > > > ________________________________ > > From: mattevans123@REDACTED > > To: erlang-bugs@REDACTED > > Date: Wed, 25 Jan 2012 13:06:27 -0500 > > Subject: Re: [erlang-bugs] Observer table viewer crash > > > > One additional point. > > > > I added the following tuple {true,20} to the "timer" parameter in the state > > record of observer_tv_table.erl > > > > It didn't crash. > > > > What is interesting though is that it refreshed the "parent" window, not the > > child window. > > > > Matt > > > > ________________________________ > > From: mattevans123@REDACTED > > To: erlang-bugs@REDACTED > > Date: Wed, 25 Jan 2012 11:20:18 -0500 > > Subject: [erlang-bugs] Observer table viewer crash > > > > Hi > > > > When I use the table viewer, select a table (any table) and "Edit->Refresh > > Interval" I get the following error. > > > > I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh > > Interval" from the table list window. > > > > The crash happens immediately, the dialog doesn't even open. > > > > Thanks > > > > Matt > > > > > > Child crashed exiting: <0.17131.1> {function_clause, > > [{observer_lib,interval_dialog, > > [{wx_ref,294,wxListCtrl,[]}, > > undefined,10,300], > > > > [{file,"observer_lib.erl"},{line,40}]}, > > {observer_tv_table,handle_event,2, > > [{file,"observer_tv_table.erl"}, > > {line,374}]}, > > {wx_object,handle_msg,5, > > [{file,"wx_object.erl"},{line,394}]}, > > {proc_lib,init_p_do_apply,3, > > [{file,"proc_lib.erl"},{line,227}]}]} > > (plexxi@REDACTED)13> > > =ERROR REPORT==== 25-Jan-2012::08:14:38 === > > ** wx object server <0.17134.1> terminating > > ** Last message in was {wx,402, > > {wx_ref,268,wxFrame,[]}, > > [], > > {wxCommand,command_menu_selected,[],0,0}} > > ** When Server state == {state, > > {wx_ref,220,wxListCtrl,[]}, > > {wx_ref,268,wxFrame,[]}, > > {wx_ref,294,wxListCtrl,[]}, > > {wx_ref,285,wxStatusBar,[]}, > > {wx_ref,293,wxBoxSizer,[]}, > > {search,true, > > {wx_ref,295,wxBoxSizer,[]}, > > 'Search Area', > > {wx_ref,298,wxTextCtrl,[]}, > > {wx_ref,309,wxTextCtrl,[]}, > > {{wx_ref,300,wxRadioButton,[]}, > > {wx_ref,302,wxRadioButton,[]}, > > {wx_ref,304,wxCheckBox,[]}}, > > undefined}, > > undefined,plexxi@REDACTED,2,<0.17135.1>,ets, > > {tab,bob,81944,0,1228,<0.38.0>,ignore,protected, > > set,1,none,false,false,undefined,undefined}, > > {attrs, > > {wx_ref,287,wxListItemAttr,[]}, > > {wx_ref,288,wxListItemAttr,[]}, > > {wx_ref,289,wxListItemAttr,[]}, > > {wx_ref,290,wxListItemAttr,[]}, > > {wx_ref,291,wxListItemAttr,[]}}, > > undefined} > > ** Reason for termination == > > ** {function_clause, > > [{observer_lib,interval_dialog, > > [{wx_ref,294,wxListCtrl,[]},undefined,10,300], > > [{file,"observer_lib.erl"},{line,40}]}, > > {observer_tv_table,handle_event,2, > > [{file,"observer_tv_table.erl"},{line,374}]}, > > {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]}, > > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]} > > > > > > _______________________________________________ erlang-bugs mailing list > > erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ erlang-bugs mailing list > > erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 26 18:14:40 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 26 Jan 2012 18:14:40 +0100 Subject: [erlang-bugs] reltool upsetting the order of things In-Reply-To: <20120124222826.GH25666@hijacked.us> References: <20120124222826.GH25666@hijacked.us> Message-ID: 2012/1/24 Andrew Thompson > On Tue, Jan 24, 2012 at 11:23:51AM +0100, Ulf Wiger wrote: > > > > As I'm standing knee-deep in rebar and retool fun, I've noticed that > reltool doesn't seem to respect the given order of applications in the > 'rel' config. > > > I've also been bitten by this and would welcome a fix. > > Andrew > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > There will be a correction for this - probably in R15B01.... /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Jan 26 19:09:42 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 26 Jan 2012 20:09:42 +0200 Subject: [erlang-bugs] reltool upsetting the order of things In-Reply-To: References: <20120124222826.GH25666@hijacked.us> Message-ID: <4F2196E6.8010803@cs.ntua.gr> On 01/26/12 19:14, Siri Hansen wrote: > > 2012/1/24 Andrew Thompson > > > On Tue, Jan 24, 2012 at 11:23:51AM +0100, Ulf Wiger wrote: > > > > As I'm standing knee-deep in rebar and retool fun, I've noticed > that reltool doesn't seem to respect the given order of applications > in the 'rel' config. > > > I've also been bitten by this and would welcome a fix. > > There will be a correction for this - probably in R15B01.... If I am allowed to add my .02 in this thread, the proper way to deal with this issue is not by simply commenting out whatever sorting reltool may be using or by honoring agreements of two people that may or may not remember them ten years down the road, but by extending the 'rel' config files with a way to specify application dependencies (if there are any) and taking them into account. Kostis From erlangsiri@REDACTED Fri Jan 27 11:38:15 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 27 Jan 2012 11:38:15 +0100 Subject: [erlang-bugs] reltool upsetting the order of things In-Reply-To: <4F2196E6.8010803@cs.ntua.gr> References: <20120124222826.GH25666@hijacked.us> <4F2196E6.8010803@cs.ntua.gr> Message-ID: 2012/1/26 Kostis Sagonas > On 01/26/12 19:14, Siri Hansen wrote: > >> >> 2012/1/24 Andrew Thompson > >> >> >> >> On Tue, Jan 24, 2012 at 11:23:51AM +0100, Ulf Wiger wrote: >> > >> > As I'm standing knee-deep in rebar and retool fun, I've noticed >> that reltool doesn't seem to respect the given order of applications >> in the 'rel' config. >> > >> I've also been bitten by this and would welcome a fix. >> >> There will be a correction for this - probably in R15B01.... >> > > If I am allowed to add my .02 in this thread, the proper way to deal with > this issue is not by simply commenting out whatever sorting reltool may be > using or by honoring agreements of two people that may or may not remember > them ten years down the road, but by extending the 'rel' config files with > a way to specify application dependencies (if there are any) and taking > them into account. > > Kostis > > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > Thank you, Kostis! This is a good point, of course. If there is a requirement on some way to specify dependencies which can not be specified with 1) the use of 'applications' and 'included_applications' in the .app file, and 2) the order of applications as specified in the .rel file or the 'rel' statement in the reltool config we will be very happy to receive a proposal - or even better - a contribution. However, for now I think we will just settle for correcting the bug which messes with the order of applications during reltools processing of 'rel' specifications. Regards /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Jan 27 13:48:01 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 27 Jan 2012 13:48:01 +0100 Subject: [erlang-bugs] reltool upsetting the order of things In-Reply-To: References: <20120124222826.GH25666@hijacked.us> <4F2196E6.8010803@cs.ntua.gr> Message-ID: The specific requirement behind the special sorting strategy was that sometimes you specifically need a certain application to start _before_ another application. One could imagine different ways of doing this, for example allowing {before, App} in the 'applications' attribute in the .app file. Most likely, this would break code, though. A new attribute, {start_before, [App]} could be another approach. OTOH, I think this is a sufficiently unusual situation, that the current solution might be the best after all. BTW, it _is_ documented! See the man page for systools:make_script/1 http://www.erlang.org/doc/man/systools.html#make_script-1 "The applications are sorted according to the dependencies between the applications. Where there are no dependencies, the order in the .rel file is kept." Reltool is more vague: "rel Release specific configuration. Each release maps to a rel, script and boot file." But it's reasonable to expect that Reltool should honor the promises made regarding the .rel file, when it maps to it. BR, Ulf W On 27 Jan 2012, at 11:38, Siri Hansen wrote: > > > 2012/1/26 Kostis Sagonas > On 01/26/12 19:14, Siri Hansen wrote: > > 2012/1/24 Andrew Thompson > > > > On Tue, Jan 24, 2012 at 11:23:51AM +0100, Ulf Wiger wrote: > > > > As I'm standing knee-deep in rebar and retool fun, I've noticed > that reltool doesn't seem to respect the given order of applications > in the 'rel' config. > > > I've also been bitten by this and would welcome a fix. > > There will be a correction for this - probably in R15B01.... > > If I am allowed to add my .02 in this thread, the proper way to deal with this issue is not by simply commenting out whatever sorting reltool may be using or by honoring agreements of two people that may or may not remember them ten years down the road, but by extending the 'rel' config files with a way to specify application dependencies (if there are any) and taking them into account. > > Kostis > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > Thank you, Kostis! This is a good point, of course. If there is a requirement on some way to specify dependencies which can not be specified with > > 1) the use of 'applications' and 'included_applications' in the .app file, and > 2) the order of applications as specified in the .rel file or the 'rel' statement in the reltool config > > we will be very happy to receive a proposal - or even better - a contribution. However, for now I think we will just settle for correcting the bug which messes with the order of applications during reltools processing of 'rel' specifications. > > Regards > /siri > _______________________________________________ > 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 Tue Jan 31 12:46:24 2012 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Tue, 31 Jan 2012 11:46:24 -0000 (GMT) Subject: [erlang-bugs] The Erlang Restricted Shell allows execution of random commands In-Reply-To: <4e27ff67-28dd-4552-8264-f94f687215a0@knuth> Message-ID: <7c0385c9-c123-430a-b7c4-5a2c10841cae@knuth> Hi all, reading from the Erlang doc: http://www.erlang.org/doc/man/shell.html#start_restricted-1 "The shell may be started in a restricted mode. In this mode, the shell evaluates a function call only if allowed." Let's write a minimal module which whitelists the 'lists' module only: ===== -module(restrict). -export([local_allowed/3, non_local_allowed/3]). -define(NON_LOCAL_ALLOWED, [lists]). local_allowed(_Cmd, _Args, State) -> {false, State}. non_local_allowed({Module, _Function}, _Args, State) -> {lists:member(Module, ?NON_LOCAL_ALLOWED), State}. ===== Let's then start a restricted shell, using the above module. $ erlc restrict.erl $ erl -stdlib restricted_shell restrict Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false] Restricted Eshell V5.8.5 (abort with ^G) And let's see if it works as expected. 1> erlang:time(). ** exception exit: restricted shell does not allow time() Cool. 2> erlang:apply(erlang, time, []). ** exception exit: restricted shell does not allow time() Yeah. 3> F = fun (M,F,A) -> lists:zipwith3({erlang, apply}, [M], [F], [ A ]) end. #Fun 4> F(erlang, time, []). [{12,35,45}] Ooops. Please notice that I'm not the one who actually discovered this bug (or is it a feature?). It was actually one of the tryerlang.org users, who kindly informed me about this. Originally I thought this was an application bug, but it is not. This is more generic and it affects the restricted shell itself. Best regards, Roberto Aloi --- @robertoaloi Erlang Solutions Ltd. www.erlang-solutions.com From spawn.think@REDACTED Tue Jan 31 13:50:33 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 31 Jan 2012 13:50:33 +0100 Subject: [erlang-bugs] The Erlang Restricted Shell allows execution of random commands In-Reply-To: <7c0385c9-c123-430a-b7c4-5a2c10841cae@knuth> References: <4e27ff67-28dd-4552-8264-f94f687215a0@knuth> <7c0385c9-c123-430a-b7c4-5a2c10841cae@knuth> Message-ID: It sounds to work only with tuple funs, which is going to be removed soon anyway. OTP-9649 Tuple funs (a two-element tuple with a module name and a function) are now officially deprecated and will be removed in R16. Use 'fun M:F/A' instead. To make you aware that your system uses tuple funs, the very first time a tuple fun is applied, a warning will be sent to the error logger. 1> F = fun (M,F,A) -> lists:zipwith3(fun(M, F,A)-> erlang:apply(M, F, A) end, [M], [F], [ A ]) end. #Fun 2> F(erlang, time, []). ** exception exit: restricted shell does not allow time() in function shell:non_local_allowed/4 in call from lists:zipwith3/4 3> or am i wrong? On Tue, Jan 31, 2012 at 12:46 PM, Roberto Aloi < roberto.aloi@REDACTED> wrote: > Hi all, > > reading from the Erlang doc: > > http://www.erlang.org/doc/man/shell.html#start_restricted-1 > > "The shell may be started in a restricted mode. In this mode, the shell > evaluates a function call only if allowed." > > Let's write a minimal module which whitelists the 'lists' module only: > > ===== > -module(restrict). > > -export([local_allowed/3, non_local_allowed/3]). > > -define(NON_LOCAL_ALLOWED, [lists]). > > local_allowed(_Cmd, _Args, State) -> > {false, State}. > > non_local_allowed({Module, _Function}, _Args, State) -> > {lists:member(Module, ?NON_LOCAL_ALLOWED), State}. > ===== > > Let's then start a restricted shell, using the above module. > > $ erlc restrict.erl > $ erl -stdlib restricted_shell restrict > > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [hipe] [kernel-poll:false] > > Restricted Eshell V5.8.5 (abort with ^G) > > And let's see if it works as expected. > > 1> erlang:time(). > ** exception exit: restricted shell does not allow time() > > Cool. > > 2> erlang:apply(erlang, time, []). > ** exception exit: restricted shell does not allow time() > > Yeah. > > 3> F = fun (M,F,A) -> lists:zipwith3({erlang, apply}, [M], [F], [ A ]) end. > #Fun > 4> F(erlang, time, []). > [{12,35,45}] > > Ooops. > > Please notice that I'm not the one who actually discovered this bug (or is > it a feature?). It was actually one of the tryerlang.org users, who > kindly informed me about this. Originally I thought this was an application > bug, but it is not. This is more generic and it affects the restricted > shell itself. > > Best regards, > > Roberto Aloi > --- > @robertoaloi > Erlang Solutions Ltd. > www.erlang-solutions.com > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ufm@REDACTED Tue Jan 31 14:00:06 2012 From: ufm@REDACTED (Fyodor Ustinov) Date: Tue, 31 Jan 2012 15:00:06 +0200 Subject: [erlang-bugs] ssh daemon and encoding. Message-ID: <4F27E5D6.70500@ufm.su> 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. From roberto.aloi@REDACTED Tue Jan 31 14:38:11 2012 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Tue, 31 Jan 2012 13:38:11 -0000 (GMT) Subject: [erlang-bugs] The Erlang Restricted Shell allows execution of random commands In-Reply-To: Message-ID: <068d8741-2e8b-49d5-8adf-127fe1a0a4b9@knuth> Not really. In R16 you could do: 1> F = fun (M,F,A) -> lists:zipwith3(fun erlang:apply/3, [M], [F], [A]) end. #Fun 2> F(init, stop, []). [ok] *dies* Regards, Roberto Aloi --- Erlang Solutions Ltd. www.erlang-solutions.com ----- Original Message ----- > It sounds to work only with tuple funs, which is going to be removed > soon anyway. > > > OTP-9649 Tuple funs (a two-element tuple with a module name and a > function) are now officially deprecated and will be removed > in R16. Use 'fun M:F/A' instead. To make you aware that your > system uses tuple funs, the very first time a tuple fun is > applied, a warning will be sent to the error logger. > > > > 1> F = fun (M,F,A) -> lists:zipwith3(fun(M, F,A)-> erlang:apply(M, F, > A) end, [M], [F], [ A ]) end. > #Fun > 2> F(erlang, time, []). > ** exception exit: restricted shell does not allow time() > in function shell:non_local_allowed/4 > in call from lists:zipwith3/4 > 3> > > > or am i wrong? > > > On Tue, Jan 31, 2012 at 12:46 PM, Roberto Aloi < > roberto.aloi@REDACTED > wrote: > > > Hi all, > > reading from the Erlang doc: > > http://www.erlang.org/doc/man/shell.html#start_restricted-1 > > "The shell may be started in a restricted mode. In this mode, the > shell evaluates a function call only if allowed." > > Let's write a minimal module which whitelists the 'lists' module > only: > > ===== > -module(restrict). > > -export([local_allowed/3, non_local_allowed/3]). > > -define(NON_LOCAL_ALLOWED, [lists]). > > local_allowed(_Cmd, _Args, State) -> > {false, State}. > > non_local_allowed({Module, _Function}, _Args, State) -> > {lists:member(Module, ?NON_LOCAL_ALLOWED), State}. > ===== > > Let's then start a restricted shell, using the above module. > > $ erlc restrict.erl > $ erl -stdlib restricted_shell restrict > > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [hipe] [kernel-poll:false] > > Restricted Eshell V5.8.5 (abort with ^G) > > And let's see if it works as expected. > > 1> erlang:time(). > ** exception exit: restricted shell does not allow time() > > Cool. > > 2> erlang:apply(erlang, time, []). > ** exception exit: restricted shell does not allow time() > > Yeah. > > 3> F = fun (M,F,A) -> lists:zipwith3({erlang, apply}, [M], [F], [ A > ]) end. > #Fun > 4> F(erlang, time, []). > [{12,35,45}] > > Ooops. > > Please notice that I'm not the one who actually discovered this bug > (or is it a feature?). It was actually one of the tryerlang.org > users, who kindly informed me about this. Originally I thought this > was an application bug, but it is not. This is more generic and it > affects the restricted shell itself. > > Best regards, > > Roberto Aloi > --- > @robertoaloi > Erlang Solutions Ltd. > www.erlang-solutions.com > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From spawn.think@REDACTED Tue Jan 31 15:07:06 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 31 Jan 2012 15:07:06 +0100 Subject: [erlang-bugs] The Erlang Restricted Shell allows execution of random commands In-Reply-To: <068d8741-2e8b-49d5-8adf-127fe1a0a4b9@knuth> References: <068d8741-2e8b-49d5-8adf-127fe1a0a4b9@knuth> Message-ID: But in that case, you can check in restrict.erl if any of the Args is equal to any of fun erlang:apply/A of erlang:spawn/A or maybe it should detect any fun M:F/A and check it against your module. On Tue, Jan 31, 2012 at 2:38 PM, Roberto Aloi < roberto.aloi@REDACTED> wrote: > Not really. In R16 you could do: > > 1> F = fun (M,F,A) -> lists:zipwith3(fun erlang:apply/3, [M], [F], [A]) > end. > #Fun > 2> F(init, stop, []). > [ok] > > *dies* > > Regards, > > Roberto Aloi > --- > Erlang Solutions Ltd. > www.erlang-solutions.com > > > ----- Original Message ----- > > It sounds to work only with tuple funs, which is going to be removed > > soon anyway. > > > > > > OTP-9649 Tuple funs (a two-element tuple with a module name and a > > function) are now officially deprecated and will be removed > > in R16. Use 'fun M:F/A' instead. To make you aware that your > > system uses tuple funs, the very first time a tuple fun is > > applied, a warning will be sent to the error logger. > > > > > > > > 1> F = fun (M,F,A) -> lists:zipwith3(fun(M, F,A)-> erlang:apply(M, F, > > A) end, [M], [F], [ A ]) end. > > #Fun > > 2> F(erlang, time, []). > > ** exception exit: restricted shell does not allow time() > > in function shell:non_local_allowed/4 > > in call from lists:zipwith3/4 > > 3> > > > > > > or am i wrong? > > > > > > On Tue, Jan 31, 2012 at 12:46 PM, Roberto Aloi < > > roberto.aloi@REDACTED > wrote: > > > > > > Hi all, > > > > reading from the Erlang doc: > > > > http://www.erlang.org/doc/man/shell.html#start_restricted-1 > > > > "The shell may be started in a restricted mode. In this mode, the > > shell evaluates a function call only if allowed." > > > > Let's write a minimal module which whitelists the 'lists' module > > only: > > > > ===== > > -module(restrict). > > > > -export([local_allowed/3, non_local_allowed/3]). > > > > -define(NON_LOCAL_ALLOWED, [lists]). > > > > local_allowed(_Cmd, _Args, State) -> > > {false, State}. > > > > non_local_allowed({Module, _Function}, _Args, State) -> > > {lists:member(Module, ?NON_LOCAL_ALLOWED), State}. > > ===== > > > > Let's then start a restricted shell, using the above module. > > > > $ erlc restrict.erl > > $ erl -stdlib restricted_shell restrict > > > > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] > > [async-threads:0] [hipe] [kernel-poll:false] > > > > Restricted Eshell V5.8.5 (abort with ^G) > > > > And let's see if it works as expected. > > > > 1> erlang:time(). > > ** exception exit: restricted shell does not allow time() > > > > Cool. > > > > 2> erlang:apply(erlang, time, []). > > ** exception exit: restricted shell does not allow time() > > > > Yeah. > > > > 3> F = fun (M,F,A) -> lists:zipwith3({erlang, apply}, [M], [F], [ A > > ]) end. > > #Fun > > 4> F(erlang, time, []). > > [{12,35,45}] > > > > Ooops. > > > > Please notice that I'm not the one who actually discovered this bug > > (or is it a feature?). It was actually one of the tryerlang.org > > users, who kindly informed me about this. Originally I thought this > > was an application bug, but it is not. This is more generic and it > > affects the restricted shell itself. > > > > Best regards, > > > > Roberto Aloi > > --- > > @robertoaloi > > Erlang Solutions Ltd. > > www.erlang-solutions.com > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ess@REDACTED Tue Jan 31 15:58:43 2012 From: ess@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 31 Jan 2012 15:58:43 +0100 Subject: [erlang-bugs] ssh daemon and encoding. In-Reply-To: <4F27E5D6.70500@ufm.su> References: <4F27E5D6.70500@ufm.su> Message-ID: <4F2801A3.5070206@trifork.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Tue Jan 31 23:11:02 2012 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 31 Jan 2012 16:11:02 -0600 Subject: [erlang-bugs] Race bug in net_kernel:get_status() Message-ID: <55582.1328047862@snookles.snookles.com> Hi, all. I believe that there's a race condition bug in net_kernel:get_status(). The system that we're seeing this on is based on R14B04, but since R15B uses the same version of net_kernel.erl as R14B04, R15B may also have this problem? A process that calls net_kernel:nodes_info/0 can hang indefinitely. A backtrace of such a hung process looks like this: Program counter: 0x0000000004281120 (net_kernel:get_status/3 + 216) CP: 0x0000000000000000 (invalid) arity = 0 0xfffffd7fd7b3e9d0 Return addr 0x0000000004280e68 (net_kernel:get_node_info/1 + 424) y(0) 'lhs@REDACTED' y(1) <0.241.0> 0xfffffd7fd7b3e9e8 Return addr 0x00000000042815b0 (net_kernel:get_nodes_info/2 + 96) y(0) normal y(1) {net_address,{{192,168,24,199},39734},"node-x.example.com",tcp,inet} y(2) <0.241.0> y(3) up [....] This is coming from a Riak system that is using Basho's NIF interface to the LevelDB embedded database, eleveldb. It's possible for those NIFs to block for long periods of time (60 seconds or more), which is certainly not a nice thing for a NIF to do, but until we work out some latency problems with the LevelDB code, the NIFs cause some really crazy scheduling of both Erlang processes and internal file descriptor polling. -Scott