From gomoripeti@REDACTED Mon Jul 1 02:38:46 2013 From: gomoripeti@REDACTED (=?ISO-8859-1?Q?Peti_G=F6m=F6ri?=) Date: Mon, 1 Jul 2013 01:38:46 +0100 Subject: [erlang-bugs] GUI debugger Module view crashes in dual monitor setup In-Reply-To: References: Message-ID: Hi Mat, debugger supports both the old gs and the new wx gui framework By default it tries to start the wx version if wx is available otherwise falls back to gs. >From the error report I think you use the gs version. As far as I know gs is not supported really by the OTP team any more. Can you try to reproduce it with wx gui: debugger:start(global, default, wx). You might need to install wxWidgets in order for this to work. br Peter On Sun, Jun 30, 2013 at 8:31 PM, Matthew Hegarty wrote: > > To reproduce > > 1. debugger:start() > 2. Move Monitor window to secondary monitor (to LHS in my case) > 3. Module / Interpret (choose module) > 4. Open Module View window > 5. It will crash as soon as there is a mouse move event with: > > Error in process <0.2844.0> with exit value: > {badarith,[{dbg_ui_trace_win,handle_event,2,[{file,"dbg_ui_trace_win.erl"},{line,696}]},{dbg_ui_view,loop,1,[{file,"dbg_ui_view.erl"},{line,77}]}]} > > line is: > > dbg_ui_trace_win.erl > 696 {coords, {gs:read(Win, x)+LastX-5, gs:read(Win, y)+LastY-5}}; > > Workaround: Open the module view window before moving it to secondary > monitor, and then it won't crash. > > === > > Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] > [kernel-poll:false] > > Linux Mint 64bit: 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC > 2012 x86_64 x86_64 x86_64 GNU/Linux > > 1st Monitor: Samsung 22" 1680 x 1050 > 2nd Monitor: Dell 19" 1290 x 1024 > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Mon Jul 1 11:23:45 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 1 Jul 2013 11:23:45 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> Message-ID: <51D14AA1.2000508@erlang.org> On 06/06/2013 01:47 AM, Anthony Ramine wrote: > Hello, > > When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old > unused variables are not recorded as such: > > t(X, Y) -> > #r{a=[ K || K<- Y ],b=[ K || K<- Y ]. > > As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. > > The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: > > t(X, Y) -> > #r{a=A=X,b=A=Y}. > > Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. > > This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. > > git fetch https://github.com/nox/otp.git fix-erl_lint-variable-usage > > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch > > Regards, > Hi Anthony, Your patch has been reviewed and the feedback was: " Hi, The first example of the commit messages lacks a '}' before the dot. I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? Best regards, " -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Mon Jul 1 11:25:13 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 1 Jul 2013 10:25:13 +0100 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: <51CC4E35.8090408@erlang.org> References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> <51CC4E35.8090408@erlang.org> Message-ID: <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> Hi Peter, On 27 Jun 2013, at 15:37, Peter Andersson wrote: > When a process that hasn't inherited the group leader from a test case > process (i.e typically one that hasn't been spawned directly or > indirectly from a test case) sends a printout to common_test (by means > of e.g ct:log), common_test will print the string to the "Unexpected I/O > log", which you find a link to from the test overview page. This is done > by actually sending the string to a process named test_server_io, which > performs the printing. It is passing the message from the common_test > logger to test_server_io that fails, because test_server_io has terminated. > Ok, but this issue only shows up on R16B01, so presumably something has changed in this regard since the last release? > Now, test_server_io should live for as long as common_test is up and > running (well, almost). You should not get that crash report unless > ct:log is called after the test run is finished or test_server_io has > crashed unexpectedly because of a bug. The latter should not be a silent > event - there should be some indication of such a crash during the test > run. Is it possible it's the former problem you encounter, or are you > sure the tests are still running when the printout happens? This thing > smells timing related error to me. Oh it most certainly is timing related. My code is basically doing the following: 1. bootstrap a bunch of configuration 2. find test cases + test config 3. install common test hooks 4. start common test The hooks installed in (3) use the config identified in (2) to bootstrap the test environment, starting and configuring remote nodes and so on, then it monitors these nodes (and other things, all just "test resources" as far as it's concerned) for the lifetime of the test, and verifies they've behaved as expected once the test case/group/suite is completed. Specifically, we do things like "shut down one node of a cluster whilst a client is busy publishing or consuming data and verify failover etc" using this approach. > There are only two short "windows" > during a test run when the common_test logger is alive while > test_server_io isn't: During startup and shutdown of the test run. If > the ct:log call happens during either window, you could get this error. > Well, it's certainly possible - likely even - that the logging handler which calls ct:log/2 *is* being called before a test suite/group/function. But this *does not* produce an error in previous versions of OTP - so it seems you're saying this timing issue is now something that must be considered if you're using >= R16B01. There's nothing in the documentation to warn about this, and it means that any ct-hooks you install must now be very careful not to use ct:log/2 at the wrong time. That's pretty annoying, since one of the reasons for choosing common_test for this is that you get a lot of nice output logging and whatnot after each test run. > Is it easy for you to reproduce the error or does it only happen > occasionally? > This happens every time I run the tests. You can replicate it thus: $ git clone https://github.com/nebularis/systest.git $ cd systest $ make test The pertinent code path is: => systest_main:main/1 => systest_runner:execute/1 => systest_ct:run/3 => ct:run_test/1 The bit that does the logging is systest_ct_log - this is adds a gen_event handler to the 'systest_event_log' event manager, which when logging occurs, will route to systest_ct_log:write_log/4 which in turn calls ct:log/2. The ct-hook that is installed is systest_cth, and there will be plenty of logging whilst we're in calls like pre_init_per_suite, post_end_per_suite and the equivalents for test groups and test functions. > We should try to rule out that there's a bug that causes test_server > failure. How can I assist in verifying that? > Then, the timing problem I described above is quite easily > fixed by making sure common_test prints to stdout if test_server isn't > up and running. I'll implement a fix for this right now, in any event. > Erm - ok, but that's hardly a fix. In that eventuality, I'm likely to just redirect all my logs somewhere else since I don't want my test runs on CI having their stdout cluttered with the *massive* amount of debug logging I do at the internal/framework level. I rely on the HTML logs to store the verbose output of each test, since we might launch up to 6 erlang nodes and report on all manner of things during the test run, but the operator log (i.e., stdout) should just contain the 'passed... failed... etc...' information. Besides, this was never an issue with previous versions of common_test, so I think the right way to fix this is to identify which change(s) broke things and then take a view on how to 'un-break' them. I can assist with this by doing a bisect, but you'll need to tell me which OTP branch I should do that against!? Cheers, Tim > Best regards, > Peter > > Ericsson AB, Erlang/OTP > > > Tim Watson wrote: >> I'm seeing some weird errors in my common_test suites since upgrading >> to R16B01 - I'd like to know if this is a bug or if my code is doing >> something wrong... >> >> ct_util_server got EXIT from <0.227.0>: {noproc, >> {gen_server,call, >> [test_server_io, >> {print,xxxFrom,unexpected_io, >> [[[["
> class=\"default\">*** User 2013-06-26 16:47:39.122 ***"], >> "\n", >> [91,102,114,97,109,101,119,111, >> 114,107,93,32,119,97,116,99, >> 104,100,111,103,58,32,110,111, >> 32,112,114,111,99,115,32,116, >> 111,32,107,105,108,108,"\n"]], >> "\n","
"]]}, >> infinity]}} >> >> That message originated in these lines of code, running in a process >> started outside of common_test: >> >> log(framework, "watchdog: no procs to kill~n", []); >> >> which calls another module: >> >> log(Scope, Fmt, Args) -> >> gen_event:sync_notify(systest_event_log, {Scope, Fmt, Args}). >> >> which ends up in the following handler (amongst other places): >> >> write_log(EvId, _Fd, What, Args) -> >> ct:log("[" ++ as_string(EvId) ++ "] " ++ as_string(What), Args). >> >> So what's up with the "unexpected_io" error here, and *why* has this >> brought the whole common_test run down? >> >> Thanks, >> >> Tim >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > From n.oxyde@REDACTED Mon Jul 1 19:08:04 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 1 Jul 2013 19:08:04 +0200 Subject: [erlang-bugs] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> Message-ID: Hello Bj?rn, I've amended my commit, please refetch. Regards, -- Anthony Ramine Le 26 juin 2013 ? 14:52, Anthony Ramine a ?crit : > Will amend. > > -- > Anthony Ramine > > Le 26 juin 2013 ? 14:43, Bj?rn Gustavsson a ?crit : > >> Thanks! Looks good. I have only two slight comments: >> >> If find the first sentence in the commit message confusing: >> >> "Local fun references look like plain old variables in the Core Erlang >> AST and should not be treated as such." >> >> I would suggest "but" instead of "and": >> >> "Local fun references look like plain old variables in the Core Erlang >> AST, but should not be treated as such." >> >> The test cases tests that the compiler does not crash and that >> the code can be loaded, but it does not test that the code actually >> works. I suggest that you rewrite it to something like this: >> >> ?MODULE() -> >> F = fun bar/1, >> G = lists:last([(fun (X) when F =:= X -> X end)]), >> F = G(F), >> ok. >> >> bar(X) -> >> X. >> >> /Bjorn >> >> >> >> On Sat, May 18, 2013 at 6:22 PM, Anthony Ramine wrote: >> Hello, >> >> This patch fixes the bug by forbidding inlining of variables which values are local fun references outside of application contexts. >> >> git fetch https://github.com/nox/otp.git fix-fname-inlining >> >> https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining >> https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining.patch >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 17 mai 2013 ? 20:06, Anthony Ramine a ?crit : >> >>> Hello, >>> >>> Shorter test case, showing the problem comes from the inline itself and not inline_list_funcs: >>> >>> -module(test). >>> -compile(inline). >>> -export([foo/0]). >>> >>> foo() -> >>> F = fun bar/1, >>> fun (X) when X =:= F -> X end. >>> >>> bar(X) -> X. >>> >>> If you run the core_lint pass, you can see where the problem comes from: >>> >>> $ erlc +clint test.erl >>> test: illegal guard expression in foo/0 >>> >>> The inliner inlines `when 'erlang':'=:='(X, F)` to `'erlang':'=:='(X, 'bar'/1)` but local fun references can't appear in guards. >>> >>> I'll try to make a patch. >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 17 mai 2013 ? 10:55, Masatake Daimon a ?crit : >>> >>>> Hello, >>>> >>>> Compiling the following module makes the compiler crash. I'm using >>>> R16B. >>>> >>>> ===== test.erl ===== >>>> -module(test). >>>> -compile(inline). >>>> -compile(inline_list_funcs). >>>> -export([foo/0]). >>>> >>>> foo() -> >>>> lists:map(fun bar/1, [1]). >>>> >>>> bar(X) -> X. >>>> >>>> ===== the crash ==== >>>> % erlc test.erl >>>> test: function '-foo/0-lists^map/1-0-'/1+15: >>>> Internal consistency check failed - please report this bug. >>>> Instruction: {move,{x,0},{yy,0}} >>>> Error: {invalid_store,{yy,0},term}: >>>> >>>> >>>> Note that the problem disappears with any of these changes: >>>> >>>> * Commenting out "-compile(inline)." >>>> * Commenting out "-compile(inline_list_funcs)." >>>> * Changing the definition of foo/0 to: >>>> foo() -> >>>> lists:map(fun bar/1, []). % [] instead of [1] >>>> * Changing the definition of foo/0 to: >>>> foo() -> >>>> lists:map(fun (A) -> bar(A) end, [1]). >>>> >>>> Regards, >>>> -- >>>> ?? ?? >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> >> >> -- >> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > From n.oxyde@REDACTED Mon Jul 1 19:30:07 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 1 Jul 2013 19:30:07 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: <51D14AA1.2000508@erlang.org> References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> Message-ID: Hi Fredrik, I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: t(X, Y) -> {A=X,A=Y}. As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. Regards, -- Anthony Ramine Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : > On 06/06/2013 01:47 AM, Anthony Ramine wrote: >> Hello, >> >> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >> unused variables are not recorded as such: >> >> t(X, Y) -> >> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >> >> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >> >> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >> >> t(X, Y) -> >> #r{a=A=X,b=A=Y}. >> >> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >> >> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >> >> git fetch >> https://github.com/nox/otp.git >> fix-erl_lint-variable-usage >> >> >> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >> >> >> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >> >> >> Regards, >> >> > Hi Anthony, > Your patch has been reviewed and the feedback was: > > " > Hi, > > The first example of the commit messages lacks a '}' before the dot. > > I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) > > I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? > > Best regards, > > " > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Tue Jul 2 09:19:12 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Jul 2013 09:19:12 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> Message-ID: <51D27EF0.6040805@erlang.org> On 07/01/2013 07:08 PM, Anthony Ramine wrote: > Hello Bj?rn, > > I've amended my commit, please refetch. > > Regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From mrhegarty@REDACTED Tue Jul 2 18:52:15 2013 From: mrhegarty@REDACTED (Matthew Hegarty) Date: Tue, 2 Jul 2013 17:52:15 +0100 Subject: [erlang-bugs] GUI debugger Module view crashes in dual monitor setup In-Reply-To: References: Message-ID: hi Peti Have compiled R16B01 from source, and included wxWidgets. When the debugger uses the wx widgets, the problem is not reproducible. Thanks Matt On 1 July 2013 01:38, Peti G?m?ri wrote: > Hi Mat, > > debugger supports both the old gs and the new wx gui framework > By default it tries to start the wx version if wx is available otherwise > falls back to gs. > From the error report I think you use the gs version. > As far as I know gs is not supported really by the OTP team any more. > > Can you try to reproduce it with wx gui: debugger:start(global, default, > wx). > > You might need to install wxWidgets in order for this to work. > > br > Peter > > On Sun, Jun 30, 2013 at 8:31 PM, Matthew Hegarty wrote: > >> >> To reproduce >> >> 1. debugger:start() >> 2. Move Monitor window to secondary monitor (to LHS in my case) >> 3. Module / Interpret (choose module) >> 4. Open Module View window >> 5. It will crash as soon as there is a mouse move event with: >> >> Error in process <0.2844.0> with exit value: >> {badarith,[{dbg_ui_trace_win,handle_event,2,[{file,"dbg_ui_trace_win.erl"},{line,696}]},{dbg_ui_view,loop,1,[{file,"dbg_ui_view.erl"},{line,77}]}]} >> >> line is: >> >> dbg_ui_trace_win.erl >> 696 {coords, {gs:read(Win, x)+LastX-5, gs:read(Win, y)+LastY-5}}; >> >> Workaround: Open the module view window before moving it to secondary >> monitor, and then it won't crash. >> >> === >> >> Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] >> [kernel-poll:false] >> >> Linux Mint 64bit: 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux >> >> 1st Monitor: Samsung 22" 1680 x 1050 >> 2nd Monitor: Dell 19" 1290 x 1024 >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matwey.kornilov@REDACTED Fri Jul 5 15:03:45 2013 From: matwey.kornilov@REDACTED (Matwey V. Kornilov) Date: Fri, 05 Jul 2013 17:03:45 +0400 Subject: [erlang-bugs] Colons in ERL_LIBS Message-ID: Hi, It seems that character ':' (colon) is not escaped in ERL_LIBS, this way it is impossible to add path consisting of colons to ERL_LIBS variable. Please, see [1] for details, the following construction won't work as expected: ERL_LIBS="/home/user/c\:dir/elixir/lib" erl -s elixir start_cli Comment: 'c:dir' is the name of directory [1] https://github.com/elixir-lang/elixir/issues/1375#issuecomment-20510270 From n.oxyde@REDACTED Fri Jul 5 16:00:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 5 Jul 2013 16:00:03 +0200 Subject: [erlang-bugs] Colons in ERL_LIBS In-Reply-To: References: Message-ID: <04E4A1E0-C4CE-4F2F-AA62-A8E53535FC89@gmail.com> Hello Matwey, Character `:` is a path delimiter. Bash itself does not understand paths containing `:` in `$PATH`. You should not use paths containing a colon. $ mkdir foo:bar $ cd foo\:bar/ $ ln -s $(which true) gagagou $ cd - /Users/nox $ gagagou -bash: gagagou: command not found $ export PATH="`pwd`/foo\:bar:$PATH" $ echo $PATH /Users/nox/foo\:bar:/Users/nox/.cabal/bin:/Users/nox/bin:/usr/local/Cellar/ruby/2.0.0-p247/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin:/usr/texbin $ gagagou -bash: gagagou: command not found $ mv foo:bar foobar $ export PATH="`pwd`/foobar:$PATH" $ gagagou $ echo $? 0 Regards, -- Anthony Ramine Le 5 juil. 2013 ? 15:03, Matwey V. Kornilov a ?crit : > > Hi, > > It seems that character ':' (colon) is not escaped in ERL_LIBS, this way it is impossible to add path consisting of colons to ERL_LIBS variable. > > Please, see [1] for details, the following construction won't work as expected: > > ERL_LIBS="/home/user/c\:dir/elixir/lib" erl -s elixir start_cli > > Comment: 'c:dir' is the name of directory > > [1] https://github.com/elixir-lang/elixir/issues/1375#issuecomment-20510270 > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From dch@REDACTED Sun Jul 7 22:15:49 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Sun, 7 Jul 2013 22:15:49 +0200 Subject: [erlang-bugs] Colons in ERL_LIBS In-Reply-To: <04E4A1E0-C4CE-4F2F-AA62-A8E53535FC89@gmail.com> References: <04E4A1E0-C4CE-4F2F-AA62-A8E53535FC89@gmail.com> Message-ID: On Friday, July 5, 2013, Anthony Ramine wrote: > Hello Matwey, > > Character `:` is a path delimiter. Bash itself does not understand paths > containing `:` in `$PATH`. You should not use paths containing a colon. > > That's OS dependent. You can do that on Windows, OSX, possibly VMS too but my memory fails me. I'd say this is a bug as c:\ is pretty much std on windows. As a workaround, IIRC windows erlang accepts relative paths, and / windows/system32 for example will be considered as relative to the root drive of the current working dir. Other alternatives include ntfs junction points. > $ mkdir foo:bar > $ cd foo\:bar/ > $ ln -s $(which true) gagagou > $ cd - > /Users/nox > $ gagagou > -bash: gagagou: command not found > $ export PATH="`pwd`/foo\:bar:$PATH" > $ echo $PATH > > /Users/nox/foo\:bar:/Users/nox/.cabal/bin:/Users/nox/bin:/usr/local/Cellar/ruby/2.0.0-p247/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin:/usr/texbin > $ gagagou > -bash: gagagou: command not found > $ mv foo:bar foobar > $ export PATH="`pwd`/foobar:$PATH" > $ gagagou > $ echo $? > 0 > > Regards, > > -- > Anthony Ramine > > Le 5 juil. 2013 ? 15:03, Matwey V. Kornilov a ?crit : > > > > > Hi, > > > > It seems that character ':' (colon) is not escaped in ERL_LIBS, this way > it is impossible to add path consisting of colons to ERL_LIBS variable. > > > > Please, see [1] for details, the following construction won't work as > expected: > > > > ERL_LIBS="/home/user/c\:dir/elixir/lib" erl -s elixir start_cli > > > > Comment: 'c:dir' is the name of directory > > > > [1] > https://github.com/elixir-lang/elixir/issues/1375#issuecomment-20510270 > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Sent from my PDP11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Jul 7 23:37:00 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 7 Jul 2013 23:37:00 +0200 Subject: [erlang-bugs] Colons in ERL_LIBS In-Reply-To: References: <04E4A1E0-C4CE-4F2F-AA62-A8E53535FC89@gmail.com> Message-ID: <40605476-5CF3-4275-B613-33F18C1B85B8@gmail.com> With regard to $PATH; that's shell dependent, not OS dependent. And I know of no shell on any UNIX-like system that allows escaping colons in path variables. Not that I know that many though. -- Anthony Ramine Le 7 juil. 2013 ? 22:15, Dave Cottlehuber a ?crit : > That's OS dependent. You can do that on Windows, OSX, possibly VMS too but my memory fails me. I'd say this is a bug as c:\ is pretty much std on windows. From Tobias.Schlager@REDACTED Mon Jul 8 11:53:07 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Mon, 8 Jul 2013 09:53:07 +0000 Subject: [erlang-bugs] SNMP erlNodeReductions defined too narrow Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B08C0E@MAIL01.win.lbaum.eu> Hi all, I just came across this line in the logs of a testing server running R16B01: User error: Got 508191824798 from {otp_mib,erl_node_table,[]}. Using wrongValue A SNMP walk with snmpwalk -v 2c -c public host:port .iso.org.dod.internet.private.enterprises fails with the following output: ... SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.3.1 = STRING: "BEAM" SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.4.1 = STRING: "5.10.2" SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.5.1 = Gauge32: 0 SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.6.1 = Counter32: 99993630 SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.7.1 = Counter32: 419219062 Error in packet. Reason: (genError) A general failure occured Failed object: SNMPv2-SMI::enterprises.193.19.3.1.2.1.1.1.7.1 Examining the exact value on the machine with erlang:statistics(wall_clock) confirms the wallclock value of 419219062 and I can't see a problem with that value. However, when I look at the next value 193.19.3.1.2.1.1.1.8.1 (erlNodeReductions) manually, erlang:statistics(reductions) gives me a total number of 508213447798 reductions. This looks exactly like the value in the error message. Furthermore, the value is clearly out of range for a 'Counter32' which is the defined type for erlNodeReductions. Googling the topic brought up the following 3 year old repository https://github.com/dreverri/erlang_snmp_reduction_issue that contains code the reproduce this behaviour. Regards Tobias From watson.timothy@REDACTED Fri Jul 12 02:03:16 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 12 Jul 2013 01:03:16 +0100 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> <51CC4E35.8090408@erlang.org> <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> Message-ID: On 1 July 2013 10:25, Tim Watson wrote:> We should try to rule out that there's a bug that causes test_server > > failure. > > How can I assist in verifying that? > Any more news on this? Is there anything more I can do to assist? Cheers, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Fri Jul 12 09:29:08 2013 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 12 Jul 2013 09:29:08 +0200 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> <51CC4E35.8090408@erlang.org> <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> Message-ID: <51DFB044.50302@erlang.org> Hello Tim, Peter is currently away enjoying the sunny summer here in Sweden. I'm sure he will get back to you when he comes back! Lukas On 12/07/13 02:03, Tim Watson wrote: > On 1 July 2013 10:25, Tim Watson > wrote:> We should try to rule out > that there's a bug that causes test_server > > > failure. > > How can I assist in verifying that? > > > Any more news on this? Is there anything more I can do to assist? > > Cheers, > Tim > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Fri Jul 12 09:36:17 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 12 Jul 2013 08:36:17 +0100 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: <51DFB044.50302@erlang.org> References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> <51CC4E35.8090408@erlang.org> <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> <51DFB044.50302@erlang.org> Message-ID: Hi Lukas, thanks for letting me know! Cheers, Tim On 12 Jul 2013, at 08:29, Lukas Larsson wrote: > Hello Tim, > > Peter is currently away enjoying the sunny summer here in Sweden. I'm sure he will get back to you when he comes back! > > Lukas > On 12/07/13 02:03, Tim Watson wrote: >> On 1 July 2013 10:25, Tim Watson wrote:> We should try to rule out that there's a bug that causes test_server >> > failure. >> >> How can I assist in verifying that? >> >> Any more news on this? Is there anything more I can do to assist? >> >> Cheers, >> Tim >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.zegenhagen@REDACTED Mon Jul 15 12:56:33 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 15 Jul 2013 12:56:33 +0200 Subject: [erlang-bugs] Denial-of-service vulnerability in erlang's group.erl In-Reply-To: <20130629215909.GD3827@corelatus.se> References: <1372170576.4174.42.camel@ax-sze> <20130625152057.GA4510@ferdair.local> <1372236330.4174.71.camel@ax-sze> <20130629215909.GD3827@corelatus.se> Message-ID: <1373885793.3597.11.camel@ax-sze> Dear Matthias, sorry for the delayed answer, I was on vacation for two weeks and read your mail just today. > While it sounds like there's a problem in group.erl which should be > fixed, my experience is that things aren't quite as bad as: > > > * We cannot simply amend the situation. > > On our embedded device, we completely avoid the situation by > authenticating users before they get to the CLI implemented in Erlang. > > We use 'dropbear' as the SSH server and have /etc/passwd use 'to_erl' > as the user's shell. The approach for serial ports is similar. > > Once authenticated, you can reboot our system using the 'reset' command. Our system probably differs slightly. We keep the "to_erl" option for the developer's shell (yes, we have a hidden serial port on the board that's not accessible to customers). And we need much more control over configurability and features than getty/dropbear give us. Therefore we would like to stick to the option of implementing our application logic in erlang with the software stacks that are already available. > You were also concerned about linux's OOM killer. > > Finding and stopping all possible ways Erlang can grab unexpected > amounts of RAM is difficult, and not just because they're no longer > unexpected once you find them. Telling linux to limit the amount > Erlang _can_ grab is much easier. You can do that with 'ulimit' or, if > starting from something like 'heart' (which you probably should be), > setrlimit(). That might be an option to stop linux from crashing other processes, but still it's bad if the erlang VM itself crashes because that means that the service is out of operation until everything is fully re-initialized. I want to underline that I do not want to start a flame war or be overly offensive, but I'm astonished about the reluctance to fix this particular bug which we consider a security bug due to the way it affects our devices. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From tuncer.ayaz@REDACTED Fri Jul 19 17:59:06 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 19 Jul 2013 17:59:06 +0200 Subject: [erlang-bugs] reltool gui and wxWidgets 2.9 Message-ID: Given that current wxErlang builds and wx:demo/0 works successfully with wxWidgets 2.9 Gtk+ 2.x, I did assume it's supposed to generally work. I did encounter some oddities though when I tried to start the reltool GUI via reltool:start/0. Basically, starting a fresh node and running reltool:start() doesn't work for me. The only way to successfully spawn it with wxErlang built against wxWidgets 2.9 is as follows: -- call reltool:debug() instead of reltool:start(): 1> reltool:debug(). -- call reltool:start() after having spawned another wxErlang GUI first: 1> observer:start(). ok 2> reltool:start(). {ok,<0.48.0>} -- dbg trace calls to reltool:* and reltool:start_link/1: 3> reltool:start(). (<0.31.0>) call reltool:start() (<0.31.0>) call reltool:start([]) (<0.31.0>) call reltool:start_link([]) (<0.31.0>) call reltool_sys_win:start_link([]) {ok,<0.38.0>} (<0.31.0>) returned from reltool_sys_win:start_link/1 -> {ok,<0.38.0>} 4> (<0.31.0>) returned from reltool:start_link/1 -> {ok,<0.38.0>} (<0.31.0>) returned from reltool:start/1 -> {ok,<0.38.0>} (<0.31.0>) returned from reltool:start/0 -> {ok,<0.38.0>} Other interesting wxWidgets 2.9 observations: -- debugger:simple(reltool, start, []) segfault: 1> debugger:quick(reltool, start, []). Segmentation fault (core dumped) -- reltool:debug/0 next/continue segfault: 1> debugger:quick(reltool, debug, []). ;; it spawns successfully but segfaults when you press next/continue Segmentation fault (core dumped) -- generally speaking the wxWidgets 2.9 version seems to take longer to display the initial window. To be clear, I haven't seen any of the above issues with wxErlang built against wxWidgets 2.8. Is wxWidgets 2.9 support still experimental and are these errors unsurprising? From andrew@REDACTED Sat Jul 20 05:25:09 2013 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 19 Jul 2013 23:25:09 -0400 Subject: [erlang-bugs] {header,1} inconsistency between TCP and SSL Message-ID: <20130720032509.GF27534@hijacked.us> Today I noticed a difference in behaviour of the {header, 1} option when using TCP and SSL in erlang releases R15B02 and newer: https://gist.github.com/Vagabond/dabecf53ac8b4317e51c As you can see, SSL in {header, 1} mode no longer includes the empty binary as the second element in the list. I believe this change was made in this commit: https://github.com/erlang/otp/commit/8f97b428eb8f2fb89c3f9ec348f577304b1b9131 If you change that back, things work the same as TCP again, but all the header_decode tests in ssl_packet_SUITE start to fail. I'm simply going to stop using {header,1} and just use the bit syntax, since I notice that Ingela considers it to be a silly option, but I wanted to at least point the inconsistency out, for posterity. Andrew From paul.joseph.davis@REDACTED Sun Jul 21 00:33:57 2013 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sat, 20 Jul 2013 17:33:57 -0500 Subject: [erlang-bugs] Compiler bug with unsafe variables in nested try statements. Message-ID: I seem to have uncovered a bug when detecting or displaying "variable 'Acc' unsafe in 'try'" errors. I managed to reduce this to a fairly small test case: -module(bam). -export([bang/0]). bang() -> case 1 of nil -> Acc = 2; _ -> try Acc = 3, Acc catch _:_ -> ok end end, Acc. The important point that I found is that its necessary to reference Acc in the try body after its been bound. Without that the unsafe error is generated properly. The error I'm seeing is: Function: bang/0 bam.erl:none: internal error in core_dsetel_module; crash reason: {{badmatch,error}, [{sys_core_dsetel,visit,2, [{file,"sys_core_dsetel.erl"},{line,98}]}, {sys_core_dsetel,visit,2, [{file,"sys_core_dsetel.erl"},{line,117}]}, {sys_core_dsetel,visit_module_1,3, [{file,"sys_core_dsetel.erl"},{line,79}]}, {sys_core_dsetel,visit_module,1, [{file,"sys_core_dsetel.erl"},{line,75}]}, {sys_core_dsetel,module,2, [{file,"sys_core_dsetel.erl"},{line,70}]}, {compile,core_dsetel_module,1, [{file,"compile.erl"},{line,1159}]}, {compile,'-internal_comp/4-anonymous-1-',2, [{file,"compile.erl"},{line,276}]}, {compile,fold_comp,3,[{file,"compile.erl"},{line,294}]}]} I discovered this on R14B01 but its still present on R16B01 as well. Out of curiosity I also reproduced it with an if statement as well: #!/usr/bin/env escript -mode(compile). main(_) -> Maybe = bar(), if Maybe -> Acc = 1; true -> try Acc = 2, Acc %, throw(foo) catch _ -> ok end end, erlang:display(Acc). bar() -> false. Somewhat fun is that if we comment out -mode(compile) for interpreted mode we can get all three values (1, 2, unbound) of Acc by changing bar/0 and/or uncommenting the throw statement. Obviously my code is broken trying to reference a variable like that; I was just a bit surprised to see a compiler error. From n.oxyde@REDACTED Tue Jul 23 09:27:57 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 23 Jul 2013 09:27:57 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> Message-ID: <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Hello, I've added a commit to the branch that fix the bug discovered with Paul Davis where used variables in try expressions aren't properly marked as unsafe. Please refetch. -- Anthony Ramine Le 1 juil. 2013 ? 19:30, Anthony Ramine a ?crit : > Hi Fredrik, > > I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: > > t(X, Y) -> > {A=X,A=Y}. > > As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. > > Regards, > > -- > Anthony Ramine > > Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : > >> On 06/06/2013 01:47 AM, Anthony Ramine wrote: >>> Hello, >>> >>> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >>> unused variables are not recorded as such: >>> >>> t(X, Y) -> >>> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >>> >>> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >>> >>> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >>> >>> t(X, Y) -> >>> #r{a=A=X,b=A=Y}. >>> >>> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >>> >>> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >>> >>> git fetch >>> https://github.com/nox/otp.git >>> fix-erl_lint-variable-usage >>> >>> >>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >>> >>> >>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >>> >>> >>> Regards, >>> >>> >> Hi Anthony, >> Your patch has been reviewed and the feedback was: >> >> " >> Hi, >> >> The first example of the commit messages lacks a '}' before the dot. >> >> I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) >> >> I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? >> >> Best regards, >> >> " >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> > From n.oxyde@REDACTED Tue Jul 23 09:28:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 23 Jul 2013 09:28:41 +0200 Subject: [erlang-bugs] Compiler bug with unsafe variables in nested try statements. In-Reply-To: References: Message-ID: Hello Paul, I've added a fix for that bug in another patch I submitted which fixes a bunch of problems with variable usage tracking. Regards, -- Anthony Ramine Le 21 juil. 2013 ? 00:33, Paul Davis a ?crit : > I seem to have uncovered a bug when detecting or displaying "variable > 'Acc' unsafe in 'try'" errors. I managed to reduce this to a fairly > small test case: > > -module(bam). > -export([bang/0]). > bang() -> > case 1 of > nil -> > Acc = 2; > _ -> > try > Acc = 3, > Acc > catch _:_ -> > ok > end > end, > Acc. > > The important point that I found is that its necessary to reference > Acc in the try body after its been bound. Without that the unsafe > error is generated properly. > > The error I'm seeing is: > > Function: bang/0 > bam.erl:none: internal error in core_dsetel_module; > crash reason: {{badmatch,error}, > [{sys_core_dsetel,visit,2, > [{file,"sys_core_dsetel.erl"},{line,98}]}, > {sys_core_dsetel,visit,2, > [{file,"sys_core_dsetel.erl"},{line,117}]}, > {sys_core_dsetel,visit_module_1,3, > [{file,"sys_core_dsetel.erl"},{line,79}]}, > {sys_core_dsetel,visit_module,1, > [{file,"sys_core_dsetel.erl"},{line,75}]}, > {sys_core_dsetel,module,2, > [{file,"sys_core_dsetel.erl"},{line,70}]}, > {compile,core_dsetel_module,1, > [{file,"compile.erl"},{line,1159}]}, > {compile,'-internal_comp/4-anonymous-1-',2, > [{file,"compile.erl"},{line,276}]}, > {compile,fold_comp,3,[{file,"compile.erl"},{line,294}]}]} > > I discovered this on R14B01 but its still present on R16B01 as well. > > Out of curiosity I also reproduced it with an if statement as well: > > #!/usr/bin/env escript > > -mode(compile). > > main(_) -> > Maybe = bar(), > if Maybe -> > Acc = 1; > true -> > try > Acc = 2, > Acc %, throw(foo) > catch _ -> > ok > end > end, > erlang:display(Acc). > > bar() -> false. > > Somewhat fun is that if we comment out -mode(compile) for interpreted > mode we can get all three values (1, 2, unbound) of Acc by changing > bar/0 and/or uncommenting the throw statement. > > Obviously my code is broken trying to reference a variable like that; > I was just a bit surprised to see a compiler error. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From paul.joseph.davis@REDACTED Tue Jul 23 09:36:53 2013 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Tue, 23 Jul 2013 02:36:53 -0500 Subject: [erlang-bugs] Compiler bug with unsafe variables in nested try statements. In-Reply-To: References: Message-ID: Thanks! On Tue, Jul 23, 2013 at 2:28 AM, Anthony Ramine wrote: > Hello Paul, > > I've added a fix for that bug in another patch I submitted which fixes a bunch of problems with variable usage tracking. > > Regards, > > -- > Anthony Ramine > > Le 21 juil. 2013 ? 00:33, Paul Davis a ?crit : > >> I seem to have uncovered a bug when detecting or displaying "variable >> 'Acc' unsafe in 'try'" errors. I managed to reduce this to a fairly >> small test case: >> >> -module(bam). >> -export([bang/0]). >> bang() -> >> case 1 of >> nil -> >> Acc = 2; >> _ -> >> try >> Acc = 3, >> Acc >> catch _:_ -> >> ok >> end >> end, >> Acc. >> >> The important point that I found is that its necessary to reference >> Acc in the try body after its been bound. Without that the unsafe >> error is generated properly. >> >> The error I'm seeing is: >> >> Function: bang/0 >> bam.erl:none: internal error in core_dsetel_module; >> crash reason: {{badmatch,error}, >> [{sys_core_dsetel,visit,2, >> [{file,"sys_core_dsetel.erl"},{line,98}]}, >> {sys_core_dsetel,visit,2, >> [{file,"sys_core_dsetel.erl"},{line,117}]}, >> {sys_core_dsetel,visit_module_1,3, >> [{file,"sys_core_dsetel.erl"},{line,79}]}, >> {sys_core_dsetel,visit_module,1, >> [{file,"sys_core_dsetel.erl"},{line,75}]}, >> {sys_core_dsetel,module,2, >> [{file,"sys_core_dsetel.erl"},{line,70}]}, >> {compile,core_dsetel_module,1, >> [{file,"compile.erl"},{line,1159}]}, >> {compile,'-internal_comp/4-anonymous-1-',2, >> [{file,"compile.erl"},{line,276}]}, >> {compile,fold_comp,3,[{file,"compile.erl"},{line,294}]}]} >> >> I discovered this on R14B01 but its still present on R16B01 as well. >> >> Out of curiosity I also reproduced it with an if statement as well: >> >> #!/usr/bin/env escript >> >> -mode(compile). >> >> main(_) -> >> Maybe = bar(), >> if Maybe -> >> Acc = 1; >> true -> >> try >> Acc = 2, >> Acc %, throw(foo) >> catch _ -> >> ok >> end >> end, >> erlang:display(Acc). >> >> bar() -> false. >> >> Somewhat fun is that if we comment out -mode(compile) for interpreted >> mode we can get all three values (1, 2, unbound) of Acc by changing >> bar/0 and/or uncommenting the throw statement. >> >> Obviously my code is broken trying to reference a variable like that; >> I was just a bit surprised to see a compiler error. >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From fritchie@REDACTED Tue Jul 23 22:44:33 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 23 Jul 2013 15:44:33 -0500 Subject: [erlang-bugs] R16B01's monitor delivery is broken? Message-ID: <15464.1374612273@snookles.snookles.com> Hi, everyone. Hope your summer vacations are going well. I have some bad news for Rickard, at least. SHA: e794251f8e54d6697e1bcc360471fd76b20c7748 Author: Rickard Green Date: Thu May 30 2013 07:56:31 GMT-0500 (CDT) Subject: Merge branch 'rickard/ptab-id-alloc/OTP-11077' into maint Parent: 22685099ace9802016bf6203c525702084717d72 Parent: 5c039a1fb4979314912dc3af6626d8d7a1c73993 Merge branch 'rickard/ptab-id-alloc/OTP-11077' into maint * rickard/ptab-id-alloc/OTP-11077: Introduce a better id allocation algorithm for PTabs This commit appears to break monitor delivery? And it may or may not be causing processes to die for reasons that we cannot see or understand. Run with R15B03-1, the example code in test6.erl is merely slow: https://gist.github.com/jtuple/aa4830a0ff0a94f69484/raw/02adc518e225f263a7e25d339ec7200ef2dda491/test6.erl On my 4 core/8 HT core MacBook Pro, R15B03-1 cannot go above 200% CPU utilization, and the execution time is correspondingly slooow. But it appears to work correctly. erl -eval '[begin io:format("Iteration ~p at ~p\n", [X,time()]), test6:go() end || X <- lists:seq(1, 240)].' When run with R16B, it's *much* faster. CPU utilization above 750% confirms that it's going faster. And it appears to work correctly. However, when run with R16B01, we see non-deterministic hangs on both OS X and various Linux platforms. CPU consumption by the "beam.smp" process drops to 0, and the next cycle of the list comprehension never starts. Thanks to the magic of Git, it's pretty clear that the commit above is broken. The commit before it appears to work well (i.e., does not hang). SHA: 22685099ace9802016bf6203c525702084717d72 Author: Anders Svensson Date: Wed May 29 2013 11:46:10 GMT-0500 (CDT) Subject: Merge branch 'anders/diameter/watchdog_function_clause/OTP-11115' into maint Using R16B01 together with the "+P legacy" flag does not hang. But this problem has given us at Basho enough ... caution ... that we will be much more cautious about moving our app packaging from R15B* to R16B*. Several seconds after CPU consumption drops to 0%, then I trigger the creation of a "erl_crash.dump" file using erlang:halt("bummer"). If I look at that file, then the process "Spawned as: test6:do_work2/0" says that there are active unidirectional links (i.e., monitors), but there is one process on that list that does not have a corresponding "=proc:" entry in the dump ... which strongly suggests to me that the process is dead. Using DTrace, I've been able to establish that the dead process is indeed alive at one time and has been scheduled & descheduled at least once. So there are really two mysteries: 1. Why is one of the test6:indirect_proxy/1 processes dying unexpectedly? (The monitor doesn't fire, SASL isn't logging any errors, etc.) 2. Why isn't a monitor message being delivered? Many thanks to Joe Blomstedt, Evan Vigil-McClanahan, Andrew Thompson, Steve Vinoski, and Sean Cribbs for their sleuthing work. -Scott --- snip --- snip --- snip --- snip --- snip --- R15B03 lock count analysis, FWIW: lock id #tries #collisions collisions [%] time [us] duration [%] ----- --- ------- ------------ --------------- ---------- ------------- proc_tab 1 1280032 1266133 98.9142 60642804 557.0583 run_queue 8 3617608 12874 0.3559 261722 2.4042 sys_tracers 1 1280042 6445 0.5035 19365 0.1779 pix_lock 256 4480284 1213 0.0271 9777 0.0898 timeofday 1 709955 1187 0.1672 3216 0.0295 [......] --- snip --- snip --- snip --- snip --- snip --- =proc:<0.29950.154> State: Waiting Spawned as: test6:do_work2/0 Spawned by: <0.48.0> Started: Tue Jul 23 04:50:54 2013 Message queue length: 0 Number of heap fragments: 0 Heap fragment data: 0 Link list: [{from,<0.48.0>,#Ref<0.0.19.96773>}, {to,<0.32497.154>,#Ref<0.0.19.96797>}, {to,<0.1184.155>,#Ref<0.0.19.96796>}, {to,<0.31361.154>,#Ref<0.0.19.96799>}, {to,<0.32019.154>,#Ref<0.0.19.96801>}, {to,<0.32501.154>,#Ref<0.0.19.96800>}, {to,<0.1352.155>,#Ref<0.0.19.96803>}, {to,<0.32415.154>,#Ref<0.0.19.96805>}, {to,<0.504.155>,#Ref<0.0.19.96804>}, {to,<0.87.155>,#Ref<0.0.19.96802>}, {to,<0.776.155>,#Ref<0.0.19.96798>}] Reductions: 45 Stack+heap: 233 OldHeap: 0 Heap unused: 155 OldHeap unused: 0 Memory: 3472 Program counter: 0x000000001e1504d0 (test6:do_work2/0 + 184) CP: 0x0000000000000000 (invalid) arity = 0 From wallentin.dahlberg@REDACTED Tue Jul 23 23:19:26 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 23 Jul 2013 23:19:26 +0200 Subject: [erlang-bugs] R16B01's monitor delivery is broken? In-Reply-To: <15464.1374612273@snookles.snookles.com> References: <15464.1374612273@snookles.snookles.com> Message-ID: True, that seems suspicious. The vacation for Rickard is going great I think. Last I heard from him, he was diving round ?land (literally "island-land") in south-eastern sweden. It will be a few weeks before he's back. In the meanwhile it is fairly lonely here at OTP, today we were two persons at the office, and there is a lot of stuff to do. I will have a quick look at it and verify but will probably let Rickard deal with it when he comes back. Thanks for a great summary and drill down of the problem! Regards, Bj?rn-Egil 2013/7/23 Scott Lystig Fritchie > Hi, everyone. Hope your summer vacations are going well. I have some > bad news for Rickard, at least. > > SHA: e794251f8e54d6697e1bcc360471fd76b20c7748 > Author: Rickard Green > Date: Thu May 30 2013 07:56:31 GMT-0500 (CDT) > Subject: Merge branch 'rickard/ptab-id-alloc/OTP-11077' into maint > Parent: 22685099ace9802016bf6203c525702084717d72 > Parent: 5c039a1fb4979314912dc3af6626d8d7a1c73993 > Merge branch 'rickard/ptab-id-alloc/OTP-11077' into maint > > * rickard/ptab-id-alloc/OTP-11077: > Introduce a better id allocation algorithm for PTabs > > This commit appears to break monitor delivery? And it may or may not be > causing processes to die for reasons that we cannot see or understand. > > Run with R15B03-1, the example code in test6.erl is merely slow: > > > https://gist.github.com/jtuple/aa4830a0ff0a94f69484/raw/02adc518e225f263a7e25d339ec7200ef2dda491/test6.erl > > On my 4 core/8 HT core MacBook Pro, R15B03-1 cannot go above 200% CPU > utilization, and the execution time is correspondingly slooow. But it > appears to work correctly. > > erl -eval '[begin io:format("Iteration ~p at ~p\n", [X,time()]), > test6:go() end || X <- lists:seq(1, 240)].' > > When run with R16B, it's *much* faster. CPU utilization above 750% > confirms that it's going faster. And it appears to work correctly. > > However, when run with R16B01, we see non-deterministic hangs on both OS > X and various Linux platforms. CPU consumption by the "beam.smp" > process drops to 0, and the next cycle of the list comprehension never > starts. > > Thanks to the magic of Git, it's pretty clear that the commit above is > broken. The commit before it appears to work well (i.e., does not > hang). > > SHA: 22685099ace9802016bf6203c525702084717d72 > Author: Anders Svensson > Date: Wed May 29 2013 11:46:10 GMT-0500 (CDT) > Subject: Merge branch > 'anders/diameter/watchdog_function_clause/OTP-11115' into maint > > Using R16B01 together with the "+P legacy" flag does not hang. But this > problem has given us at Basho enough ... caution ... that we will be > much more cautious about moving our app packaging from R15B* to R16B*. > > Several seconds after CPU consumption drops to 0%, then I trigger the > creation of a "erl_crash.dump" file using erlang:halt("bummer"). If I > look at that file, then the process "Spawned as: test6:do_work2/0" says > that there are active unidirectional links (i.e., monitors), but there > is one process on that list that does not have a corresponding > "=proc:" entry in the dump ... which strongly suggests > to me that the process is dead. Using DTrace, I've been able to > establish that the dead process is indeed alive at one time and has been > scheduled & descheduled at least once. So there are really two > mysteries: > > 1. Why is one of the test6:indirect_proxy/1 processes dying > unexpectedly? (The monitor doesn't fire, SASL isn't logging any errors, > etc.) > > 2. Why isn't a monitor message being delivered? > > Many thanks to Joe Blomstedt, Evan Vigil-McClanahan, Andrew Thompson, > Steve Vinoski, and Sean Cribbs for their sleuthing work. > > -Scott > > --- snip --- snip --- snip --- snip --- snip --- > > R15B03 lock count analysis, FWIW: > > lock id #tries #collisions collisions [%] time [us] > duration [%] > ----- --- ------- ------------ --------------- ---------- > ------------- > proc_tab 1 1280032 1266133 98.9142 60642804 > 557.0583 > run_queue 8 3617608 12874 0.3559 261722 > 2.4042 > sys_tracers 1 1280042 6445 0.5035 19365 > 0.1779 > pix_lock 256 4480284 1213 0.0271 9777 > 0.0898 > timeofday 1 709955 1187 0.1672 3216 > 0.0295 > [......] > > --- snip --- snip --- snip --- snip --- snip --- > > =proc:<0.29950.154> > State: Waiting > Spawned as: test6:do_work2/0 > Spawned by: <0.48.0> > Started: Tue Jul 23 04:50:54 2013 > Message queue length: 0 > Number of heap fragments: 0 > Heap fragment data: 0 > Link list: [{from,<0.48.0>,#Ref<0.0.19.96773>}, > {to,<0.32497.154>,#Ref<0.0.19.96797>}, > {to,<0.1184.155>,#Ref<0.0.19.96796>}, > {to,<0.31361.154>,#Ref<0.0.19.96799>}, > {to,<0.32019.154>,#Ref<0.0.19.96801>}, > {to,<0.32501.154>,#Ref<0.0.19.96800>}, > {to,<0.1352.155>,#Ref<0.0.19.96803>}, > {to,<0.32415.154>,#Ref<0.0.19.96805>}, {to,<0.504.155>,#Ref<0.0.19.96804>}, > {to,<0.87.155>,#Ref<0.0.19.96802>}, {to,<0.776.155>,#Ref<0.0.19.96798>}] > Reductions: 45 > Stack+heap: 233 > OldHeap: 0 > Heap unused: 155 > OldHeap unused: 0 > Memory: 3472 > Program counter: 0x000000001e1504d0 (test6:do_work2/0 + 184) > CP: 0x0000000000000000 (invalid) > arity = 0 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manuel@REDACTED Wed Jul 24 23:33:16 2013 From: manuel@REDACTED (=?UTF-8?Q?Manuel_Dur=C3=A1n_Aguete?=) Date: Wed, 24 Jul 2013 23:33:16 +0200 Subject: [erlang-bugs] A dets big ? Message-ID: Hi all, I've posted to erlang-questions but email is waiting for moderator approval. After upgrading a project from R14B03 to R16B01 I've found that dets files are growing constanly after delete operations. In previous version the empty space was reused to allocate new data, after R16B seems that empty space isn't reused. I've uploaded a test case to github: http://kcy.me/oz1s any idea ? Than You. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From manuel@REDACTED Thu Jul 25 20:43:29 2013 From: manuel@REDACTED (=?UTF-8?Q?Manuel_Dur=C3=A1n_Aguete?=) Date: Thu, 25 Jul 2013 20:43:29 +0200 Subject: [erlang-bugs] A dets big ? In-Reply-To: References: Message-ID: Hello, After some research the problem seem to be related to a dets:traverse/2 after the dets file is opened. I've updated the code in github with new tests, now it calls dets directly. Thank you. Regards. 2013/7/24 Manuel Dur?n Aguete > Hi all, > > I've posted to erlang-questions but email is waiting for moderator > approval. > > After upgrading a project from R14B03 to R16B01 I've found that dets files > are growing constanly after delete operations. In previous version the > empty space was reused to allocate new data, after R16B seems that empty > space isn't reused. > > I've uploaded a test case to github: http://kcy.me/oz1s > > any idea ? > > > Than You. Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sun Jul 28 16:48:49 2013 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sun, 28 Jul 2013 16:48:49 +0200 Subject: [erlang-bugs] A dets big ? In-Reply-To: ("Manuel =?iso-8859-1?Q?Dur=E1n?= Aguete"'s message of "Thu, 25 Jul 2013 20:43:29 +0200") References: Message-ID: <82ppu24u5q.fsf@assar.nollberga> >>>>> "Manuel" == Manuel Dur?n Aguete writes: >> >> After upgrading a project from R14B03 to R16B01 I've found that >> dets files are growing constanly after delete operations. >> >> I've uploaded a test case to github: http://kcy.me/oz1s > > After some research the problem seem to be related to a > dets:traverse/2 after the dets file is opened. > > I've updated the code in github with new tests, now it calls dets > directly. Hi, I, too, have seen a(nother) strange issue with dets, it might possibly be the same root cause. I saw bad_object_header errors. A short summary of what I found is that when Erlang is compiled with gcc 4.8.1, at least on a 32-bit linux, code in efile_drv.c start acting unexpectedly, causing eg file:pread with 2 positions to fail with {error,einval}. I managed to boil my initial dets issues down to this test program: -module(detstest). -export([start/0]). start() -> F = "detstest", file:delete(F), {error, enoent} = file:read_file_info(F), {ok, Db} = dets:open_file(d, [{file,F}, {keypos,2}]), %% need 2 entries for the error to show ok = dets:insert(Db, {a, 1}), ok = dets:insert(Db, {b, 2}), io:format("~p~n", [dets:close(Db)]). If Erlang is compiled with gcc-4.8.1, it prints {error,{bad_object_header,"detstest"}}, while I would have expected it to print just ok. I traced the dets issue down to a call to file:pread, and managed to boil it down a bit further to this test program: -module(pread). -export([start/0]). start() -> {ok,Fd} = file:open("pread-test", [write,raw,binary,read]), file:write(Fd, <<"abcdef\n">>), io:format("~p~n", [file:pread(Fd, [{0,1}])]), io:format("~p~n", [file:pread(Fd, [{1,1}])]), io:format("~p~n", [file:pread(Fd, [{0,1}, {1,1}])]), file:close(Fd). When Erlang is compiled with gcc-4.8.1, it prints: {ok,[<<"a">>]} {ok,[<<"b">>]} {error,einval} while with gcc-4.7.3, it prints what I would expect: {ok,[<<"a">>]} {ok,[<<"b">>]} {ok,[<<"a">>,<<"b">>]} With the change in the diff below, pread, and also dets, starts to behave as expected again, but this is not a complete bugfix. I don't fully understand what's going on, and similar code is at many places in efile_drv.c. That's why I indented the diff---it is only an illustration---so nobody can take it for a complete solution. Even a seemingly unrelated change, eg inserting fprintf(stdout,"sizeof(q)=%d",sizeof(q)); just before the if statement, instead of applying the diff, will also make the file:pread behave as expected. Perhaps the code is runs into some kind of undefined behaviour in C? Some info: - Erlang: compiled OTP_R16B01 from git - System: debian (unstable), core i5, 32-bits - Kernel: 3.10-1-686-pae - gcc: gcc (Debian 4.8.1-8) 4.8.1 with this version, pread fails with einval - gcc-4.7: gcc-4.7 (Debian 4.7.3-4) 4.7.3 with this version, pread and dets behaves as expected. I found I had the problem beacause debian's erlang (r16.b.1-dfsg-4) was compiled with gcc-4.8, and I couldn't recreate the issue when compiling from git, until I upgraded gcc. diff --git a/erts/emulator/drivers/common/efile_drv.c b/erts/emulator/drivers/common/efile_drv.c index 595b048..65ce49a 100644 --- a/erts/emulator/drivers/common/efile_drv.c +++ b/erts/emulator/drivers/common/efile_drv.c @@ -3746,9 +3746,14 @@ file_outputv(ErlDrvData e, ErlIOVec *ev) { for (i = 1; i < 1+n; i++) { Uint32 sizeH, sizeL; size_t size; - if ( !EV_GET_UINT64(ev, &d->c.preadv.offsets[i-1], &p, &q) - || !EV_GET_UINT32(ev, &sizeH, &p, &q) - || !EV_GET_UINT32(ev, &sizeL, &p, &q)) { + int gotOffsets; + int gotSizeH; + int gotSizeL; + + gotOffsets = EV_GET_UINT64(ev, &d->c.preadv.offsets[i-1], &p, &q); + gotSizeH = !gotOffsets || EV_GET_UINT32(ev, &sizeH, &p, &q); + gotSizeL = !gotSizeH || EV_GET_UINT32(ev, &sizeL, &p, &q); + if (!gotOffsets || !gotSizeH || !gotSizeL) { reply_posix_error(desc, EINVAL); break; } BRs Tomas From tthread@REDACTED Mon Jul 29 06:19:04 2013 From: tthread@REDACTED (=?KOI8-R?B?6czY0SD9xdLCwcs=?=) Date: Mon, 29 Jul 2013 11:19:04 +0700 Subject: [erlang-bugs] "cannot match" waning doesn't show in compilation stage Message-ID: Hello, there is a _no warnings_ when I try to compile the following code: -module('1'). -record(record_1,{arg}). -record(record_2,{}). -export([foo/2]). foo(#record_1{},#record_2{})-> {ok,1}; foo(#record_1{arg=1},#record_2{}) -> {ok,2}. tthread@REDACTED:~/rep/vcs/apps/vcs_core/src$ erl Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.2 (abort with ^G) 1> c("1.erl"). {ok,'1'} Otherwise when you try to compile a simpler code, something like this, everything is fine: -module('1'). -record(record_1,{arg}). -record(record_2,{}). -export([foo/2]). foo(#record_1{},_)-> {ok,1}; foo(#record_1{arg=1},#record_2{}) -> {ok,2}. tthread@REDACTED:~/rep/vcs/apps/vcs_core/src$ erl Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.2 (abort with ^G) 1> c("1.erl"). 1.erl:17: Warning: this clause cannot match because a previous clause at line 15 always matches {ok,'1'} There is should be a warning because the second case will never match so far it included in first case. But it doesn't cover by warning message. It can lead to a difficult logical problem. With best Regards, Ilya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Jul 30 00:39:23 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 30 Jul 2013 00:39:23 +0200 Subject: [erlang-bugs] erlang:halt/2 doesn't flush by default as advertised Message-ID: According to the documentation, erlang:halt/2 should flush unless {flush,false} is given: For integer Status the Erlang runtime system closes all ports and allows > async threads to finish their operations before exiting. To exit without > such flushing use Option as {flush,false}. However, we noticed that erlang:halt(0, []) is not flushing at all. Looking at the code, we were able to verify it: https://github.com/erlang/otp/blob/a5fc79292b9b018cd39d104a8cd2e79de141e3ad/erts/emulator/beam/bif.c#L3937 The value of flush should be initialized to 1. Thank you! PS: erlang:halt/0 and erlang:halt/1 **are** working as advertised. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Tue Jul 30 10:20:43 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 30 Jul 2013 10:20:43 +0200 Subject: [erlang-bugs] erlang:halt/2 doesn't flush by default as advertised In-Reply-To: References: Message-ID: <51F7775B.50700@erlang.org> Hi! On 07/30/2013 12:39 AM, Jos? Valim wrote: > According to the documentation > , erlang:halt/2 should > flush unless {flush,false} is given: > > For integer Status the Erlang runtime system closes all ports and > allows async threads to finish their operations before exiting. To > exit without such flushing use Option as {flush,false}. > > > However, we noticed that erlang:halt(0, []) is not flushing at all. > Looking at the code, we were able to verify it: > > https://github.com/erlang/otp/blob/a5fc79292b9b018cd39d104a8cd2e79de141e3ad/erts/emulator/beam/bif.c#L3937 > > The value of flush should be initialized to 1. > > Thank you! > Yes, that is a bug and your suggested fix seems the right thing to do. I'll fix it. > PS: erlang:halt/0 and erlang:halt/1 **are** working as advertised. > Thanks! Patrik > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Jul 30 16:34:08 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 30 Jul 2013 15:34:08 +0100 Subject: [erlang-bugs] common_test + test_server_io errors In-Reply-To: References: <5A095356-16E8-4224-BA03-AA58C30FC28D@gmail.com> <51CC4E35.8090408@erlang.org> <3B4CC6D8-4CB5-4236-AEDC-CBAF51A9E7AE@gmail.com> <51DFB044.50302@erlang.org> Message-ID: So chaps, I've found the commit that altered the IO handling in test_server (in fact, the addition of test_server_io). To clarify, prior to the addition of test_server_io, calls to ct:log/2 (and friends, e.g., ct:pal/2 and so on) would succeed even if no test was running and end up being handled as if they resided in before/after suite and/or before/after testcase functions. Now it seems that I've got to vet all the processes that might end up calling ct:log/2 (indirectly via my event manager) somehow, but there's no proper API to determine whether or not it is safe to do so. Having all my debug/info level testing framework logs emitted to the HTML files was a big reason for choosing common_test, so I'm loth to redirect them elsewhere. My code is basically doing lots of custom (data driven) setup/teardown before and after test suites and test cases, and even though some of this runs before (or during) the common_test test run is started, I *really* don't want to have to create yet another file location that needs to be inspected when tests fail. I'm also not keen on filling up stdio with lots of logging noise. Any ideas how I can work around this situation without shooting myself in the head/foot? ;) Cheers, Tim On 12 Jul 2013, at 08:36, Tim Watson wrote: > Hi Lukas, thanks for letting me know! > > Cheers, > Tim > > On 12 Jul 2013, at 08:29, Lukas Larsson wrote: > >> Hello Tim, >> >> Peter is currently away enjoying the sunny summer here in Sweden. I'm sure he will get back to you when he comes back! >> >> Lukas >> On 12/07/13 02:03, Tim Watson wrote: >>> On 1 July 2013 10:25, Tim Watson wrote:> We should try to rule out that there's a bug that causes test_server >>> > failure. >>> >>> How can I assist in verifying that? >>> >>> Any more news on this? Is there anything more I can do to assist? >>> >>> Cheers, >>> Tim >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Jul 31 10:37:54 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 31 Jul 2013 10:37:54 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Message-ID: Hello, I've added a commit that fixes variable usage tracking when reporting the redefinition of a record field, e.g. X is not reported as unused in: t() -> X = 1, #r{a=foo,a=bar}. Please refetch. Regards, -- Anthony Ramine Le 23 juil. 2013 ? 09:27, Anthony Ramine a ?crit : > Hello, > > I've added a commit to the branch that fix the bug discovered with Paul Davis where used variables in try expressions aren't properly marked as unsafe. > > Please refetch. > > -- > Anthony Ramine > > Le 1 juil. 2013 ? 19:30, Anthony Ramine a ?crit : > >> Hi Fredrik, >> >> I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: >> >> t(X, Y) -> >> {A=X,A=Y}. >> >> As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : >> >>> On 06/06/2013 01:47 AM, Anthony Ramine wrote: >>>> Hello, >>>> >>>> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >>>> unused variables are not recorded as such: >>>> >>>> t(X, Y) -> >>>> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >>>> >>>> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >>>> >>>> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >>>> >>>> t(X, Y) -> >>>> #r{a=A=X,b=A=Y}. >>>> >>>> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >>>> >>>> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >>>> >>>> git fetch >>>> https://github.com/nox/otp.git >>>> fix-erl_lint-variable-usage >>>> >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >>>> >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >>>> >>>> >>>> Regards, >>>> >>>> >>> Hi Anthony, >>> Your patch has been reviewed and the feedback was: >>> >>> " >>> Hi, >>> >>> The first example of the commit messages lacks a '}' before the dot. >>> >>> I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) >>> >>> I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? >>> >>> Best regards, >>> >>> " >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >> > From fredrik@REDACTED Wed Jul 31 11:19:52 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 31 Jul 2013 11:19:52 +0200 Subject: [erlang-bugs] [erlang-patches] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Message-ID: <51F8D6B8.1070208@erlang.org> On 07/31/2013 10:37 AM, Anthony Ramine wrote: > Hello, > > I've added a commit that fixes variable usage tracking when reporting the redefinition of a record field, e.g. X is not reported as unused in: > > t() -> X = 1, #r{a=foo,a=bar}. > > Please refetch. > > Regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team