From joe@REDACTED Thu Sep 1 03:45:22 2011 From: joe@REDACTED (Joe Williams) Date: Wed, 31 Aug 2011 18:45:22 -0700 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> Message-ID: Siri, I have added tests and squashed my commits, rewriting the commit message while I was at it. Please refetch and let me know if this is up to your standards for graduation. -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > Hi Joe - Yes, you can put your application inside release_handler_SUITE_data/lib. And hopefully you can use the functions create_and_install_fake_first_release and create_fake_upgrade_release - you can see examples of that in release_handler_SUITE.erl. Please let me know if you need any more advice on the testing. > Regards > /siri > > > 2011/8/30 Joe Williams > > Siri, > > > > I could use some advice on how best to test this code. Currently I have a little dummy application with the proper supervision tree to trigger this upgrade case. Here are the steps I use to reproduce: > > > > https://gist.github.com/da109fb6939ef7aac031 > > > > Note that this is using my topic branch so you can see the additional logging. > > > > I noticed that there is a release_handler_SUITE_data directory in the sasl tests, should I just add another directory specifically for this and store the dummy application there for testing? > > > > Thanks. > > > > -Joe > > > > > > -- > > Name: Joseph A. Williams > > Email: joe@REDACTED (mailto:joe@REDACTED) > > Blog: http://www.joeandmotorboat.com/ > > Twitter: http://twitter.com/williamsjoe > > > > > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > > > > Great Joe - this is much better :) > > > Could you please add some tests for this also? > > > Thanks > > > /siri > > > > > > 2011/8/29 Joe Williams > > > > Siri, > > > > > > > > Please fetch this branch again. > > > > > > > > I have added errors where I had my functions returning empty lists. I believe this should bubble up to release_handler causing a restart similar to the timeout behavior we currently have. > > > > > > > > -Joe > > > > > > > > > > > > -- > > > > Name: Joseph A. Williams > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > Blog: http://www.joeandmotorboat.com/ > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > > > > > > > > Siri, > > > > > > > > > > In case #2 the node would be in an "unpacked" state but perhaps that isn't possible since the upgrade may be partially installed already. I'll work on implementing #1 and reply back soon. > > > > > > > > > > -Joe > > > > > > > > > > > > > > > -- > > > > > Name: Joseph A. Williams > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > > > > > > > > > > Hi Joe - > > > > > > I think I would prefer solution 1), although that's probably mostly because I don't really understand solution 2)... What do you mean by "stop the upgrade from completing"? in which state would the node be after this? > > > > > > /siri > > > > > > > > > > > > 2011/8/26 Joe Williams > > > > > > > Siri, > > > > > > > > > > > > > > That sounds correct, with the current patch there is that risk. In my case I would see the error message post-upgrade and restart things as needed but I certainly see your point. The VM restarting is a brutal but idiomatic way to deal with this issue, let it fail :). > > > > > > > > > > > > > > I think there are two possibilities here, 1) continue with the restart behavior but make sure we print error messages before we do or 2) print error messages but stop the upgrade from completing if we catch the bad case. Thoughts? > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > -- > > > > > > > Name: Joseph A. Williams > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > Sorry for being so slow - but I still don't really understand :( > > > > > > > > My concerns are really about whether or not we should allow the upgrade to be performed in this case. For sure I think we should > > > > > > > > > > > > > > > > 1) avoid the timeout, and > > > > > > > > 2) let the user know what the problem is > > > > > > > > > > > > > > > > but is it correct to let the upgrade pass after this? Is it not an error situation? > > > > > > > > > > > > > > > > It seems to me that we risk getting into a situation where we believe that the system is upgraded, but in fact there could be branches of the supervisor tree where process have not had the chance to run their code_change functions. I mean - even if we print the error report, there is no guarantee that it is really detected unless the operation actually fails. > > > > > > > > > > > > > > > > Please correct me if I completely misunderstood the situation. > > > > > > > > > > > > > > > > Regards > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Joe Williams > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > I ran into two issues that this patch addresses. Check out the commit message at https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for the details. In both cases I found that in production an error in the logs was preferable to the restart of the VM since both are easily fixable with a small application change or in the case of the suspended supervisor using a different app up. Also see this comment in release_handler_1 regarding the supervisor, https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which suggests this corner case is known by at least a few people. Currently there is no way to know *why* your VM just restarted after the upgrade in either case. > > > > > > > > > > > > > > > > > > Let me know if you have any other questions. > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > Could you please explain a bit about the situation where you discovered this problem? I agree that the timeout and VM restart is not very good, and it makes sense to check if the supervisor is suspended. But I'm not really sure if it is correct to allow the upgrade to continue when this error occurs. Even if an error message is printed, I guess it could be quite easy to miss this fact... and the question is if that would be a problem or not? Why is the supervisor suspended in the first place? > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Siri Hansen > > > > > > > > > > > Hi Joe - I've just started looking at this. Do you think it would be possible to add a test case for it? > > > > > > > > > > > Regards > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/24 Joe Williams > > > > > > > > > > > > Anything I can do regarding this patch? I have happily been running it in production since I submitted it to the list in June. > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Anything I can do to help this patch graduate? > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Updated this branch, please refetch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great, thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > Please fetch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a different branch with a better commit message and no white space changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent. I will include your patch in 'pu' after rewording the > > > > > > > > > > > > > > > > summary line to imperative form. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nothing specific, just wondered if anyone had any thoughts on how I dealt with a couple of corner cases in installing releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll fix things up and get back shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > Any thoughts/feedback on this patch? I realize it doesn't follow the guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly and will clean it up soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything in particular? I just got caught up in tideous merge work > > > > > > > > > > > > > > > > > > > yesterday and missed to include your patch in 'pu', I was about > > > > > > > > > > > > > > > > > > > to take it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you have a cleanup I can wait for it... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) release_handler > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > erlang-patches mailing list > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Sep 1 16:51:36 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 1 Sep 2011 16:51:36 +0200 Subject: [erlang-patches] What's cooking in erlang/otp (2011-09-01) Message-ID: <201109011451.p81EpYnG002384@smaug.otp.ericsson.se> Make sure to check the updated wiki on github. ------------------------------------------------------------ [Graduated] * fk/ref_manual_fix (otp) (2011-07-20) 1 commit + Fix non-existing function (erlang:disconnect/1) in distributed reference manual (da76dcc) * fm/gen_tcp_udp_doc_packet_type (kernel) (2011-06-19) 1 commit + Fix type of Packet arg of gen_tcp:send/2 and gen_udp:send/4 (af89387) * ft/fix_supervisor_temporary_restart (stdlib) (2011-08-03) 1 commit + fix supervisors restarting temporary children (4f9b938) * ml/two-trivial-documentation-fixes (otp, stdlib) (2011-06-21) 1 commit + Fix trivial documentation errors (217f907) * ms/epmd-fix-compiler-warnings (erts) (2011-06-03) 1 commit + epmd: fix compiler warnings (b5ff56d) * pl/no_bat_files_none_win32 (observer, webtool) (2011-07-21) 1 commit + Do not install *.bat files on non-win32 machines (a863e97) * rc/eunit-2.2.0 (eunit) (2011-07-18) 1 commit + Updated to EUnit version 2.2.0 (e70a2fd) * rc/stdlib-edoc-fix (stdlib) (2011-08-18) 1 commit + fix broken edoc annotations (6a49d6d) * rz/add_proplist_type (common_test, dialyzer, edoc, stdlib, test_server) (2011-05-22) 1 commit + Add a proplist() type (7d8a1f8) * ta/configure-fdatasync (erts) (2011-06-13) 2 commits + Document fdatasync -lrt requirement (SunOS <= 5.10) (8f0f462) + Move fdatasync autoconf checks to proper place (8b579a2) * ta/hipe_cleanup (hipe) (2011-07-05) 1 commit + Clean up hipe.hrl.src (Signed-off-by: Kostis) (aa1d02f) * ta/teach_emacs_yecc_and_leex_compile (tools) (2011-07-03) 1 commit + Teach the emacs mode to compile yecc and leex files (7afd736) * ta/wx-obsolete-guard (wx) (2011-06-28) 1 commit + wx: fix obsolete guard warning (list/1) (af61de4) ------------------------------------------------------------ [New topics] * pg/fix-cover-leftover-down-msg (tools) (2011-08-29) 1 commit - [cover]fix leftover {'DOWN', ..} msg in callers queue (07e2860) * sa/dialyzer-dev (dialyzer, hipe) (2011-01-30) 6 commits - Add origin information to #fun_var closures (4d9bf5c) - Suppress some warnings about generation of non-returning funs (45537dc) - Enhance Dialyzer's inference on comparisons (e7f7a30) - Fix infinite loop in dataflow (25b2e48) - Minor fix in dead code (ae96591) - Update r9c/{inets,mnesia} results in dialyzer's test suite (c68f922) ------------------------------------------------------------ [Stalled] * nox/xmerl-namespace-axis (xmerl) (2010-12-07) 12 commits . Implement namespace axis (27d791f) . Add `#xmlPI` support to xmerl_xpath:write_node/1 (75e67f5) . Fix processing-instruction(name?) (f05e78b) . Fix path filters (610df56) . Support more top-level primary expressions (770d6d9) . Accumulate comments in element nodes (e5b6b3a) . Add `default_attrs` option (18584c5) . Allow whole documents to be returned (aef3dea) . Track parents and namespace in `#xmlAttribute` nodes (dc9b220) . Track parents in `#xmlPI` nodes (5095331) . Set `vsn` field in `#xmlDecl` record (d712331) . Fix namespace-conformance constraints (e062270) Action expected from: R15 * pd/ttb-cleanup (observer, runtime_tools) (2011-08-25) 38 commits . Support for stopped and resumed tracing. (7e2c876) . More robust testing of tracing with 'local' option. (1924817) . Print path to logs dir unless nofetch option specified. (f7dc3bf) . Removed unused option to send realtime trace to erlide. (224f432) . Documented global state when applying formatting function to trace logs. (584eec8) . Test for: (BUGFIX) Error with ip tracing to wrap sets. (7f2123b) . Stop option 'return' changed to 'return_fetch_dir' (b610184) . update format function's description (e598660) . It is safe to change cwd on control node or remote nodes while tracing (2d319d3) . fixed documentation (4e3b8cc) . additional tests for ttb module (da2e84e) . new tests for ttb module (871839b) . . . Action expected from: R15 * bw/efile_exists (erts) (2010-10-07) 1 commit - prim_file:exists/{1,2} which is lightweight file existence check (7203932) Action expected from: Topic author * fm/posix-fallocate (erts, kernel) (2011-04-15) 4 commits - Added missing surrounding if statement (5ec9fab) - Fixes to file:allocate/2 and respective tests (d0fb479) - Fix build on Solaris (9b8aecf) - Added file:allocate/2 (7554dbb) Action expected from: Topic author * jn/gen_stream (stdlib) (2011-04-15) 2 commits - Update gen_stream tests to conform with common_test standard (9f50d34) - Add gen_stream behaviour (3065e10) Action expected from: OTP-Team * ms/epmd-IPv6-node-reg (erts, kernel) (2011-06-03) 1 commit - epmd: support IPv6 node registration (5523b21) Action expected from: R15 * sa/callback-attr (compiler, inets, kernel, orber, otp, stdlib) (2010-06-08) 8 commits - Add callback specs into 'application' module in kernel (4bca766) - Add callback specs to tftp module following internet documentation (bba649c) - Add callback specs to inets_service module following possibly deprecated comments (e41a958) - Add '-callback' attributes in stdlib's behaviours (d8d94c4) - Update primary bootstrap (199525a) - Update the documentation with information on the callback attribute (311a25f) - Automatically generate 'behaviour_info' function from '-callback' attributes (7c44f16) - Add '-callback' attribute to language syntax (e8336ff) Action expected from: OTP-Team * ta/typer-quote-atoms (hipe, typer) (2011-03-20) 1 commit - Quote atoms if necessary in types (254e21e) Action expected from: Hipe-team reviewer * hl/beam_disasm-no_attri_chunk (compiler) (2011-08-26) 2 commits - Add test suite for beam_disasm in compiler (63b3acf) - Fix error if no attributes chunk found in beam files (e0cca51) Action expected from: Topic author * pr/mnesia_frag_hash (mnesia) (2011-04-27) 2 commits - add mnesia_frag_hash test (1d6762d) - Reduce calls to phash in key_to_frag_number (67a20c0) Action expected from: Topic author * rc/epp-include-path-fix (stdlib) (2011-06-14) 1 commit - Make Erlang preprocessor check dir of current file first (b5d2469) Action expected from: Topic author ------------------------------------------------------------ [Cooking] * bg/temp-hipe-fixes (compiler, hipe, kernel) (2010-03-15) 6 commits - Avoid crash by skipping compilation_SUITE:on_load/1 (a8ea623) - Inline less aggressively for native-code compilation (1346686) - Crudely fix return type for the lists:key{search,find,member}/3 (c03a748) - seq_trace_SUITE: Don't native-compile (b8c17a9) - Disable native code if on_load is used (974ee4e) - andor_SUITE: Don't native-compile (86e4df8) This branch contains temporary workarounds to avoid failing test cases and is never intended to graduate. * cr/md2-With-RSA-Encryption (crypto, public_key) (2011-08-06) 1 commit - support md2WithRSAEncryption certificates in public_key (0535da1) * dc/fix_win32_static_crypto (crypto, erts) (2011-08-11) 1 commit - Fix win32 OpenSSL static linking broken in 20c9d6e (52230a4) * fm/enif_is_number (erts) (2011-06-08) 1 commit - Add NIF function enif_is_number (8db78b0) * fm/external_size_2 (erts, hipe) (2011-05-16) 1 commit - Add erlang:external_size/2 BIF (1b2cea3) * hw/detect-cpus-on-irix (erts) (2011-06-07) 1 commit - Detect the available CPUs on IRIX (e68fde9) * hw/ignore-empty-epmd-address (erts) (2011-07-13) 1 commit - Let epmd ignore empty ERL_EPMD_ADDRESS (32228c6) * jw/release_handler_1 (sasl) (2011-06-09) 1 commit - General improvements to get_supervised_procs (abcd0fb) * mp/xmerl-ucs2-fix (xmerl) (2011-08-25) 1 commit - Fixed xmerl_ucs UCS2 little endian en/decoding (374b029) * ms/ei-int-overflow-in-string-atom-enc (erl_interface) (2011-06-06) 1 commit - ei: integer overflow in string/atom encoding (9cf9cde) * rc/ftp-avoid-hanging (inets) (2010-08-25) 1 commit - Avoid hanging in socket-accept (cb7dfde) * rc/remote-shell-completion (kernel) (2010-10-22) 1 commit - make tab completion work in remote shells (73d1959) * ta/docs-fixes (common_test, cosFileTransfer, dialyzer, diameter, erts, hipe, ic, inets, kernel, otp, runtime_tools, ssl, stdlib, test_server, toolbar, tools, wx, xmerl) (2011-08-31) 17 commits - Fix more misspellings of compatibility (716fd41) - Fix misspelling of kept (3b7b509) - Fix misspelling of compatibility in ssl_basic_SUITE (b0a4cf4) - Fix misspelling of compatibility (4bd8f07) - Fix misspelling of accommodate (3d2b625) - Fix misspelling of exceed (c93eae8) - Fix misspelling of accidentally (5ad89f7) - Fix misspelling of erroneous in xmerl_xsd (5963237) - Fix misspelling of erroneous (4428847) - Fix misspelling of successful (7897415) - Fix typos in instrument(3) (80c0fb1) - Fix typos in dbg(3) (9617d46) . . . * ta/erl_compile-dead-code (stdlib) (2011-08-19) 1 commit - Remove dead code in erl_compile (4c63d9d) * ta/nif-variadic-funs (erts) (2011-05-13) 1 commit - erts: convert variadic nif funs into inline funs (9a1f9b6) * ta/sendfile (erts, kernel) (2011-01-13) 1 commit - Implement file:sendfile (d2ad2e9) * ta/werror (asn1, compiler, erts, parsetools, sasl) (2011-09-01) 15 commits - compiler, asn1 Makefiles: Use -Werror instead of +warnings_as_errors (d5b3407) - systools: add warnings_as_errors option (54fd64d) - asn1ct: add warnings_as_errors option (00127b8) - leex: optimize werror/1 (ba9553c) - yecc: optimize werror/1 (9735c11) - yecc: use more descriptive name: 'werror' (7d3e58c) - leex: use more descriptive name: 'werror' (cd1f08c) - compile: optimize werror/1 (585c20a) - compile: log warnings as errors if -Werror is enabled (8366321) - yecc: log warnings as errors if -Werror is enabled (6fa0895) - leex: log warnings as errors if -Werror is enabled (3fb7bc5) - yecc: honour -Werror passed from erlc (3c9faae) . . . * tn/inet_drv-fix (erts) (2011-04-08) 1 commit - Use libdlpi to get physical address (e360563) * va/http-win-dir-traversal (inets) (2011-08-26) 1 commit - Fix httpd directory traversal on Windows (a936795) * va/httpd-typo-fix (inets) (2011-08-25) 1 commit - Typofix in httpd_file:handle_error message (8fcbeef) ------------------------------------------------------------ [Dropped] * at/error_logger_calls (diameter, inets, ssl) (2011-07-01) 1 commit . Fix incorrect use of error_logger:(info|warning|error)_report/2 (ba12fcc) Fixed in a different way * fm/zlib_doc (erts, kernel) (2011-05-31) 1 commit . Fix doc and spec tags for a few zlib erlang module functions (efe2951) No longer relevant From joe@REDACTED Thu Sep 1 16:57:06 2011 From: joe@REDACTED (Joe Williams) Date: Thu, 1 Sep 2011 07:57:06 -0700 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> Message-ID: <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> Seems good to me, I went ahead and made the changes. Please refetch and let me know if there is anything else. -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > Thanks Joe! This looks very good. I have two minor comments only: > > 1) Maybe you could change the first line of the commit message to say > > General improvements to release_handler_1:get_supervised_procs > > or > > General improvements to get_supervised_procs in release_handler_1 > > 2) And when I looked at the tests it occured to me that it might be a good idea to change the error reasons to something more descriptive than 'release_handler_error'. What do you think? I know that there will be error messages in the shell, but I find it better if even the returned error reason gives a hint about what failed. My suggestions for the three calls to error/1 respectively (please change if you have better ideas): > > suspended_supervisor > {which_children_failed,Other} > {get_modules_failed,Other} > > Please let me know what you think about this. > > Regards > /siri > > 2011/9/1 Joe Williams > > Siri, > > > > I have added tests and squashed my commits, rewriting the commit message while I was at it. Please refetch and let me know if this is up to your standards for graduation. > > > > -Joe > > > > > > -- > > Name: Joseph A. Williams > > Email: joe@REDACTED (mailto:joe@REDACTED) > > Blog: http://www.joeandmotorboat.com/ > > Twitter: http://twitter.com/williamsjoe > > > > > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > > > > Hi Joe - Yes, you can put your application inside release_handler_SUITE_data/lib. And hopefully you can use the functions create_and_install_fake_first_release and create_fake_upgrade_release - you can see examples of that in release_handler_SUITE.erl. Please let me know if you need any more advice on the testing. > > > Regards > > > /siri > > > > > > > > > 2011/8/30 Joe Williams > > > > Siri, > > > > > > > > I could use some advice on how best to test this code. Currently I have a little dummy application with the proper supervision tree to trigger this upgrade case. Here are the steps I use to reproduce: > > > > > > > > https://gist.github.com/da109fb6939ef7aac031 > > > > > > > > Note that this is using my topic branch so you can see the additional logging. > > > > > > > > I noticed that there is a release_handler_SUITE_data directory in the sasl tests, should I just add another directory specifically for this and store the dummy application there for testing? > > > > > > > > Thanks. > > > > > > > > -Joe > > > > > > > > > > > > -- > > > > Name: Joseph A. Williams > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > Blog: http://www.joeandmotorboat.com/ > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > > > > > > > > Great Joe - this is much better :) > > > > > Could you please add some tests for this also? > > > > > Thanks > > > > > /siri > > > > > > > > > > 2011/8/29 Joe Williams > > > > > > Siri, > > > > > > > > > > > > Please fetch this branch again. > > > > > > > > > > > > I have added errors where I had my functions returning empty lists. I believe this should bubble up to release_handler causing a restart similar to the timeout behavior we currently have. > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > -- > > > > > > Name: Joseph A. Williams > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > In case #2 the node would be in an "unpacked" state but perhaps that isn't possible since the upgrade may be partially installed already. I'll work on implementing #1 and reply back soon. > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Name: Joseph A. Williams > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > Hi Joe - > > > > > > > > I think I would prefer solution 1), although that's probably mostly because I don't really understand solution 2)... What do you mean by "stop the upgrade from completing"? in which state would the node be after this? > > > > > > > > /siri > > > > > > > > > > > > > > > > 2011/8/26 Joe Williams > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > That sounds correct, with the current patch there is that risk. In my case I would see the error message post-upgrade and restart things as needed but I certainly see your point. The VM restarting is a brutal but idiomatic way to deal with this issue, let it fail :). > > > > > > > > > > > > > > > > > > I think there are two possibilities here, 1) continue with the restart behavior but make sure we print error messages before we do or 2) print error messages but stop the upgrade from completing if we catch the bad case. Thoughts? > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > Sorry for being so slow - but I still don't really understand :( > > > > > > > > > > My concerns are really about whether or not we should allow the upgrade to be performed in this case. For sure I think we should > > > > > > > > > > > > > > > > > > > > 1) avoid the timeout, and > > > > > > > > > > 2) let the user know what the problem is > > > > > > > > > > > > > > > > > > > > but is it correct to let the upgrade pass after this? Is it not an error situation? > > > > > > > > > > > > > > > > > > > > It seems to me that we risk getting into a situation where we believe that the system is upgraded, but in fact there could be branches of the supervisor tree where process have not had the chance to run their code_change functions. I mean - even if we print the error report, there is no guarantee that it is really detected unless the operation actually fails. > > > > > > > > > > > > > > > > > > > > Please correct me if I completely misunderstood the situation. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Joe Williams > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > I ran into two issues that this patch addresses. Check out the commit message at https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for the details. In both cases I found that in production an error in the logs was preferable to the restart of the VM since both are easily fixable with a small application change or in the case of the suspended supervisor using a different app up. Also see this comment in release_handler_1 regarding the supervisor, https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which suggests this corner case is known by at least a few people. Currently there is no way to know *why* your VM just restarted after the upgrade in either case. > > > > > > > > > > > > > > > > > > > > > > Let me know if you have any other questions. > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > Could you please explain a bit about the situation where you discovered this problem? I agree that the timeout and VM restart is not very good, and it makes sense to check if the supervisor is suspended. But I'm not really sure if it is correct to allow the upgrade to continue when this error occurs. Even if an error message is printed, I guess it could be quite easy to miss this fact... and the question is if that would be a problem or not? Why is the supervisor suspended in the first place? > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Siri Hansen > > > > > > > > > > > > > Hi Joe - I've just started looking at this. Do you think it would be possible to add a test case for it? > > > > > > > > > > > > > Regards > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/24 Joe Williams > > > > > > > > > > > > > > Anything I can do regarding this patch? I have happily been running it in production since I submitted it to the list in June. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything I can do to help this patch graduate? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Updated this branch, please refetch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great, thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > Please fetch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a different branch with a better commit message and no white space changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent. I will include your patch in 'pu' after rewording the > > > > > > > > > > > > > > > > > > summary line to imperative form. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nothing specific, just wondered if anyone had any thoughts on how I dealt with a couple of corner cases in installing releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll fix things up and get back shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > Any thoughts/feedback on this patch? I realize it doesn't follow the guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly and will clean it up soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything in particular? I just got caught up in tideous merge work > > > > > > > > > > > > > > > > > > > > > yesterday and missed to include your patch in 'pu', I was about > > > > > > > > > > > > > > > > > > > > > to take it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you have a cleanup I can wait for it... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) release_handler > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > erlang-patches mailing list > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdmanana@REDACTED Fri Sep 2 09:38:47 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 2 Sep 2011 00:38:47 -0700 Subject: [erlang-patches] [PATCH] - fix enif_compare bug on 64bits systems Message-ID: git fetch git://github.com/fdmanana/otp.git enif_compare_64_to_32bits_cast https://github.com/fdmanana/otp/compare/enif_compare_64_to_32bits_cast This issue was originally reported at erlang-bugs by Paul Davis: http://erlang.org/pipermail/erlang-bugs/2011-August/002565.html regards, -- Filipe David Manana, "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From magnus.henoch@REDACTED Fri Sep 2 19:11:14 2011 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Fri, 02 Sep 2011 18:11:14 +0100 (BST) Subject: [erlang-patches] run_erl: propagate exit status In-Reply-To: Message-ID: Hi all, Here is a patch that makes run_erl return the exit status of its child process. (Probably only useful when using run_erl without -daemon, just for convenient logging.) I added a signal handler for SIGALRM, since that appeared to be one of the ways run_erl exits, but I haven't been able to trigger that in my testing (it always exits because it can't read from the child's pty). I would appreciate informed opinions about whether that part is necessary and correct. git fetch git://github.com/legoscia/otp.git run_erl_exit_status https://github.com/legoscia/otp/commit/29364cf9a6e1fcfd032503ff9888cffc4327b867 Regards, Magnus From pguyot@REDACTED Sat Sep 3 20:06:39 2011 From: pguyot@REDACTED (Paul Guyot) Date: Sat, 3 Sep 2011 20:06:39 +0200 Subject: [erlang-patches] Patch for binary pattern matching of floats with HiPE Message-ID: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> Hello, HiPE generates bad code for a pattern matching of a float with a variable size length such as : <> The following function always fail when compiled natively and behaves as expected with BEAM: bin_to_float(B,S) -> <> = B, F. Judging from the almost identical code for integers, this obviously is a typo. I guess both code could be factorized, although I do not know what the policy is for duplicate code in HiPE (it's just about 14x2 lines). The following commit fixes this bug. Also, a test is obvious to implement and I wish HiPE tests were open source, so we could enrich them. https://github.com/pguyot/otp/commit/79e0c0345539624ed8bdcea2450dc2252f8375e8 git fetch git://github.com/pguyot/otp.git fix-hipe-bs_get_float2 Regards, Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From mikpe@REDACTED Sun Sep 4 14:41:15 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Sun, 4 Sep 2011 14:41:15 +0200 Subject: [erlang-patches] Patch for binary pattern matching of floats with HiPE In-Reply-To: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> References: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> Message-ID: <20067.29163.713999.867257@pilspetsen.it.uu.se> Paul Guyot writes: > Hello, > > HiPE generates bad code for a pattern matching of a float with a variable size length such as : > <> > > The following function always fail when compiled natively and behaves as expected with BEAM: > > bin_to_float(B,S) -> > <> = B, > F. > > Judging from the almost identical code for integers, this obviously is a typo. I guess both code could be factorized, although I do not know what the policy is for duplicate code in HiPE (it's just about 14x2 lines). > > The following commit fixes this bug. Also, a test is obvious to implement and I wish HiPE tests were open source, so we could enrich them. > > https://github.com/pguyot/otp/commit/79e0c0345539624ed8bdcea2450dc2252f8375e8 The above patch is Acked-by: Mikael Pettersson > git fetch git://github.com/pguyot/otp.git fix-hipe-bs_get_float2 > > Regards, > > Paul > -- > Semiocast http://semiocast.com/ > +33.183627948 - 20 rue Lacaze, 75014 Paris > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From kostis@REDACTED Mon Sep 5 11:53:59 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 05 Sep 2011 12:53:59 +0300 Subject: [erlang-patches] Patch for binary pattern matching of floats with HiPE In-Reply-To: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> References: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> Message-ID: <4E649C37.7010103@cs.ntua.gr> On 09/03/11 21:06, Paul Guyot wrote: > Hello, > > HiPE generates bad code for a pattern matching of a float with a variable size length such as : > <> > > The following function always fail when compiled natively and behaves as expected with BEAM: > > bin_to_float(B,S) -> > <> = B, > F. > > Judging from the almost identical code for integers, this obviously is a typo. I guess both code could be factorized, although I do not know what the policy is for duplicate code in HiPE (it's just about 14x2 lines). > > The following commit fixes this bug. Also, a test is obvious to implement and I wish HiPE tests were open source, so we could enrich them. > > https://github.com/pguyot/otp/commit/79e0c0345539624ed8bdcea2450dc2252f8375e8 > git fetch git://github.com/pguyot/otp.git fix-hipe-bs_get_float2 Hi Paul, Your patch is fine. As a matter of fact, I agree with you that the code around that line needs refactoring to avoid code duplication. If you have the time/energy to do this and add it to your patch, it will be appreciated. Otherwise, I guess your current patch will do. Can I ask the folks at OTP to add this to 'pu' and graduate it soon? Related to your wish, it's inaccurate that the HiPE tests are not open source. It's just that they are still under CVS (in a repository where only HiPE members have write access), using a different format than the ones in OTP. But they are available to anyone and you can get them via the command: cvs -d:pserver:guest@REDACTED:/hipe checkout tests Actually, there was a test for the case you discovered but for some unknown reason it was commented out :-( Not anymore. Merci beaucoup pour le "bug fix", Kostis From henrik@REDACTED Mon Sep 5 12:14:49 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 5 Sep 2011 12:14:49 +0200 Subject: [erlang-patches] Patch for binary pattern matching of floats with HiPE In-Reply-To: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> References: <0AB10E0E-65C7-44B7-ADBF-E04489AB025F@kallisys.net> Message-ID: <4E64A119.10707@erlang.org> On 09/03/2011 08:06 PM, Paul Guyot wrote: > Hello, > > HiPE generates bad code for a pattern matching of a float with a variable size length such as : > <> > > The following function always fail when compiled natively and behaves as expected with BEAM: > > bin_to_float(B,S) -> > <> = B, > F. > > Judging from the almost identical code for integers, this obviously is a typo. I guess both code could be factorized, although I do not know what the policy is for duplicate code in HiPE (it's just about 14x2 lines). > > The following commit fixes this bug. Also, a test is obvious to implement and I wish HiPE tests were open source, so we could enrich them. > > https://github.com/pguyot/otp/commit/79e0c0345539624ed8bdcea2450dc2252f8375e8 > git fetch git://github.com/pguyot/otp.git fix-hipe-bs_get_float2 > > Regards, > > Paul Hi I will include this in 'pu' and aim for fast graduation Thank you for the contribution! -- /Henrik Nord Erlang/OTP From joe@REDACTED Mon Sep 5 23:08:06 2011 From: joe@REDACTED (Joe Williams) Date: Mon, 5 Sep 2011 14:08:06 -0700 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> Message-ID: Siri, Please refetch and let me know if the test works for you now. Thanks! -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe On Monday, September 5, 2011 at 2:32 AM, Siri Hansen wrote: > Hi Joe - had a look at your changes... and it turned out to be quite interesting... > > First, I saw that you hadn't updated the test suite with the new exit reason - but when I executed the test it did not fail... :o > > It turned out that you catched the call to ?t:fail/1 - which actually only does an exit... I assume you meant "case catch" and not "catch case"... However, catching this is not at all necessary here, since it will be catched by the rpc:call anyway - it will return {badrpc, {'EXIT', {suspended_supervisor, _}}} . > > Also, two other comments on the test case: > > * when the call to get_supervised_procs return something unexpected - please print the return value in the test log (using e.g. ct:log/2) in order to make trouble shooting easier > * stopping the node could be moved outside of the test case, in order to avoid hanging nodes if the test fails. This you can do by adding something like > > supervisor_which_children_timeout(cleanup, Conf) -> > stop_node(node_name(supervisor_which_children_timeout)). > > > This will then be called during end_per_testcase. I see that there are other test cases that don't do this, and I will clean up that before the next release. > > Regards > /siri > > > 2011/9/1 Joe Williams > > Seems good to me, I went ahead and made the changes. > > > > Please refetch and let me know if there is anything else. > > > > -Joe > > > > > > -- > > Name: Joseph A. Williams > > Email: joe@REDACTED (mailto:joe@REDACTED) > > Blog: http://www.joeandmotorboat.com/ > > Twitter: http://twitter.com/williamsjoe > > > > > > On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > > > > > Thanks Joe! This looks very good. I have two minor comments only: > > > > > > 1) Maybe you could change the first line of the commit message to say > > > > > > General improvements to release_handler_1:get_supervised_procs > > > > > > or > > > > > > General improvements to get_supervised_procs in release_handler_1 > > > > > > 2) And when I looked at the tests it occured to me that it might be a good idea to change the error reasons to something more descriptive than 'release_handler_error'. What do you think? I know that there will be error messages in the shell, but I find it better if even the returned error reason gives a hint about what failed. My suggestions for the three calls to error/1 respectively (please change if you have better ideas): > > > > > > suspended_supervisor > > > {which_children_failed,Other} > > > {get_modules_failed,Other} > > > > > > Please let me know what you think about this. > > > > > > Regards > > > /siri > > > > > > 2011/9/1 Joe Williams > > > > Siri, > > > > > > > > I have added tests and squashed my commits, rewriting the commit message while I was at it. Please refetch and let me know if this is up to your standards for graduation. > > > > > > > > -Joe > > > > > > > > > > > > -- > > > > Name: Joseph A. Williams > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > Blog: http://www.joeandmotorboat.com/ > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > > > > > > > > Hi Joe - Yes, you can put your application inside release_handler_SUITE_data/lib. And hopefully you can use the functions create_and_install_fake_first_release and create_fake_upgrade_release - you can see examples of that in release_handler_SUITE.erl. Please let me know if you need any more advice on the testing. > > > > > Regards > > > > > /siri > > > > > > > > > > > > > > > 2011/8/30 Joe Williams > > > > > > Siri, > > > > > > > > > > > > I could use some advice on how best to test this code. Currently I have a little dummy application with the proper supervision tree to trigger this upgrade case. Here are the steps I use to reproduce: > > > > > > > > > > > > https://gist.github.com/da109fb6939ef7aac031 > > > > > > > > > > > > Note that this is using my topic branch so you can see the additional logging. > > > > > > > > > > > > I noticed that there is a release_handler_SUITE_data directory in the sasl tests, should I just add another directory specifically for this and store the dummy application there for testing? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > -- > > > > > > Name: Joseph A. Williams > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > > > > > > > > > > > > Great Joe - this is much better :) > > > > > > > Could you please add some tests for this also? > > > > > > > Thanks > > > > > > > /siri > > > > > > > > > > > > > > 2011/8/29 Joe Williams > > > > > > > > Siri, > > > > > > > > > > > > > > > > Please fetch this branch again. > > > > > > > > > > > > > > > > I have added errors where I had my functions returning empty lists. I believe this should bubble up to release_handler causing a restart similar to the timeout behavior we currently have. > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Name: Joseph A. Williams > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > In case #2 the node would be in an "unpacked" state but perhaps that isn't possible since the upgrade may be partially installed already. I'll work on implementing #1 and reply back soon. > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > Hi Joe - > > > > > > > > > > I think I would prefer solution 1), although that's probably mostly because I don't really understand solution 2)... What do you mean by "stop the upgrade from completing"? in which state would the node be after this? > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > 2011/8/26 Joe Williams > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > That sounds correct, with the current patch there is that risk. In my case I would see the error message post-upgrade and restart things as needed but I certainly see your point. The VM restarting is a brutal but idiomatic way to deal with this issue, let it fail :). > > > > > > > > > > > > > > > > > > > > > > I think there are two possibilities here, 1) continue with the restart behavior but make sure we print error messages before we do or 2) print error messages but stop the upgrade from completing if we catch the bad case. Thoughts? > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > Sorry for being so slow - but I still don't really understand :( > > > > > > > > > > > > My concerns are really about whether or not we should allow the upgrade to be performed in this case. For sure I think we should > > > > > > > > > > > > > > > > > > > > > > > > 1) avoid the timeout, and > > > > > > > > > > > > 2) let the user know what the problem is > > > > > > > > > > > > > > > > > > > > > > > > but is it correct to let the upgrade pass after this? Is it not an error situation? > > > > > > > > > > > > > > > > > > > > > > > > It seems to me that we risk getting into a situation where we believe that the system is upgraded, but in fact there could be branches of the supervisor tree where process have not had the chance to run their code_change functions. I mean - even if we print the error report, there is no guarantee that it is really detected unless the operation actually fails. > > > > > > > > > > > > > > > > > > > > > > > > Please correct me if I completely misunderstood the situation. > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Joe Williams > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > > > I ran into two issues that this patch addresses. Check out the commit message at https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for the details. In both cases I found that in production an error in the logs was preferable to the restart of the VM since both are easily fixable with a small application change or in the case of the suspended supervisor using a different app up. Also see this comment in release_handler_1 regarding the supervisor, https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which suggests this corner case is known by at least a few people. Currently there is no way to know *why* your VM just restarted after the upgrade in either case. > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if you have any other questions. > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please explain a bit about the situation where you discovered this problem? I agree that the timeout and VM restart is not very good, and it makes sense to check if the supervisor is suspended. But I'm not really sure if it is correct to allow the upgrade to continue when this error occurs. Even if an error message is printed, I guess it could be quite easy to miss this fact... and the question is if that would be a problem or not? Why is the supervisor suspended in the first place? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Siri Hansen > > > > > > > > > > > > > > > Hi Joe - I've just started looking at this. Do you think it would be possible to add a test case for it? > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/24 Joe Williams > > > > > > > > > > > > > > > > Anything I can do regarding this patch? I have happily been running it in production since I submitted it to the list in June. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything I can do to help this patch graduate? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Updated this branch, please refetch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great, thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > Please fetch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a different branch with a better commit message and no white space changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent. I will include your patch in 'pu' after rewording the > > > > > > > > > > > > > > > > > > > > summary line to imperative form. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nothing specific, just wondered if anyone had any thoughts on how I dealt with a couple of corner cases in installing releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll fix things up and get back shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > Any thoughts/feedback on this patch? I realize it doesn't follow the guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly and will clean it up soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything in particular? I just got caught up in tideous merge work > > > > > > > > > > > > > > > > > > > > > > > yesterday and missed to include your patch in 'pu', I was about > > > > > > > > > > > > > > > > > > > > > > > to take it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you have a cleanup I can wait for it... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) release_handler > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > erlang-patches mailing list > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Sep 6 09:45:56 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 6 Sep 2011 09:45:56 +0200 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> Message-ID: Hi Joe - looks good now! :) Thanks for your effort! /siri 2011/9/5 Joe Williams > Siri, > > Please refetch and let me know if the test works for you now. > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, September 5, 2011 at 2:32 AM, Siri Hansen wrote: > > Hi Joe - had a look at your changes... and it turned out to be quite > interesting... > > First, I saw that you hadn't updated the test suite with the new exit > reason - but when I executed the test it did not fail... :o > > It turned out that you catched the call to ?t:fail/1 - which actually only > does an exit... I assume you meant "case catch" and not "catch case"... > However, catching this is not at all necessary here, since it will be > catched by the rpc:call anyway - it will return {badrpc, {'EXIT', > {suspended_supervisor, _}}} . > > Also, two other comments on the test case: > > * when the call to get_supervised_procs return something unexpected - > please print the return value in the test log (using e.g. ct:log/2) in order > to make trouble shooting easier > * stopping the node could be moved outside of the test case, in order to > avoid hanging nodes if the test fails. This you can do by adding something > like > > supervisor_which_children_timeout(cleanup, Conf) -> > stop_node(node_name(supervisor_which_children_timeout)). > > This will then be called during end_per_testcase. I see that there are > other test cases that don't do this, and I will clean up that before the > next release. > > Regards > /siri > > > 2011/9/1 Joe Williams > > Seems good to me, I went ahead and made the changes. > > Please refetch and let me know if there is anything else. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > > Thanks Joe! This looks very good. I have two minor comments only: > > 1) Maybe you could change the first line of the commit message to say > > General improvements to release_handler_1:get_supervised_procs > > or > > General improvements to get_supervised_procs in release_handler_1 > > 2) And when I looked at the tests it occured to me that it might be a good > idea to change the error reasons to something more descriptive than > 'release_handler_error'. What do you think? I know that there will be error > messages in the shell, but I find it better if even the returned error > reason gives a hint about what failed. My suggestions for the three calls to > error/1 respectively (please change if you have better ideas): > > suspended_supervisor > {which_children_failed,Other} > {get_modules_failed,Other} > > Please let me know what you think about this. > > Regards > /siri > > 2011/9/1 Joe Williams > > Siri, > > I have added tests and squashed my commits, rewriting the commit message > while I was at it. Please refetch and let me know if this is up to your > standards for graduation. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > Hi Joe - Yes, you can put your application inside > release_handler_SUITE_data/lib. And hopefully you can use the > functions create_and_install_fake_first_release > and create_fake_upgrade_release - you can see examples of that in > release_handler_SUITE.erl. Please let me know if you need any more advice on > the testing. > Regards > /siri > > > 2011/8/30 Joe Williams > > Siri, > > I could use some advice on how best to test this code. Currently I have a > little dummy application with the proper supervision tree to trigger this > upgrade case. Here are the steps I use to reproduce: > > https://gist.github.com/da109fb6939ef7aac031 > > Note that this is using my topic branch so you can see the additional > logging. > > I noticed that there is a release_handler_SUITE_data directory in the sasl > tests, should I just add another directory specifically for this and store > the dummy application there for testing? > > Thanks. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > Great Joe - this is much better :) > Could you please add some tests for this also? > Thanks > /siri > > 2011/8/29 Joe Williams > > Siri, > > Please fetch this branch again. > > I have added errors where I had my functions returning empty lists. I > believe this should bubble up to release_handler causing a restart similar > to the timeout behavior we currently have. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > Siri, > > In case #2 the node would be in an "unpacked" state but perhaps that isn't > possible since the upgrade may be partially installed already. I'll work on > implementing #1 and reply back soon. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > Hi Joe - > I think I would prefer solution 1), although that's probably mostly because > I don't really understand solution 2)... What do you mean by "stop the > upgrade from completing"? in which state would the node be after this? > /siri > > 2011/8/26 Joe Williams > > Siri, > > That sounds correct, with the current patch there is that risk. In my case > I would see the error message post-upgrade and restart things as needed but > I certainly see your point. The VM restarting is a brutal but idiomatic way > to deal with this issue, let it fail :). > > I think there are two possibilities here, 1) continue with the restart > behavior but make sure we print error messages before we do or 2) print > error messages but stop the upgrade from completing if we catch the bad > case. Thoughts? > > -Joe > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > Hi again, Joe! > > Sorry for being so slow - but I still don't really understand :( > My concerns are really about whether or not we should allow the upgrade to > be performed in this case. For sure I think we should > > 1) avoid the timeout, and > 2) let the user know what the problem is > > but is it correct to let the upgrade pass after this? Is it not an error > situation? > > It seems to me that we risk getting into a situation where we believe > that the system is upgraded, but in fact there could be branches of the > supervisor tree where process have not had the chance to run their > code_change functions. I mean - even if we print the error report, there is > no guarantee that it is really detected unless the operation actually fails. > > Please correct me if I completely misunderstood the situation. > > Regards > /siri > > > 2011/8/25 Joe Williams > > Siri, > > I ran into two issues that this patch addresses. Check out the commit > message at > https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for > the details. In both cases I found that in production an error in the logs > was preferable to the restart of the VM since both are easily fixable with a > small application change or in the case of the suspended supervisor using a > different app up. Also see this comment in release_handler_1 regarding the > supervisor, > https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which > suggests this corner case is known by at least a few people. Currently there > is no way to know *why* your VM just restarted after the upgrade in either > case. > > Let me know if you have any other questions. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > Hi again, Joe! > > Could you please explain a bit about the situation where you discovered > this problem? I agree that the timeout and VM restart is not very good, and > it makes sense to check if the supervisor is suspended. But I'm not really > sure if it is correct to allow the upgrade to continue when this error > occurs. Even if an error message is printed, I guess it could be quite easy > to miss this fact... and the question is if that would be a problem or not? > Why is the supervisor suspended in the first place? > > Regards > /siri > > > 2011/8/25 Siri Hansen > > Hi Joe - I've just started looking at this. Do you think it would be > possible to add a test case for it? > Regards > /siri > > > 2011/8/24 Joe Williams > > Anything I can do regarding this patch? I have happily been running it in > production since I submitted it to the list in June. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > Anything I can do to help this patch graduate? > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > Updated this branch, please refetch. > > git fetch git://github.com/joewilliams/otp.git release_handler_1 > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > Great, thanks! > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > Please fetch: > > git fetch git://github.com/joewilliams/otp.git release_handler_1 > > This is a different branch with a better commit message and no white space > changes. > > > Excellent. I will include your patch in 'pu' after rewording the > summary line to imperative form. > > > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > Nothing specific, just wondered if anyone had any thoughts on how I dealt > with a couple of corner cases in installing releases. > > I'll fix things up and get back shortly. > > -- > Name: Joseph A. Williams > Email: joe@REDACTED (mailto:joe@REDACTED ) > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > Any thoughts/feedback on this patch? I realize it doesn't follow the > guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly > and will clean it up soon. > > > Anything in particular? I just got caught up in tideous merge work > yesterday and missed to include your patch in 'pu', I was about > to take it now. > > But if you have a cleanup I can wait for it... > > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED (mailto:joe@REDACTED ) > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > git fetch git://github.com/joewilliams/otp.git ( > http://github.com/joewilliams/otp.git) ( > http://github.com/joewilliams/otp.git) release_handler > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED > ) > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED > ) > http://erlang.org/mailman/listinfo/erlang-patches > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david@REDACTED Tue Sep 6 10:36:54 2011 From: david@REDACTED (David JULIEN) Date: Tue, 06 Sep 2011 08:36:54 -0000 Subject: [erlang-patches] [PATCH] Add latin9 support in xmerl_ucs Message-ID: Hello, Add latin9 support (translate latin9 characters to ucs4 characters) in xmerl_ucs. Latin9 is similar to latin1 except for 8 characters (see http://en.wikipedia.org/wiki/ISO/IEC_8859-15). git fetch git://github.com/davidjulien/otp.git xmerl_ucs-latin9-support https://github.com/davidjulien/otp/commit/60c2511da7fb72197a807e77e62fdf671676e718 Best regards, David JULIEN http://semiocast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Sep 6 11:49:22 2011 From: henrik@REDACTED (Henrik Nord) Date: Tue, 6 Sep 2011 11:49:22 +0200 Subject: [erlang-patches] [PATCH] Add latin9 support in xmerl_ucs In-Reply-To: References: Message-ID: <4E65ECA2.7070700@erlang.org> On 07/29/2011 11:52 AM, David JULIEN wrote: > Hello, > > Add latin9 support (translate latin9 characters to ucs4 characters) in > xmerl_ucs. Latin9 is similar to latin1 except for 8 characters (see > http://en.wikipedia.org/wiki/ISO/IEC_8859-15 > ). > > git fetch git://github.com/davidjulien/otp.git xmerl_ucs-latin9-support > > https://github.com/davidjulien/otp/commit/60c2511da7fb72197a807e77e62fdf671676e718 > > > Best regards, > > David JULIEN > http://semiocast.com > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Somehow I got this email today, a "small" delay on the mailserver. I have included you patch in 'pu' -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Sep 6 15:49:48 2011 From: henrik@REDACTED (Henrik Nord) Date: Tue, 6 Sep 2011 15:49:48 +0200 Subject: [erlang-patches] support md2WithRSAEncryption certificates In-Reply-To: <87sjpeml6v.fsf@sloppy.mti.ag> References: <87sjpeml6v.fsf@sloppy.mti.ag> Message-ID: <4E6624FC.30504@erlang.org> On 08/06/2011 08:47 PM, Christian von Roques wrote: > I've added support for md2WithRSAEncryption certificates to public_key > and the necessary support for md2 to crypto:rsa_sign/3 and > crypto:rsa_verify/4. > > git fetch git://github.com/roques/otp.git md2WithRSAEncryption > > > I did this to solve the following urgent problem, which others might > stumble upon in the future as well: One of our service providers > switched their SSL-certificate. The new certificate is issued by > "VeriSign International Server CA - Class 3", which is included in many > collections of trusted root certificates. However, to be supported by > ancient software VeriSign's Class 3 certificate itself is issued by > VeriSign's "Class 3 Public Primary Certification Authority", which is a > self-signed md2WithRSAEncryption certificate. All this would not be a > problem in itself, our service provider however has bundled his > certificate with the complete certificate chain up to and *including* > VeriSign's md2WithRSAEncryption root-certificate. This mistake causes > OTP's ssl to try and fail to verify the self-signature of VeriSign's > root-certificate, because it does not yet know how to check > md2WithRSAEncryption signatures. > > Attempts to solve the problem via polite requests to our service > provider not to include VeriSign's root certificate in the certificate > chain up to now just got "upgrade your Java to a current version" > replies. --- I'm not sure if my patch counts as "upgrading Java", but > it solves the problem :-) > > Christian. > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello we would like you to correct the following for us to include this branch. * add documentation for crypto * add test case for crypto * Split into two commits (crypto and public_key) /Sverker -- /Henrik Nord Erlang/OTP From joe@REDACTED Tue Sep 6 17:51:22 2011 From: joe@REDACTED (Joe Williams) Date: Tue, 6 Sep 2011 08:51:22 -0700 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> Message-ID: <70DFFEE9A63041B38ADB25FACFA6F331@joetify.com> Great, let me know if any other changes are needed. Thanks! -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe On Tuesday, September 6, 2011 at 12:45 AM, Siri Hansen wrote: > Hi Joe - looks good now! :) > Thanks for your effort! > /siri > > 2011/9/5 Joe Williams > > Siri, > > > > Please refetch and let me know if the test works for you now. > > > > Thanks! > > > > -Joe > > > > > > -- > > Name: Joseph A. Williams > > Email: joe@REDACTED (mailto:joe@REDACTED) > > Blog: http://www.joeandmotorboat.com/ > > Twitter: http://twitter.com/williamsjoe > > > > > > On Monday, September 5, 2011 at 2:32 AM, Siri Hansen wrote: > > > > > Hi Joe - had a look at your changes... and it turned out to be quite interesting... > > > > > > First, I saw that you hadn't updated the test suite with the new exit reason - but when I executed the test it did not fail... :o > > > > > > It turned out that you catched the call to ?t:fail/1 - which actually only does an exit... I assume you meant "case catch" and not "catch case"... However, catching this is not at all necessary here, since it will be catched by the rpc:call anyway - it will return {badrpc, {'EXIT', {suspended_supervisor, _}}} . > > > > > > Also, two other comments on the test case: > > > > > > * when the call to get_supervised_procs return something unexpected - please print the return value in the test log (using e.g. ct:log/2) in order to make trouble shooting easier > > > * stopping the node could be moved outside of the test case, in order to avoid hanging nodes if the test fails. This you can do by adding something like > > > > > > supervisor_which_children_timeout(cleanup, Conf) -> > > > stop_node(node_name(supervisor_which_children_timeout)). > > > > > > > > > This will then be called during end_per_testcase. I see that there are other test cases that don't do this, and I will clean up that before the next release. > > > > > > Regards > > > /siri > > > > > > > > > 2011/9/1 Joe Williams > > > > Seems good to me, I went ahead and made the changes. > > > > > > > > Please refetch and let me know if there is anything else. > > > > > > > > -Joe > > > > > > > > > > > > -- > > > > Name: Joseph A. Williams > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > Blog: http://www.joeandmotorboat.com/ > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > > > > > > > > > Thanks Joe! This looks very good. I have two minor comments only: > > > > > > > > > > 1) Maybe you could change the first line of the commit message to say > > > > > > > > > > General improvements to release_handler_1:get_supervised_procs > > > > > > > > > > or > > > > > > > > > > General improvements to get_supervised_procs in release_handler_1 > > > > > > > > > > 2) And when I looked at the tests it occured to me that it might be a good idea to change the error reasons to something more descriptive than 'release_handler_error'. What do you think? I know that there will be error messages in the shell, but I find it better if even the returned error reason gives a hint about what failed. My suggestions for the three calls to error/1 respectively (please change if you have better ideas): > > > > > > > > > > suspended_supervisor > > > > > {which_children_failed,Other} > > > > > {get_modules_failed,Other} > > > > > > > > > > Please let me know what you think about this. > > > > > > > > > > Regards > > > > > /siri > > > > > > > > > > 2011/9/1 Joe Williams > > > > > > Siri, > > > > > > > > > > > > I have added tests and squashed my commits, rewriting the commit message while I was at it. Please refetch and let me know if this is up to your standards for graduation. > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > -- > > > > > > Name: Joseph A. Williams > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > > > > > > > > > > > > Hi Joe - Yes, you can put your application inside release_handler_SUITE_data/lib. And hopefully you can use the functions create_and_install_fake_first_release and create_fake_upgrade_release - you can see examples of that in release_handler_SUITE.erl. Please let me know if you need any more advice on the testing. > > > > > > > Regards > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > 2011/8/30 Joe Williams > > > > > > > > Siri, > > > > > > > > > > > > > > > > I could use some advice on how best to test this code. Currently I have a little dummy application with the proper supervision tree to trigger this upgrade case. Here are the steps I use to reproduce: > > > > > > > > > > > > > > > > https://gist.github.com/da109fb6939ef7aac031 > > > > > > > > > > > > > > > > Note that this is using my topic branch so you can see the additional logging. > > > > > > > > > > > > > > > > I noticed that there is a release_handler_SUITE_data directory in the sasl tests, should I just add another directory specifically for this and store the dummy application there for testing? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Name: Joseph A. Williams > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > Great Joe - this is much better :) > > > > > > > > > Could you please add some tests for this also? > > > > > > > > > Thanks > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > 2011/8/29 Joe Williams > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > Please fetch this branch again. > > > > > > > > > > > > > > > > > > > > I have added errors where I had my functions returning empty lists. I believe this should bubble up to release_handler causing a restart similar to the timeout behavior we currently have. > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > In case #2 the node would be in an "unpacked" state but perhaps that isn't possible since the upgrade may be partially installed already. I'll work on implementing #1 and reply back soon. > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Joe - > > > > > > > > > > > > I think I would prefer solution 1), although that's probably mostly because I don't really understand solution 2)... What do you mean by "stop the upgrade from completing"? in which state would the node be after this? > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/26 Joe Williams > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > > > That sounds correct, with the current patch there is that risk. In my case I would see the error message post-upgrade and restart things as needed but I certainly see your point. The VM restarting is a brutal but idiomatic way to deal with this issue, let it fail :). > > > > > > > > > > > > > > > > > > > > > > > > > > I think there are two possibilities here, 1) continue with the restart behavior but make sure we print error messages before we do or 2) print error messages but stop the upgrade from completing if we catch the bad case. Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry for being so slow - but I still don't really understand :( > > > > > > > > > > > > > > My concerns are really about whether or not we should allow the upgrade to be performed in this case. For sure I think we should > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) avoid the timeout, and > > > > > > > > > > > > > > 2) let the user know what the problem is > > > > > > > > > > > > > > > > > > > > > > > > > > > > but is it correct to let the upgrade pass after this? Is it not an error situation? > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems to me that we risk getting into a situation where we believe that the system is upgraded, but in fact there could be branches of the supervisor tree where process have not had the chance to run their code_change functions. I mean - even if we print the error report, there is no guarantee that it is really detected unless the operation actually fails. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please correct me if I completely misunderstood the situation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Joe Williams > > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I ran into two issues that this patch addresses. Check out the commit message at https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for the details. In both cases I found that in production an error in the logs was preferable to the restart of the VM since both are easily fixable with a small application change or in the case of the suspended supervisor using a different app up. Also see this comment in release_handler_1 regarding the supervisor, https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which suggests this corner case is known by at least a few people. Currently there is no way to know *why* your VM just restarted after the upgrade in either case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if you have any other questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please explain a bit about the situation where you discovered this problem? I agree that the timeout and VM restart is not very good, and it makes sense to check if the supervisor is suspended. But I'm not really sure if it is correct to allow the upgrade to continue when this error occurs. Even if an error message is printed, I guess it could be quite easy to miss this fact... and the question is if that would be a problem or not? Why is the supervisor suspended in the first place? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Siri Hansen > > > > > > > > > > > > > > > > > Hi Joe - I've just started looking at this. Do you think it would be possible to add a test case for it? > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/24 Joe Williams > > > > > > > > > > > > > > > > > > Anything I can do regarding this patch? I have happily been running it in production since I submitted it to the list in June. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything I can do to help this patch graduate? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Updated this branch, please refetch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great, thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > Please fetch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a different branch with a better commit message and no white space changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent. I will include your patch in 'pu' after rewording the > > > > > > > > > > > > > > > > > > > > > > summary line to imperative form. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nothing specific, just wondered if anyone had any thoughts on how I dealt with a couple of corner cases in installing releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll fix things up and get back shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Any thoughts/feedback on this patch? I realize it doesn't follow the guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly and will clean it up soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything in particular? I just got caught up in tideous merge work > > > > > > > > > > > > > > > > > > > > > > > > > yesterday and missed to include your patch in 'pu', I was about > > > > > > > > > > > > > > > > > > > > > > > > > to take it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you have a cleanup I can wait for it... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) release_handler > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roques@REDACTED Tue Sep 6 20:35:22 2011 From: roques@REDACTED (Christian von Roques) Date: Tue, 06 Sep 2011 20:35:22 +0200 Subject: [erlang-patches] support md2WithRSAEncryption certificates In-Reply-To: <4E6624FC.30504@erlang.org> (Henrik Nord's message of "Tue, 6 Sep 2011 15:49:48 +0200") References: <87sjpeml6v.fsf@sloppy.mti.ag> <4E6624FC.30504@erlang.org> Message-ID: <87r53tr02d.fsf@sloppy.mti.ag> Henrik Nord writes: > On 08/06/2011 08:47 PM, Christian von Roques wrote: >> I've added support for md2WithRSAEncryption certificates to public_key >> and the necessary support for md2 to crypto:rsa_sign/3 and >> crypto:rsa_verify/4. >> [...] > we would like you to correct the following for us to include this branch. > > * add documentation for crypto > * add test case for crypto > * Split into two commits (crypto and public_key) done. Please re-fetch git fetch git://github.com/roques/otp.git md2WithRSAEncryption The branch now consists of the requested two commits and an additional trivial third commit documenting crypto:sha_mac_96/2 to compute an SHA MAC, not MD5. Christian. From roques@REDACTED Tue Sep 6 20:56:25 2011 From: roques@REDACTED (Christian von Roques) Date: Tue, 06 Sep 2011 20:56:25 +0200 Subject: [erlang-patches] cppcheck(1) inspired changes Message-ID: <87mxehqz3a.fsf@sloppy.mti.ag> I toyed with cppcheck(1) http://cppcheck.sourceforge.net/ a static analysis tool for C/C++ code. It warned about several places in the Erlang sources, but despite its intention to have zero false positives, not all its findings were caused by real errors in the code. git fetch git://github.com/roques/otp.git cppcheck This branch contains a few changes inspired by cppcheck(1)'s findings, I don't think any of them are really urgent, but they still are fixes: * One potential use of an uninitialized variable when neither ERTS_SMP nor ERTS_POLL_ASYNC_INTERRUPT_SUPPORT is defined. * Not leaving erl_eterm_state locked when malloc(3) fails in erl_eterm_alloc(). * Two malloc-leaks in error paths of mn_send_write() and ei_reg_restore(). Christian. From acmmlyc@REDACTED Wed Sep 7 01:31:23 2011 From: acmmlyc@REDACTED (Anneli Cuss) Date: Wed, 7 Sep 2011 09:31:23 +1000 Subject: [erlang-patches] [PATCH 1/1] Documentation fix: ei_decode_ei_term() returns 1 if index is incremented Message-ID: Hi all, Included is a documentation fix and very minor clean-up for ei_decode_ei_term(). Links follow, then the synopsis. ? ??git fetch git://github.com/celtic/otp.git fix_erl_interface_docs ? ??https://github.com/celtic/otp/compare/fix_erl_interface_docs ? ??https://github.com/celtic/otp/compare/fix_erl_interface_docs.patch The function terminates with: ? ? ? ? *index += s-s0; ? ? ? ? return 1; ? ? } We note that there is no other case of `return 1` in the function (i.e. the function never returns `1` without incrementing `*index`). There are a few cases of returning `0`, and in none of these cases is `*index` incremented. There are a few cases like this, however: ? ? ? ? case ERL_SMALL_TUPLE_EXT: ? ? ? ? ? ? term->arity = get8(s); ? ? ? ? ? ? break; /*return 0;*/ Thus `1` will be ultimately returned, and the tuple header passed. This is good behaviour, but the documentation needs to reflect it. The commented returns could probably do with being removed. Thanks, Anneli From henrik@REDACTED Wed Sep 7 10:43:04 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 7 Sep 2011 10:43:04 +0200 Subject: [erlang-patches] support md2WithRSAEncryption certificates In-Reply-To: <87r53tr02d.fsf@sloppy.mti.ag> References: <87sjpeml6v.fsf@sloppy.mti.ag> <4E6624FC.30504@erlang.org> <87r53tr02d.fsf@sloppy.mti.ag> Message-ID: <4E672E98.7000509@erlang.org> On 09/06/2011 08:35 PM, Christian von Roques wrote: > Henrik Nord writes: >> On 08/06/2011 08:47 PM, Christian von Roques wrote: >>> I've added support for md2WithRSAEncryption certificates to public_key >>> and the necessary support for md2 to crypto:rsa_sign/3 and >>> crypto:rsa_verify/4. >>> [...] >> we would like you to correct the following for us to include this branch. >> >> * add documentation for crypto >> * add test case for crypto >> * Split into two commits (crypto and public_key) > done. > > Please re-fetch > > git fetch git://github.com/roques/otp.git md2WithRSAEncryption > > The branch now consists of the requested two commits and an additional > trivial third commit documenting crypto:sha_mac_96/2 to compute an SHA > MAC, not MD5. > > Christian. Great thanks for the fast update, refetched! -- /Henrik Nord Erlang/OTP From henrik@REDACTED Wed Sep 7 10:51:43 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 7 Sep 2011 10:51:43 +0200 Subject: [erlang-patches] cppcheck(1) inspired changes In-Reply-To: <87mxehqz3a.fsf@sloppy.mti.ag> References: <87mxehqz3a.fsf@sloppy.mti.ag> Message-ID: <4E67309F.5030105@erlang.org> On 09/06/2011 08:56 PM, Christian von Roques wrote: > I toyed with cppcheck(1) http://cppcheck.sourceforge.net/ > a static analysis tool for C/C++ code. It warned about several places > in the Erlang sources, but despite its intention to have zero false > positives, not all its findings were caused by real errors in the code. > > git fetch git://github.com/roques/otp.git cppcheck > > This branch contains a few changes inspired by cppcheck(1)'s findings, > I don't think any of them are really urgent, but they still are fixes: > > * One potential use of an uninitialized variable when neither ERTS_SMP > nor ERTS_POLL_ASYNC_INTERRUPT_SUPPORT is defined. > > * Not leaving erl_eterm_state locked when malloc(3) fails in > erl_eterm_alloc(). > > * Two malloc-leaks in error paths of mn_send_write() and ei_reg_restore(). > > Christian. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hi I have included your branch in 'pu' -- /Henrik Nord Erlang/OTP From henrik@REDACTED Wed Sep 7 10:59:09 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 7 Sep 2011 10:59:09 +0200 Subject: [erlang-patches] [PATCH 1/1] Documentation fix: ei_decode_ei_term() returns 1 if index is incremented In-Reply-To: References: Message-ID: <4E67325D.1080101@erlang.org> On 09/07/2011 01:31 AM, Anneli Cuss wrote: > git fetch git://github.com/celtic/otp.git fix_erl_interface_docs Thank you for the contribution. I have included you branch in 'pu', and modified your really long commit msg lines. -- /Henrik Nord Erlang/OTP From lihaitao@REDACTED Thu Sep 8 06:16:31 2011 From: lihaitao@REDACTED (Haitao Li) Date: Thu, 8 Sep 2011 12:16:31 +0800 Subject: [erlang-patches] [PATCH] ms_tranform: Fix incorrect `variable shadowed' warnings In-Reply-To: References: Message-ID: On Fri, Aug 26, 2011 at 10:42 AM, Haitao Li wrote: > Hi, > > The scope for a variable is its function clause. Variables bound in one > function clause should not interfere with other function clauses. This > patch removes incorrect passing of variable bindings from one function > clause to another. > > git fetch git://github.com/lht/otp.git fix-ms_transform-scope-warn > https://github.com/lht/otp/compare/fix-ms_transform-scope-warn > https://github.com/lht/otp/compare/fix-ms_transform-scope-warn.patch > May I know status about this patch? Is it uninterested by OTP or, is the patch itself incorrect at all? I have amended the commit message by adding detail about reproducing the issue. - Haitao From henrik@REDACTED Thu Sep 8 09:43:00 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 8 Sep 2011 09:43:00 +0200 Subject: [erlang-patches] [PATCH] ms_tranform: Fix incorrect `variable shadowed' warnings In-Reply-To: References: Message-ID: <4E687204.2050308@erlang.org> On 09/08/2011 06:16 AM, Haitao Li wrote: > On Fri, Aug 26, 2011 at 10:42 AM, Haitao Li wrote: >> Hi, >> >> The scope for a variable is its function clause. Variables bound in one >> function clause should not interfere with other function clauses. This >> patch removes incorrect passing of variable bindings from one function >> clause to another. >> >> git fetch git://github.com/lht/otp.git fix-ms_transform-scope-warn >> https://github.com/lht/otp/compare/fix-ms_transform-scope-warn >> https://github.com/lht/otp/compare/fix-ms_transform-scope-warn.patch >> > May I know status about this patch? Is it uninterested by OTP or, is > the patch itself incorrect at all? > > I have amended the commit message by adding detail about reproducing the issue. > > - Haitao > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches I had actually missed this patch. I dont know if it was me or the mail servers not delivering it to me until now. But thank you for the bump, I have now included it in 'pu' and will investigate further. Thank you for the contribution, and sorry for the delay and trubble -- /Henrik Nord Erlang/OTP From lihaitao@REDACTED Thu Sep 8 10:28:35 2011 From: lihaitao@REDACTED (Haitao Li) Date: Thu, 8 Sep 2011 16:28:35 +0800 Subject: [erlang-patches] [PATCH] ms_tranform: Fix incorrect `variable shadowed' warnings In-Reply-To: <4E687204.2050308@erlang.org> References: <4E687204.2050308@erlang.org> Message-ID: > I had actually missed this patch. > I dont know if it was me or the mail servers not delivering it to me until > now. > > But thank you for the bump, I have now included it in 'pu' and will > investigate further. > > Thank you for the contribution, and sorry for the delay and trubble > Great! Thank you for the update! /Haitao From christopher.faulet@REDACTED Thu Sep 8 10:57:22 2011 From: christopher.faulet@REDACTED (Christopher Faulet) Date: Thu, 08 Sep 2011 10:57:22 +0200 Subject: [erlang-patches] Supervisor improvements Message-ID: <4E688372.4000101@capflam.org> Hi, Here are 2 patches to improve supervisor behavior: * Explicitly kill dynamic child processes when simple-one-for-one supervisor terminates: git fetch git://github.com/capflam/otp.git simple_one_for_one_shutdown https://github.com/capflam/otp/compare/simple_one_for_one_shutdown https://github.com/capflam/otp/compare/simple_one_for_one_shutdown.patch * Allow an infinite timeout to shutdown worker processes: git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity https://github.com/capflam/otp/compare/supervisor_shutdown_infinity https://github.com/capflam/otp/compare/supervisor_shutdown_infinity.patch Best regards, -- Christopher Faulet http://www.yakaz.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From erlangsiri@REDACTED Thu Sep 8 12:24:41 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 8 Sep 2011 12:24:41 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: <4E688372.4000101@capflam.org> References: <4E688372.4000101@capflam.org> Message-ID: Hi Christopher! Thanks for you contribution! Could you please give some background information regarding the use of these new features? In which situations do you find them useful? Regards /siri@REDACTED 2011/9/8 Christopher Faulet > Hi, > > Here are 2 patches to improve supervisor behavior: > > * Explicitly kill dynamic child processes when simple-one-for-one > supervisor terminates: > > git fetch git://github.com/capflam/otp.git simple_one_for_one_shutdown > > https://github.com/capflam/otp/compare/simple_one_for_one_shutdown > https://github.com/capflam/otp/compare/simple_one_for_one_shutdown.patch > > > * Allow an infinite timeout to shutdown worker processes: > > git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity > > https://github.com/capflam/otp/compare/supervisor_shutdown_infinity > https://github.com/capflam/otp/compare/supervisor_shutdown_infinity.patch > > Best regards, > -- > Christopher Faulet > http://www.yakaz.com > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.faulet@REDACTED Thu Sep 8 15:16:27 2011 From: christopher.faulet@REDACTED (Christopher Faulet) Date: Thu, 08 Sep 2011 15:16:27 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: References: <4E688372.4000101@capflam.org> Message-ID: <4E68C02B.7010208@capflam.org> Le 08/09/2011 12:24, Siri Hansen a ?crit : > Hi Christopher! > > Thanks for you contribution! Could you please give some background > information regarding the use of these new features? In which situations > do you find them useful? > Yes, sure. Set the shutdown strategy of a supervisor to infinity when child process is a worker is useful when its cleanup _MUST_ be done or when it _MUST_ reply to a request in progress. For example, If you have a process that read its internal state in a database when 'Module:init/1' is called and write it in 'Module:terminate/2'. It's hard to set an upper bound timeout here. And, for some external reasons, it may be slow. In all case, you want to be sure that the supervisor won't kill the process too early. Here, an infinite timeout is a good solution. It exists some workarounds, but not usable in all cases. I think that killing a worker after a timeout is highly application-dependent. It's a shame to force developers to use it. My approach is to let the choice. The problem with simple_one_for_one supervisors has already been explained on erlang-questions [1]. A nice workaround is used in Agner [2]. IMHO, it's a breach of promises made by the supervisor behavior. its purpose is to start, stop and monitor its child processes, restarting them when necessary. There is no reason to deal with dynamic child processes in a different way than other child processes. this can be seen as a lack of consistency. In fact, my patches try to solve 2 sides of the same problem: How to control the shutdown of a worker in a supervision tree, no matter what happens. [1] http://erlang.org/pipermail/erlang-questions/2011-February/056228.html [2] https://github.com/agner/agner/blob/master/src/agner_app.erl -- Christopher Faulet http://www.yakaz.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From rh@REDACTED Mon Sep 12 16:31:56 2011 From: rh@REDACTED (Robin Haberkorn) Date: Mon, 12 Sep 2011 16:31:56 +0200 (CEST) Subject: [erlang-patches] Improving supervisor shutdown procedure In-Reply-To: Message-ID: Hi! I've just observed a very peculiar behaviour of the OTP supervisor and application controller, on one of our embedded Erlang nodes: When a supervisor gets stuck in an infinite process restart loop, it does not (and cannot) respond to shutdown signals. More specifically this happens if the supervised process crashes in its start function (and it's not the initial process start, of course). I know that a supervisor shouldn't get stuck in an endless loop and that you probably have good reason to handle restarts that way. I nevertheless would like to hear your opinion. Now, if the erlang node is to shut down (either because it's told so or a permanent application terminates), the application controller will signal all application masters to shut down. However it does so without any timeout after which a kill signal would be sent. If there exists a supervisor stuck in a restart loop like the one described above, the application controller will dead lock. One of the reasons why this may happen is the start function (e.g. init/1 in the gen_server callback module), taking too long before failing, which may be because of a gen_server call timeout (about which the supervised process does not necessarily know anything). It may even be that by unfavourable timing / race condition, the application controller terminates while a supervisor is just restarting a process doing an application module call (e.g. application:set_env/3) in its init which then has to time out, resulting in a perfect dead lock. Indeed this is exactly what has happened to me. A test case for reproducing this behaviour can be downloaded from github (it's a small OTP application): https://github.com/downloads/travelping/otp/supervisor_deadlock_testcase.tar.gz Call deadlock_app:provoke_deadlock/0 to start it up. It does contain some comments as well. A patch to be discussed can be fetched here: git fetch git@REDACTED:travelping/otp.git fix_shutdown_supervisor https://github.com/travelping/otp/compare/fix_shutdown_supervisor https://github.com/travelping/otp/compare/fix_shutdown_supervisor.patch It basically checks the message queue for shutdown messages before any attempted restart and shuts down if it finds one. This does not of course handle cases in which the process start function hangs indefinitely, if this is to be handled at all (!?). I also thought about the application controller termination behaviour. Wouldn't it be better if it had an application shutdown timeout - analogous to the supervisor child shutdown timeouts - after which it kills the application master? Such a timeout could be infinite by default to ensure backward compatibility and be configurable by a kernel environment variable. Thanks in advance, Robin Haberkorn -- -- ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From joe@REDACTED Wed Sep 14 01:31:53 2011 From: joe@REDACTED (Joe Williams) Date: Tue, 13 Sep 2011 16:31:53 -0700 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: <70DFFEE9A63041B38ADB25FACFA6F331@joetify.com> References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> <70DFFEE9A63041B38ADB25FACFA6F331@joetify.com> Message-ID: <03BB721479CA4756B71CADDD85829E62@joetify.com> Siri, Anything else need to be done to graduate/merge this patch? Thanks. -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe On Tuesday, September 6, 2011 at 8:51 AM, Joe Williams wrote: > Great, let me know if any other changes are needed. > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED (mailto:joe@REDACTED) > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Tuesday, September 6, 2011 at 12:45 AM, Siri Hansen wrote: > > > Hi Joe - looks good now! :) > > Thanks for your effort! > > /siri > > > > 2011/9/5 Joe Williams > > > Siri, > > > > > > Please refetch and let me know if the test works for you now. > > > > > > Thanks! > > > > > > -Joe > > > > > > > > > -- > > > Name: Joseph A. Williams > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > Blog: http://www.joeandmotorboat.com/ > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > On Monday, September 5, 2011 at 2:32 AM, Siri Hansen wrote: > > > > > > > Hi Joe - had a look at your changes... and it turned out to be quite interesting... > > > > > > > > First, I saw that you hadn't updated the test suite with the new exit reason - but when I executed the test it did not fail... :o > > > > > > > > It turned out that you catched the call to ?t:fail/1 - which actually only does an exit... I assume you meant "case catch" and not "catch case"... However, catching this is not at all necessary here, since it will be catched by the rpc:call anyway - it will return {badrpc, {'EXIT', {suspended_supervisor, _}}} . > > > > > > > > Also, two other comments on the test case: > > > > > > > > * when the call to get_supervised_procs return something unexpected - please print the return value in the test log (using e.g. ct:log/2) in order to make trouble shooting easier > > > > * stopping the node could be moved outside of the test case, in order to avoid hanging nodes if the test fails. This you can do by adding something like > > > > > > > > supervisor_which_children_timeout(cleanup, Conf) -> > > > > stop_node(node_name(supervisor_which_children_timeout)). > > > > > > > > > > > > This will then be called during end_per_testcase. I see that there are other test cases that don't do this, and I will clean up that before the next release. > > > > > > > > Regards > > > > /siri > > > > > > > > > > > > 2011/9/1 Joe Williams > > > > > Seems good to me, I went ahead and made the changes. > > > > > > > > > > Please refetch and let me know if there is anything else. > > > > > > > > > > -Joe > > > > > > > > > > > > > > > -- > > > > > Name: Joseph A. Williams > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > > > > > > > > > > > Thanks Joe! This looks very good. I have two minor comments only: > > > > > > > > > > > > 1) Maybe you could change the first line of the commit message to say > > > > > > > > > > > > General improvements to release_handler_1:get_supervised_procs > > > > > > > > > > > > or > > > > > > > > > > > > General improvements to get_supervised_procs in release_handler_1 > > > > > > > > > > > > 2) And when I looked at the tests it occured to me that it might be a good idea to change the error reasons to something more descriptive than 'release_handler_error'. What do you think? I know that there will be error messages in the shell, but I find it better if even the returned error reason gives a hint about what failed. My suggestions for the three calls to error/1 respectively (please change if you have better ideas): > > > > > > > > > > > > suspended_supervisor > > > > > > {which_children_failed,Other} > > > > > > {get_modules_failed,Other} > > > > > > > > > > > > Please let me know what you think about this. > > > > > > > > > > > > Regards > > > > > > /siri > > > > > > > > > > > > 2011/9/1 Joe Williams > > > > > > > Siri, > > > > > > > > > > > > > > I have added tests and squashed my commits, rewriting the commit message while I was at it. Please refetch and let me know if this is up to your standards for graduation. > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Name: Joseph A. Williams > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > > > > > > > > > > > > > > Hi Joe - Yes, you can put your application inside release_handler_SUITE_data/lib. And hopefully you can use the functions create_and_install_fake_first_release and create_fake_upgrade_release - you can see examples of that in release_handler_SUITE.erl. Please let me know if you need any more advice on the testing. > > > > > > > > Regards > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/30 Joe Williams > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > I could use some advice on how best to test this code. Currently I have a little dummy application with the proper supervision tree to trigger this upgrade case. Here are the steps I use to reproduce: > > > > > > > > > > > > > > > > > > https://gist.github.com/da109fb6939ef7aac031 > > > > > > > > > > > > > > > > > > Note that this is using my topic branch so you can see the additional logging. > > > > > > > > > > > > > > > > > > I noticed that there is a release_handler_SUITE_data directory in the sasl tests, should I just add another directory specifically for this and store the dummy application there for testing? > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > Great Joe - this is much better :) > > > > > > > > > > Could you please add some tests for this also? > > > > > > > > > > Thanks > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > 2011/8/29 Joe Williams > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > Please fetch this branch again. > > > > > > > > > > > > > > > > > > > > > > I have added errors where I had my functions returning empty lists. I believe this should bubble up to release_handler causing a restart similar to the timeout behavior we currently have. > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > In case #2 the node would be in an "unpacked" state but perhaps that isn't possible since the upgrade may be partially installed already. I'll work on implementing #1 and reply back soon. > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Joe - > > > > > > > > > > > > > I think I would prefer solution 1), although that's probably mostly because I don't really understand solution 2)... What do you mean by "stop the upgrade from completing"? in which state would the node be after this? > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/26 Joe Williams > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > That sounds correct, with the current patch there is that risk. In my case I would see the error message post-upgrade and restart things as needed but I certainly see your point. The VM restarting is a brutal but idiomatic way to deal with this issue, let it fail :). > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think there are two possibilities here, 1) continue with the restart behavior but make sure we print error messages before we do or 2) print error messages but stop the upgrade from completing if we catch the bad case. Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry for being so slow - but I still don't really understand :( > > > > > > > > > > > > > > > My concerns are really about whether or not we should allow the upgrade to be performed in this case. For sure I think we should > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) avoid the timeout, and > > > > > > > > > > > > > > > 2) let the user know what the problem is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > but is it correct to let the upgrade pass after this? Is it not an error situation? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems to me that we risk getting into a situation where we believe that the system is upgraded, but in fact there could be branches of the supervisor tree where process have not had the chance to run their code_change functions. I mean - even if we print the error report, there is no guarantee that it is really detected unless the operation actually fails. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please correct me if I completely misunderstood the situation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Joe Williams > > > > > > > > > > > > > > > > Siri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I ran into two issues that this patch addresses. Check out the commit message at https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for the details. In both cases I found that in production an error in the logs was preferable to the restart of the VM since both are easily fixable with a small application change or in the case of the suspended supervisor using a different app up. Also see this comment in release_handler_1 regarding the supervisor, https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which suggests this corner case is known by at least a few people. Currently there is no way to know *why* your VM just restarted after the upgrade in either case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if you have any other questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi again, Joe! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please explain a bit about the situation where you discovered this problem? I agree that the timeout and VM restart is not very good, and it makes sense to check if the supervisor is suspended. But I'm not really sure if it is correct to allow the upgrade to continue when this error occurs. Even if an error message is printed, I guess it could be quite easy to miss this fact... and the question is if that would be a problem or not? Why is the supervisor suspended in the first place? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/25 Siri Hansen > > > > > > > > > > > > > > > > > > Hi Joe - I've just started looking at this. Do you think it would be possible to add a test case for it? > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > /siri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2011/8/24 Joe Williams > > > > > > > > > > > > > > > > > > > Anything I can do regarding this patch? I have happily been running it in production since I submitted it to the list in June. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything I can do to help this patch graduate? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Updated this branch, please refetch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great, thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > Please fetch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) release_handler_1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a different branch with a better commit message and no white space changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent. I will include your patch in 'pu' after rewording the > > > > > > > > > > > > > > > > > > > > > > > summary line to imperative form. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nothing specific, just wondered if anyone had any thoughts on how I dealt with a couple of corner cases in installing releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll fix things up and get back shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Any thoughts/feedback on this patch? I realize it doesn't follow the guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly and will clean it up soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anything in particular? I just got caught up in tideous merge work > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday and missed to include your patch in 'pu', I was about > > > > > > > > > > > > > > > > > > > > > > > > > > to take it now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you have a cleanup I can wait for it... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > Name: Joseph A. Williams > > > > > > > > > > > > > > > > > > > > > > > > > > > Email: joe@REDACTED (mailto:joe@REDACTED) (mailto:joe@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > > > Blog: http://www.joeandmotorboat.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > Twitter: http://twitter.com/williamsjoe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > git fetch git://github.com/joewilliams/otp.git (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) (http://github.com/joewilliams/otp.git) release_handler > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > erlang-patches mailing list > > > > > > > > > > > > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > > > > > > > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Wed Sep 14 09:41:06 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 14 Sep 2011 09:41:06 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: <4E688372.4000101@capflam.org> References: <4E688372.4000101@capflam.org> Message-ID: <4E705A92.2010200@erlang.org> On 09/08/2011 10:57 AM, Christopher Faulet wrote: > git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity I have included this branch in 'pu' Thank you for the contribution. No news about the other one as of yet Thank you for the contribution! -- /Henrik Nord Erlang/OTP From erlangsiri@REDACTED Wed Sep 14 11:51:48 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 14 Sep 2011 11:51:48 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: <4E705A92.2010200@erlang.org> References: <4E688372.4000101@capflam.org> <4E705A92.2010200@erlang.org> Message-ID: 2011/9/14 Henrik Nord > On 09/08/2011 10:57 AM, Christopher Faulet wrote: > >> git fetch git://github.com/capflam/otp.**gitsupervisor_shutdown_infinity >> > I have included this branch in 'pu' > > Thank you for the contribution. > > No news about the other one as of yet > > Thank you for the contribution! > > -- > /Henrik Nord Erlang/OTP > > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > Hi again Christopher - thanks for the information!! I have discussed the simple_one_for_one_shutdown problem with my colleagues, and finally we came to the same conclusion as you did :) The current behavior is definitely not acceptable so we decided to take in you patch. If you don't mind I would however like you to do some minor adjustments first: 1) I think it would be good to document the differences in how shutdown is handled for simple_one_for_one supervisors compared to other supervisors. I.e. that there is no defined shutdown order, and that the workers will terminate "in parallel". 2) If the shutdown strategy for the dynamic children is a timer, and the timer expires - then it looks like there will be one error report printed per worker that is not yet terminated (please correct me if I'm wrong). I believe that this could be quite heavy if there are many workers left. I would suggest to print only one error report in this situation - either listing all pids or just say how many processes we are talking about. Also, as Henrik writes, your supervisor_shutdown_infinity patch is already included in pu. Before finally including it in our development branch, I would also like you to add some more information to the documentation (a warning?) - about using this feature with care, and if you need to use it then implement the worker in a safe way so the cleanup procedure can not hang... since this can actually cause the termination of the complete supervisor tree to hang. Thanks! /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Wed Sep 14 12:14:46 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 14 Sep 2011 12:14:46 +0200 Subject: [erlang-patches] release_handler_1 improvements In-Reply-To: <03BB721479CA4756B71CADDD85829E62@joetify.com> References: <1C74E579B911446FBEFB7DF9D3DDD11A@joetify.com> <20110609071143.GB16577@erix.ericsson.se> <59BD610D63824C4AABB5673C3688A9FF@joetify.com> <20110610155125.GD7170@erix.ericsson.se> <5599EA2E920D462E9CA899BD7DF1B3E6@joetify.com> <6ED9E10797924705B8D252A4593F22E3@joetify.com> <89662D877556421FAD369A3FEA3A4CCA@joetify.com> <1D2A83CC04464B4B8E1655BBAF425D7A@joetify.com> <6F6DD401770C49A1A6897C7C75CCF197@joetify.com> <6E54F66DBA84471295E9125262648B74@joetify.com> <203F65FBB7014F63B6F35E74183743BF@joetify.com> <22DB16C2B7BB4AEEB402CF84D8F037AB@joetify.com> <70DFFEE9A63041B38ADB25FACFA6F331@joetify.com> <03BB721479CA4756B71CADDD85829E62@joetify.com> Message-ID: Hi Joe - you can just sit back and relax :) Your patch will go it's way through pu, then opu and finally into the development branch for R14B04. Regards /siri 2011/9/14 Joe Williams > Siri, > > Anything else need to be done to graduate/merge this patch? > > Thanks. > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, September 6, 2011 at 8:51 AM, Joe Williams wrote: > > Great, let me know if any other changes are needed. > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, September 6, 2011 at 12:45 AM, Siri Hansen wrote: > > Hi Joe - looks good now! :) > Thanks for your effort! > /siri > > 2011/9/5 Joe Williams > > Siri, > > Please refetch and let me know if the test works for you now. > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, September 5, 2011 at 2:32 AM, Siri Hansen wrote: > > Hi Joe - had a look at your changes... and it turned out to be quite > interesting... > > First, I saw that you hadn't updated the test suite with the new exit > reason - but when I executed the test it did not fail... :o > > It turned out that you catched the call to ?t:fail/1 - which actually only > does an exit... I assume you meant "case catch" and not "catch case"... > However, catching this is not at all necessary here, since it will be > catched by the rpc:call anyway - it will return {badrpc, {'EXIT', > {suspended_supervisor, _}}} . > > Also, two other comments on the test case: > > * when the call to get_supervised_procs return something unexpected - > please print the return value in the test log (using e.g. ct:log/2) in order > to make trouble shooting easier > * stopping the node could be moved outside of the test case, in order to > avoid hanging nodes if the test fails. This you can do by adding something > like > > supervisor_which_children_timeout(cleanup, Conf) -> > stop_node(node_name(supervisor_which_children_timeout)). > > This will then be called during end_per_testcase. I see that there are > other test cases that don't do this, and I will clean up that before the > next release. > > Regards > /siri > > > 2011/9/1 Joe Williams > > Seems good to me, I went ahead and made the changes. > > Please refetch and let me know if there is anything else. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Thursday, September 1, 2011 at 12:59 AM, Siri Hansen wrote: > > Thanks Joe! This looks very good. I have two minor comments only: > > 1) Maybe you could change the first line of the commit message to say > > General improvements to release_handler_1:get_supervised_procs > > or > > General improvements to get_supervised_procs in release_handler_1 > > 2) And when I looked at the tests it occured to me that it might be a good > idea to change the error reasons to something more descriptive than > 'release_handler_error'. What do you think? I know that there will be error > messages in the shell, but I find it better if even the returned error > reason gives a hint about what failed. My suggestions for the three calls to > error/1 respectively (please change if you have better ideas): > > suspended_supervisor > {which_children_failed,Other} > {get_modules_failed,Other} > > Please let me know what you think about this. > > Regards > /siri > > 2011/9/1 Joe Williams > > Siri, > > I have added tests and squashed my commits, rewriting the commit message > while I was at it. Please refetch and let me know if this is up to your > standards for graduation. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, August 30, 2011 at 11:41 PM, Siri Hansen wrote: > > Hi Joe - Yes, you can put your application inside > release_handler_SUITE_data/lib. And hopefully you can use the > functions create_and_install_fake_first_release > and create_fake_upgrade_release - you can see examples of that in > release_handler_SUITE.erl. Please let me know if you need any more advice on > the testing. > Regards > /siri > > > 2011/8/30 Joe Williams > > Siri, > > I could use some advice on how best to test this code. Currently I have a > little dummy application with the proper supervision tree to trigger this > upgrade case. Here are the steps I use to reproduce: > > https://gist.github.com/da109fb6939ef7aac031 > > Note that this is using my topic branch so you can see the additional > logging. > > I noticed that there is a release_handler_SUITE_data directory in the sasl > tests, should I just add another directory specifically for this and store > the dummy application there for testing? > > Thanks. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, August 30, 2011 at 1:44 AM, Siri Hansen wrote: > > Great Joe - this is much better :) > Could you please add some tests for this also? > Thanks > /siri > > 2011/8/29 Joe Williams > > Siri, > > Please fetch this branch again. > > I have added errors where I had my functions returning empty lists. I > believe this should bubble up to release_handler causing a restart similar > to the timeout behavior we currently have. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, August 29, 2011 at 9:35 AM, Joe Williams wrote: > > Siri, > > In case #2 the node would be in an "unpacked" state but perhaps that isn't > possible since the upgrade may be partially installed already. I'll work on > implementing #1 and reply back soon. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Monday, August 29, 2011 at 7:31 AM, Siri Hansen wrote: > > Hi Joe - > I think I would prefer solution 1), although that's probably mostly because > I don't really understand solution 2)... What do you mean by "stop the > upgrade from completing"? in which state would the node be after this? > /siri > > 2011/8/26 Joe Williams > > Siri, > > That sounds correct, with the current patch there is that risk. In my case > I would see the error message post-upgrade and restart things as needed but > I certainly see your point. The VM restarting is a brutal but idiomatic way > to deal with this issue, let it fail :). > > I think there are two possibilities here, 1) continue with the restart > behavior but make sure we print error messages before we do or 2) print > error messages but stop the upgrade from completing if we catch the bad > case. Thoughts? > > -Joe > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, August 26, 2011 at 1:08 AM, Siri Hansen wrote: > > Hi again, Joe! > > Sorry for being so slow - but I still don't really understand :( > My concerns are really about whether or not we should allow the upgrade to > be performed in this case. For sure I think we should > > 1) avoid the timeout, and > 2) let the user know what the problem is > > but is it correct to let the upgrade pass after this? Is it not an error > situation? > > It seems to me that we risk getting into a situation where we believe > that the system is upgraded, but in fact there could be branches of the > supervisor tree where process have not had the chance to run their > code_change functions. I mean - even if we print the error report, there is > no guarantee that it is really detected unless the operation actually fails. > > Please correct me if I completely misunderstood the situation. > > Regards > /siri > > > 2011/8/25 Joe Williams > > Siri, > > I ran into two issues that this patch addresses. Check out the commit > message at > https://github.com/joewilliams/otp/commit/9c3a53789326cdd929f1c3b4525716b1c0abfe87 for > the details. In both cases I found that in production an error in the logs > was preferable to the restart of the VM since both are easily fixable with a > small application change or in the case of the suspended supervisor using a > different app up. Also see this comment in release_handler_1 regarding the > supervisor, > https://github.com/erlang/otp/blob/dev/lib/sasl/src/release_handler_1.erl#L454 which > suggests this corner case is known by at least a few people. Currently there > is no way to know *why* your VM just restarted after the upgrade in either > case. > > Let me know if you have any other questions. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Thursday, August 25, 2011 at 6:35 AM, Siri Hansen wrote: > > Hi again, Joe! > > Could you please explain a bit about the situation where you discovered > this problem? I agree that the timeout and VM restart is not very good, and > it makes sense to check if the supervisor is suspended. But I'm not really > sure if it is correct to allow the upgrade to continue when this error > occurs. Even if an error message is printed, I guess it could be quite easy > to miss this fact... and the question is if that would be a problem or not? > Why is the supervisor suspended in the first place? > > Regards > /siri > > > 2011/8/25 Siri Hansen > > Hi Joe - I've just started looking at this. Do you think it would be > possible to add a test case for it? > Regards > /siri > > > 2011/8/24 Joe Williams > > Anything I can do regarding this patch? I have happily been running it in > production since I submitted it to the list in June. > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Wednesday, July 6, 2011 at 3:43 PM, Joe Williams wrote: > > Anything I can do to help this patch graduate? > > Thanks! > > -Joe > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Tuesday, June 14, 2011 at 12:26 PM, Joe Williams wrote: > > Updated this branch, please refetch. > > git fetch git://github.com/joewilliams/otp.git release_handler_1 > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, June 10, 2011 at 8:52 AM, Joe Williams wrote: > > Great, thanks! > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > On Friday, June 10, 2011 at 8:51 AM, Raimo Niskanen wrote: > > On Thu, Jun 09, 2011 at 08:20:51AM -0700, Joe Williams wrote: > > Please fetch: > > git fetch git://github.com/joewilliams/otp.git release_handler_1 > > This is a different branch with a better commit message and no white space > changes. > > > Excellent. I will include your patch in 'pu' after rewording the > summary line to imperative form. > > > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Thursday, June 9, 2011 at 7:44 AM, Joe Williams wrote: > > Nothing specific, just wondered if anyone had any thoughts on how I dealt > with a couple of corner cases in installing releases. > > I'll fix things up and get back shortly. > > -- > Name: Joseph A. Williams > Email: joe@REDACTED (mailto:joe@REDACTED ) > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Thursday, June 9, 2011 at 12:11 AM, Raimo Niskanen wrote: > > On Wed, Jun 08, 2011 at 03:41:37PM -0700, Joe Williams wrote: > > Any thoughts/feedback on this patch? I realize it doesn't follow the > guidelines (https://github.com/erlang/otp/wiki/Submitting-patches) exactly > and will clean it up soon. > > > Anything in particular? I just got caught up in tideous merge work > yesterday and missed to include your patch in 'pu', I was about > to take it now. > > But if you have a cleanup I can wait for it... > > > > -- > Name: Joseph A. Williams > Email: joe@REDACTED (mailto:joe@REDACTED ) > Blog: http://www.joeandmotorboat.com/ > Twitter: http://twitter.com/williamsjoe > > > On Tuesday, June 7, 2011 at 2:33 PM, Joe Williams wrote: > > git fetch git://github.com/joewilliams/otp.git ( > http://github.com/joewilliams/otp.git) ( > http://github.com/joewilliams/otp.git) release_handler > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED > ) > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED > ) > http://erlang.org/mailman/listinfo/erlang-patches > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.faulet@REDACTED Wed Sep 14 18:00:03 2011 From: christopher.faulet@REDACTED (Christopher Faulet) Date: Wed, 14 Sep 2011 18:00:03 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: References: <4E688372.4000101@capflam.org> <4E705A92.2010200@erlang.org> Message-ID: <4E70CF83.6060207@capflam.org> Le 14/09/2011 11:51, Siri Hansen a ?crit : > I have discussed the simple_one_for_one_shutdown problem with my > colleagues, and finally we came to the same conclusion as you did :) The > current behavior is definitely not acceptable so we decided to take in > you patch. If you don't mind I would however like you to do some minor > adjustments first: > > 1) I think it would be good to document the differences in how shutdown > is handled for simple_one_for_one supervisors compared to other > supervisors. I.e. that there is no defined shutdown order, and that the > workers will terminate "in parallel". > > 2) If the shutdown strategy for the dynamic children is a timer, and the > timer expires - then it looks like there will be one error report > printed per worker that is not yet terminated (please correct me if I'm > wrong). I believe that this could be quite heavy if there are many > workers left. I would suggest to print only one error report in this > situation - either listing all pids or just say how many processes we > are talking about. > > > Also, as Henrik writes, your supervisor_shutdown_infinity patch is > already included in pu. Before finally including it in our development > branch, I would also like you to add some more information to the > documentation (a warning?) - about using this feature with care, and if > you need to use it then implement the worker in a safe way so the > cleanup procedure can not hang... since this can actually cause the > termination of the complete supervisor tree to hang. > Siri, Thanks for your feedback. You can re-fetch the branches: git fetch git://github.com/capflam/otp.git simple_one_for_one_shutdown git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity Let me know if there is any problem with my updates (Especially with the documentation). -- Christopher Faulet http://www.yakaz.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From henrik@REDACTED Thu Sep 15 09:19:27 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 15 Sep 2011 09:19:27 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: <4E70CF83.6060207@capflam.org> References: <4E688372.4000101@capflam.org> <4E705A92.2010200@erlang.org> <4E70CF83.6060207@capflam.org> Message-ID: <4E71A6FF.4020304@erlang.org> On 09/14/2011 06:00 PM, Christopher Faulet wrote: > Le 14/09/2011 11:51, Siri Hansen a ?crit : >> I have discussed the simple_one_for_one_shutdown problem with my >> colleagues, and finally we came to the same conclusion as you did :) The >> current behavior is definitely not acceptable so we decided to take in >> you patch. If you don't mind I would however like you to do some minor >> adjustments first: >> >> 1) I think it would be good to document the differences in how shutdown >> is handled for simple_one_for_one supervisors compared to other >> supervisors. I.e. that there is no defined shutdown order, and that the >> workers will terminate "in parallel". >> >> 2) If the shutdown strategy for the dynamic children is a timer, and the >> timer expires - then it looks like there will be one error report >> printed per worker that is not yet terminated (please correct me if I'm >> wrong). I believe that this could be quite heavy if there are many >> workers left. I would suggest to print only one error report in this >> situation - either listing all pids or just say how many processes we >> are talking about. >> >> >> Also, as Henrik writes, your supervisor_shutdown_infinity patch is >> already included in pu. Before finally including it in our development >> branch, I would also like you to add some more information to the >> documentation (a warning?) - about using this feature with care, and if >> you need to use it then implement the worker in a safe way so the >> cleanup procedure can not hang... since this can actually cause the >> termination of the complete supervisor tree to hang. >> > Siri, > > Thanks for your feedback. You can re-fetch the branches: > > git fetch git://github.com/capflam/otp.git simple_one_for_one_shutdown > git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity > > Let me know if there is any problem with my updates (Especially with the > documentation). > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Refetched supervisor_shutdown_infinity Included simple_one_for_one_shutdown in 'pu' Thank you -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Sep 15 10:54:13 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 15 Sep 2011 10:54:13 +0200 Subject: [erlang-patches] Supervisor improvements In-Reply-To: <4E70CF83.6060207@capflam.org> References: <4E688372.4000101@capflam.org> <4E705A92.2010200@erlang.org> <4E70CF83.6060207@capflam.org> Message-ID: 2011/9/14 Christopher Faulet > Le 14/09/2011 11:51, Siri Hansen a ?crit : > > I have discussed the simple_one_for_one_shutdown problem with my > > colleagues, and finally we came to the same conclusion as you did :) The > > current behavior is definitely not acceptable so we decided to take in > > you patch. If you don't mind I would however like you to do some minor > > adjustments first: > > > > 1) I think it would be good to document the differences in how shutdown > > is handled for simple_one_for_one supervisors compared to other > > supervisors. I.e. that there is no defined shutdown order, and that the > > workers will terminate "in parallel". > > > > 2) If the shutdown strategy for the dynamic children is a timer, and the > > timer expires - then it looks like there will be one error report > > printed per worker that is not yet terminated (please correct me if I'm > > wrong). I believe that this could be quite heavy if there are many > > workers left. I would suggest to print only one error report in this > > situation - either listing all pids or just say how many processes we > > are talking about. > > > > > > Also, as Henrik writes, your supervisor_shutdown_infinity patch is > > already included in pu. Before finally including it in our development > > branch, I would also like you to add some more information to the > > documentation (a warning?) - about using this feature with care, and if > > you need to use it then implement the worker in a safe way so the > > cleanup procedure can not hang... since this can actually cause the > > termination of the complete supervisor tree to hang. > > > > Siri, > > Thanks for your feedback. You can re-fetch the branches: > > git fetch git://github.com/capflam/otp.git simple_one_for_one_shutdown > git fetch git://github.com/capflam/otp.git supervisor_shutdown_infinity > > Let me know if there is any problem with my updates (Especially with the > documentation). > > -- > Christopher Faulet > http://www.yakaz.com > > Thanks Christopher - it looks good! :) /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.henoch@REDACTED Thu Sep 15 11:01:28 2011 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Thu, 15 Sep 2011 10:01:28 +0100 (BST) Subject: [erlang-patches] Specify file name and error reason when failing to create cookie In-Reply-To: <74bee9d2-8f8d-460b-bab6-3d67d9c8c080@knuth> Message-ID: <0fd490fe-0c8a-4692-99e7-d3b89bdf96d6@knuth> I just got the error "Failed to create cookie file" when running a build in our build environment. It worked when I ran the same command manually, so I resorted to patching auth.erl to tell me exactly what's wrong. (Turned out to be an incorrectly set HOME variable.) I imagine this could be useful in general, so here is the patch: git fetch git://github.com/legoscia/otp.git create_cookie_error_msg https://github.com/legoscia/otp/compare/create_cookie_error_msg https://github.com/legoscia/otp/compare/create_cookie_error_msg.patch -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From henrik@REDACTED Thu Sep 15 11:24:25 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 15 Sep 2011 11:24:25 +0200 Subject: [erlang-patches] Specify file name and error reason when failing to create cookie In-Reply-To: <0fd490fe-0c8a-4692-99e7-d3b89bdf96d6@knuth> References: <0fd490fe-0c8a-4692-99e7-d3b89bdf96d6@knuth> Message-ID: <4E71C449.3040103@erlang.org> On 09/15/2011 11:01 AM, Magnus Henoch wrote: > I just got the error "Failed to create cookie file" when running a > build in our build environment. It worked when I ran the same > command manually, so I resorted to patching auth.erl to tell me > exactly what's wrong. (Turned out to be an incorrectly set HOME > variable.) > > I imagine this could be useful in general, so here is the patch: > > git fetch git://github.com/legoscia/otp.git create_cookie_error_msg > > https://github.com/legoscia/otp/compare/create_cookie_error_msg > https://github.com/legoscia/otp/compare/create_cookie_error_msg.patch Thank you! I have included this in 'pu' -- /Henrik Nord Erlang/OTP From erlangsiri@REDACTED Thu Sep 15 16:36:42 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 15 Sep 2011 16:36:42 +0200 Subject: [erlang-patches] Improving supervisor shutdown procedure In-Reply-To: References: Message-ID: Hi Robin! I have started looking at this, and indeed it seems like a problem we need to investigate further... I do think that your patch is a bit too simple :( The main problem is that the supervisor does not know where the shutdown message comes from, and I believe it may cause some unexpected behavior if the shutdown is received from a different process than the supervisor's parent. If you were to continue on this idea, maybe you could look at a way to leave the control back to the gen_server (which the supervisor is built on top of) - since this knows who it's parent is. It is only an idea, and I do not know if it is possible to do it in a good way. First of all, I think I will look more into your idea about a shutdown timer in the application_controller. I'll get back to you when I have some more thoughts around this... Regards /siri 2011/9/12 Robin Haberkorn > Hi! > > I've just observed a very peculiar behaviour of the > OTP supervisor and application controller, on one of our > embedded Erlang nodes: > > When a supervisor gets stuck in an infinite process > restart loop, it does not (and cannot) respond to shutdown > signals. More specifically this happens if the supervised > process crashes in its start function (and it's not the > initial process start, of course). > I know that a supervisor shouldn't get stuck in > an endless loop and that you probably have good reason to > handle restarts that way. I nevertheless would like to > hear your opinion. > > Now, if the erlang node is to shut down (either because > it's told so or a permanent application terminates), > the application controller will signal all application > masters to shut down. However it does so without any timeout > after which a kill signal would be sent. > If there exists a supervisor stuck in a restart loop like > the one described above, the application controller will > dead lock. > > One of the reasons why this may happen is the start function > (e.g. init/1 in the gen_server callback module), taking > too long before failing, which may be because of a gen_server > call timeout (about which the supervised process does not > necessarily know anything). > > It may even be that by unfavourable timing / race condition, > the application controller terminates while a supervisor is > just restarting a process doing an application module call > (e.g. application:set_env/3) in its init which then has > to time out, resulting in a perfect dead lock. > Indeed this is exactly what has happened to me. > > A test case for reproducing this behaviour can be downloaded > from github (it's a small OTP application): > > > https://github.com/downloads/travelping/otp/supervisor_deadlock_testcase.tar.gz > > Call deadlock_app:provoke_deadlock/0 to start it up. > It does contain some comments as well. > > A patch to be discussed can be fetched here: > > git fetch git@REDACTED:travelping/otp.git fix_shutdown_supervisor > > https://github.com/travelping/otp/compare/fix_shutdown_supervisor > https://github.com/travelping/otp/compare/fix_shutdown_supervisor.patch > > It basically checks the message queue for shutdown messages > before any attempted restart and shuts down if it finds > one. > This does not of course handle cases in which the process > start function hangs indefinitely, if this is to be > handled at all (!?). > > I also thought about the application controller termination > behaviour. Wouldn't it be better if it had an application > shutdown timeout - analogous to the supervisor child shutdown > timeouts - after which it kills the application master? > Such a timeout could be infinite by default to ensure backward > compatibility and be configurable by a kernel environment > variable. > > Thanks in advance, > Robin Haberkorn > > -- > -- > ------------------ managed broadband access ------------------ > > Travelping GmbH phone: +49-391-8190990 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Thu Sep 15 19:38:23 2011 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Thu, 15 Sep 2011 19:38:23 +0200 Subject: [erlang-patches] [PATCH] Quote atoms if necessary in types In-Reply-To: References: Message-ID: <1316108303-4654-1-git-send-email-tomas.abrahamsson@gmail.com> Atoms in some occurrences were not correctly quoted when formatted to strings, for instance by the typer program. Example: -module(tb). -export(['UPPERCASE-FUNCTION-NAME'/0, f1/0, f2/0, f3/0]). -record('UPPERCASE-RECORD-NAME', {x}). -record(r2, {'UPPERCASE-FIELD-NAME'}). -type 'UPPERCASE-TYPE-NAME'() :: integer(). 'UPPERCASE-FUNCTION-NAME'() -> ok. f1() -> #'UPPERCASE-RECORD-NAME'{x=1}. f2() -> #r2{'UPPERCASE-FIELD-NAME'=1}. -spec f3() -> 'UPPERCASE-TYPE-NAME'(). f3() -> 1. Given the program above, the output from typer --plt some.plt tb.erl resulted in the following specs being printed: -spec UPPERCASE-FUNCTION-NAME() -> 'ok'. -spec f1() -> #UPPERCASE-RECORD-NAME{x::1}. -spec f2() -> #r2{UPPERCASE-FIELD-NAME::1}. -spec f3() -> UPPERCASE-TYPE-NAME(). This commit changes the output to become the following: -spec 'UPPERCASE-FUNCTION-NAME'() -> 'ok'. -spec f1() -> #'UPPERCASE-RECORD-NAME'{x::1}. -spec f2() -> #r2{'UPPERCASE-FIELD-NAME'::1}. -spec f3() -> 'UPPERCASE-TYPE-NAME'(). --- lib/hipe/cerl/erl_types.erl | 16 +++++++++++----- lib/typer/src/typer.erl | 2 +- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/lib/hipe/cerl/erl_types.erl b/lib/hipe/cerl/erl_types.erl index 1748c1c..7ff1707 100644 --- a/lib/hipe/cerl/erl_types.erl +++ b/lib/hipe/cerl/erl_types.erl @@ -211,7 +211,8 @@ record_field_diffs_to_string/2, subst_all_vars_to_any/1, lift_list_to_pos_empty/1, - is_erl_type/1 + is_erl_type/1, + atom_to_string/1 ]). %%-define(DO_ERL_TYPES_TEST, true). @@ -3360,14 +3361,14 @@ t_to_string(?var(Id), _RecDict) when is_integer(Id) -> record_to_string(Tag, [_|Fields], FieldNames, RecDict) -> FieldStrings = record_fields_to_string(Fields, FieldNames, RecDict, []), - "#" ++ atom_to_list(Tag) ++ "{" ++ string:join(FieldStrings, ",") ++ "}". + "#" ++ atom_to_string(Tag) ++ "{" ++ string:join(FieldStrings, ",") ++ "}". record_fields_to_string([F|Fs], [{FName, _DefType}|FDefs], RecDict, Acc) -> NewAcc = case t_is_any(F) orelse t_is_atom('undefined', F) of true -> Acc; false -> - StrFV = atom_to_list(FName) ++ "::" ++ t_to_string(F, RecDict), + StrFV = atom_to_string(FName) ++ "::" ++ t_to_string(F, RecDict), %% ActualDefType = t_subtract(DefType, t_atom('undefined')), %% Str = case t_is_any(ActualDefType) of %% true -> StrFV; @@ -3393,7 +3394,7 @@ field_diffs([F|Fs], [{FName, DefType}|FDefs], RecDict, Acc) -> case t_is_subtype(F, DefType) of true -> Acc; false -> - Str = atom_to_list(FName) ++ "::" ++ t_to_string(DefType, RecDict), + Str = atom_to_string(FName) ++ "::" ++ t_to_string(DefType, RecDict), [Str|Acc] end, field_diffs(Fs, FDefs, RecDict, NewAcc); @@ -3906,7 +3907,7 @@ t_form_to_string({type, _L, union, Args}) -> string:join(t_form_to_string_list(Args), " | "); t_form_to_string({type, _L, Name, []} = T) -> try t_to_string(t_from_form(T)) - catch throw:{error, _} -> atom_to_list(Name) ++ "()" + catch throw:{error, _} -> atom_to_string(Name) ++ "()" end; t_form_to_string({type, _L, Name, List}) -> io_lib:format("~w(~s)", @@ -3920,6 +3921,11 @@ t_form_to_string_list([H|T], Acc) -> t_form_to_string_list([], Acc) -> lists:reverse(Acc). +-spec atom_to_string(atom()) -> string(). + +atom_to_string(Atom) -> + lists:flatten(io_lib:format("~w", [Atom])). + %%============================================================================= %% %% Utilities diff --git a/lib/typer/src/typer.erl b/lib/typer/src/typer.erl index e40c4f3..fd906c8 100644 --- a/lib/typer/src/typer.erl +++ b/lib/typer/src/typer.erl @@ -539,7 +539,7 @@ get_type_string(F, A, Info, Mode) -> case {Mode, Type} of {file, {contract, _}} -> ""; _ -> - Prefix = lists:concat(["-spec ", F]), + Prefix = lists:concat(["-spec ", erl_types:atom_to_string(F)]), lists:concat([Prefix, TypeStr, "."]) end; true -> -- 1.7.5.4 From henrik@REDACTED Fri Sep 16 11:10:24 2011 From: henrik@REDACTED (Henrik Nord) Date: Fri, 16 Sep 2011 11:10:24 +0200 Subject: [erlang-patches] [PATCH] Quote atoms if necessary in types In-Reply-To: <1316108303-4654-1-git-send-email-tomas.abrahamsson@gmail.com> References: <1316108303-4654-1-git-send-email-tomas.abrahamsson@gmail.com> Message-ID: <4E731280.5090501@erlang.org> On 09/15/2011 07:38 PM, Tomas Abrahamsson wrote: > Atoms in some occurrences were not correctly quoted when formatted to > strings, for instance by the typer program. Example: > > -module(tb). > -export(['UPPERCASE-FUNCTION-NAME'/0, f1/0, f2/0, f3/0]). > -record('UPPERCASE-RECORD-NAME', {x}). > -record(r2, {'UPPERCASE-FIELD-NAME'}). > -type 'UPPERCASE-TYPE-NAME'() :: integer(). > > 'UPPERCASE-FUNCTION-NAME'() -> ok. > > f1() -> #'UPPERCASE-RECORD-NAME'{x=1}. > > f2() -> #r2{'UPPERCASE-FIELD-NAME'=1}. > > -spec f3() -> 'UPPERCASE-TYPE-NAME'(). > f3() -> 1. > > Given the program above, the output from typer --plt some.plt tb.erl > resulted in the following specs being printed: > > -spec UPPERCASE-FUNCTION-NAME() -> 'ok'. > -spec f1() -> #UPPERCASE-RECORD-NAME{x::1}. > -spec f2() -> #r2{UPPERCASE-FIELD-NAME::1}. > -spec f3() -> UPPERCASE-TYPE-NAME(). > > This commit changes the output to become the following: > > -spec 'UPPERCASE-FUNCTION-NAME'() -> 'ok'. > -spec f1() -> #'UPPERCASE-RECORD-NAME'{x::1}. > -spec f2() -> #r2{'UPPERCASE-FIELD-NAME'::1}. > -spec f3() -> 'UPPERCASE-TYPE-NAME'(). > --- > lib/hipe/cerl/erl_types.erl | 16 +++++++++++----- > lib/typer/src/typer.erl | 2 +- > 2 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/lib/hipe/cerl/erl_types.erl b/lib/hipe/cerl/erl_types.erl > index 1748c1c..7ff1707 100644 > --- a/lib/hipe/cerl/erl_types.erl > +++ b/lib/hipe/cerl/erl_types.erl > @@ -211,7 +211,8 @@ > record_field_diffs_to_string/2, > subst_all_vars_to_any/1, > lift_list_to_pos_empty/1, > - is_erl_type/1 > + is_erl_type/1, > + atom_to_string/1 > ]). > > %%-define(DO_ERL_TYPES_TEST, true). > @@ -3360,14 +3361,14 @@ t_to_string(?var(Id), _RecDict) when is_integer(Id) -> > > record_to_string(Tag, [_|Fields], FieldNames, RecDict) -> > FieldStrings = record_fields_to_string(Fields, FieldNames, RecDict, []), > - "#" ++ atom_to_list(Tag) ++ "{" ++ string:join(FieldStrings, ",") ++ "}". > + "#" ++ atom_to_string(Tag) ++ "{" ++ string:join(FieldStrings, ",") ++ "}". > > record_fields_to_string([F|Fs], [{FName, _DefType}|FDefs], RecDict, Acc) -> > NewAcc = > case t_is_any(F) orelse t_is_atom('undefined', F) of > true -> Acc; > false -> > - StrFV = atom_to_list(FName) ++ "::" ++ t_to_string(F, RecDict), > + StrFV = atom_to_string(FName) ++ "::" ++ t_to_string(F, RecDict), > %% ActualDefType = t_subtract(DefType, t_atom('undefined')), > %% Str = case t_is_any(ActualDefType) of > %% true -> StrFV; > @@ -3393,7 +3394,7 @@ field_diffs([F|Fs], [{FName, DefType}|FDefs], RecDict, Acc) -> > case t_is_subtype(F, DefType) of > true -> Acc; > false -> > - Str = atom_to_list(FName) ++ "::" ++ t_to_string(DefType, RecDict), > + Str = atom_to_string(FName) ++ "::" ++ t_to_string(DefType, RecDict), > [Str|Acc] > end, > field_diffs(Fs, FDefs, RecDict, NewAcc); > @@ -3906,7 +3907,7 @@ t_form_to_string({type, _L, union, Args}) -> > string:join(t_form_to_string_list(Args), " | "); > t_form_to_string({type, _L, Name, []} = T) -> > try t_to_string(t_from_form(T)) > - catch throw:{error, _} -> atom_to_list(Name) ++ "()" > + catch throw:{error, _} -> atom_to_string(Name) ++ "()" > end; > t_form_to_string({type, _L, Name, List}) -> > io_lib:format("~w(~s)", > @@ -3920,6 +3921,11 @@ t_form_to_string_list([H|T], Acc) -> > t_form_to_string_list([], Acc) -> > lists:reverse(Acc). > > +-spec atom_to_string(atom()) -> string(). > + > +atom_to_string(Atom) -> > + lists:flatten(io_lib:format("~w", [Atom])). > + > %%============================================================================= > %% > %% Utilities > diff --git a/lib/typer/src/typer.erl b/lib/typer/src/typer.erl > index e40c4f3..fd906c8 100644 > --- a/lib/typer/src/typer.erl > +++ b/lib/typer/src/typer.erl > @@ -539,7 +539,7 @@ get_type_string(F, A, Info, Mode) -> > case {Mode, Type} of > {file, {contract, _}} -> ""; > _ -> > - Prefix = lists:concat(["-spec ", F]), > + Prefix = lists:concat(["-spec ", erl_types:atom_to_string(F)]), > lists:concat([Prefix, TypeStr, "."]) > end; > true -> Thank you, refetched this -- /Henrik Nord Erlang/OTP From henrik@REDACTED Fri Sep 16 16:22:20 2011 From: henrik@REDACTED (Henrik Nord) Date: Fri, 16 Sep 2011 16:22:20 +0200 Subject: [erlang-patches] What's cooking in erlang/otp (2011-09-16) Message-ID: <201109161422.p8GEMEsB013510@smaug.otp.ericsson.se> The release date for R14B04 is close. Patches submitted next week will most likely be included in the R15 release ------------------------------------------------------------ [Graduated] * dc/fix_win32_static_crypto (crypto, erts) (2011-08-11) 1 commit + Fix win32 OpenSSL static linking broken in 20c9d6e (52230a4) * fm/enif_compare-64-to-32bits-cast (erts) (2011-09-01) 1 commit + Fix enif_compare on 64bits machines (03d8c28) * fm/external_size_2 (erts, hipe) (2011-05-16) 1 commit + Add erlang:external_size/2 BIF (1b2cea3) * hw/detect-cpus-on-irix (erts) (2011-06-07) 1 commit + Detect the available CPUs on IRIX (e68fde9) * hw/ignore-empty-epmd-address (erts) (2011-07-13) 1 commit + Let epmd ignore empty ERL_EPMD_ADDRESS (32228c6) * ms/ei-int-overflow-in-string-atom-enc (erl_interface) (2011-06-06) 1 commit + ei: integer overflow in string/atom encoding (9cf9cde) * sa/dialyzer-dev (dialyzer, hipe) (2011-01-30) 6 commits + Add origin information to #fun_var closures (4d9bf5c) + Suppress some warnings about generation of non-returning funs (45537dc) + Enhance Dialyzer's inference on comparisons (e7f7a30) + Fix infinite loop in dataflow (25b2e48) + Minor fix in dead code (ae96591) + Update r9c/{inets,mnesia} results in dialyzer's test suite (c68f922) * ta/erl_compile-dead-code (stdlib) (2011-08-19) 1 commit + Remove dead code in erl_compile (4c63d9d) * ta/werror (asn1, compiler, erts, parsetools, sasl, snmp) (2011-09-06) 15 commits + snmp: extend warnings_as_errors test (bbdc6a3) + systools: add warnings_as_errors option (130f34e) + asn1ct: add warnings_as_errors option (fa90ce7) + leex: optimize werror/1 (78c109d) + yecc: optimize werror/1 (5d4aadd) + yecc: use more descriptive name: 'werror' (9520bbf) + leex: use more descriptive name: 'werror' (ebb7283) + compile: optimize werror/1 (899dbcf) + compile: log warnings as errors if -Werror is enabled (25f32f4) + yecc: log warnings as errors if -Werror is enabled (a6b46d1) + leex: log warnings as errors if -Werror is enabled (089df2b) + yecc: honour -Werror passed from erlc (48de2c2) . . . * va/httpd-typo-fix (inets) (2011-08-25) 1 commit + Typofix in httpd_file:handle_error message (8fcbeef) ------------------------------------------------------------ [New topics] * ac/fix-erl_interface-docs (erl_interface) (2011-09-07) 2 commits - Make comment reflect code in erl_interface/src/misc/ei_decode_term.c (ff9a8a6) - ei_decode_ei_term() returns 1 if index is incremented (292eb1b) * cf/simple_one_for_one_shutdown (otp, stdlib) (2011-09-14) 3 commits - Explain how dynamic child processes are stopped (0473132) - Stack errors when dynamic children are stopped (42c581d) - Explicitly kill dynamic children in supervisors (4775947) * cf/supervisor_shutdown_infinity (otp, stdlib) (2011-09-14) 2 commits - Add a warning to docs about workers' shutdown strategy (76cc98d) - Allow an infinite timeout to shutdown worker processes (9f6552d) * cr/cppcheck (erl_interface, erts) (2011-08-08) 1 commit - Changes inspired by running cppcheck(1) (ef757a1) * dj/xmerl_ucs-latin9-support (xmerl) (2011-04-13) 1 commit - Add latin9 (iso-8859-15) support in xmerl_ucs (60c2511) * hl/fix-ms_transform-scope-warn (stdlib) (2011-08-26) 1 commit - ms_transform: Fix incorrect `variable shadowed' warnings (29610af) * mh/create_cookie_error_msg (kernel) (2011-09-15) 1 commit - Specify file name and error on create_cookie failure (9319587) * pg/fix-hipe-bs_get_float2 (hipe) (2011-09-03) 1 commit - Fix bug with binary pattern matching of floats of variable size (ba14137) ------------------------------------------------------------ [Stalled] * bw/efile_exists (erts) (2010-10-07) 1 commit - prim_file:exists/{1,2} which is lightweight file existence check (7203932) Action expected from: Topic author * fm/posix-fallocate (erts, kernel) (2010-12-28) 1 commit - Added file:allocate/2 (682f39a) Action expected from: Topic author * hl/beam_disasm-no_attri_chunk (compiler) (2011-08-26) 2 commits - Add test suite for beam_disasm in compiler (63b3acf) - Fix error if no attributes chunk found in beam files (e0cca51) Action expected from: Topic author * jn/gen_stream (stdlib) (2011-04-15) 2 commits - Update gen_stream tests to conform with common_test standard (ce84daf) - Add gen_stream behaviour (6a089a4) Action expected from: OTP-Team * ms/epmd-IPv6-node-reg (erts, kernel) (2011-06-03) 1 commit - epmd: support IPv6 node registration (5523b21) Action expected from: R15 * pr/mnesia_frag_hash (mnesia) (2011-04-27) 2 commits - add mnesia_frag_hash test (1d6762d) - Reduce calls to phash in key_to_frag_number (67a20c0) Action expected from: Topic author * rc/epp-include-path-fix (stdlib) (2011-06-14) 1 commit - Make Erlang preprocessor check dir of current file first (b5d2469) Action expected from: Topic author * fm/enif_is_number (erts) (2011-06-08) 1 commit - Add NIF function enif_is_number (8db78b0) Action expected from: R15 * ta/nif-variadic-funs (erts) (2011-05-13) 1 commit - erts: convert variadic nif funs into inline funs (9a1f9b6) Action expected from: R15 * tn/inet_drv-fix (erts) (2011-04-08) 1 commit - Use libdlpi to get physical address (e360563) Action expected from: Topic author * nox/xmerl-namespace-axis (xmerl) (2010-12-07) 12 commits . Implement namespace axis (27d791f) . Add `#xmlPI` support to xmerl_xpath:write_node/1 (75e67f5) . Fix processing-instruction(name?) (f05e78b) . Fix path filters (610df56) . Support more top-level primary expressions (770d6d9) . Accumulate comments in element nodes (e5b6b3a) . Add `default_attrs` option (18584c5) . Allow whole documents to be returned (aef3dea) . Track parents and namespace in `#xmlAttribute` nodes (dc9b220) . Track parents in `#xmlPI` nodes (5095331) . Set `vsn` field in `#xmlDecl` record (d712331) . Fix namespace-conformance constraints (e062270) Action expected from: R15 * pd/ttb-cleanup (observer, runtime_tools) (2011-08-25) 38 commits . Support for stopped and resumed tracing. (7e2c876) . More robust testing of tracing with 'local' option. (1924817) . Print path to logs dir unless nofetch option specified. (f7dc3bf) . Removed unused option to send realtime trace to erlide. (224f432) . Documented global state when applying formatting function to trace logs. (584eec8) . Test for: (BUGFIX) Error with ip tracing to wrap sets. (7f2123b) . Stop option 'return' changed to 'return_fetch_dir' (b610184) . update format function's description (e598660) . It is safe to change cwd on control node or remote nodes while tracing (2d319d3) . fixed documentation (4e3b8cc) . additional tests for ttb module (da2e84e) . new tests for ttb module (871839b) . . . Action expected from: R15 * sa/callback-attr (compiler, inets, kernel, orber, otp, stdlib) (2010-06-08) 8 commits - Add callback specs into 'application' module in kernel (4bca766) - Add callback specs to tftp module following internet documentation (bba649c) - Add callback specs to inets_service module following possibly deprecated comments (e41a958) - Add '-callback' attributes in stdlib's behaviours (d8d94c4) - Update primary bootstrap (199525a) - Update the documentation with information on the callback attribute (311a25f) - Automatically generate 'behaviour_info' function from '-callback' attributes (7c44f16) - Add '-callback' attribute to language syntax (e8336ff) Action expected from: R15 ------------------------------------------------------------ [Cooking] * bg/temp-hipe-fixes (compiler, hipe, kernel) (2010-03-15) 6 commits - Avoid crash by skipping compilation_SUITE:on_load/1 (a8ea623) - Inline less aggressively for native-code compilation (1346686) - Crudely fix return type for the lists:key{search,find,member}/3 (c03a748) - seq_trace_SUITE: Don't native-compile (b8c17a9) - Disable native code if on_load is used (974ee4e) - andor_SUITE: Don't native-compile (86e4df8) This branch contains temporary workarounds to avoid failing test cases and is never intended to graduate. * cr/md2-With-RSA-Encryption (crypto, public_key) (2011-09-06) 3 commits - Document crypto:sha_mac_96/2 to compute an SHA MAC, not MD5 (6cd2fa9) - Support md2WithRSAEncryption certificates in public_key (c7e5f75) - Support 'md2' hash in crypto:rsa_sign/3 and crypto:rsa_verify/4 (82897cc) * jw/release_handler_1 (sasl) (2011-06-09) 1 commit - General improvements to release_handler_1:get_supervised_procs (feecf39) * mp/xmerl-ucs2-fix (xmerl) (2011-08-25) 1 commit - Fixed xmerl_ucs UCS2 little endian en/decoding (374b029) * pg/fix-cover-leftover-down-msg (tools) (2011-08-29) 1 commit - [cover]fix leftover {'DOWN', ..} msg in callers queue (07e2860) * rc/ftp-avoid-hanging (inets) (2010-08-25) 1 commit - Avoid hanging in socket-accept (cb7dfde) * rc/remote-shell-completion (kernel) (2010-10-22) 1 commit - make tab completion work in remote shells (73d1959) * ta/docs-fixes (common_test, cosFileTransfer, dialyzer, diameter, erts, hipe, ic, inets, kernel, otp, runtime_tools, ssl, stdlib, test_server, toolbar, tools, wx, xmerl) (2011-08-31) 17 commits - Fix more misspellings of compatibility (c59dc07) - Fix misspelling of kept (411edce) - Fix misspelling of compatibility in ssl_basic_SUITE (41683d2) - Fix misspelling of compatibility (2f696e4) - Fix misspelling of accommodate (65c9f41) - Fix misspelling of exceed (dfbbdaa) - Fix misspelling of accidentally (044a09a) - Fix misspelling of erroneous in xmerl_xsd (d15f145) - Fix misspelling of erroneous (90fc4f6) - Fix misspelling of successful (90f703b) - Fix typos in instrument(3) (e17a38a) - Fix typos in dbg(3) (38f6fbc) . . . * ta/typer-quote-atoms (hipe, typer) (2011-09-15) 1 commit - Quote atoms if necessary in types (9c132d6) * ta/sendfile (erts, kernel) (2011-01-13) 1 commit - Implement file:sendfile (e362bb2) * va/http-win-dir-traversal (inets) (2011-08-26) 1 commit - Fix httpd directory traversal on Windows (a936795) ------------------------------------------------------------ [Dropped] From tuncer.ayaz@REDACTED Sun Sep 18 01:16:03 2011 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 18 Sep 2011 01:16:03 +0200 Subject: [erlang-patches] [erts, stdlib] fix escript/primary archive reloading Message-ID: git fetch git://github.com/tuncer/otp.git erl_prim_loader-primary_archive-reloading https://github.com/tuncer/otp/compare/erl_prim_loader-primary_archive-reloading https://github.com/tuncer/otp/compare/erl_prim_loader-primary_archive-reloading.patch From jimenezrick@REDACTED Mon Sep 19 14:49:51 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Mon, 19 Sep 2011 14:49:51 +0200 Subject: [erlang-patches] Fix silly typos in Reference Manual and heart doc Message-ID: <20110919124951.GA15324@viper.server01.org> Hi, It fixes a few silly typos in the doc: missing spaces, missing parenthesis and a small modification. It touches: macro reference manual, distributed reference manual and heart doc. These are separated in 3 commits. Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-doctypos Here you may take a look at these 3 commits: https://github.com/jimenezrick/otp/commits/fix-doctypos Regards -- Ricardo (http://r.untroubled.be/) From henrik@REDACTED Mon Sep 19 15:26:29 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 19 Sep 2011 15:26:29 +0200 Subject: [erlang-patches] Fix silly typos in Reference Manual and heart doc In-Reply-To: <20110919124951.GA15324@viper.server01.org> References: <20110919124951.GA15324@viper.server01.org> Message-ID: <4E774305.2080504@erlang.org> On 09/19/2011 02:49 PM, Ricardo Catalinas Jim?nez wrote: > Hi, > > It fixes a few silly typos in the doc: missing spaces, missing > parenthesis and a small modification. It touches: macro reference > manual, distributed reference manual and heart doc. These are separated > in 3 commits. > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-doctypos > > Here you may take a look at these 3 commits: > https://github.com/jimenezrick/otp/commits/fix-doctypos > > > Regards Thank you for the contribution! -- /Henrik Nord Erlang/OTP From erlangsiri@REDACTED Tue Sep 20 12:09:06 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 20 Sep 2011 12:09:06 +0200 Subject: [erlang-patches] Improving supervisor shutdown procedure In-Reply-To: References: Message-ID: Hi again Robin! Just a quick follow-up on this. After some thinking and discussing, the conclusion is to go for both ideas - i.e. both the shutdown timer in application_controller, and the supervisor leaving the control back to gen_server between each restart attempt. Any thoughts, objections or contributions are of course still welcome! Regards /siri 2011/9/15 Siri Hansen > Hi Robin! > > I have started looking at this, and indeed it seems like a problem we need > to investigate further... I do think that your patch is a bit too simple :( > The main problem is that the supervisor does not know where the shutdown > message comes from, and I believe it may cause some unexpected behavior if > the shutdown is received from a different process than the supervisor's > parent. If you were to continue on this idea, maybe you could look at a way > to leave the control back to the gen_server (which the supervisor is built > on top of) - since this knows who it's parent is. It is only an idea, and I > do not know if it is possible to do it in a good way. > > First of all, I think I will look more into your idea about a shutdown > timer in the application_controller. I'll get back to you when I have some > more thoughts around this... > > Regards > /siri > > > > 2011/9/12 Robin Haberkorn > >> Hi! >> >> I've just observed a very peculiar behaviour of the >> OTP supervisor and application controller, on one of our >> embedded Erlang nodes: >> >> When a supervisor gets stuck in an infinite process >> restart loop, it does not (and cannot) respond to shutdown >> signals. More specifically this happens if the supervised >> process crashes in its start function (and it's not the >> initial process start, of course). >> I know that a supervisor shouldn't get stuck in >> an endless loop and that you probably have good reason to >> handle restarts that way. I nevertheless would like to >> hear your opinion. >> >> Now, if the erlang node is to shut down (either because >> it's told so or a permanent application terminates), >> the application controller will signal all application >> masters to shut down. However it does so without any timeout >> after which a kill signal would be sent. >> If there exists a supervisor stuck in a restart loop like >> the one described above, the application controller will >> dead lock. >> >> One of the reasons why this may happen is the start function >> (e.g. init/1 in the gen_server callback module), taking >> too long before failing, which may be because of a gen_server >> call timeout (about which the supervised process does not >> necessarily know anything). >> >> It may even be that by unfavourable timing / race condition, >> the application controller terminates while a supervisor is >> just restarting a process doing an application module call >> (e.g. application:set_env/3) in its init which then has >> to time out, resulting in a perfect dead lock. >> Indeed this is exactly what has happened to me. >> >> A test case for reproducing this behaviour can be downloaded >> from github (it's a small OTP application): >> >> >> https://github.com/downloads/travelping/otp/supervisor_deadlock_testcase.tar.gz >> >> Call deadlock_app:provoke_deadlock/0 to start it up. >> It does contain some comments as well. >> >> A patch to be discussed can be fetched here: >> >> git fetch git@REDACTED:travelping/otp.git fix_shutdown_supervisor >> >> https://github.com/travelping/otp/compare/fix_shutdown_supervisor >> https://github.com/travelping/otp/compare/fix_shutdown_supervisor.patch >> >> It basically checks the message queue for shutdown messages >> before any attempted restart and shuts down if it finds >> one. >> This does not of course handle cases in which the process >> start function hangs indefinitely, if this is to be >> handled at all (!?). >> >> I also thought about the application controller termination >> behaviour. Wouldn't it be better if it had an application >> shutdown timeout - analogous to the supervisor child shutdown >> timeouts - after which it kills the application master? >> Such a timeout could be infinite by default to ensure backward >> compatibility and be configurable by a kernel environment >> variable. >> >> Thanks in advance, >> Robin Haberkorn >> >> -- >> -- >> ------------------ managed broadband access ------------------ >> >> Travelping GmbH phone: +49-391-8190990 >> Roentgenstr. 13 fax: +49-391-819099299 >> D-39108 Magdeburg email: info@REDACTED >> GERMANY web: http://www.travelping.com >> >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 >> -------------------------------------------------------------- >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdmanana@REDACTED Tue Sep 20 19:57:19 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Tue, 20 Sep 2011 10:57:19 -0700 Subject: [erlang-patches] Fix documentation for erlang:process_info/2 Message-ID: git fetch git://github.com/fdmanana/otp.git process_info_doc_fix Web diff: https://github.com/fdmanana/otp/compare/process_info_doc_fix -- Filipe David Manana, "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From sverker@REDACTED Wed Sep 21 15:10:16 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 21 Sep 2011 15:10:16 +0200 Subject: [erlang-patches] support md2WithRSAEncryption certificates In-Reply-To: <87r53tr02d.fsf@sloppy.mti.ag> References: <87sjpeml6v.fsf@sloppy.mti.ag> <4E6624FC.30504@erlang.org> <87r53tr02d.fsf@sloppy.mti.ag> Message-ID: <4E79E238.7070302@erix.ericsson.se> Bad news. It looks like we will not include this patch in R14B04 after all. It caused problem on our build machines that uses version 1.0.0 of OpenSSL. MD2 hash has been excluded from 1.0.0 because it is not considered cryptographically secure. /Sverker, Erlang/OTP Christian von Roques wrote: > Henrik Nord writes: > >> On 08/06/2011 08:47 PM, Christian von Roques wrote: >> >>> I've added support for md2WithRSAEncryption certificates to public_key >>> and the necessary support for md2 to crypto:rsa_sign/3 and >>> crypto:rsa_verify/4. >>> [...] >>> > > >> we would like you to correct the following for us to include this branch. >> >> * add documentation for crypto >> * add test case for crypto >> * Split into two commits (crypto and public_key) >> > > done. > > Please re-fetch > > git fetch git://github.com/roques/otp.git md2WithRSAEncryption > > The branch now consists of the requested two commits and an additional > trivial third commit documenting crypto:sha_mac_96/2 to compute an SHA > MAC, not MD5. > > Christian. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From henrik@REDACTED Fri Sep 23 12:25:22 2011 From: henrik@REDACTED (Henrik Nord) Date: Fri, 23 Sep 2011 12:25:22 +0200 Subject: [erlang-patches] What's cooking in erlang/otp (2011-09-22) Message-ID: <201109231025.p8NAPJER001688@smaug.otp.ericsson.se> The release date for R14B04 is close. ------------------------------------------------------------ [Graduated] * ac/fix-erl_interface-docs (erl_interface) (2011-09-07) 2 commits + Make comment reflect code in erl_interface/src/misc/ei_decode_term.c (ff9a8a6) + ei_decode_ei_term() returns 1 if index is incremented (292eb1b) * cr/cppcheck (erl_interface, erts) (2011-08-08) 1 commit + Changes inspired by running cppcheck(1) (ef757a1) * cr/md2-With-RSA-Encryption (crypto, public_key) (2011-09-06) 3 commits + Document crypto:sha_mac_96/2 to compute an SHA MAC, not MD5 (6cd2fa9) + Support md2WithRSAEncryption certificates in public_key (c7e5f75) + Support 'md2' hash in crypto:rsa_sign/3 and crypto:rsa_verify/4 (82897cc) * dj/xmerl_ucs-latin9-support (xmerl) (2011-04-13) 1 commit + Add latin9 (iso-8859-15) support in xmerl_ucs (60c2511) * jw/release_handler_1 (sasl) (2011-06-09) 1 commit + General improvements to release_handler_1:get_supervised_procs (feecf39) * mp/xmerl-ucs2-fix (xmerl) (2011-08-25) 1 commit + Fixed xmerl_ucs UCS2 little endian en/decoding (374b029) * pg/fix-hipe-bs_get_float2 (hipe) (2011-09-03) 1 commit + Fix bug with binary pattern matching of floats of variable size (ba14137) * ta/docs-fixes (common_test, cosFileTransfer, dialyzer, diameter, erts, hipe, ic, inets, kernel, otp, runtime_tools, ssl, stdlib, test_server, toolbar, tools, wx, xmerl) (2011-09-16) 19 commits + Fix misspelling of intermediate (85b7372) + Fix typos in erts/preloaded/src (067b7a9) + Fix more misspellings of compatibility (c59dc07) + Fix misspelling of kept (411edce) + Fix misspelling of compatibility in ssl_basic_SUITE (41683d2) + Fix misspelling of compatibility (2f696e4) + Fix misspelling of accommodate (65c9f41) + Fix misspelling of exceed (dfbbdaa) + Fix misspelling of accidentally (044a09a) + Fix misspelling of erroneous in xmerl_xsd (d15f145) + Fix misspelling of erroneous (90fc4f6) + Fix misspelling of successful (90f703b) . . . * ta/typer-quote-atoms (dialyzer, hipe, typer) (2011-09-19) 2 commits + Update Dialyzer's reference results (291e32d) + Quote atoms if necessary in types (9c132d6) * hl/beam_disasm-no_attri_chunk (compiler) (2011-07-22) 1 commit + beam_disasm: Handle stripped BEAM files (347dfb0) a slightly different solution has been merged ------------------------------------------------------------ [New topics] * rj/fix-doctypos (kernel, otp) (2011-09-19) 3 commits - Adds missing spaces in Reference Manual in distributed section (0ac642f) - Fixes typo in heart doc, adds missing parenthesis (60ed9f9) - Fixes typo in Reference Manual in macros section (63c101d) * ta/erl_prim_loader-primary_archive-reloading (erts, stdlib) (2011-09-01) 1 commit - [erts,stdlib] fix escript/primary archive reloading (e88bfb7) ------------------------------------------------------------ [Stalled] * bw/efile_exists (erts) (2010-10-07) 1 commit - prim_file:exists/{1,2} which is lightweight file existence check (7203932) Action expected from: Topic author * fm/enif_is_number (erts) (2011-06-08) 1 commit - Add NIF function enif_is_number (8db78b0) Action expected from: R15 * fm/posix-fallocate (erts, kernel) (2010-12-28) 1 commit - Added file:allocate/2 (682f39a) Action expected from: Topic author * jn/gen_stream (stdlib) (2011-04-15) 2 commits - Update gen_stream tests to conform with common_test standard (ce84daf) - Add gen_stream behaviour (6a089a4) Action expected from: OTP-Team * ms/epmd-IPv6-node-reg (erts, kernel) (2011-06-03) 1 commit - epmd: support IPv6 node registration (5523b21) Action expected from: R15 * pr/mnesia_frag_hash (mnesia) (2011-04-27) 2 commits - add mnesia_frag_hash test (1d6762d) - Reduce calls to phash in key_to_frag_number (67a20c0) Action expected from: Topic author * ta/nif-variadic-funs (erts) (2011-05-13) 1 commit - erts: convert variadic nif funs into inline funs (9a1f9b6) Action expected from: R15 * tn/inet_drv-fix (erts) (2011-04-08) 1 commit - Use libdlpi to get physical address (e360563) Action expected from: Topic author * nox/xmerl-namespace-axis (xmerl) (2010-12-07) 12 commits . Implement namespace axis (27d791f) . Add `#xmlPI` support to xmerl_xpath:write_node/1 (75e67f5) . Fix processing-instruction(name?) (f05e78b) . Fix path filters (610df56) . Support more top-level primary expressions (770d6d9) . Accumulate comments in element nodes (e5b6b3a) . Add `default_attrs` option (18584c5) . Allow whole documents to be returned (aef3dea) . Track parents and namespace in `#xmlAttribute` nodes (dc9b220) . Track parents in `#xmlPI` nodes (5095331) . Set `vsn` field in `#xmlDecl` record (d712331) . Fix namespace-conformance constraints (e062270) Action expected from: R15 * pd/ttb-cleanup (observer, runtime_tools) (2011-08-25) 38 commits . Support for stopped and resumed tracing. (7e2c876) . More robust testing of tracing with 'local' option. (1924817) . Print path to logs dir unless nofetch option specified. (f7dc3bf) . Removed unused option to send realtime trace to erlide. (224f432) . Documented global state when applying formatting function to trace logs. (584eec8) . Test for: (BUGFIX) Error with ip tracing to wrap sets. (7f2123b) . Stop option 'return' changed to 'return_fetch_dir' (b610184) . update format function's description (e598660) . It is safe to change cwd on control node or remote nodes while tracing (2d319d3) . fixed documentation (4e3b8cc) . additional tests for ttb module (da2e84e) . new tests for ttb module (871839b) . . . Action expected from: R15 * sa/callback-attr (compiler, inets, kernel, orber, otp, stdlib) (2010-06-08) 8 commits - Add callback specs into 'application' module in kernel (4bca766) - Add callback specs to tftp module following internet documentation (bba649c) - Add callback specs to inets_service module following possibly deprecated comments (e41a958) - Add '-callback' attributes in stdlib's behaviours (d8d94c4) - Update primary bootstrap (199525a) - Update the documentation with information on the callback attribute (311a25f) - Automatically generate 'behaviour_info' function from '-callback' attributes (7c44f16) - Add '-callback' attribute to language syntax (e8336ff) Action expected from: R15 ------------------------------------------------------------ [Cooking] * bg/temp-hipe-fixes (compiler, kernel) (2010-03-15) 5 commits - Avoid crash by skipping compilation_SUITE:on_load/1 (dbfaf1e) - Inline less aggressively for native-code compilation (d3c0f64) - seq_trace_SUITE: Don't native-compile (c567913) - Disable native code if on_load is used (df43791) - andor_SUITE: Don't native-compile (60d5f08) This branch contains temporary workarounds to avoid failing test cases and is never intended to graduate. * cf/simple_one_for_one_shutdown (otp, stdlib) (2011-09-14) 3 commits - Explain how dynamic child processes are stopped (0473132) - Stack errors when dynamic children are stopped (42c581d) - Explicitly kill dynamic children in supervisors (4775947) * rc/epp-include-path-fix (stdlib) (2011-06-14) 1 commit - Make Erlang preprocessor check dir of current file first (b5d2469) * cf/supervisor_shutdown_infinity (otp, stdlib) (2011-09-14) 2 commits - Add a warning to docs about workers' shutdown strategy (76cc98d) - Allow an infinite timeout to shutdown worker processes (9f6552d) * hl/fix-ms_transform-scope-warn (stdlib) (2011-08-26) 1 commit - ms_transform: Fix incorrect `variable shadowed' warnings (29610af) * mh/create_cookie_error_msg (kernel) (2011-09-15) 1 commit - Specify file name and error on create_cookie failure (9319587) * pg/fix-cover-leftover-down-msg (tools) (2011-08-29) 1 commit - [cover]fix leftover {'DOWN', ..} msg in callers queue (cc087c3) * rc/remote-shell-completion (kernel) (2010-10-22) 1 commit - make tab completion work in remote shells (73d1959) * ta/sendfile (erts, kernel) (2011-01-13) 1 commit - Implement file:sendfile (e362bb2) * va/http-win-dir-traversal (inets) (2011-08-26) 1 commit - Fix httpd directory traversal on Windows (a936795) ------------------------------------------------------------ [Dropped] * rc/ftp-avoid-hanging (inets) (2010-08-25) 1 commit . Avoid hanging in socket-accept (cb7dfde) There will be a dtimeout option in inets-5.8 (R15) that will solve this problem From jimenezrick@REDACTED Sun Sep 25 01:44:28 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Sun, 25 Sep 2011 01:44:28 +0200 Subject: [erlang-patches] Fixes TypEr crash when doing old files cleanup Message-ID: <20110924234428.GA23063@viper.server01.org> Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-typer-delete * One commit in this branch: I reported this bug some months ago. Kostis Sagonas acknowledged that there was a bug but not action was taken. So I would like to insist politely that a fix should be included for this silly bug. The bug is very simple and the solution *does not alter* in any way the core functionality of TypEr. The thing is that when TypEr starts, it tries to clean up the old files generated by itself, but if any of those files is not there, TypEr will crash because of this: ok = file:delete(OldFile) So, it is as simple as to replace that line with: file:delete(OldFile) Thanks in advance. -- Ricardo (http://r.untroubled.be/) From jimenezrick@REDACTED Sun Sep 25 01:49:55 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Sun, 25 Sep 2011 01:49:55 +0200 Subject: [erlang-patches] Fixes debugger UI messages Message-ID: <20110924234955.GB23063@viper.server01.org> Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-debugger-msgs * Two commits in this branch: 1. Fixes debugger message with wx Adds missing spaces when using wx UI. The gs UI didn't need them. Also changes the exclamation of the message by a dot, more formal style for a UI message. 2. Fixes "OK" spelling in debugger messages and variables Simple code refactor in the debugger: renames all the occurrences of "Ok" to "OK" in the code, variable names and strings. This improves the consistency of the code and follows the GTK UI where "OK" is always used. The code changes are very simple, but I tried the debugger with wx and gs to make sure nothing breaks. Thanks in advance. -- Ricardo (http://r.untroubled.be/) From jimenezrick@REDACTED Sun Sep 25 01:56:29 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Sun, 25 Sep 2011 01:56:29 +0200 Subject: [erlang-patches] Removes exec bit from code base in files: erl, hrl, xml, html, asn, gif, xpm, make, C, info files, dat, bat Message-ID: <20110924235629.GC23063@viper.server01.org> Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-remove-exec-bit * Three commits in this branch: 1. Removes exec bit from: erl, hrl, xml, html, asn, gif, xpm I know it's a little too paranoid, but it's so ugly to have in UNIX files with the exec bit set incorrectly :-/. I removed the exec bit just from files which I'm quite sure will not break anything. 2. Removes exec bit from files related to: XML, make, C I'm quite sure this doesn't break anything. 3. Removes exec bit from files: info files, dat, bat This should not break anything. Thanks in advance. -- Ricardo (http://r.untroubled.be/) From g@REDACTED Sun Sep 25 06:57:00 2011 From: g@REDACTED (Garrett Smith) Date: Sat, 24 Sep 2011 23:57:00 -0500 Subject: [erlang-patches] Fix to mod_log logging of content length Message-ID: git fetch git://github.com/gar1t/otp.git mod_log-fix https://github.com/gar1t/otp/compare/mod_log-fix https://github.com/gar1t/otp/compare/mod_log-fix.patch mod_log was logging response content length as a string, which was formatted in the log as an Erlang integer list. It uses integer for Bytes transferred everywhere else. This fix converts content length from a string to an integer, which corrects the log formatting problem. From jimenezrick@REDACTED Mon Sep 26 00:12:22 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Mon, 26 Sep 2011 00:12:22 +0200 Subject: [erlang-patches] Fixes module erlang doc style: option description Message-ID: <20110925221222.GD994@viper.server01.org> Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-erlang-doc-style It is just a small doc fix to keep consistent the module doc. -- Ricardo (http://r.untroubled.be/) From henrik@REDACTED Mon Sep 26 12:02:32 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 26 Sep 2011 12:02:32 +0200 Subject: [erlang-patches] Fixes module erlang doc style: option description In-Reply-To: <20110925221222.GD994@viper.server01.org> References: <20110925221222.GD994@viper.server01.org> Message-ID: <4E804DB8.6020305@erlang.org> On 09/26/2011 12:12 AM, Ricardo Catalinas Jim?nez wrote: > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-erlang-doc-style > > > It is just a small doc fix to keep consistent the module doc. > Thank you, I have included you 4 patches in 'pu'. The codestop for R14B04 has passed so your patches will be for the R15 release. -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Sep 26 12:08:07 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 26 Sep 2011 12:08:07 +0200 Subject: [erlang-patches] Fix to mod_log logging of content length In-Reply-To: References: Message-ID: <4E804F07.7030300@erlang.org> On 09/25/2011 06:57 AM, Garrett Smith wrote: > git fetch git://github.com/gar1t/otp.git mod_log-fix > > https://github.com/gar1t/otp/compare/mod_log-fix > https://github.com/gar1t/otp/compare/mod_log-fix.patch > > mod_log was logging response content length as a string, which was > formatted in the log as an Erlang integer list. > > It uses integer for Bytes transferred everywhere else. > > This fix converts content length from a string to an integer, which > corrects the log formatting problem. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Thank you. I have included your patch in 'pu' -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Sep 26 12:23:14 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 26 Sep 2011 12:23:14 +0200 Subject: [erlang-patches] run_erl: propagate exit status In-Reply-To: References: Message-ID: <4E805292.3010104@erlang.org> On 09/02/2011 07:11 PM, Magnus Henoch wrote: > Hi all, > > Here is a patch that makes run_erl return the exit status of its child > process. (Probably only useful when using run_erl without -daemon, > just for convenient logging.) > > I added a signal handler for SIGALRM, since that appeared to be one of > the ways run_erl exits, but I haven't been able to trigger that in my > testing (it always exits because it can't read from the child's pty). > I would appreciate informed opinions about whether that part is > necessary and correct. > > git fetch git://github.com/legoscia/otp.git run_erl_exit_status > https://github.com/legoscia/otp/commit/29364cf9a6e1fcfd032503ff9888cffc4327b867 > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Thank you. Your patch is included in 'pu' -- /Henrik Nord Erlang/OTP From benmmurphy@REDACTED Tue Sep 27 02:13:26 2011 From: benmmurphy@REDACTED (Ben Murphy) Date: Tue, 27 Sep 2011 01:13:26 +0100 Subject: [erlang-patches] Fix to unknown ssl extension parsing Message-ID: Hi all, Here is a patch that fixes up the decoding of unknown extensions in SSL Hello packets. The original code interpreted the length of unknown extensions as being in bits instead of bytes so after reading one unknown extension it would end up skipping the rest of the extensions (once it has the wrong offset it keeps on reading corrupted extensions). I'm not exactly sure about what impact the incorrect decoding could have. The only Hello extension used in the SSL library is the secure renegotiation extension. It may be possible that sometimes we will not perform secure negotiation when it is available. git fetch git://github.com/benmmurphy/otp.gitfix_unknown_ssl_extension_parsing https://github.com/benmmurphy/otp/commit/5f7725dc581c7891cb41e725db50076d654511ba I was able to run the new_ssl tests fine but I wasn't able to get the old_ssl tests running on my machine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Tue Sep 27 17:01:13 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 27 Sep 2011 17:01:13 +0200 Subject: [erlang-patches] Fix to unknown ssl extension parsing In-Reply-To: References: Message-ID: <4E81E539.4050304@erix.ericsson.se> Hi ! We will accept the patch and leave the last clause as it is with a new comment. Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. Data not following the correct extension format will be considered not understood. Regards Ingela Erlang/OTP team - Ericsson AB Ben Murphy wrote: > Hi all, > > Here is a patch that fixes up the decoding of unknown extensions in > SSL Hello packets. The original code interpreted the length of unknown > extensions as being in bits instead of bytes so after reading one > unknown extension it would end up skipping the rest of the extensions > (once it has the wrong offset it keeps on reading corrupted > extensions). I'm not exactly sure about what impact the incorrect > decoding could have. The only Hello extension used in the SSL library > is the secure renegotiation extension. It may be possible that > sometimes we will not perform secure negotiation when it is available. > > git fetch git://github.com/benmmurphy/otp.git > fix_unknown_ssl_extension_parsing > https://github.com/benmmurphy/otp/commit/5f7725dc581c7891cb41e725db50076d654511ba > > I was able to run the new_ssl tests fine but I wasn't able to get the > old_ssl tests running on my machine. > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From jimenezrick@REDACTED Wed Sep 28 01:36:28 2011 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Wed, 28 Sep 2011 01:36:28 +0200 Subject: [erlang-patches] Fixes net_kernel:get_net_ticktime() doc Message-ID: <20110927233628.GA3980@viper.server01.org> Adds missing description when `ignored' is returned. Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-net_kernel-doc Review here: https://github.com/jimenezrick/otp/compare/fix-net_kernel-doc https://github.com/jimenezrick/otp/compare/fix-net_kernel-doc.patch -- Ricardo (http://r.untroubled.be/) From kostis@REDACTED Wed Sep 28 08:09:06 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 28 Sep 2011 09:09:06 +0300 Subject: [erlang-patches] Fixes TypEr crash when doing old files cleanup In-Reply-To: <20110924234428.GA23063@viper.server01.org> References: <20110924234428.GA23063@viper.server01.org> Message-ID: <4E82BA02.70904@cs.ntua.gr> On 09/25/11 02:44, Ricardo Catalinas Jim?nez wrote: > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-typer-delete > > > * One commit in this branch: > > I reported this bug some months ago. Kostis Sagonas acknowledged that > there was a bug but not action was taken. So I would like to insist > politely that a fix should be included for this silly bug. > > The bug is very simple and the solution *does not alter* in any way the > core functionality of TypEr. > > The thing is that when TypEr starts, it tries to clean up the old files > generated by itself, but if any of those files is not there, TypEr will > crash because of this: > > ok = file:delete(OldFile) > > So, it is as simple as to replace that line with: > > file:delete(OldFile) Thanks for the reminder! We will fix the problem in a better way. Kostis From henrik@REDACTED Wed Sep 28 10:13:09 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 28 Sep 2011 10:13:09 +0200 Subject: [erlang-patches] Fixes TypEr crash when doing old files cleanup In-Reply-To: <4E82BA02.70904@cs.ntua.gr> References: <20110924234428.GA23063@viper.server01.org> <4E82BA02.70904@cs.ntua.gr> Message-ID: <4E82D715.3070605@erlang.org> On 09/28/2011 08:09 AM, Kostis Sagonas wrote: > On 09/25/11 02:44, Ricardo Catalinas Jim?nez wrote: >> Please fetch: >> git fetch git://github.com/jimenezrick/otp.git fix-typer-delete >> >> >> * One commit in this branch: >> >> I reported this bug some months ago. Kostis Sagonas acknowledged that >> there was a bug but not action was taken. So I would like to insist >> politely that a fix should be included for this silly bug. >> >> The bug is very simple and the solution *does not alter* in any way the >> core functionality of TypEr. >> >> The thing is that when TypEr starts, it tries to clean up the old files >> generated by itself, but if any of those files is not there, TypEr will >> crash because of this: >> >> ok = file:delete(OldFile) >> >> So, it is as simple as to replace that line with: >> >> file:delete(OldFile) > > Thanks for the reminder! We will fix the problem in a better way. > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Ok I will drop this from 'pu' then -- /Henrik Nord Erlang/OTP From roques@REDACTED Wed Sep 28 10:16:33 2011 From: roques@REDACTED (Christian von Roques) Date: Wed, 28 Sep 2011 10:16:33 +0200 Subject: [erlang-patches] support md2WithRSAEncryption certificates In-Reply-To: <4E79E238.7070302@erix.ericsson.se> (Sverker Eriksson's message of "Wed, 21 Sep 2011 15:10:16 +0200") References: <87sjpeml6v.fsf@sloppy.mti.ag> <4E6624FC.30504@erlang.org> <87r53tr02d.fsf@sloppy.mti.ag> <4E79E238.7070302@erix.ericsson.se> Message-ID: <8739fhm68u.fsf@sloppy.mti.ag> Sverker Eriksson writes: > Bad news. It looks like we will not include this patch in R14B04 after all. > It caused problem on our build machines that uses version 1.0.0 of > OpenSSL. MD2 hash has been excluded from 1.0.0 because it is not > considered cryptographically secure. Bad news, indeed :-( I'm currently swamped with other work and am unable to find the time required for the correct solution. I've written a trivial patch making usage of MD2 (and all other digests) conditional on #ifndef OPENSSL_NO_MD2 respectively #ifndef OPENSSL_NO_ However, this is NOT the correct long-term solution. Adding #ifdef OPENSSL_NO_MD2 only solves our problem (crashing verification of Verisign's root-certificate) as long as Erlang is linked with an old release of OpenSSL, which still builds support for md2 by default. The right solution would be something like: http://cvs.openssl.org/chngview?cn=18260 http://cvs.openssl.org/chngview?cn=18317 When removing my patchset, please make sure to retain commit 6cd2fa9346d51ab936873d96b5c96bf5c15ddcf0 Author: Christian von Roques Date: Tue Sep 6 19:30:10 2011 +0200 Document crypto:sha_mac_96/2 to compute an SHA MAC, not MD5 As well as the following change in public_key.erl: @@ -335,7 +335,9 %%-------------------------------------------------------------------- verify(PlainText, DigestType, Signature, #'RSAPublicKey'{modulus = Mod, publicExponent = Exp}) - when is_binary (PlainText), DigestType == sha; DigestType == md5 -> + when is_binary(PlainText), + (DigestType == md5 orelse + DigestType == sha) -> crypto:rsa_verify(DigestType, sized_binary(PlainText), sized_binary(Signature), @@ -335,7 +335,9 %%-------------------------------------------------------------------- verify(PlainText, DigestType, Signature, #'RSAPublicKey'{modulus = Mod, publicExponent = Exp}) - when is_binary (PlainText), DigestType == sha; DigestType == md5 -> + when is_binary(PlainText), + (DigestType == md5 orelse + DigestType == sha) -> crypto:rsa_verify(DigestType, sized_binary(PlainText), sized_binary(Signature), Sorry for not completing the job, Christian. > Christian von Roques wrote: >> Henrik Nord writes: >>> On 08/06/2011 08:47 PM, Christian von Roques wrote: >>> >>>> I've added support for md2WithRSAEncryption certificates to public_key >>>> and the necessary support for md2 to crypto:rsa_sign/3 and >>>> crypto:rsa_verify/4. >>>> [...] >>>> >> >> >>> we would like you to correct the following for us to include this branch. >>> >>> * add documentation for crypto >>> * add test case for crypto >>> * Split into two commits (crypto and public_key) >>> >> >> done. >> >> Please re-fetch >> >> git fetch git://github.com/roques/otp.git md2WithRSAEncryption >> >> The branch now consists of the requested two commits and an additional >> trivial third commit documenting crypto:sha_mac_96/2 to compute an SHA >> MAC, not MD5. >> >> Christian. >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> From henrik@REDACTED Thu Sep 29 14:30:39 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 29 Sep 2011 14:30:39 +0200 Subject: [erlang-patches] Fixes net_kernel:get_net_ticktime() doc In-Reply-To: <20110927233628.GA3980@viper.server01.org> References: <20110927233628.GA3980@viper.server01.org> Message-ID: <4E8464EF.3050405@erlang.org> On 09/28/2011 01:36 AM, Ricardo Catalinas Jim?nez wrote: > Adds missing description when `ignored' is returned. > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-net_kernel-doc > > Review here: > https://github.com/jimenezrick/otp/compare/fix-net_kernel-doc > https://github.com/jimenezrick/otp/compare/fix-net_kernel-doc.patch > Thank you, patch included in 'pu' -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Sep 29 14:35:17 2011 From: henrik@REDACTED (Henrik Nord) Date: Thu, 29 Sep 2011 14:35:17 +0200 Subject: [erlang-patches] Fix documentation for erlang:process_info/2 In-Reply-To: References: Message-ID: <4E846605.5060406@erlang.org> On 09/20/2011 07:57 PM, Filipe David Manana wrote: > git fetch git://github.com/fdmanana/otp.git process_info_doc_fix > > Web diff: > https://github.com/fdmanana/otp/compare/process_info_doc_fix > Hi We will not include this patch as it removes the description of the max priority. However it might not be the best written part of the documentation, and if you want to reword it to make it easy for the reader we are willing to accept such a patch. -- /Henrik Nord Erlang/OTP From fdmanana@REDACTED Thu Sep 29 19:15:23 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 29 Sep 2011 10:15:23 -0700 Subject: [erlang-patches] Fix documentation for erlang:process_info/2 In-Reply-To: <4E846605.5060406@erlang.org> References: <4E846605.5060406@erlang.org> Message-ID: On Thu, Sep 29, 2011 at 5:35 AM, Henrik Nord wrote: > On 09/20/2011 07:57 PM, Filipe David Manana wrote: >> >> git ?fetch ?git://github.com/fdmanana/otp.git ?process_info_doc_fix >> >> Web diff: >> https://github.com/fdmanana/otp/compare/process_info_doc_fix >> > Hi > > We will not include this patch as it removes the description of the max > priority. I think it was misunderstood the goal of the patch. The same exact paragraph, about process priorities, is duplicated in 2 places: https://github.com/erlang/otp/blob/dev/erts/doc/src/erlang.xml#L3660 and https://github.com/erlang/otp/blob/dev/erts/doc/src/erlang.xml#L3707 The first one makes sense, as it's under the section describing process_flag(priority, Level). The second one however seems like a copy paste accident because it's under the section describing process_flag(save_calls, N). > However it might not be the best written part of the documentation, and if > you want to reword it to make it easy for the reader we are willing to > accept such a patch. > > -- > /Henrik Nord Erlang/OTP > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Filipe David Manana, "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From kenji.rikitake@REDACTED Fri Sep 30 08:10:30 2011 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 30 Sep 2011 15:10:30 +0900 Subject: [erlang-patches] FreeBSD PCRE Bugfix Re: [erlang-questions] FreeBSD patches In-Reply-To: <20110916095213.GA11461@erix.ericsson.se> References: <20110916095213.GA11461@erix.ericsson.se> Message-ID: <20110930061030.GA13216@k2r.org> The CC option sequence change was for correctly linking the PCRE library, I remember. This has been around for at least for a few years and I suggest including this to R15 will really help. See also: https://github.com/jj1bdx/otp/commit/d362e677b5bd75f1aae7798f3b1b923d33cb0dc0 http://erlang.2086793.n4.nabble.com/Make-Erlang-compile-on-recent-FreeBSD-releases-long-td2119832.html Kenji Rikitake ++> Raimo Niskanen [2011-09-16 11:51:50 +0200]: > # cat files/patch-erts-emulator-Makefile.in > > $FreeBSD: ports/lang/erlang/files/patch-erts-emulator-Makefile.in,v 1.3 2008/11/05 23:32:22 olgeni Exp $ > > --- erts/emulator/Makefile.in.orig > +++ erts/emulator/Makefile.in > @@ -544,7 +546,7 @@ > endif > > $(OBJDIR)/%.o: beam/%.c > - $(CC) $(subst -O2, $(GEN_OPT_FLGS), $(CFLAGS)) $(INCLUDES) -c $< -o $@ > + $(CC) $(INCLUDES) $(subst -O2, $(GEN_OPT_FLGS), $(CFLAGS)) -c $< -o $@ > > else