From jesper.louis.andersen@REDACTED Fri Feb 1 12:04:42 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 1 Feb 2013 12:04:42 +0100 Subject: [erlang-bugs] binary:matches/3 fails in R14A In-Reply-To: References: <20130131213101.GB59775@ferdmbp.gateway.2wire.net> Message-ID: binary:replace/X and binary:split/X do understand the 'global' atom. So it depends on what kind of call there is made. On Thu, Jan 31, 2013 at 10:40 PM, Tuncer Ayaz wrote: > On Thu, Jan 31, 2013 at 10:31 PM, Fred Hebert wrote: > > I'm looking at the doc at > > http://www.erlang.org/doc/man/binary.html#matches-3 > > > > The type spec mentions the following: > > > > matches(Subject, Pattern, Options) -> Found > > > > Types: > > Subject = binary() > > Pattern = binary() | [binary()] | cp() > > Found = [part()] > > Options = [Option] > > Option = {scope, part()} > > part() = {Start :: integer() >= 0, Length :: integer()} > > > > It seems [global] as an option is not valid. Could this be the problem? > > I was under the impression `re` functions would take a `global` option, > > not `binary` module stuff. > > Yeah, you're probably right, I may have been misled by previous > re:run/3 use :). > > > On 01/31, Tuncer Ayaz wrote: > >> Originally reported by Bartosz Kolodziej as part of [1] > >> is the following a bug or intentionally throwing badarg? > >> > >> 1> binary:matches(<<>>,<<"a">>,[global]). > >> ** exception error: bad argument > >> in function binary:matches/3 > >> called as binary:matches(<<>>,<<"a">>,[global]) > >> > >> Tested with otp.git at 68b804f. > >> > >> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html > >> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Fri Feb 1 12:13:29 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 1 Feb 2013 12:13:29 +0100 Subject: [erlang-bugs] binary:matches/3 fails in R14A In-Reply-To: References: <20130131213101.GB59775@ferdmbp.gateway.2wire.net> Message-ID: On Fri, Feb 1, 2013 at 12:04 PM, Jesper Louis Andersen wrote: > binary:replace/X and binary:split/X do understand the 'global' atom. > So it depends on what kind of call there is made. Actually, binary:matches/X searches Subject until exhausted. So, maybe binary:match/X should allow 'global' to operate like binary:matches/X. Does that make sense? > On Thu, Jan 31, 2013 at 10:40 PM, Tuncer Ayaz wrote: >> >> On Thu, Jan 31, 2013 at 10:31 PM, Fred Hebert wrote: >> > I'm looking at the doc at >> > http://www.erlang.org/doc/man/binary.html#matches-3 >> > >> > The type spec mentions the following: >> > >> > matches(Subject, Pattern, Options) -> Found >> > >> > Types: >> > Subject = binary() >> > Pattern = binary() | [binary()] | cp() >> > Found = [part()] >> > Options = [Option] >> > Option = {scope, part()} >> > part() = {Start :: integer() >= 0, Length :: integer()} >> > >> > It seems [global] as an option is not valid. Could this be the >> > problem? I was under the impression `re` functions would take a >> > `global` option, not `binary` module stuff. >> >> Yeah, you're probably right, I may have been misled by previous >> re:run/3 use :). >> >> > On 01/31, Tuncer Ayaz wrote: >> >> Originally reported by Bartosz Kolodziej as part of [1] >> >> is the following a bug or intentionally throwing badarg? >> >> >> >> 1> binary:matches(<<>>,<<"a">>,[global]). >> >> ** exception error: bad argument >> >> in function binary:matches/3 >> >> called as binary:matches(<<>>,<<"a">>,[global]) >> >> >> >> Tested with otp.git at 68b804f. >> >> >> >> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html >> >> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html From konrad.gadek@REDACTED Fri Feb 1 14:12:49 2013 From: konrad.gadek@REDACTED (Konrad =?utf-8?Q?G=C4=85dek?=) Date: Fri, 1 Feb 2013 13:12:49 +0000 (GMT) Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847E7@mailsvr4.RICOL.EDU> Message-ID: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> FYI no such strange behaviour on Windows 7 Home Premium, x86-64, R16A 64bit. Does q() also give you such strange behaviour? /Konrad G?dek ----- Oryginalna wiadomo?? ----- Od: "Edward D. McDowell" Do: "erlang-bugs@REDACTED" Wys?ane: czwartek, 31 stycze? 2013 19:10:16 Temat: [erlang-bugs] R16A erl.exe does not exit properly on Windows. The Erlang command line program erl.exe release R16A does not exit properly on Windows 7 Starter Edition using a 32-bit processor. When the shell is terminated using either init:stop() or halt() several hundred carriage-return line-feed sequences are printed and then Windows displays "erl.exe has stopped working." No crash dump is produced. This problem does not occur with the Windows shell werl.exe. _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From pan@REDACTED Fri Feb 1 15:37:46 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 1 Feb 2013 15:37:46 +0100 Subject: [erlang-bugs] binary:matches/3 fails in R14A In-Reply-To: References: Message-ID: <510BD33A.8020703@erlang.org> Hi Tuncer! On 01/31/2013 09:33 PM, Tuncer Ayaz wrote: > Originally reported by Bartosz Kolodziej as part of [1] > is the following a bug or intentionally throwing badarg? As the option 'global' is not valid for binary:matches (only for replace and split), it's most definitely intentional. binary:matches, btw, already searches for all matches. I however strongly discourage use of R14A, it's a release candidate... > 1> binary:matches(<<>>,<<"a">>,[global]). > ** exception error: bad argument > in function binary:matches/3 > called as binary:matches(<<>>,<<"a">>,[global]) > > Tested with otp.git at 68b804f. > > [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html > [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html /Patrik From pan@REDACTED Fri Feb 1 15:45:31 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 1 Feb 2013 15:45:31 +0100 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> References: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> Message-ID: <510BD50B.3070406@erlang.org> Hi! On 02/01/2013 02:12 PM, Konrad G?dek wrote: > FYI no such strange behaviour on Windows 7 Home Premium, x86-64, R16A 64bit. > Does q() also give you such strange behaviour? > > /Konrad G?dek > > ----- Oryginalna wiadomo?? ----- > Od: "Edward D. McDowell" > Do: "erlang-bugs@REDACTED" > Wys?ane: czwartek, 31 stycze? 2013 19:10:16 > Temat: [erlang-bugs] R16A erl.exe does not exit properly on Windows. > > > > > > The Erlang command line program erl.exe release R16A does not exit properly > > on Windows 7 Starter Edition using a 32-bit processor. I bet this has something to do with the flushing of "stdout" data at exit. I will be way from OTP for a week, but will send you approximately one million questions about this when I get back, if it's not already solved by then! Just to let you know you're not ignored :) > > > When the shell is terminated using either init:stop() or halt() several > > hundred carriage-return line-feed sequences are printed and then Windows > > displays "erl.exe has stopped working." No crash dump is produced. > > > > This problem does not occur with the Windows shell werl.exe. > _______________________________________________ > 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 Cheers, /Patrik From gtsiour@REDACTED Fri Feb 1 16:06:14 2013 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Fri, 01 Feb 2013 17:06:14 +0200 Subject: [erlang-bugs] make -j 16 fails when ./configure --with-dynamic-trace=systemtap Message-ID: <510BD9E6.5040604@softlab.ntua.gr> Hi! I'm trying to build an Erlang/OTP system configured with --with-dynamic-trace=systemtap and it fails with: > beam/dtrace-wrapper.h:49:27: error: erlang_dtrace.h: No such file or directory I attach the full log for details. Let me state that this works well when I do a simple make (without the -j flag). Is this a known issue? Thanks, yiannis -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed... Name: dtrace.log Type: text/x-log Size: 4584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From tuncer.ayaz@REDACTED Fri Feb 1 18:32:13 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 1 Feb 2013 18:32:13 +0100 Subject: [erlang-bugs] binary:matches/3 fails in R14A In-Reply-To: <510BD33A.8020703@erlang.org> References: <510BD33A.8020703@erlang.org> Message-ID: On Fri, 01 Feb 2013 15:37:46 +0100, Patrik Nyblom wrote: > Hi Tuncer! > On 01/31/2013 09:33 PM, Tuncer Ayaz wrote: >> Originally reported by Bartosz Kolodziej as part of [1] >> is the following a bug or intentionally throwing badarg? > As the option 'global' is not valid for binary:matches (only for > replace and split), it's most definitely intentional. > binary:matches, btw, already searches for all matches. Yeah, I realized that thanks to Fred [3]. Still, would it make sense to support 'global' in binary:match/N and make it thereby function like binary:matches/N? [3] http://erlang.org/pipermail/erlang-bugs/2013-January/003343.html > I however strongly discourage use of R14A, it's a release candidate... I'm not using that release, it's just the version Bartosz tested with in 2010. >> 1> binary:matches(<<>>,<<"a">>,[global]). >> ** exception error: bad argument >> in function binary:matches/3 >> called as binary:matches(<<>>,<<"a">>,[global]) >> >> Tested with otp.git at 68b804f. >> >> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html >> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html From diego.llarrull@REDACTED Fri Feb 1 21:00:12 2013 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Fri, 01 Feb 2013 17:00:12 -0300 Subject: [erlang-bugs] R16 EUnit *** context setup failed *** In-Reply-To: References: <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com> Message-ID: <510C1ECC.3040900@tecso.coop> Hello everyone, I'm working on a riak_core based project, that is, one which uses rebar + GNU make and where the src files are located in different folders than the beam files, which are inside inside zipped (.ez) files. sync + libnotify will do the trick for unzipped files, but some extra trickery was needed to load the new .beam files a) compile the modified sources b) (create and) run a script that generates the .zip files containing the .beams and deploys those files in their destination directory c) run the following code: reload() -> Modules = [ X || {X,L} <- code:all_loaded(), is_list(L),string:str(L, ?PATH_TO_CODE_DIR) =/= 0], lists:map(fun(X) -> c:l(X) end, Modules). Hope this helps anyone, right now I'm trying out ssync to see if it is able to handle zipped files. Best regards, Diego El jue 31 ene 2013 12:51:33 ART, Bj?rn Gustavsson escribi?: > Thanks for bisecting! > > I will fix the bug in R16B. > > > On Thu, Jan 31, 2013 at 1:11 AM, Tuncer Ayaz > wrote: > > On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote: > > I can reproduce this with the exact same steps. > > This is the git-bisect result: > > 70b5e24c9498225fadc08d19503269c8aad851bf is the first bad commit > commit 70b5e24c9498225fadc08d19503269c8aad851bf > Author: Bjorn Gustavsson > > Date: Tue Sep 11 15:03:53 2012 +0200 > > Fix filelib:wildcard/2 > > filelib:wildcard("some/relative/path/*.beam", Path) would fail to > match any file. That is, filelib:wildcard/2 would not work if the > first component of the pattern did not contain any wildcard > characters. > > Noticed-by: Samuel Rivas > > > Le 13 nov. 2012 ? 14:18, Tuncer Ayaz a ?crit : > > > >> If I build and run rebar's EUnit tests with R16, I see "*** context > >> setup failed ***" errors. > >> > >> Interestingly, if I use a tree where ebin/*, rebar, and > .eunit/*.beam > >> have been built with R15B02, then neither R16 nor R15 throw the > >> context setup errors. > >> > >> # fetch and build rebar > >> $ git clone git://github.com/rebar/rebar.git > > >> $ cd rebar > >> $ make > >> # run tests with new rebar binary > >> $ ./rebar eunit > >> # *** context setup failed *** errors and 50 out of 72 tests > >> # not executed > >> $ rm ebin/* .eunit/* rebar > >> # rebuild rebar and EUnit tests with R15 > >> $ make && ./rebar eunit > >> # running EUnit tests with either R15 or R16 works now > >> > >> Can anyone else reproduce this? Could this be caused by compiler > >> changes in R16? I don't see any changes in lib/eunit after R15B02. > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From diego.llarrull@REDACTED Fri Feb 1 21:03:09 2013 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Fri, 01 Feb 2013 17:03:09 -0300 Subject: [erlang-bugs] R16 EUnit *** context setup failed *** In-Reply-To: <510C1ECC.3040900@tecso.coop> References: <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com> <510C1ECC.3040900@tecso.coop> Message-ID: <510C1F7D.9030206@tecso.coop> Sorry! That mail was meant for another thread. Feel free to delete the previous mail. Sorry for the inconvenience On 01/02/13 17:00, Diego Llarrull wrote: > Hello everyone, > > I'm working on a riak_core based project, that is, one which uses > rebar + GNU make and where the src files are located in different > folders than the beam files, which are inside inside zipped (.ez) files. > > sync + libnotify will do the trick for unzipped files, but some extra > trickery was needed to load the new .beam files > > a) compile the modified sources > b) (create and) run a script that generates the .zip files containing > the .beams and deploys those files in their destination directory > c) run the following code: > > reload() -> > Modules = [ X || {X,L} <- code:all_loaded(), > is_list(L),string:str(L, ?PATH_TO_CODE_DIR) =/= 0], > lists:map(fun(X) -> c:l(X) end, Modules). > > Hope this helps anyone, right now I'm trying out ssync to see if it is > able to handle zipped files. > > Best regards, > > Diego > > El jue 31 ene 2013 12:51:33 ART, Bj?rn Gustavsson escribi?: >> Thanks for bisecting! >> >> I will fix the bug in R16B. >> >> >> On Thu, Jan 31, 2013 at 1:11 AM, Tuncer Ayaz > > wrote: >> >> On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote: >> > I can reproduce this with the exact same steps. >> >> This is the git-bisect result: >> >> 70b5e24c9498225fadc08d19503269c8aad851bf is the first bad commit >> commit 70b5e24c9498225fadc08d19503269c8aad851bf >> Author: Bjorn Gustavsson > > >> Date: Tue Sep 11 15:03:53 2012 +0200 >> >> Fix filelib:wildcard/2 >> >> filelib:wildcard("some/relative/path/*.beam", Path) would >> fail to >> match any file. That is, filelib:wildcard/2 would not work if >> the >> first component of the pattern did not contain any wildcard >> characters. >> >> Noticed-by: Samuel Rivas >> >> > Le 13 nov. 2012 ? 14:18, Tuncer Ayaz a ?crit : >> > >> >> If I build and run rebar's EUnit tests with R16, I see "*** >> context >> >> setup failed ***" errors. >> >> >> >> Interestingly, if I use a tree where ebin/*, rebar, and >> .eunit/*.beam >> >> have been built with R15B02, then neither R16 nor R15 throw the >> >> context setup errors. >> >> >> >> # fetch and build rebar >> >> $ git clone git://github.com/rebar/rebar.git >> >> >> $ cd rebar >> >> $ make >> >> # run tests with new rebar binary >> >> $ ./rebar eunit >> >> # *** context setup failed *** errors and 50 out of 72 tests >> >> # not executed >> >> $ rm ebin/* .eunit/* rebar >> >> # rebuild rebar and EUnit tests with R15 >> >> $ make && ./rebar eunit >> >> # running EUnit tests with either R15 or R16 works now >> >> >> >> Can anyone else reproduce this? Could this be caused by compiler >> >> changes in R16? I don't see any changes in lib/eunit after >> R15B02. >> >> >> >> >> -- >> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > From jose.valim@REDACTED Sat Feb 2 21:42:19 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 2 Feb 2013 13:42:19 -0700 Subject: [erlang-bugs] Unused variable causing v3_kernel crash Message-ID: Hello everyone, The following module fails to compile using both R15B03-01 and R16A: -module(sample). -export([hello/1]). hello(X) -> case do_something(X) of false -> A = false; Res -> { A, B } = Res, do_something(A), do_something(B) end, ThisShouldNotFail = A, ok. do_something(X) -> external:do_something(X). With the following exception: crash reason: {function_clause, [{v3_kernel,lit_vars, [{ivalues, [11,{file,"sample.erl"}], [{k_var,[],ker4},{k_atom,[],ok}]}], [{file,"v3_kernel.erl"},{line,1749}]}, {v3_kernel,uexpr,3,[{file,"v3_kernel.erl"},{line,1628}]}, {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1408}]}, {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1409}]}, {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1716}]}, {v3_kernel,'-umatch_list/3-anonymous-0-',3, [{file,"v3_kernel.erl"},{line,1735}]}, {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1711}]}, {v3_kernel,'-umatch_list/3-anonymous-0-',3, [{file,"v3_kernel.erl"},{line,1735}]}]} The code and exceptions are also available here: https://gist.github.com/7bd4eea30cd187e68caa Removing the `ThisShouldNotFail` assignment makes it work correctly, although I wouldn't expect it to explode with that line and just output a couple warnings instead. This snippet was extract from a more complex code. The name of the functions, module and variables do not seem to affect the failure. I tried to further debug the issue but I could not pinpoint the failure. Let me know if I can help any further. Thank you for your time, * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Feb 3 03:28:47 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 3 Feb 2013 03:28:47 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: References: Message-ID: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> I may have a fix for this: git fetch https://github.com/nox/otp.git fix-seq-opt https://github.com/nox/otp/compare/erlang:master...fix-seq-opt https://github.com/nox/otp/compare/erlang:master...fix-seq-opt.patch Your bug seems to come from the Core Erlang to Kernel Erlang pass not coping with multiple values into sequences' arguments, that is expressions which values aren't used. My branch adds a new check to core_lint to detect that kind of invalid code and fixes sys_core_fold so that it doesn't generate it anymore when optimizing away unused values. To check that this is indeed sys_core_fold's optimizations that makes the compilation fail, do: erlc +no_copt sample.erl To enable the Core Erlang linting pass, do: erlc +clint sample.erl Regards, -- Anthony Ramine Le 2 f?vr. 2013 ? 21:42, Jos? Valim a ?crit : > Hello everyone, > > The following module fails to compile using both R15B03-01 and R16A: > > -module(sample). > -export([hello/1]). > > hello(X) -> > case do_something(X) of > false -> > A = false; > Res -> > { A, B } = Res, > do_something(A), > do_something(B) > end, > ThisShouldNotFail = A, > ok. > > do_something(X) -> > external:do_something(X). > > With the following exception: > > crash reason: {function_clause, > [{v3_kernel,lit_vars, > [{ivalues, > [11,{file,"sample.erl"}], > [{k_var,[],ker4},{k_atom,[],ok}]}], > [{file,"v3_kernel.erl"},{line,1749}]}, > {v3_kernel,uexpr,3,[{file,"v3_kernel.erl"},{line,1628}]}, > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1408}]}, > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1409}]}, > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1716}]}, > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > [{file,"v3_kernel.erl"},{line,1735}]}, > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1711}]}, > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > [{file,"v3_kernel.erl"},{line,1735}]}]} > > The code and exceptions are also available here: https://gist.github.com/7bd4eea30cd187e68caa > > Removing the `ThisShouldNotFail` assignment makes it work correctly, although I wouldn't expect it to explode with that line and just output a couple warnings instead. > > This snippet was extract from a more complex code. The name of the functions, module and variables do not seem to affect the failure. > > I tried to further debug the issue but I could not pinpoint the failure. Let me know if I can help any further. > > Thank you for your time, > > > Jos? Valim > www.plataformatec.com.br > Founder and Lead Developer > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From bgustavsson@REDACTED Sun Feb 3 10:58:09 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 3 Feb 2013 10:58:09 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> Message-ID: Yes, your fix seems to be correct. Do you think you could write a test case and provide some details in the commit message? (Personally I would put everything into one commit.) I suggest that you end your commit message with: Reported-by: Jos? Valim On Sun, Feb 3, 2013 at 3:28 AM, Anthony Ramine wrote: > I may have a fix for this: > > git fetch https://github.com/nox/otp.git fix-seq-opt > > https://github.com/nox/otp/compare/erlang:master...fix-seq-opt > > https://github.com/nox/otp/compare/erlang:master...fix-seq-opt.patch > > Your bug seems to come from the Core Erlang to Kernel Erlang pass not > coping with > multiple values into sequences' arguments, that is expressions which > values aren't > used. > > My branch adds a new check to core_lint to detect that kind of invalid > code and > fixes sys_core_fold so that it doesn't generate it anymore when optimizing > away > unused values. > > To check that this is indeed sys_core_fold's optimizations that makes the > compilation fail, do: > > erlc +no_copt sample.erl > > To enable the Core Erlang linting pass, do: > > erlc +clint sample.erl > > Regards, > > -- > Anthony Ramine > > Le 2 f?vr. 2013 ? 21:42, Jos? Valim a ?crit : > > > Hello everyone, > > > > The following module fails to compile using both R15B03-01 and R16A: > > > > -module(sample). > > -export([hello/1]). > > > > hello(X) -> > > case do_something(X) of > > false -> > > A = false; > > Res -> > > { A, B } = Res, > > do_something(A), > > do_something(B) > > end, > > ThisShouldNotFail = A, > > ok. > > > > do_something(X) -> > > external:do_something(X). > > > > With the following exception: > > > > crash reason: {function_clause, > > [{v3_kernel,lit_vars, > > [{ivalues, > > [11,{file,"sample.erl"}], > > [{k_var,[],ker4},{k_atom,[],ok}]}], > > [{file,"v3_kernel.erl"},{line,1749}]}, > > > {v3_kernel,uexpr,3,[{file,"v3_kernel.erl"},{line,1628}]}, > > > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1408}]}, > > > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1409}]}, > > > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1716}]}, > > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > > [{file,"v3_kernel.erl"},{line,1735}]}, > > > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1711}]}, > > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > > [{file,"v3_kernel.erl"},{line,1735}]}]} > > > > The code and exceptions are also available here: > https://gist.github.com/7bd4eea30cd187e68caa > > > > Removing the `ThisShouldNotFail` assignment makes it work correctly, > although I wouldn't expect it to explode with that line and just output a > couple warnings instead. > > > > This snippet was extract from a more complex code. The name of the > functions, module and variables do not seem to affect the failure. > > > > I tried to further debug the issue but I could not pinpoint the failure. > Let me know if I can help any further. > > > > Thank you for your time, > > > > > > Jos? Valim > > www.plataformatec.com.br > > Founder and Lead Developer > > > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Feb 3 12:32:15 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 3 Feb 2013 12:32:15 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> Message-ID: Hi, I've added some details and squashed the two commits together, please refetch. In which suite should I put such a test case? Regards, -- Anthony Ramine Le 3 f?vr. 2013 ? 10:58, Bj?rn Gustavsson a ?crit : > Yes, your fix seems to be correct. > > Do you think you could write a test case and > provide some details in the commit message? > (Personally I would put everything into one > commit.) > > I suggest that you end your commit message > with: > > Reported-by: Jos? Valim > > > > On Sun, Feb 3, 2013 at 3:28 AM, Anthony Ramine wrote: > I may have a fix for this: > > git fetch https://github.com/nox/otp.git fix-seq-opt > > https://github.com/nox/otp/compare/erlang:master...fix-seq-opt > https://github.com/nox/otp/compare/erlang:master...fix-seq-opt.patch > > Your bug seems to come from the Core Erlang to Kernel Erlang pass not coping with > multiple values into sequences' arguments, that is expressions which values aren't > used. > > My branch adds a new check to core_lint to detect that kind of invalid code and > fixes sys_core_fold so that it doesn't generate it anymore when optimizing away > unused values. > > To check that this is indeed sys_core_fold's optimizations that makes the > compilation fail, do: > > erlc +no_copt sample.erl > > To enable the Core Erlang linting pass, do: > > erlc +clint sample.erl > > Regards, > > -- > Anthony Ramine > > Le 2 f?vr. 2013 ? 21:42, Jos? Valim a ?crit : > > > Hello everyone, > > > > The following module fails to compile using both R15B03-01 and R16A: > > > > -module(sample). > > -export([hello/1]). > > > > hello(X) -> > > case do_something(X) of > > false -> > > A = false; > > Res -> > > { A, B } = Res, > > do_something(A), > > do_something(B) > > end, > > ThisShouldNotFail = A, > > ok. > > > > do_something(X) -> > > external:do_something(X). > > > > With the following exception: > > > > crash reason: {function_clause, > > [{v3_kernel,lit_vars, > > [{ivalues, > > [11,{file,"sample.erl"}], > > [{k_var,[],ker4},{k_atom,[],ok}]}], > > [{file,"v3_kernel.erl"},{line,1749}]}, > > {v3_kernel,uexpr,3,[{file,"v3_kernel.erl"},{line,1628}]}, > > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1408}]}, > > {v3_kernel,ubody,3,[{file,"v3_kernel.erl"},{line,1409}]}, > > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1716}]}, > > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > > [{file,"v3_kernel.erl"},{line,1735}]}, > > {v3_kernel,umatch,3,[{file,"v3_kernel.erl"},{line,1711}]}, > > {v3_kernel,'-umatch_list/3-anonymous-0-',3, > > [{file,"v3_kernel.erl"},{line,1735}]}]} > > > > The code and exceptions are also available here: https://gist.github.com/7bd4eea30cd187e68caa > > > > Removing the `ThisShouldNotFail` assignment makes it work correctly, although I wouldn't expect it to explode with that line and just output a couple warnings instead. > > > > This snippet was extract from a more complex code. The name of the functions, module and variables do not seem to affect the failure. > > > > I tried to further debug the issue but I could not pinpoint the failure. Let me know if I can help any further. > > > > Thank you for your time, > > > > > > Jos? Valim > > www.plataformatec.com.br > > Founder and Lead Developer > > > > > > _______________________________________________ > > 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 bgustavsson@REDACTED Mon Feb 4 07:17:45 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 4 Feb 2013 07:17:45 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> Message-ID: On Sun, Feb 3, 2013 at 12:32 PM, Anthony Ramine wrote: > Hi, > > I've added some details and squashed the two commits together, > please refetch. > > In which suite should I put such a test case? > > I suggest core_fold_SUITE. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Feb 4 12:16:15 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 4 Feb 2013 12:16:15 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> Message-ID: <02DCDA11-8D9B-44BC-895C-7F8F6855A3CD@gmail.com> I added a commit with two test cases, please refetch. -- Anthony Ramine Le 4 f?vr. 2013 ? 07:17, Bj?rn Gustavsson a ?crit : > > On Sun, Feb 3, 2013 at 12:32 PM, Anthony Ramine wrote: > Hi, > > I've added some details and squashed the two commits together, > please refetch. > > In which suite should I put such a test case? > > > I suggest core_fold_SUITE. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Mon Feb 4 14:43:08 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 4 Feb 2013 14:43:08 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: <02DCDA11-8D9B-44BC-895C-7F8F6855A3CD@gmail.com> References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> <02DCDA11-8D9B-44BC-895C-7F8F6855A3CD@gmail.com> Message-ID: Thanks for test suite. There are a few issues, though. First, the new test cases are not correctly listed in the lists in the groups/0 function, so they will not actually be run. Second, being very paranoid when writing test cases, I would make sure that the compiled code atually works (in this case, that the function with side effects is actually called). Here is my suggestion how it can be done. If you are fine with my changes, we can simply squash my commit into yours. https://github.com/bjorng/otp/commit/4e21e16ebc1c012ac52b89ba1b38d6f98cfbac2c Note that since there is no good reason for keeping the test case case in a separate file, I have put all code for unused_multiple_values into core_fold_SUITE itself. On Mon, Feb 4, 2013 at 12:16 PM, Anthony Ramine wrote: > I added a commit with two test cases, please refetch. > > -- > Anthony Ramine > > Le 4 f?vr. 2013 ? 07:17, Bj?rn Gustavsson a ?crit : > > > > > On Sun, Feb 3, 2013 at 12:32 PM, Anthony Ramine > wrote: > > Hi, > > > > I've added some details and squashed the two commits together, > > please refetch. > > > > In which suite should I put such a test case? > > > > > > I suggest core_fold_SUITE. > > > > -- > > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Mon Feb 4 14:55:39 2013 From: rickard@REDACTED (Rickard Green) Date: Mon, 4 Feb 2013 14:55:39 +0100 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: <510BD50B.3070406@erlang.org> References: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> <510BD50B.3070406@erlang.org> Message-ID: >> >> The Erlang command line program erl.exe release R16A does not exit properly >> >> on Windows 7 Starter Edition using a 32-bit processor. > I bet this has something to do with the flushing of "stdout" data at exit. I will be way from OTP for a week, but will send you approximately one million questions about this when I get back, if it's not already solved by then! Just to let you know you're not ignored :) >> >> >> When the shell is terminated using either init:stop() or halt() several >> >> hundred carriage-return line-feed sequences are printed and then Windows >> >> displays "erl.exe has stopped working." No crash dump is produced. >> >> >> >> This problem does not occur with the Windows shell werl.exe. >> _______________________________________________ We have found three bugs in the vanilla/fd/spawn-driver code on Windows. One of them being in the flush of stdout as Patrik was betting on. Fixes of these bugs will probably fix this issue as well as other crashes on Windows. We will try to make a test Windows build available as soon as possible, but I don't know exactly how and when yet. Regards, Rickard Green, Erlang/OTP, Ericsson AB From shino.shun@REDACTED Mon Feb 4 15:40:08 2013 From: shino.shun@REDACTED (Shunichi Shinohara) Date: Mon, 4 Feb 2013 23:40:08 +0900 Subject: [erlang-bugs] R16A readme typo: application:get_key/3 Message-ID: Hi all, I found a tiny typo in R16A readme file. http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme OTP-10694 Add application:get_key/3. The new function provides a default value for a configuration parameter. Thanks to Serge Aleynikov. application:get_key/3 does not exist even in R16A, probably application:get_env/3 is the correct one. Regards, Shunishi Shinohara From n.oxyde@REDACTED Mon Feb 4 15:50:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 4 Feb 2013 15:50:10 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> <02DCDA11-8D9B-44BC-895C-7F8F6855A3CD@gmail.com> Message-ID: <98AB97FB-CA23-45D7-BDBD-7C7C065A9B31@gmail.com> I squashed your commit with mine; please refetch. -- Anthony Ramine Le 4 f?vr. 2013 ? 14:43, Bj?rn Gustavsson a ?crit : > Thanks for test suite. > > There are a few issues, though. > > First, the new test cases are not correctly listed > in the lists in the groups/0 function, so they will > not actually be run. > > Second, being very paranoid when writing test > cases, I would make sure that the compiled > code atually works (in this case, that the function > with side effects is actually called). > > Here is my suggestion how it can be done. If > you are fine with my changes, we can simply > squash my commit into yours. > > https://github.com/bjorng/otp/commit/4e21e16ebc1c012ac52b89ba1b38d6f98cfbac2c > > Note that since there is no good reason for > keeping the test case case in a separate file, > I have put all code for unused_multiple_values > into core_fold_SUITE itself. > > > > On Mon, Feb 4, 2013 at 12:16 PM, Anthony Ramine wrote: > I added a commit with two test cases, please refetch. > > -- > Anthony Ramine > > Le 4 f?vr. 2013 ? 07:17, Bj?rn Gustavsson a ?crit : > > > > > On Sun, Feb 3, 2013 at 12:32 PM, Anthony Ramine wrote: > > Hi, > > > > I've added some details and squashed the two commits together, > > please refetch. > > > > In which suite should I put such a test case? > > > > > > I suggest core_fold_SUITE. > > > > -- > > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Feb 4 15:50:58 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 4 Feb 2013 15:50:58 +0100 Subject: [erlang-bugs] Native compilation hangs with rm-reverse-eta-conversion In-Reply-To: <50FFE51C.9070002@cs.ntua.gr> References: <50FBAB1E.2070703@cs.ntua.gr> <50FFE51C.9070002@cs.ntua.gr> Message-ID: <29FB512D-CB33-4F6C-B897-A9389D820EDF@gmail.com> Hi Kostis, Any chance you take a look at this soon..? Regards, -- Anthony Ramine Le 23 janv. 2013 ? 14:26, Kostis Sagonas a ?crit : > On 01/23/2013 01:49 PM, Anthony Ramine wrote: >> Hi, >> >> The bytecode invariant that I broke is the fact that a function cannot be used as >> a closure and as a normal function both at the same time, thus the eta-abstraction >> is needed by HiPE. >> >> Kostis, could you give me directions on how to make HiPE not need the intermediate >> closures when doing fun Name/Arity? > > Hi Antony, > > I am attending a conference this week and will look at this issue during the weekend or early next week. > > Kostis From fredrik@REDACTED Mon Feb 4 16:59:47 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 4 Feb 2013 16:59:47 +0100 Subject: [erlang-bugs] Unused variable causing v3_kernel crash In-Reply-To: <98AB97FB-CA23-45D7-BDBD-7C7C065A9B31@gmail.com> References: <91A4A766-3342-4736-990C-1A2E3B7F448E@gmail.com> <02DCDA11-8D9B-44BC-895C-7F8F6855A3CD@gmail.com> <98AB97FB-CA23-45D7-BDBD-7C7C065A9B31@gmail.com> Message-ID: <510FDAF3.1070401@erlang.org> On 02/04/2013 03:50 PM, Anthony Ramine wrote: > I squashed your commit with mine; please refetch. > Re-fetched. Thanks! -- BR Fredrik Gustafsson Erlang OTP Team From EMcDowell@REDACTED Mon Feb 4 21:11:40 2013 From: EMcDowell@REDACTED (McDowell, Edward D.) Date: Mon, 4 Feb 2013 15:11:40 -0500 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> References: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847E7@mailsvr4.RICOL.EDU> <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> Message-ID: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847EA@mailsvr4.RICOL.EDU> Yes, q() gives the same behavior. I am using the 32-bit version of Erlang R16A. I experience the problem on three different computers, a 32-bit netbook running Windows 7 Starter, a 32-bit desktop running Windows XP, and a 64-bit laptop running the 32-bit Erlang distribution on Windows 7 Home. -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Konrad Gadek Sent: Friday, February 01, 2013 8:13 AM To: erlang-bugs@REDACTED Subject: Re: [erlang-bugs] R16A erl.exe does not exit properly on Windows. FYI no such strange behaviour on Windows 7 Home Premium, x86-64, R16A 64bit. Does q() also give you such strange behaviour? /Konrad G?dek ----- Oryginalna wiadomo?? ----- Od: "Edward D. McDowell" Do: "erlang-bugs@REDACTED" Wys?ane: czwartek, 31 stycze? 2013 19:10:16 Temat: [erlang-bugs] R16A erl.exe does not exit properly on Windows. The Erlang command line program erl.exe release R16A does not exit properly on Windows 7 Starter Edition using a 32-bit processor. When the shell is terminated using either init:stop() or halt() several hundred carriage-return line-feed sequences are printed and then Windows displays "erl.exe has stopped working." No crash dump is produced. This problem does not occur with the Windows shell werl.exe. _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Tue Feb 5 00:08:24 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 05 Feb 2013 00:08:24 +0100 Subject: [erlang-bugs] R16A : can't compile In-Reply-To: <510AEAA9.2070304@wanadoo.fr> References: <510AEAA9.2070304@wanadoo.fr> Message-ID: <51103F68.5010209@wanadoo.fr> Hello, looks like with some glibc version on a 32bits system, fallocate64() function is not exported. This a problem, since _FILE_OFFSET_BITS is set to 64 and fallocate() is redirected to fallocate64(). I suspect that AC_CHECK_FUNC() in configure doesn't catch such problem. Do you see any workaround ? (except switch to a 64 bits system ;) )... Regards Le 31/01/2013 23:05, PAILLEAU Eric a ?crit : > obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate': > /home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013: > undefined reference to `fallocate64' > > gcc version 4.4.1 (GCC) > > Linux Mandriva 2010 : 2.6.31.14-desktop-1mnb #1 SMP i686 Intel(R) > Core(TM)2 Duo CPU T7250 @ 2.00GHz GNU/Linux > > erts/autoconf/config.guess returns i686-pc-linux-gnu > > I tried to change/comment some values in erts/i686-pc-linux-gnu/config.h > like : > #define HAVE_FALLOCATE 0 > #define HAVE_POSIX_FALLOCATE > > but without success. > > Any tip ? > > Regards > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From tristan.sloughter@REDACTED Wed Feb 6 05:30:39 2013 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Tue, 5 Feb 2013 22:30:39 -0600 Subject: [erlang-bugs] R16A ssl 'certificate unknown' Message-ID: Testing out R16A I ran into an ssl error on some code that works fine on R15B03-1. The code I discovered it on is part of wooga's estatsd that posts json to the librato API: https://github.com/wooga/estatsd/blob/master/apps/estatsd/src/adapters/estatsda_librato.erl#L108 On R16A I get the error: {conn_failed,{error,{essl,"certificate unknown"}}} I suspect it is related to this commit: https://github.com/erlang/otp/commit/69d4a56d9f7ade14fd0496ffbf56d96bf9184aef#lib/ssl/src/ssl_handshake.erl What else should I do to help figure out what is going wrong here? Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.anderton.andin@REDACTED Wed Feb 6 09:19:17 2013 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Wed, 6 Feb 2013 09:19:17 +0100 Subject: [erlang-bugs] R16A ssl 'certificate unknown' In-Reply-To: References: Message-ID: <51121205.3070902@erix.ericsson.se> Hi Tristan! Tristan Sloughter wrote: > Testing out R16A I ran into an ssl error on some code that works fine > on R15B03-1. The code I discovered it on is part of wooga's estatsd > that posts json to the librato API: > > https://github.com/wooga/estatsd/blob/master/apps/estatsd/src/adapters/estatsda_librato.erl#L108 > > On R16A I get the error: > > {conn_failed,{error,{essl,"certificate unknown"}}} > I suspect it is related to this commit: > > https://github.com/erlang/otp/commit/69d4a56d9f7ade14fd0496ffbf56d96bf9184aef#lib/ssl/src/ssl_handshake.erl This commit is in R15B03-1 and should make it less likely that you get an ASN-1 decode error. > > What else should I do to help figure out what is going wrong here? > It sounds like it could be an error in the asn1 application. You could apply the following patch to get some more information. I think we will add this to code. diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl index 1929370..4c51450 100644 --- a/lib/ssl/src/ssl_handshake.erl +++ b/lib/ssl/src/ssl_handshake.erl @@ -258,7 +258,9 @@ certify(#certificate{asn1_certificates = ASN1Certs}, C ertDbHandle, CertDbRef, path_validation_alert(Reason) end catch - error:_ -> + error:Error -> + Report = io_lib:format("Decode of certificate failed due to: ~p", [Error]), + error_logger:error_report(Report), %% ASN-1 decode of certificate somehow failed ?ALERT_REC(?FATAL, ?CERTIFICATE_UNKNOWN) end. Regards Ingela Erlang/OTP team Ericsson AB From rickard@REDACTED Wed Feb 6 18:57:24 2013 From: rickard@REDACTED (Rickard Green) Date: Wed, 6 Feb 2013 18:57:24 +0100 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: References: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> <510BD50B.3070406@erlang.org> Message-ID: On Feb 4, 2013, at 2:55 PM, Rickard Green wrote: >>> >>> The Erlang command line program erl.exe release R16A does not exit properly >>> >>> on Windows 7 Starter Edition using a 32-bit processor. >> I bet this has something to do with the flushing of "stdout" data at exit. I will be way from OTP for a week, but will send you approximately one million questions about this when I get back, if it's not already solved by then! Just to let you know you're not ignored :) >>> >>> >>> When the shell is terminated using either init:stop() or halt() several >>> >>> hundred carriage-return line-feed sequences are printed and then Windows >>> >>> displays "erl.exe has stopped working." No crash dump is produced. >>> >>> >>> >>> This problem does not occur with the Windows shell werl.exe. >>> _______________________________________________ > > We have found three bugs in the vanilla/fd/spawn-driver code on Windows. One of them being in the flush of stdout as Patrik was betting on. Fixes of these bugs will probably fix this issue as well as other crashes on Windows. We will try to make a test Windows build available as soon as possible, but I don't know exactly how and when yet. > > Regards, > Rickard Green, Erlang/OTP, Ericsson AB > Snapshots from our daily tests follow. The crash during exit of erl.exe should have been fixed. Please let us know the result if you test them out. 32-bit Windows binary package: http://erlang.org/download/otp_win32_R16B_test.exe 64-bit Windows binary package: http://erlang.org/download/otp_win64_R16B_test.exe Regards, Rickard Green, Erlang/OTP, Ericsson AB From EMcDowell@REDACTED Wed Feb 6 20:35:46 2013 From: EMcDowell@REDACTED (McDowell, Edward D.) Date: Wed, 6 Feb 2013 14:35:46 -0500 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: References: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> <510BD50B.3070406@erlang.org> Message-ID: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847EC@mailsvr4.RICOL.EDU> The erl.exe crash no longer occurs using otp_win32_R16B_test. :) There was never a problem with the win64 version. I will test both versions further and let you know if I find any problems. Despite the crash, R16A runs about 20% faster than R15B on some highly-concurrent test programs. -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Rickard Green Sent: Wednesday, February 06, 2013 12:57 PM To: Erlang Bugs Subject: Re: [erlang-bugs] R16A erl.exe does not exit properly on Windows. On Feb 4, 2013, at 2:55 PM, Rickard Green wrote: >>> >>> The Erlang command line program erl.exe release R16A does not exit properly >>> >>> on Windows 7 Starter Edition using a 32-bit processor. >> I bet this has something to do with the flushing of "stdout" data at exit. I will be way from OTP for a week, but will send you approximately one million questions about this when I get back, if it's not already solved by then! Just to let you know you're not ignored :) >>> >>> >>> When the shell is terminated using either init:stop() or halt() several >>> >>> hundred carriage-return line-feed sequences are printed and then Windows >>> >>> displays "erl.exe has stopped working." No crash dump is produced. >>> >>> >>> >>> This problem does not occur with the Windows shell werl.exe. >>> _______________________________________________ > > We have found three bugs in the vanilla/fd/spawn-driver code on Windows. One of them being in the flush of stdout as Patrik was betting on. Fixes of these bugs will probably fix this issue as well as other crashes on Windows. We will try to make a test Windows build available as soon as possible, but I don't know exactly how and when yet. > > Regards, > Rickard Green, Erlang/OTP, Ericsson AB > Snapshots from our daily tests follow. The crash during exit of erl.exe should have been fixed. Please let us know the result if you test them out. 32-bit Windows binary package: http://erlang.org/download/otp_win32_R16B_test.exe 64-bit Windows binary package: http://erlang.org/download/otp_win64_R16B_test.exe Regards, Rickard Green, Erlang/OTP, Ericsson AB _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From rickard@REDACTED Thu Feb 7 09:17:28 2013 From: rickard@REDACTED (Rickard Green) Date: Thu, 7 Feb 2013 09:17:28 +0100 Subject: [erlang-bugs] R16A erl.exe does not exit properly on Windows. In-Reply-To: <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847EC@mailsvr4.RICOL.EDU> References: <1862525747.3305209.1359724369859.JavaMail.root@erlang-solutions.com> <510BD50B.3070406@erlang.org> <79EEF8FD7A3DA9458F4886A20D3F35B401EFF91847EC@mailsvr4.RICOL.EDU> Message-ID: <51136318.9040202@erlang.org> On 02/06/2013 08:35 PM, McDowell, Edward D. wrote: > The erl.exe crash no longer occurs using otp_win32_R16B_test. :) > There was never a problem with the win64 version. > > I will test both versions further and let you know if I find any problems. > Despite the crash, R16A runs about 20% faster than R15B on some highly-concurrent test programs. > Great, thanks! Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From mattevans123@REDACTED Thu Feb 7 17:04:23 2013 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 7 Feb 2013 11:04:23 -0500 Subject: [erlang-bugs] erlang:delete_element/2 missing Message-ID: Hi, It's in the Erlang documentation. Has this been removed (tried on R15B01 and R15B03)? Erlang R15B01 (erts-5.9.1) [source] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.1 ?(abort with ^G) 1> erlang:delete_element(2, {one, two, three}). ** exception error: undefined function erlang:delete_element/2 2>? From vinoski@REDACTED Thu Feb 7 17:14:15 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 7 Feb 2013 11:14:15 -0500 Subject: [erlang-bugs] erlang:delete_element/2 missing In-Reply-To: References: Message-ID: On Thu, Feb 7, 2013 at 11:04 AM, Matthew Evans wrote: > > Hi, > > It's in the Erlang documentation. Has this been removed (tried on R15B01 > and R15B03)? > > > > Erlang R15B01 (erts-5.9.1) [source] [smp:8:8] [async-threads:0] [hipe] > [kernel-poll:false] > > Eshell V5.9.1 (abort with ^G) > 1> erlang:delete_element(2, {one, two, three}). > ** exception error: undefined function erlang:delete_element/2 > 2> That's a new bif for R16: Erlang R16A (erts-5.10) [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false] Eshell V5.10 (abort with ^G) 1> erlang:delete_element(2, {one, two, three}). {one,three} 2> --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Thu Feb 7 17:29:15 2013 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 7 Feb 2013 11:29:15 -0500 Subject: [erlang-bugs] erlang:delete_element/2 missing In-Reply-To: References: , Message-ID: Ugh...thanks Steve, I'm not sure I want to move to R16A yet.? I guess I'll do something like this. 4> Tupple = {one,two,three}. 5> lists:foldl(fun(C,Acc) when C/=2 -> erlang:append_element(Acc,erlang:element(C,Tupple)); (_,Acc) -> Acc end,{},[1,2,3]). {one,three} ________________________________ > Date: Thu, 7 Feb 2013 11:14:15 -0500 > Subject: Re: [erlang-bugs] erlang:delete_element/2 missing > From: vinoski@REDACTED > To: mattevans123@REDACTED > CC: erlang-questions@REDACTED; erlang-bugs@REDACTED > > > > On Thu, Feb 7, 2013 at 11:04 AM, Matthew Evans > > wrote: > > Hi, > > It's in the Erlang documentation. Has this been removed (tried on > R15B01 and R15B03)? > > > > Erlang R15B01 (erts-5.9.1) [source] [smp:8:8] [async-threads:0] [hipe] > [kernel-poll:false] > > Eshell V5.9.1 (abort with ^G) > 1> erlang:delete_element(2, {one, two, three}). > ** exception error: undefined function erlang:delete_element/2 > 2> > > That's a new bif for R16: > > Erlang R16A (erts-5.10) [source] [64-bit] [smp:8:8] [async-threads:10] > [kernel-poll:false] > > Eshell V5.10 (abort with ^G) > 1> erlang:delete_element(2, {one, two, three}). > {one,three} > 2> > > --steve From paul.cager@REDACTED Thu Feb 7 19:06:51 2013 From: paul.cager@REDACTED (Paul Cager) Date: Thu, 7 Feb 2013 18:06:51 +0000 Subject: [erlang-bugs] R15B03 - Following a send_timeout on a socket, the socket will no longer be closed on process exit. Message-ID: Erlang R15B03 (V5.9.3.1) on Linux (RHEL 6.3). Normally if the connected process of a TCP socket exits, the socket is closed. However if a socket has option send_timeout (*without* send_timeout_close), and a send does indeed timeout, then the socket is not closed when the connected process exits. It is also not closed if you use gen_tcp:close(), erlang:port_close() etc. This results in a "leaked" socket that becomes impossible to close (unless the remote end closes, or the whole beam OS process exits). To reproduce (on Linux) ======================= 1) Build the runtime with INET_DRV_DEBUG turned on in inet_drv.c. 2) In one window run netstat so you can see which sockets are open on the test port (1616) while true; do netstat -nap | grep :1616 ; sleep 1; done 3) Run the Erlang test module below to demonstrate the *working* case (i.e. not hitting a send_timeout). 4) Note from the debug output that tcp_inet_stop of inet_drv is called. As a result the socket closes (indicated by netstat output). 5) Edit the test module to comment out the exit() where indicated (%% COMMENT OUT FOLLOWING LINES TO DEMONSTRATE PROBLEM). Re-run the test. 6) Note that tcp_inet_stop is *not* called and that the socket remains established even after termination of the connected process. 7) If you replace the exit() following the send_timeout with a call to prim_inet:close() or erlang:port_close() you get similar results. ============================================================================================ -module(test_tcp_close2). -compile(export_all). main() -> {Pid, _Ref} = spawn_monitor(fun() -> run_test() end), receive {'DOWN', _, process, Pid, _} -> io:format("Child process terminated - socket should definately be closed~n", []), io:format("All ports: ~p~n", [erlang:ports()]) end. run_test() -> {ok, LSock} = gen_tcp:listen(1616, [binary, {packet,0}, {active, false}, {reuseaddr, true}]), spawn(?MODULE, connect_and_idle, [1616]), {ok, Sock} = gen_tcp:accept(LSock), {ok, FD} = prim_inet:getfd(Sock), io:format("All ports: ~p~n", [erlang:ports()]), io:format("** Accepted a connection with FD~p~n", [FD]), debug_fd(FD), ok = inet:setopts(Sock, [ {send_timeout, 250}, {active, once}, {nodelay, true}, {sndbuf, 32 * 1024}, {keepalive, true} ]), fill_write(Sock, FD). fill_write(Sock, FD) -> %% Make sure the output buffer becomes full so we trigger send_timeout. Size = 16 * 1024 * 8, %% 16 KB (k *bytes*). case gen_tcp:send(Sock, <<0:Size>>) of {error, timeout} -> io:format("** timeout~n", []), debug_fd(FD), io:format("Self=~p, port_info=~p~n", [self(), erlang:port_info(Sock)]), io:format("** About to exit~n", []), io:format("All ports: ~p~n", [erlang:ports()]), exit(normal), ok; {error, X} -> io:format("** Unexpected send error: ~p~n", [X]), debug_fd(FD), io:format("** port_info: ~p~n", [catch erlang:port_info(Sock, connected)]); ok -> timer:sleep(1000), debug_fd(FD), io:format("Self=~p, port_info=~p~n", [self(), erlang:port_info(Sock)]), %% COMMENT OUT FOLLOWING LINES TO DEMONSTRATE PROBLEM % Exit before send_timeout happens - this should work exit(normal), %% END COMMENT OUT FOLLOWING LINES TO DEMONSTRATE PROBLEM fill_write(Sock, FD) end. debug_mbox() -> receive X -> io:format("Got message ~p~n", [X]), debug_mbox() after 1000 -> ok end. debug_fd(FD) -> File = "/proc/" ++ os:getpid() ++ "/fd/" ++ integer_to_list(FD), Result = os:cmd("ls -l " ++ File ++ " 2>&1"), io:format("FD ~p: ~p~n", [FD, Result]). connect_and_idle(Port) -> {ok, _Sock} = gen_tcp:connect("localhost", Port, [{active,false}, {mode,binary}, {packet, 0}]), timer:sleep(60000), io:format("idle reader closing~n", []). ============================================================================================ Normal Exit of Process. (gdb) bt #0 tcp_inet_stop (e=0x95e580) at drivers/common/inet_drv.c: #1 0x0000000000495b87 in terminate_port (prt=0x7ffff679ba98) at beam/io.c:1976 #2 0x0000000000498df8 in erts_do_exit_port (p=0x7ffff679ba98, from=, reason=) at beam/io.c:2203 #3 0x00000000004aa513 in doit_exit_link (lnk=0x9919f0, vpcontext=) at beam/erl_process.c:8611 #4 0x0000000000515057 in erts_sweep_links (root=, doit=0x4aa260 , context=0x7ffff4952bf0) at beam/erl_monitors.c:859 #5 0x00000000004b0a46 in continue_exit_process (p=0x98b8d0, pix_lock=) at beam/erl_process.c:9005 #6 0x00000000005399c7 in terminate_proc (c_p=0x98b8d0, pc=, reg=, bf=) at beam/beam_emu.c:5524 #7 handle_error (c_p=0x98b8d0, pc=, reg=, bf=) at beam/beam_emu.c:5399 #8 0x000000000053a6f4 in process_main () at beam/beam_emu.c:2436 #9 0x00000000004b17a9 in sched_thread_func (vesdp=0x7ffff7e5bd40) at beam/erl_process.c:5217 #10 0x00000000005bbf86 in thr_wrapper (vtwd=0x7fffffffd850) at pthread/ethread.c:106 #11 0x00000031b4407851 in start_thread () from /lib64/libpthread.so.0 #12 0x00000031b3ce811d in clone () from /lib64/libc.so.6 From kostis@REDACTED Fri Feb 8 12:30:08 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 08 Feb 2013 12:30:08 +0100 Subject: [erlang-bugs] Minor annoyance after 'make clean' Message-ID: <5114E1C0.10901@cs.ntua.gr> Every time I issue a 'make clean' the file lib/ssh/doc/html/SSH_protocols.png which apparently is part of the code base of the master branch, gets deleted. Is this intentional? The problem is that after the 'make clean', a subsequent 'git status' command shows the following: # On branch master # Changed but not updated: # (use "git add/rm ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # deleted: lib/ssh/doc/html/SSH_protocols.png # Can this be fixed? Kostis From n.oxyde@REDACTED Fri Feb 8 12:47:34 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 8 Feb 2013 12:47:34 +0100 Subject: [erlang-bugs] Minor annoyance after 'make clean' In-Reply-To: <5114E1C0.10901@cs.ntua.gr> References: <5114E1C0.10901@cs.ntua.gr> Message-ID: Hi, It can, and here is a fix. git fetch https://github.com/nox/otp.git fix-ssh-html-doc https://github.com/nox/otp/compare/erlang:master...fix-ssh-html-doc https://github.com/nox/otp/compare/erlang:master...fix-ssh-html-doc.patch Regards, -- Anthony Ramine Le 8 f?vr. 2013 ? 12:30, Kostis Sagonas a ?crit : > Every time I issue a 'make clean' the file > > lib/ssh/doc/html/SSH_protocols.png > > which apparently is part of the code base of the master branch, gets deleted. Is this intentional? > > The problem is that after the 'make clean', a subsequent 'git status' command shows the following: > > # On branch master > # Changed but not updated: > # (use "git add/rm ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working directory) > # > # deleted: lib/ssh/doc/html/SSH_protocols.png > # > > > Can this be fixed? > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From coolchevy@REDACTED Fri Feb 8 14:17:18 2013 From: coolchevy@REDACTED (Vitaliy Kulchevych) Date: Fri, 8 Feb 2013 15:17:18 +0200 Subject: [erlang-bugs] erlang,hd,[[]] Message-ID: Hi, all! I'm using cpu_sup for monitoring os of erlang node. Sometimes I catch crash: {badarg,[{erlang,hd,[[]],[]},{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,282}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]} Darwin coolchevy.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 Mac OS X 10.7.5 Erlang from mac ports: Erlang R15B (erts-5.9) -- live free or die; From n.oxyde@REDACTED Sat Feb 9 14:01:47 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 9 Feb 2013 14:01:47 +0100 Subject: [erlang-bugs] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <51098739.8020308@ninenines.eu> References: <51098739.8020308@ninenines.eu> Message-ID: Hi, I've got a fix: git fetch https://github.com/nox/otp.git wide-chars https://github.com/nox/otp/compare/erlang:master...wide-chars https://github.com/nox/otp/compare/erlang:master...wide-chars.patch I can't test the win32 part though. Bj?rn, should I add some autoconf machinery to know whether wcwidth() is available? Regards, -- Anthony Ramine Le 30 janv. 2013 ? 21:48, Lo?c Hoguin a ?crit : > Erlang R16A (erts-5.10) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10 (abort with ^G) > 1> "aaa". > "aaa" > 2> "??". > "??" > 3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3>3> > > In 1> I wrote an ASCII string, got the result, then tried to up-down-up-down-up-down-up-down and it adds/remove "aaa" as intended. > > Then in 2> I wrote an Unicode string, got the result (nice!), then tried to do the same up-down mimic except everytime I did down when the Unicode text was printed, it added a 3> on the line. It only does so for the Unicode and not for ASCII. > > Thinking there's some missing cleanup there. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From ufm@REDACTED Sun Feb 10 01:34:26 2013 From: ufm@REDACTED (Fyodor Ustinov) Date: Sun, 10 Feb 2013 02:34:26 +0200 Subject: [erlang-bugs] R15B03, ssh:daemon and io:rows/io:columns Message-ID: <093abc45fe5653ec43bcca278acdb580.squirrel@mail.ufm.su> Hi! Call io:rows/0 and io:columns/0 in shell called from ssh:daemon hang on 5 seconds and show: 1> io:rows(). {error,enotsup} I.e. 2 additional empty string and error. It's a bug or feature? -- WBR, Fyodor From eric.pailleau@REDACTED Sun Feb 10 12:31:45 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 10 Feb 2013 12:31:45 +0100 Subject: [erlang-bugs] R16A : can't compile In-Reply-To: <51103F68.5010209@wanadoo.fr> References: <510AEAA9.2070304@wanadoo.fr> <51103F68.5010209@wanadoo.fr> Message-ID: <51178521.9020406@wanadoo.fr> hello, I reach to compile R16A by overriding CPPFLAGS with 32 bit file offset : #> export CPPFLAGS=-D_FILE_OFFSET_BITS=32 but I found 2 anothers problems with WX driver. See my next mail. Regards From eric.pailleau@REDACTED Sun Feb 10 12:34:11 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 10 Feb 2013 12:34:11 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation Message-ID: <511785B3.10406@wanadoo.fr> Hello following my former mail, here is below issue in WX driver compilation which is discarded in configure... _______________________________________________________________________ configure: ERL ROOT DIR: /usr/local/lib/erlang checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... no checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.10) checking for wxWidgets static library... no checking if wxwidgets have opengl support... no checking for GLintptr... no checking for GLintptrARB... no checking for GLchar... no checking for GLcharARB... no checking for GLhalfARB... no checking for GLint64EXT... no checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... no configure: WARNING: Can not find wx/stc/stc.h -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g -O2 -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=32 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/lib/wx/include/ -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread checking if we can link wxwidgets programs... no configure: WARNING: Can not link wx program are all developer packages installed? checking if we can add -Werror=return-type to CFLAGS (via CFLAGS)... yes checking if we can add -Werror=return-type to CXXFLAGS (via CFLAGS)... yes configure: error: Cannot build wxErlang driver, see ./CONF_INFO for information _______________________________________________________________________ The problem is that wx/stc/stc.h exists in /usr/include/wx-2.8 ... $> locate stc.h /usr/include/wx-2.8/wx/stc/stc.h /usr/local/wx/stc/stc.h Another issue is that my -D_FILE_OFFSET_BITS=32 directive is overriden by default -D_FILE_OFFSET_BITS=64 at the end of command line (see first Warning above). So even if the driver is created, this will fail with my former fallocate64 error... as a logical result, wx application fails due to missing driver : _______________________________________________________________________ Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10 (abort with ^G) 1> observer:start(). {error,{{load_driver,"No driver found"}, [{wxe_server,start,1,[{file,"wxe_server.erl"},{line,64}]}, {wx,new,1,[{file,"wx.erl"},{line,114}]}, {observer_wx,init,1,[{file,"observer_wx.erl"},{line,87}]}, {wx_object,init_it,6,[{file,"wx_object.erl"},{line,299}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} =ERROR REPORT==== 10-Feb-2013::11:49:55 === ERROR: Could not find 'wxe_driver.so' in: /usr/local/lib/erlang/lib/wx-1.0/priv _______________________________________________________________________ From robert.virding@REDACTED Mon Feb 11 01:35:37 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 11 Feb 2013 00:35:37 +0000 (GMT) Subject: [erlang-bugs] erlang,hd,[[]] In-Reply-To: Message-ID: <885709795.11504937.1360542937804.JavaMail.root@erlang-solutions.com> You are crashing because you are trying to call hd([]) which is illegal as hd/1 returns the head of the argument list and [] has no head. Hence the badarg error. Why it is calling hd([]) in cpu_sup:get_uint32/2 is another story. Can't help you there. Robert ----- Original Message ----- > From: "Vitaliy Kulchevych" > To: erlang-bugs@REDACTED > Sent: Friday, 8 February, 2013 2:17:18 PM > Subject: [erlang-bugs] erlang,hd,[[]] > > Hi, all! > I'm using cpu_sup for monitoring os of erlang node. Sometimes I catch > crash: > > {badarg,[{erlang,hd,[[]],[]},{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,282}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]} > > > Darwin coolchevy.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug > 23 > 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 > > Mac OS X 10.7.5 > > Erlang from mac ports: Erlang R15B (erts-5.9) > > -- > live free or die; > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From coolchevy@REDACTED Mon Feb 11 09:24:07 2013 From: coolchevy@REDACTED (Vitaliy Kulchevych) Date: Mon, 11 Feb 2013 10:24:07 +0200 Subject: [erlang-bugs] erlang,hd,[[]] In-Reply-To: <885709795.11504937.1360542937804.JavaMail.root@erlang-solutions.com> References: <885709795.11504937.1360542937804.JavaMail.root@erlang-solutions.com> Message-ID: Hi, Robert! Yes, it's true. When os:cmd("LANG=C LC_ALL=C uptime") calling on loaded system there returns empty string. I think os:cmd has timeout. May be cpu_sup must be catch it? On Mon, Feb 11, 2013 at 2:35 AM, Robert Virding wrote: > You are crashing because you are trying to call hd([]) which is illegal as hd/1 returns the head of the argument list and [] has no head. Hence the badarg error. Why it is calling hd([]) in cpu_sup:get_uint32/2 is another story. Can't help you there. > > Robert > > ----- Original Message ----- >> From: "Vitaliy Kulchevych" >> To: erlang-bugs@REDACTED >> Sent: Friday, 8 February, 2013 2:17:18 PM >> Subject: [erlang-bugs] erlang,hd,[[]] >> >> Hi, all! >> I'm using cpu_sup for monitoring os of erlang node. Sometimes I catch >> crash: >> >> {badarg,[{erlang,hd,[[]],[]},{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,282}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]} >> >> >> Darwin coolchevy.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug >> 23 >> 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 >> >> Mac OS X 10.7.5 >> >> Erlang from mac ports: Erlang R15B (erts-5.9) >> >> -- >> live free or die; >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> -- live free or die; From fredrik@REDACTED Mon Feb 11 10:28:46 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 11 Feb 2013 10:28:46 +0100 Subject: [erlang-bugs] [erlang-patches] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: References: <51098739.8020308@ninenines.eu> Message-ID: <5118B9CE.3040606@erlang.org> On 02/09/2013 02:01 PM, Anthony Ramine wrote: > Hi, > > I've got a fix: > > git fetch https://github.com/nox/otp.git wide-chars > > https://github.com/nox/otp/compare/erlang:master...wide-chars > https://github.com/nox/otp/compare/erlang:master...wide-chars.patch > > I can't test the win32 part though. > > Bj?rn, should I add some autoconf machinery to know whether wcwidth() is > available? > > Regards, > Thanks, It is currently cooking in the 'master-pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From wallentin.dahlberg@REDACTED Mon Feb 11 10:29:28 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Mon, 11 Feb 2013 10:29:28 +0100 Subject: [erlang-bugs] erlang,hd,[[]] In-Reply-To: References: <885709795.11504937.1360542937804.JavaMail.root@erlang-solutions.com> Message-ID: 2013/2/11 Vitaliy Kulchevych > Hi, Robert! > > Yes, it's true. > When os:cmd("LANG=C LC_ALL=C uptime") calling on loaded system there > returns empty string. > I think os:cmd has timeout. > May be cpu_sup must be catch it? > Either that or it shouldn't call it in the first place. Using a capability without checking if it exists .. not ideal. > > On Mon, Feb 11, 2013 at 2:35 AM, Robert Virding > wrote: > > You are crashing because you are trying to call hd([]) which is illegal > as hd/1 returns the head of the argument list and [] has no head. Hence the > badarg error. Why it is calling hd([]) in cpu_sup:get_uint32/2 is another > story. Can't help you there. > > > > Robert > > > > ----- Original Message ----- > >> From: "Vitaliy Kulchevych" > >> To: erlang-bugs@REDACTED > >> Sent: Friday, 8 February, 2013 2:17:18 PM > >> Subject: [erlang-bugs] erlang,hd,[[]] > >> > >> Hi, all! > >> I'm using cpu_sup for monitoring os of erlang node. Sometimes I catch > >> crash: > >> > >> > {badarg,[{erlang,hd,[[]],[]},{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,282}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]} > >> > >> > >> Darwin coolchevy.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug > >> 23 > >> 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 > >> > >> Mac OS X 10.7.5 > >> > >> Erlang from mac ports: Erlang R15B (erts-5.9) > >> > >> -- > >> live free or die; > >> _______________________________________________ > >> erlang-bugs mailing list > >> erlang-bugs@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-bugs > >> > > > > -- > live free or die; > _______________________________________________ > 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 Feb 11 10:56:03 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 11 Feb 2013 10:56:03 +0100 Subject: [erlang-bugs] [erlang-patches] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: References: <51098739.8020308@ninenines.eu> Message-ID: <5118C033.5050301@erlang.org> On 02/09/2013 02:01 PM, Anthony Ramine wrote: > Hi, > > I've got a fix: > > git fetch https://github.com/nox/otp.git wide-chars > > https://github.com/nox/otp/compare/erlang:master...wide-chars > https://github.com/nox/otp/compare/erlang:master...wide-chars.patch > > I can't test the win32 part though. > > Bj?rn, should I add some autoconf machinery to know whether wcwidth() is > available? > > Regards, > Your patch is failing on windows: error LNK2019: unresolved external symbol wcwidth referenced in function check_buf_size Could you please have a look at this? -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Mon Feb 11 11:58:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 11 Feb 2013 11:58:41 +0100 Subject: [erlang-bugs] [erlang-patches] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <5118C033.5050301@erlang.org> References: <51098739.8020308@ninenines.eu> <5118C033.5050301@erlang.org> Message-ID: <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> Hi, There is no wcwidth() in Windows, I'll add some autoconf magic to conditionally use it. -- Anthony Ramine Le 11 f?vr. 2013 ? 10:56, Fredrik a ?crit : > On 02/09/2013 02:01 PM, Anthony Ramine wrote: >> Hi, >> >> I've got a fix: >> >> git fetch https://github.com/nox/otp.git wide-chars >> >> https://github.com/nox/otp/compare/erlang:master...wide-chars >> https://github.com/nox/otp/compare/erlang:master...wide-chars.patch >> >> I can't test the win32 part though. >> >> Bj?rn, should I add some autoconf machinery to know whether wcwidth() is >> available? >> >> Regards, >> > Your patch is failing on windows: > > error LNK2019: unresolved external symbol wcwidth referenced in function check_buf_size > > > Could you please have a look at this? > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From niticin@REDACTED Mon Feb 11 16:20:47 2013 From: niticin@REDACTED (Anton Nikitin) Date: Mon, 11 Feb 2013 19:20:47 +0400 Subject: [erlang-bugs] Inets-5.9.3 Content-length:0 HTTP/1.1 Bug Message-ID: Hello, I'm facing the following issue, when executing the following code with inets-5.9.3: inets:start(). F = fun() -> io:format("Started thread~n"), [ begin io:format("Response ~p~n", [httpc:request('get', {"http://nikitin.reksoft.ru:7080/TestErlang/testerlang", []}, [{version, "HTTP/1.1"}], [])]), timer:sleep(1000) end || _ <- lists:seq(1, 5)] end. [spawn(F) || _ <- lists:seq(1, 500)]. According to the TCP traces everything is fine. The HTTP/1.1 request: GET /TestErlang/testerlang HTTP/1.1 te: host: nikitin.reksoft.ru:7080 connection: keep-alive The HTTP/1.1 response: HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/plain Content-Length: 0 Date: Mon, 11 Feb 2013 15:15:31 GMT But some of the reponses are formed wrongly in this way: Response {ok,{{"HTTP/1.1",404,"Not Found"}, [{"date","Mon, 11 Feb 2013 15:16:19 GMT"}, {"server","Apache-Coyote/1.1"}, {"content-length","0"}, {"content-type","text/plain"}], "HTTP/1.1 404 Not Found\r\nServer: Apache-Coyote/1.1\r\nContent-Type: text/plain\r\nContent-Length: 0\r\nDate: Mon, 11 Feb 2013 15:16:19 GMT\r\n\r\nHTTP/1.1 404 Not Found\r\nServer: Apache-Coyote/1.1\r\nContent-Type: text/plain\r\nContent-Length: 0\r\nDate: Mon, 11 Feb 2013 15:16:19 GMT\r\n\r\n"}} The bug can be reproduced in a multi-thread case only. Workaround: HTTP/1.1 server responds with some content body and content length is not zero. Best Regards, Anton Nikitin -------------- next part -------------- An HTML attachment was scrubbed... URL: From inanun@REDACTED Tue Feb 12 10:43:47 2013 From: inanun@REDACTED (Kyungho Yun) Date: Tue, 12 Feb 2013 18:43:47 +0900 Subject: [erlang-bugs] module_info function of pman doesn't work. (call to tuple fun) Message-ID: Hi all. Problem ======= module_info function of pman doesn't work. To reproduce ============ 1. pman:start() on erlang shell. 2. select a process in Pman window. 3. Select View menu. 4. Select module_info. 5. You can see error message instead of the module infomation. Environments =========== Erlang R16A RC / ubuntu 12.04 Description =========== It works until R15B04 with some warning message: Call to tuple fun {gs_frontend,module_info}. Tuple funs are deprecated and will be removed in R16. Use "fun M:F/A" instead, for example "fun gs_frontend:module_info/0". (This warning will only be shown the first time a tuple fun is called.) similar codes: lib/tools/src/fprof.erl 90:apply({M, F}, Args) 101:apply({M, F}, Args, Options) lib/tools/test/xref_SUITE_data/read/read.erl 81: apply({a,b},[1005]), 82: apply({a,A},[1005]), % {a,'$F_EXPR',1} lib/pman/src/pman_win.erl 549: vformat("", catch apply({ModuleName, module_info},[])). lib/sasl/src/si_sasl_supp.erl 363: case catch apply({Module, Func}, [Opt, Data]) of BR. Yun,Kyungho. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Tue Feb 12 18:00:29 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 12 Feb 2013 18:00:29 +0100 Subject: [erlang-bugs] [erlang-patches] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> References: <51098739.8020308@ninenines.eu> <5118C033.5050301@erlang.org> <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> Message-ID: <511A752D.8070104@erlang.org> Hi! On 02/11/2013 11:58 AM, Anthony Ramine wrote: > Hi, > > There is no wcwidth() in Windows, I'll add some autoconf magic to conditionally > use it. > I think you can skip all the testing of widths on windows, the win_con.c code takes care of the actual width of the glyphs to at least some extent. Autoconfing for wcwidth is however a good idea anyway. Cheers, /Patrik From n.oxyde@REDACTED Tue Feb 12 18:10:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 12 Feb 2013 18:10:03 +0100 Subject: [erlang-bugs] [erlang-patches] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <511A752D.8070104@erlang.org> References: <51098739.8020308@ninenines.eu> <5118C033.5050301@erlang.org> <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> <511A752D.8070104@erlang.org> Message-ID: <66BCBDD2-DC29-4A28-A4EC-848BFF23E6E0@gmail.com> Ok, I'll add some autoconf machinery for unix and remove wcwidth for win32. -- Anthony Ramine Le 12 f?vr. 2013 ? 18:00, Patrik Nyblom a ?crit : > Hi! > > On 02/11/2013 11:58 AM, Anthony Ramine wrote: >> Hi, >> >> There is no wcwidth() in Windows, I'll add some autoconf magic to conditionally >> use it. >> > I think you can skip all the testing of widths on windows, the win_con.c code takes care of the actual width of the glyphs to at least some extent. > Autoconfing for wcwidth is however a good idea anyway. > > Cheers, > /Patrik > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From essen@REDACTED Tue Feb 12 23:57:48 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 12 Feb 2013 23:57:48 +0100 Subject: [erlang-bugs] R16: HiPE failure with /bits in funs Message-ID: <511AC8EC.3070507@ninenines.eu> The following module fails to compile with R16. It also fails on R15B03 and probably previous versions. I do not know HiPE internals so no patch. -module(hipe_error). -export([run/0]). run() -> fun (<< $c, _/bits >>) -> ok end. The following errors are reported: 7> c(hipe_error, [native]). EXITED with reason {function_clause,[{hipe_rtl_binary_match,gen_rtl,[{bs_match_string,<<99>>,1},[],[{rtl_var,21}],16,2],[{file,[104,105,112,101,95,114,116,108,95,98,105,110,97,114,121,95,109,97,116,99,104,46,101,114,108]},{line,45}]},{hipe_rtl_binary,gen_rtl,7,[{file,[104,105,112,101,95,114,116,108,95,98,105,110,97,114,121,46,101,114,108]},{line,33}]},{hipe_rtl_primops,gen_primop,3,[{file,[104,105,112,101,95,114,116,108,95,112,114,105,109,111,112,115,46,101,114,108]},{line,147}]},{hipe_icode2rtl,gen_call,3,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,189}]},{hipe_icode2rtl,translate_instrs,5,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,104}]},{hipe_icode2rtl,translate,2,[{file,[104,105,112,101,95,105,99,111,100,101,50,114,116,108,46,101,114,108]},{line,71}]},{hipe_main,translate_to_rtl,2,[{file,[104,105,112,101,95,109,97,105,110,46,101,114,108]},{line,396}]},{hipe_main,icode_to_rtl,4,[{file,[104,105,112,101,95,109,97,105,110,4 6,101,114,108]},{line,376}]}]} @hipe:829 hipe_error.erl:none: internal error in native_compile; crash reason: {{hipe,829, {function_clause, [{hipe_rtl_binary_match,gen_rtl, [{bs_match_string,<<"c">>,1}, [], [{rtl_var,21}], 16,2], [{file,"hipe_rtl_binary_match.erl"},{line,45}]}, {hipe_rtl_binary,gen_rtl,7, [{file,"hipe_rtl_binary.erl"},{line,33}]}, {hipe_rtl_primops,gen_primop,3, [{file,"hipe_rtl_primops.erl"},{line,147}]}, {hipe_icode2rtl,gen_call,3, [{file,"hipe_icode2rtl.erl"},{line,189}]}, {hipe_icode2rtl,translate_instrs,5, [{file,"hipe_icode2rtl.erl"},{line,104}]}, {hipe_icode2rtl,translate,2, [{file,"hipe_icode2rtl.erl"},{line,71}]}, {hipe_main,translate_to_rtl,2, [{file,"hipe_main.erl"},{line,396}]}, {hipe_main,icode_to_rtl,4, [{file,"hipe_main.erl"},{line,376}]}]}}, [{hipe,finalize_fun_sequential,3, [{file,"hipe.erl"},{line,829}]}, {hipe,'-finalize_fun_concurrent/3-fun-3-',4, [{file,"hipe.erl"},{line,795}]}]} error 8> =ERROR REPORT==== 12-Feb-2013::23:51:59 === Error: [hipe:828]: ERROR: {function_clause, [{hipe_rtl_binary_match,gen_rtl, [{bs_match_string,<<"c">>,1}, [], [{rtl_var,21}], 16,2], [{file, "hipe_rtl_binary_match.erl"}, {line,45}]}, {hipe_rtl_binary,gen_rtl,7, [{file,"hipe_rtl_binary.erl"}, {line,33}]}, {hipe_rtl_primops,gen_primop,3, [{file,"hipe_rtl_primops.erl"}, {line,147}]}, {hipe_icode2rtl,gen_call,3, [{file,"hipe_icode2rtl.erl"}, {line,189}]}, {hipe_icode2rtl, translate_instrs,5, [{file,"hipe_icode2rtl.erl"}, {line,104}]}, {hipe_icode2rtl,translate,2, [{file,"hipe_icode2rtl.erl"}, {line,71}]}, {hipe_main,translate_to_rtl,2, [{file,"hipe_main.erl"}, {line,396}]}, {hipe_main,icode_to_rtl,4, [{file,"hipe_main.erl"}, {line,376}]}]} =ERROR REPORT==== 12-Feb-2013::23:51:59 === Error in process <0.120.0> with exit value: {{hipe,829,{function_clause,[{hipe_rtl_binary_match,gen_rtl,[{bs_match_string,<<1 byte>>,1},[],[{rtl_var,21}],16,2],[{file,"hipe_rtl_binary_match.erl"},{line,45}]},{hipe_rtl_binary,gen_rtl,7,[{file,"hipe_rtl_binary.erl"},{line,33}]},{hipe_rtl_primops... -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From kostis@REDACTED Wed Feb 13 00:47:24 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 13 Feb 2013 00:47:24 +0100 Subject: [erlang-bugs] R16: HiPE failure with /bits in funs In-Reply-To: <511AC8EC.3070507@ninenines.eu> References: <511AC8EC.3070507@ninenines.eu> Message-ID: <511AD48C.20908@cs.ntua.gr> On 02/12/2013 11:57 PM, Lo?c Hoguin wrote: > The following module fails to compile with R16. It also fails on R15B03 > and probably previous versions. I do not know HiPE internals so no patch. > > > -module(hipe_error). > -export([run/0]). > > run() -> > fun (<< $c, _/bits >>) -> ok end. Well, actually the culprit here is neither the /bits nor the fun... It's the $c! For example, the following variant of your code compiles happily under HiPE: run() -> fun (<< X, _/bits >>) when X =:= $c -> ok end. I'll put it on my (long) TODO list but it's unlikely that this will be fixed for R16B. Merci beaucoup pour la rapport de bogue, Kostis From bgustavsson@REDACTED Wed Feb 13 15:29:41 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 13 Feb 2013 15:29:41 +0100 Subject: [erlang-bugs] module_info function of pman doesn't work. (call to tuple fun) In-Reply-To: References: Message-ID: On Tue, Feb 12, 2013 at 10:43 AM, Kyungho Yun wrote: > Hi all. > > Problem > ======= > module_info function of pman doesn't work. > > To reproduce > ============ > 1. pman:start() on erlang shell. > 2. select a process in Pman window. > 3. Select View menu. > 4. Select module_info. > 5. You can see error message instead of the module infomation. > > Thanks, will fix. > > similar codes: > lib/tools/src/fprof.erl > 90:apply({M, F}, Args) > 101:apply({M, F}, Args, Options) > > It is a function definition for fprof:apply/2, not a call to apply/2. Not a bug. > lib/tools/test/xref_SUITE_data/read/read.erl > 81: apply({a,b},[1005]), > 82: apply({a,A},[1005]), % {a,'$F_EXPR',1} > > This is testdata for the test suite. I am not an export on Xref, but I don't think Xref tries to distinguish calls that will suceed from calls that will fail. > lib/pman/src/pman_win.erl > 549: vformat("", catch apply({ModuleName, module_info},[])). > > That is the cause of the bug you reported above. > lib/sasl/src/si_sasl_supp.erl > 363: case catch apply({Module, Func}, [Opt, Data]) of > > Will fix. /Bjorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.kruber@REDACTED Wed Feb 13 15:52:06 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 13 Feb 2013 15:52:06 +0100 Subject: [erlang-bugs] edoc ignoring all docs from included .hrl Message-ID: <6702321.KbKQoBQZmV@csr-pc40.zib.de> edoc seems to ignore _all_ documentation from included .hrl files (at least R15B03 and R16A) While it should probably ignore file-scope documentation, docs for types and functions should be present in the modules that include the .hrl. The functions themselves are present in the generated docs, just not the description. -> use the attached files and run edoc: erl -noshell -run edoc_run application "'my_app'" '"."' '[{preprocess, true}]' Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: db_common.hrl Type: text/x-matlab Size: 385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: db_ets.erl Type: text/x-erlang Size: 292 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Thu Feb 14 17:43:29 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 14 Feb 2013 17:43:29 +0100 Subject: [erlang-bugs] R16 EUnit *** context setup failed *** In-Reply-To: References: <85BE9BC9-731C-4DAE-BD47-A33FE7B30AD5@gmail.com> Message-ID: On Thu, Jan 31, 2013 at 4:51 PM, Bj?rn Gustavsson wrote: > Thanks for bisecting! > > I will fix the bug in R16B. Thanks Bjorn, 499eef0 resolved the regression. > On Thu, Jan 31, 2013 at 1:11 AM, Tuncer Ayaz wrote: >> >> On Fri, Nov 23, 2012 at 4:20 PM, Anthony Ramine wrote: >> > I can reproduce this with the exact same steps. >> >> This is the git-bisect result: >> >> 70b5e24c9498225fadc08d19503269c8aad851bf is the first bad commit >> commit 70b5e24c9498225fadc08d19503269c8aad851bf >> Author: Bjorn Gustavsson >> Date: Tue Sep 11 15:03:53 2012 +0200 >> >> Fix filelib:wildcard/2 >> >> filelib:wildcard("some/relative/path/*.beam", Path) would fail to >> match any file. That is, filelib:wildcard/2 would not work if the >> first component of the pattern did not contain any wildcard >> characters. >> >> Noticed-by: Samuel Rivas From mjtruog@REDACTED Sat Feb 16 06:25:04 2013 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 15 Feb 2013 21:25:04 -0800 Subject: [erlang-bugs] binary:part/3 Message-ID: <511F1830.603@gmail.com> There is a problem with the binary:part type spec used by dialyzer (the function is a BIF), such that it thinks the Length is pos_integer() instead of integer(). A similar problem exists within the documentation here (with the Length type): http://www.erlang.org/doc/man/binary.html#part-3 From kostis@REDACTED Sun Feb 17 11:59:12 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 17 Feb 2013 11:59:12 +0100 Subject: [erlang-bugs] binary:part/3 In-Reply-To: <511F1830.603@gmail.com> References: <511F1830.603@gmail.com> Message-ID: <5120B800.2050602@cs.ntua.gr> On 02/16/2013 06:25 AM, Michael Truog wrote: > There is a problem with the binary:part type spec used by dialyzer (the function is a BIF), such that it thinks the Length is pos_integer() instead of integer(). A similar problem exists within the documentation here (with the Length type): > http://www.erlang.org/doc/man/binary.html#part-3 First of all, the documentation you are pointing out specifies that the third argument is "Len = integer() >= 0" so Len should be declared as non_neg_integer(), not integer(). Second, and more important, this has been corrected in R16A/R16B: https://github.com/erlang/otp/blob/master/lib/stdlib/src/binary.erl#L186 If you want a correction for a previous Erlang/OTP release, change the corresponding entry in file lib/hipe/cerl/erl_bif_types.erl Kostis From mjtruog@REDACTED Sun Feb 17 12:12:55 2013 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 17 Feb 2013 03:12:55 -0800 Subject: [erlang-bugs] binary:part/3 In-Reply-To: <5120B800.2050602@cs.ntua.gr> References: <511F1830.603@gmail.com> <5120B800.2050602@cs.ntua.gr> Message-ID: <5120BB37.8010205@gmail.com> On 02/17/2013 02:59 AM, Kostis Sagonas wrote: > On 02/16/2013 06:25 AM, Michael Truog wrote: >> There is a problem with the binary:part type spec used by dialyzer (the function is a BIF), such that it thinks the Length is pos_integer() instead of integer(). A similar problem exists within the documentation here (with the Length type): >> http://www.erlang.org/doc/man/binary.html#part-3 > > First of all, the documentation you are pointing out specifies that the third argument is "Len = integer() >= 0" so Len should be declared as non_neg_integer(), not integer(). > > Second, and more important, this has been corrected in R16A/R16B: > > https://github.com/erlang/otp/blob/master/lib/stdlib/src/binary.erl#L186 > > If you want a correction for a previous Erlang/OTP release, change the corresponding entry in file lib/hipe/cerl/erl_bif_types.erl > > Kostis > The documentation is wrong as you can see from the entry above: http://www.erlang.org/doc/man/binary.html#part-2 The Len should be an integer() since negative Len values do work as mentioned within PosLen = part() = {Start :: integer() >= 0, Length :: integer()} binary:part/3 is just providing the same parameters without the tuple wrapper for PosLen. From kostis@REDACTED Sun Feb 17 12:23:31 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 17 Feb 2013 12:23:31 +0100 Subject: [erlang-bugs] binary:part/3 In-Reply-To: <5120BB37.8010205@gmail.com> References: <511F1830.603@gmail.com> <5120B800.2050602@cs.ntua.gr> <5120BB37.8010205@gmail.com> Message-ID: <5120BDB3.7040705@cs.ntua.gr> On 02/17/2013 12:12 PM, Michael Truog wrote: > On 02/17/2013 02:59 AM, Kostis Sagonas wrote: >> On 02/16/2013 06:25 AM, Michael Truog wrote: >>> There is a problem with the binary:part type spec used by dialyzer (the function is a BIF), such that it thinks the Length is pos_integer() instead of integer(). A similar problem exists within the documentation here (with the Length type): >>> http://www.erlang.org/doc/man/binary.html#part-3 >> >> First of all, the documentation you are pointing out specifies that the third argument is "Len = integer()>= 0" so Len should be declared as non_neg_integer(), not integer(). >> >> Second, and more important, this has been corrected in R16A/R16B: >> >> https://github.com/erlang/otp/blob/master/lib/stdlib/src/binary.erl#L186 >> >> If you want a correction for a previous Erlang/OTP release, change the corresponding entry in file lib/hipe/cerl/erl_bif_types.erl >> >> Kostis >> > The documentation is wrong as you can see from the entry above: > http://www.erlang.org/doc/man/binary.html#part-2 > > The Len should be an integer() since negative Len values do work as mentioned within > PosLen = part() = {Start :: integer()>= 0, Length :: integer()} > > binary:part/3 is just providing the same parameters without the tuple wrapper for PosLen. You are right. There is definitely some discrepancy between the documentation and the declared types. Somebody from OTP should fix this. Kostis From eric.pailleau@REDACTED Sun Feb 17 12:31:21 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 17 Feb 2013 12:31:21 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation Message-ID: <5120BF89.9040700@wanadoo.fr> Hello, I'm struggling with the WX use in Erlang. I upgraded to the last 2.9.4 wxWidgets package and compiled it, like the otp/lib/wx/README ask to : ./configure --with-opengl --enable-unicode --enable-graphics_ctx --enable-gnomeprint --disable-shared On the same machine, R15B03 find OpenGL enabled while R16A don't ... But R15B03 fail to compile on wxePrintout.cpp. Finally I have neither R15B03 nor R16A with WX ... A help would be appreciated !!!... ================= R15B03 ======================================= checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/local/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... yes (version 2.9.4) checking for wxWidgets static library... yes checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/local/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.9.4) checking for wxWidgets static library... yes checking if wxwidgets have opengl support... yes checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... yes checking if we can link wxwidgets programs... yes everything looks fine then but *compilation failed on wxePrintout.cpp* with : g++ -c -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g -O2 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/local/lib/wx/include/gtk2-unicode-static-2.9 -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_VOID_P=4 -DHAVE_GL_GL_H=1 -DHAVE_GL_SUPPORT=1 -DHAVE_GLINTPTR=1 -DHAVE_GLINTPTRARB=1 -DHAVE_GLCHAR=1 -DHAVE_GLCHARARB=1 -DHAVE_GLHALFARB=1 -DHAVE_GLINT64EXT=1 -DHAVE_WX_STC_STC_H=1 -I/home/eric/T?l?chargement/otp_src_R15B03/erts/emulator/beam -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/i686-pc-linux-gnu -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/internal -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/internal/i686-pc-linux-gnu -I/home/eric/T?l?chargement/otp_src_R15B03/erts/emulator/sys/unix wxePrintout.cpp -o i686-pc-linux-gnu/wxePrintout.o In file included from wxePrintout.cpp:24: gen/wxe_derived_dest.h: In constructor ?EwxPanel::EwxPanel(wxWindow*, int, int, int, int, long int)?: gen/wxe_derived_dest.h:48: attention : ?wxPanel::wxPanel(wxWindow*, int, int, int, int, long int, const wxString&)? is deprecated (declared at /usr/local/include/wx-2.9/wx/generic/panelg.h:34) gen/wxe_derived_dest.h: In constructor ?EwxWindowDC::EwxWindowDC()?: gen/wxe_derived_dest.h:97: erreur: no matching function for call to ?wxWindowDC::wxWindowDC()? /usr/local/include/wx-2.9/wx/dcclient.h:25: note: candidats sont: wxWindowDC::wxWindowDC(wxDCImpl*) /usr/local/include/wx-2.9/wx/dcclient.h:22: note: wxWindowDC::wxWindowDC(wxWindow*) /usr/local/include/wx-2.9/wx/dcclient.h:20: note: wxWindowDC::wxWindowDC(const wxWindowDC&) gen/wxe_derived_dest.h: In constructor ?EwxClientDC::EwxClientDC()?: gen/wxe_derived_dest.h:103: erreur: no matching function for call to ?wxClientDC::wxClientDC()? /usr/local/include/wx-2.9/wx/dcclient.h:41: note: candidats sont: wxClientDC::wxClientDC(wxDCImpl*) /usr/local/include/wx-2.9/wx/dcclient.h:38: note: wxClientDC::wxClientDC(wxWindow*) /usr/local/include/wx-2.9/wx/dcclient.h:36: note: wxClientDC::wxClientDC(const wxClientDC&) gen/wxe_derived_dest.h: In constructor ?EwxPaintDC::EwxPaintDC()?: gen/wxe_derived_dest.h:109: erreur: no matching function for call to ?wxPaintDC::wxPaintDC()? /usr/local/include/wx-2.9/wx/dcclient.h:57: note: candidats sont: wxPaintDC::wxPaintDC(wxDCImpl*) /usr/local/include/wx-2.9/wx/dcclient.h:54: note: wxPaintDC::wxPaintDC(wxWindow*) /usr/local/include/wx-2.9/wx/dcclient.h:52: note: wxPaintDC::wxPaintDC(const wxPaintDC&) gen/wxe_derived_dest.h: In constructor ?EwxImage::EwxImage(const wxString&, long int, int)?: gen/wxe_derived_dest.h:205: attention : ?wxImage::wxImage(const wxString&, long int, int)? is deprecated (declared at /usr/local/include/wx-2.9/wx/image.h:524) In file included from wxePrintout.cpp:24: gen/wxe_derived_dest.h: In constructor ?EwxSingleChoiceDialog::EwxSingleChoiceDialog(wxWindow*, const wxString&, const wxString&, const wxArrayString&, char**, long int, const wxPoint&)?: gen/wxe_derived_dest.h:580: attention : ?wxSingleChoiceDialog::wxSingleChoiceDialog(wxWindow*, const wxString&, const wxString&, const wxArrayString&, char**, long int, const wxPoint&)? is deprecated (declared at /usr/local/include/wx-2.9/wx/generic/choicdgg.h:166) gen/wxe_derived_dest.h: In constructor ?EwxGLCanvas::EwxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&)?: gen/wxe_derived_dest.h:681: attention : ?wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, const int*, const wxPalette&)? is deprecated (declared at /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:65) gen/wxe_derived_dest.h: In constructor ?EwxGLCanvas::EwxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&)?: gen/wxe_derived_dest.h:682: attention : ?wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, const int*, const wxPalette&)? is deprecated (declared at /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:77) gen/wxe_derived_dest.h: In constructor ?EwxGLCanvas::EwxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&)?: gen/wxe_derived_dest.h:683: attention : ?wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, const int*, const wxPalette&)? is deprecated (declared at /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:54) gen/wxe_derived_dest.h: In constructor ?EwxMDIClientWindow::EwxMDIClientWindow(wxMDIParentFrame*, long int)?: gen/wxe_derived_dest.h:715: erreur: no matching function for call to ?wxMDIClientWindow::wxMDIClientWindow(wxMDIParentFrame*&, long int&)? /usr/local/include/wx-2.9/wx/gtk/mdi.h:142: note: candidats sont: wxMDIClientWindow::wxMDIClientWindow() /usr/local/include/wx-2.9/wx/gtk/mdi.h:140: note: wxMDIClientWindow::wxMDIClientWindow(const wxMDIClientWindow&) make[3]: *** [i686-pc-linux-gnu/wxePrintout.o] Erreur 1 Is the WX 2.9.4 incompatible with R15B03 ? ================= R16A ======================================= checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking GL/glu.h usability... yes checking GL/glu.h presence... yes checking for GL/glu.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/local/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... yes (version 2.9.4) checking for wxWidgets static library... yes checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/local/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.9.4) checking for wxWidgets static library... yes checking if wxwidgets have opengl support... *no* checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... no configure: WARNING: Can not find wx/stc/stc.h -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g -O2 -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=32 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/local/lib/wx/include/gtk2-unicode-static-2.9 -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread checking if we can link wxwidgets programs... no ================================================================= From lukas@REDACTED Mon Feb 18 09:25:33 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 18 Feb 2013 09:25:33 +0100 Subject: [erlang-bugs] binary:part/3 In-Reply-To: <5120BB37.8010205@gmail.com> References: <511F1830.603@gmail.com> <5120B800.2050602@cs.ntua.gr> <5120BB37.8010205@gmail.com> Message-ID: <5121E57D.7000700@erlang.org> Thanks for bringing this to our attention, I've updated the relevant code. Lukas On 17/02/13 12:12, Michael Truog wrote: > On 02/17/2013 02:59 AM, Kostis Sagonas wrote: >> On 02/16/2013 06:25 AM, Michael Truog wrote: >>> There is a problem with the binary:part type spec used by dialyzer (the function is a BIF), such that it thinks the Length is pos_integer() instead of integer(). A similar problem exists within the documentation here (with the Length type): >>> http://www.erlang.org/doc/man/binary.html#part-3 >> First of all, the documentation you are pointing out specifies that the third argument is "Len = integer() >= 0" so Len should be declared as non_neg_integer(), not integer(). >> >> Second, and more important, this has been corrected in R16A/R16B: >> >> https://github.com/erlang/otp/blob/master/lib/stdlib/src/binary.erl#L186 >> >> If you want a correction for a previous Erlang/OTP release, change the corresponding entry in file lib/hipe/cerl/erl_bif_types.erl >> >> Kostis >> > The documentation is wrong as you can see from the entry above: > http://www.erlang.org/doc/man/binary.html#part-2 > > The Len should be an integer() since negative Len values do work as mentioned within > PosLen = part() = {Start :: integer() >= 0, Length :: integer()} > > binary:part/3 is just providing the same parameters without the tuple wrapper for PosLen. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From dangud@REDACTED Mon Feb 18 11:01:32 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 18 Feb 2013 11:01:32 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <5120BF89.9040700@wanadoo.fr> References: <5120BF89.9040700@wanadoo.fr> Message-ID: R15B03 does not work with wxWidgets-2.9.* R16[A|B] should work and the stc header should be there, stc is included by default in wxWidgets-2.9, so I don't know why it goes wrong for you. /Dan On Sun, Feb 17, 2013 at 12:31 PM, PAILLEAU Eric wrote: > Hello, > > I'm struggling with the WX use in Erlang. > I upgraded to the last 2.9.4 wxWidgets package and compiled it, like the > otp/lib/wx/README ask to : > ./configure --with-opengl --enable-unicode --enable-graphics_ctx > --enable-gnomeprint --disable-shared > > On the same machine, R15B03 find OpenGL enabled > while R16A don't ... > > But R15B03 fail to compile on wxePrintout.cpp. > > Finally I have neither R15B03 nor R16A with WX ... > > A help would be appreciated !!!... > > ================= R15B03 ======================================= > > checking GL/gl.h usability... yes > > checking GL/gl.h presence... yes > > checking for GL/gl.h... yes > > checking for debug build of wxWidgets... checking for wx-config... > /usr/local/bin/wx-config > checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... yes > (version 2.9.4) > checking for wxWidgets static library... yes > > checking for standard build of wxWidgets... checking for wx-config... > (cached) /usr/local/bin/wx-config > checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes > (version 2.9.4) > checking for wxWidgets static library... yes > > checking if wxwidgets have opengl support... yes > > checking for GLintptr... yes > > checking for GLintptrARB... yes > > checking for GLchar... yes > > checking for GLcharARB... yes > > checking for GLhalfARB... yes > > checking for GLint64EXT... yes > > checking GLU Callbacks uses Tiger Style... no > > checking for wx/stc/stc.h... yes > > checking if we can link wxwidgets programs... yes > > everything looks fine then but *compilation failed on wxePrintout.cpp* > with : > > g++ -c -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g > -O2 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT > -I/usr/local/lib/wx/include/gtk2-unicode-static-2.9 > -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread > -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 > -DSIZEOF_VOID_P=4 -DHAVE_GL_GL_H=1 -DHAVE_GL_SUPPORT=1 -DHAVE_GLINTPTR=1 > -DHAVE_GLINTPTRARB=1 -DHAVE_GLCHAR=1 -DHAVE_GLCHARARB=1 > -DHAVE_GLHALFARB=1 -DHAVE_GLINT64EXT=1 -DHAVE_WX_STC_STC_H=1 > -I/home/eric/T?l?chargement/otp_src_R15B03/erts/emulator/beam > -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include > -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/i686-pc-linux-gnu -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/internal > -I/home/eric/T?l?chargement/otp_src_R15B03/erts/include/internal/i686-pc-linux-gnu > -I/home/eric/T?l?chargement/otp_src_R15B03/erts/emulator/sys/unix > wxePrintout.cpp -o i686-pc-linux-gnu/wxePrintout.o > > In file included from wxePrintout.cpp:24: > > gen/wxe_derived_dest.h: In constructor ?EwxPanel::EwxPanel(wxWindow*, > int, int, int, int, long int)?: > gen/wxe_derived_dest.h:48: attention : ?wxPanel::wxPanel(wxWindow*, int, > int, int, int, long int, const wxString&)? is deprecated (declared at > /usr/local/include/wx-2.9/wx/generic/panelg.h:34) > > gen/wxe_derived_dest.h: In constructor ?EwxWindowDC::EwxWindowDC()?: > > gen/wxe_derived_dest.h:97: erreur: no matching function for call to > ?wxWindowDC::wxWindowDC()? > /usr/local/include/wx-2.9/wx/dcclient.h:25: note: candidats sont: > wxWindowDC::wxWindowDC(wxDCImpl*) > /usr/local/include/wx-2.9/wx/dcclient.h:22: note: > wxWindowDC::wxWindowDC(wxWindow*) > /usr/local/include/wx-2.9/wx/dcclient.h:20: note: > wxWindowDC::wxWindowDC(const wxWindowDC&) > gen/wxe_derived_dest.h: In constructor ?EwxClientDC::EwxClientDC()?: > > gen/wxe_derived_dest.h:103: erreur: no matching function for call to > ?wxClientDC::wxClientDC()? > /usr/local/include/wx-2.9/wx/dcclient.h:41: note: candidats sont: > wxClientDC::wxClientDC(wxDCImpl*) > /usr/local/include/wx-2.9/wx/dcclient.h:38: note: > wxClientDC::wxClientDC(wxWindow*) > /usr/local/include/wx-2.9/wx/dcclient.h:36: note: > wxClientDC::wxClientDC(const wxClientDC&) > gen/wxe_derived_dest.h: In constructor ?EwxPaintDC::EwxPaintDC()?: > > gen/wxe_derived_dest.h:109: erreur: no matching function for call to > ?wxPaintDC::wxPaintDC()? > /usr/local/include/wx-2.9/wx/dcclient.h:57: note: candidats sont: > wxPaintDC::wxPaintDC(wxDCImpl*) > /usr/local/include/wx-2.9/wx/dcclient.h:54: note: > wxPaintDC::wxPaintDC(wxWindow*) > /usr/local/include/wx-2.9/wx/dcclient.h:52: note: > wxPaintDC::wxPaintDC(const wxPaintDC&) > gen/wxe_derived_dest.h: In constructor ?EwxImage::EwxImage(const > wxString&, long int, int)?: > gen/wxe_derived_dest.h:205: attention : ?wxImage::wxImage(const > wxString&, long int, int)? is deprecated (declared at > /usr/local/include/wx-2.9/wx/image.h:524) > In file included from wxePrintout.cpp:24: > gen/wxe_derived_dest.h: In constructor > ?EwxSingleChoiceDialog::EwxSingleChoiceDialog(wxWindow*, const > wxString&, const wxString&, const wxArrayString&, char**, long int, > const wxPoint&)?: > gen/wxe_derived_dest.h:580: attention : > ?wxSingleChoiceDialog::wxSingleChoiceDialog(wxWindow*, const wxString&, > const wxString&, const wxArrayString&, char**, long int, const > wxPoint&)? is deprecated (declared at > /usr/local/include/wx-2.9/wx/generic/choicdgg.h:166) > gen/wxe_derived_dest.h: In constructor > ?EwxGLCanvas::EwxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, > const wxPoint&, const wxSize&, long int, const wxString&, int*, const > wxPalette&)?: > gen/wxe_derived_dest.h:681: attention : > ?wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, const > wxPoint&, const wxSize&, long int, const wxString&, const int*, const > wxPalette&)? is deprecated (declared at > /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:65) > gen/wxe_derived_dest.h: In constructor > ?EwxGLCanvas::EwxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, > const wxPoint&, const wxSize&, long int, const wxString&, int*, const > wxPalette&)?: > gen/wxe_derived_dest.h:682: attention : > ?wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, const > wxPoint&, const wxSize&, long int, const wxString&, const int*, const > wxPalette&)? is deprecated (declared at > /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:77) > gen/wxe_derived_dest.h: In constructor > ?EwxGLCanvas::EwxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const > wxSize&, long int, const wxString&, int*, const wxPalette&)?: > gen/wxe_derived_dest.h:683: attention : > ?wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const > wxSize&, long int, const wxString&, const int*, const wxPalette&)? is > deprecated (declared at /usr/local/include/wx-2.9/wx/gtk/glcanvas.h:54) > gen/wxe_derived_dest.h: In constructor > ?EwxMDIClientWindow::EwxMDIClientWindow(wxMDIParentFrame*, long int)?: > gen/wxe_derived_dest.h:715: erreur: no matching function for call to > ?wxMDIClientWindow::wxMDIClientWindow(wxMDIParentFrame*&, long int&)? > /usr/local/include/wx-2.9/wx/gtk/mdi.h:142: note: candidats sont: > wxMDIClientWindow::wxMDIClientWindow() > /usr/local/include/wx-2.9/wx/gtk/mdi.h:140: note: > wxMDIClientWindow::wxMDIClientWindow(const wxMDIClientWindow&) > make[3]: *** [i686-pc-linux-gnu/wxePrintout.o] Erreur 1 > > Is the WX 2.9.4 incompatible with R15B03 ? > > ================= R16A ======================================= > checking GL/gl.h usability... yes > > checking GL/gl.h presence... yes > > checking for GL/gl.h... yes > > checking GL/glu.h usability... yes > > checking GL/glu.h presence... yes > > checking for GL/glu.h... yes > > checking for debug build of wxWidgets... checking for wx-config... > /usr/local/bin/wx-config > checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... yes > (version 2.9.4) > checking for wxWidgets static library... yes > > checking for standard build of wxWidgets... checking for wx-config... > (cached) /usr/local/bin/wx-config > checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes > (version 2.9.4) > checking for wxWidgets static library... yes > > checking if wxwidgets have opengl support... > *no* > > checking for GLintptr... yes > > checking for GLintptrARB... yes > > checking for GLchar... yes > > checking for GLcharARB... yes > > checking for GLhalfARB... yes > > checking for GLint64EXT... yes > > checking GLU Callbacks uses Tiger Style... no > > checking for wx/stc/stc.h... no > > configure: WARNING: Can not find wx/stc/stc.h -g -Wall -O2 -fPIC > -fomit-frame-pointer -fno-strict-aliasing -g -O2 > -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=32 -D_GNU_SOURCE > -D_THREAD_SAFE -D_REENTRANT > -I/usr/local/lib/wx/include/gtk2-unicode-static-2.9 > -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread > > > checking if we can link wxwidgets programs... no > ================================================================= > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From hans.bolinder@REDACTED Mon Feb 18 15:04:58 2013 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 18 Feb 2013 14:04:58 +0000 Subject: [erlang-bugs] edoc ignoring all docs from included .hrl In-Reply-To: <6702321.KbKQoBQZmV@csr-pc40.zib.de> References: <6702321.KbKQoBQZmV@csr-pc40.zib.de> Message-ID: <56466BD70414EA48969B4064696CF28C03D74A@ESESSMB207.ericsson.se> [Sorry for posting twice] Hi Nico, If I'm not mistaken, it's a known limitation of EDoc. See edoc(3), read_source/2, the preprocess option: Note: comments in included files will not be available to EDoc, even with this option enabled. Best regards, Hans Bolinder, Erlang/OTP, Ericsson AB From eric.pailleau@REDACTED Mon Feb 18 21:42:37 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 18 Feb 2013 21:42:37 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: References: <5120BF89.9040700@wanadoo.fr> Message-ID: <5122923D.5050408@wanadoo.fr> Hello Dan, OK , I will try with a clean install of R16B but admit it is strange that R16A does not find openGl support in the library while R15B03 does... Could not this be a configure test issue ? Thanks for your interest. Regards. From pan@REDACTED Tue Feb 19 11:01:29 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 19 Feb 2013 11:01:29 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <5122923D.5050408@wanadoo.fr> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> Message-ID: <51234D79.5040302@erlang.org> On 02/18/2013 09:42 PM, PAILLEAU Eric wrote: > Hello Dan, > OK , I will try with a clean install of R16B but admit > it is strange that R16A does not find openGl support in the > library while R15B03 does... > Could not this be a configure test issue ? > > Thanks for your interest. > Regards. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Could you post a configure log (or the relevant part thereof) from a successful R15B build (using the old wxWidgets library)? Cheers, /Patrik From eric.pailleau@REDACTED Tue Feb 19 22:08:08 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 19 Feb 2013 22:08:08 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <51234D79.5040302@erlang.org> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> Message-ID: <5123E9B8.2080608@wanadoo.fr> Hello Patrick and Dan, I uninstalled everything related to wx of my system with rpm, then I removed all manually compiled wx 2.9 libraries. Then I installed again wx 2.8.10 packages of my system with rpm. #) configure, make and install for R15B03 is OK : ==================================================================================== checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... no checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.10) checking for wxWidgets static library... no checking if wxwidgets have opengl support... yes checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... yes checking if we can link wxwidgets programs... yes ==================================================================================== But I encountered a little issue when launching observer : =ERROR REPORT==== 19-Feb-2013::21:43:20 === ERROR: Could not find 'wxe_driver.so' in: /usr/local/lib/erlang/lib/wx-1.0/priv certainly due to my former install of R16A (without wx) there was still an empty wx-1.0 directory and then erl try to use the most highest driver version. /usr/local/lib/erlang/lib/wx-0.99.1/priv/wxe_driver.so /usr/local/lib/erlang/lib/wx-0.99.2/priv/wxe_driver.so /usr/local/lib/erlang/lib/wx-1.0/priv/ <-- empty I suppose that install *should not create wx directories when wx is not enabled*, or erl to use the highest non empty priv directory of wx... By removing this directory everything fine. observer works. #) Now R16A : WX is OK but compilation fails on : obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate': /home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013: undefined reference to `fallocate64' As I told before my libc does not export fallocate64, see my former mail on such subject. =================================================================== checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking GL/glu.h usability... yes checking GL/glu.h presence... yes checking for GL/glu.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... no checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.10) checking for wxWidgets static library... no checking if wxwidgets have opengl support... yes checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking GL/glu.h usability... yes checking GL/glu.h presence... yes checking for GL/glu.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... no checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.10) checking for wxWidgets static library... no checking if wxwidgets have opengl support... yes checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... yes checking if we can link wxwidgets programs... yes checking for wx/stc/stc.h... yes checking if we can link wxwidgets programs... yes =============================================================== now R16A with : export CPPFLAGS=-D_FILE_OFFSET_BITS=32 in order to use fallocate32 ... ================================================================= checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking GL/glu.h usability... yes checking GL/glu.h presence... yes checking for GL/glu.h... yes checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... no checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.10) checking for wxWidgets static library... no checking if wxwidgets have opengl support... no checking for GLintptr... yes checking for GLintptrARB... yes checking for GLchar... yes checking for GLcharARB... yes checking for GLhalfARB... yes checking for GLint64EXT... yes checking GLU Callbacks uses Tiger Style... no checking for wx/stc/stc.h... no configure: WARNING: Can not find wx/stc/stc.h -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g -O2 -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=32 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/lib/wx/include/ -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread checking if we can link wxwidgets programs... no configure: WARNING: Can not link wx program are all developer packages installed? ================================================================= The whole R16A compile, except WX... So the problem is my _FILE_OFFSET_BITS=32 overriding ! ... Maybe you can understand where the problem is and do a fix in order to let use of 32 bit offset if needed . Best regards. From jani.j.hakala@REDACTED Wed Feb 20 02:05:43 2013 From: jani.j.hakala@REDACTED (Jani Hakala) Date: Wed, 20 Feb 2013 03:05:43 +0200 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <5123E9B8.2080608@wanadoo.fr> (PAILLEAU Eric's message of "Tue, 19 Feb 2013 22:08:08 +0100") References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> Message-ID: <874nh77q1k.fsf@pingviini.dyndns.org> PAILLEAU Eric writes: > #) Now R16A : > WX is OK but compilation fails on : > obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate': > /home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013: > undefined reference to `fallocate64' > This might be caused by an old version of libc. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568924 "fallocate64() is missing in libc 2.10" Jani Hakala From kostis@REDACTED Wed Feb 20 11:34:59 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 20 Feb 2013 12:34:59 +0200 Subject: [erlang-bugs] dialyzer typename/0 and typename/1 names are treated the same? In-Reply-To: References: Message-ID: <5124A6D3.4010908@cs.ntua.gr> On 01/22/13 05:28, ???? ????? ??? ? wrote: > > Given the sample module below, dialyzer reports that f_datum is already defined. > > This behaviour is strange to me because I'm expecting f_datum/0 and f_datum/1 to be treated as two independent types. Is this a bug or specification? For the record: we have fixed this issue and have submitted a patch that is cooking in the master-pu branch. Most likely it will end up in R16B so the typename/0 vs. typename/1 confusion will not cause dialyzer crashes like the one below: > $ dialyzer --src --plt ~/.dialyzer_plt.R15B03 src/foobar.erl > Checking whether the PLT /Users/norton/.dialyzer_plt.R15B03 is up-to-date... yes > Proceeding with analysis... > dialyzer: Analysis failed with error: > Could not scan the following file(s): [{"/Users/norton/appfoobar/src/foobar.erl", > "Type f_datum already defined\n"}] However, let me point out that the example program which was used to illustrate the problem is meaningless. > -type foo() :: foo. > -type bar(T) :: list(T). > > -type f_datum(T) :: foo() | bar(T). > -type f_datum() :: f_datum(f_datum()). In particular, the last type declaration is not well-founded: there cannot possibly be any term that belongs to this type. Although the patch we submitted for R16B will not detect such problems, bear in mind that a future version of dialyzer may scream bloody murder when given such (nonsensical) type declarations. Kostis From eric.pailleau@REDACTED Wed Feb 20 21:06:43 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 20 Feb 2013 21:06:43 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <874nh77q1k.fsf@pingviini.dyndns.org> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> Message-ID: <51252CD3.4010101@wanadoo.fr> Le 20/02/2013 02:05, Jani Hakala a ?crit : > PAILLEAU Eric writes: > >> #) Now R16A : >> WX is OK but compilation fails on : >> obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate': >> /home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013: >> undefined reference to `fallocate64' >> > This might be caused by an old version of libc. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568924 > > "fallocate64() is missing in libc 2.10" hello, yes Jani, I know this. But for some reasons I need to keep this one. So I used gcc flag overriding export CPPFLAGS=-D_FILE_OFFSET_BITS=32 I'm in a situation where I have to choose between R15B03 with WX or R16 without WX. But maybe a fix will be found soon ? :) . I suppose there is some needs on some system to limit the fallocate to a 32 bit offset ... regards From pan@REDACTED Fri Feb 22 16:48:43 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 22 Feb 2013 16:48:43 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <51252CD3.4010101@wanadoo.fr> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> <51252CD3.4010101@wanadoo.fr> Message-ID: <5127935B.1050703@erlang.org> I suppose you could try to just edit erts//config.h after you've run configure and remove #define HAVE_FALLOCATE 1, or in some other way disable fallocate. Configure should detect that it does not work, but the configure test does not do its job in this case. The Erlang system does not depend on fallocate, it just tries to use it if it exists and works. /Patrik On 02/20/2013 09:06 PM, PAILLEAU Eric wrote: > Le 20/02/2013 02:05, Jani Hakala a ?crit : >> PAILLEAU Eric writes: >> >>> #) Now R16A : >>> WX is OK but compilation fails on : >>> obj/i686-pc-linux-gnu/opt/smp/unix_efile.o: In function `efile_fallocate': >>> /home/eric/otp_src_R16A/erts/emulator/drivers/unix/unix_efile.c:1013: >>> undefined reference to `fallocate64' >>> >> This might be caused by an old version of libc. >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568924 >> >> "fallocate64() is missing in libc 2.10" > hello, > > yes Jani, I know this. > > But for some reasons I need to keep this one. > > So I used gcc flag overriding > export CPPFLAGS=-D_FILE_OFFSET_BITS=32 > > I'm in a situation where I have to choose between R15B03 with WX > or R16 without WX. > But maybe a fix will be found soon ? :) . > I suppose there is some needs on some system to limit > the fallocate to a 32 bit offset ... > regards > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Sat Feb 23 10:01:39 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 23 Feb 2013 10:01:39 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <5127935B.1050703@erlang.org> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> <51252CD3.4010101@wanadoo.fr> <5127935B.1050703@erlang.org> Message-ID: <51288573.8040802@wanadoo.fr> Le 22/02/2013 16:48, Patrik Nyblom a ?crit : > I suppose you could try to just edit erts//config.h after > you've run configure and remove #define HAVE_FALLOCATE 1, or in some > other way disable fallocate. Configure should detect that it does not > work, but the configure test does not do its job in this case. The > Erlang system does not depend on fallocate, it just tries to use it if > it exists and works. Hello Patrick, That do the trick. Thanks. I already tried to play with config.h but by setting #define HAVE_FALLOCATE 0 instead of removing the line ! I certainly crossed my eyes between #if and #if defined ! Note that HAVE_SOMETHING directives can be considered requiring boolean values 0/1 ... confusing. Thanks for the help, meanwhile the configure still not detect that the libc does not allow fallocate64 and wrongly define HAVE_FALLOCATE ... OTP team will certainly think it is not very important as far old libc will vanish one day ... Regards From pan@REDACTED Mon Feb 25 11:11:06 2013 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 25 Feb 2013 11:11:06 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <51288573.8040802@wanadoo.fr> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> <51252CD3.4010101@wanadoo.fr> <5127935B.1050703@erlang.org> <51288573.8040802@wanadoo.fr> Message-ID: <512B38BA.3030503@erlang.org> Hi! On 02/23/2013 10:01 AM, PAILLEAU Eric wrote: > Le 22/02/2013 16:48, Patrik Nyblom a ?crit : >> I suppose you could try to just edit erts//config.h after >> you've run configure and remove #define HAVE_FALLOCATE 1, or in some >> other way disable fallocate. Configure should detect that it does not >> work, but the configure test does not do its job in this case. The >> Erlang system does not depend on fallocate, it just tries to use it if >> it exists and works. > Hello Patrick, > > That do the trick. Thanks. Great! > I already tried to play with config.h but > by setting > #define HAVE_FALLOCATE 0 > instead of removing the line ! > > I certainly crossed my eyes between > #if > and > #if defined ! > > Note that HAVE_SOMETHING directives can be considered requiring boolean > values 0/1 ... confusing. > > Thanks for the help, > meanwhile the configure still not detect that the libc does not > allow fallocate64 and wrongly define HAVE_FALLOCATE ... > OTP team will certainly think it is not very important > as far old libc will vanish one day ... Could you try the attached patch and see if it correctly detects your broken fallocate? After applying the patch, you need to cd to the patched source dir root and: $ export ERL_TOP=`pwd` $ ./otp_build autoconf Then rerun configure and see what ends up in config.h. Hopefully HAVE_FALLOCATE should not be defined. > > Regards > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Cheers, /Patrik -------------- next part -------------- A non-text attachment was scrubbed... Name: fallocate_config.diff Type: text/x-patch Size: 1063 bytes Desc: not available URL: From sebastian.egner@REDACTED Mon Feb 25 13:48:54 2013 From: sebastian.egner@REDACTED (Sebastian Egner) Date: Mon, 25 Feb 2013 13:48:54 +0100 Subject: [erlang-bugs] bug (HiPE) Message-ID: <6ADF2CCA-360B-4A26-81E0-5566351D0453@entelios.com> Hello, Consider the following module: ---- a.erl ---- -module(a). -export([foo/1]). foo(X) when is_number(X) -> is_integer(X). ---- Then a:foo(0) evaluates to 'false' when compiled with HiPE: 1> c(a). 2> a:foo(0). true 3> hipe:c(a, []). 4> a:foo(0). false % *** WRONG *** The bug seems to be related to HiPE's icode type analysis: 5> hipe:c(a, [no_icode_type]). 6> a:foo(0). true For what it is worth, we have reproduced the problem on R14B04, R15B02, R15B03, R16A and OTP_R16A_RELEASE_CANDIDATE-434-gc8651ed on Debian GNU/Linux and for MacOSX (10.8.2). Kind regards, Sebastian Egner and Johannes Wei?l From kostis@REDACTED Mon Feb 25 17:10:57 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 25 Feb 2013 17:10:57 +0100 Subject: [erlang-bugs] bug (HiPE) In-Reply-To: <6ADF2CCA-360B-4A26-81E0-5566351D0453@entelios.com> References: <6ADF2CCA-360B-4A26-81E0-5566351D0453@entelios.com> Message-ID: <512B8D11.8040904@cs.ntua.gr> On 02/25/2013 01:48 PM, Sebastian Egner wrote: > Hello, > > Consider the following module: > > ---- a.erl ---- > -module(a). > -export([foo/1]). > > foo(X) when is_number(X) -> > is_integer(X). > ---- > > Then a:foo(0) evaluates to 'false' when compiled with HiPE: > > 1> c(a). > 2> a:foo(0). > true > 3> hipe:c(a, []). > 4> a:foo(0). > false % *** WRONG *** > > The bug seems to be related to HiPE's icode type analysis: > > 5> hipe:c(a, [no_icode_type]). > 6> a:foo(0). > true > > For what it is worth, we have reproduced the problem on R14B04, R15B02, R15B03, > R16A and OTP_R16A_RELEASE_CANDIDATE-434-gc8651ed on Debian GNU/Linux > and for MacOSX (10.8.2). Thanks for bringing the bug into our attention. The two line fix for it can be seen here: https://github.com/kostis/otp/commit/6907ed77452dcf409e0e3540cf7bd876e87b54b9 Although it's probably after the code freeze date, I sincerely hope that this makes it into R16B because it fixes a real bug in the integer range analysis of the native code compiler (and I cannot see how it breaks anything else). Here is the command for adding this: git fetch git://github.com/kostis/otp.git hipe-icode-range-bug Kostis From nico.kruber@REDACTED Tue Feb 26 16:12:39 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Tue, 26 Feb 2013 16:12:39 +0100 Subject: [erlang-bugs] case_clause in io:put_chars during common test run Message-ID: <6192208.abDjT9ijVO@csr-pc40.zib.de> In current Erlang master I get a case_clause in io:put_chars running Scalaris unit tests (we use common test here). The actual test suite at which this happens varies though. Here are two logs: ------------------------------- EXIT, reason {terminated, [{io,put_chars, [<0.25486.1>,unicode, [60,47,112,114,101,62,10,"
\n

\n", "Test run history\n | ","Top level test index\n\n

\n", ["
","Copyright © ", "2013"," ", "Open Telecom Platform
\n", "Updated: ","Tue Feb 26 2013 06:35:39", "","
\n
\n"], "
\n\n\n"]], []}, {test_server_ctrl,stop_minor_log_file,0, [{file,"test_server_ctrl.erl"},{line,1815}]}, {test_server_ctrl,run_test_cases_loop,5, [{file,"test_server_ctrl.erl"},{line,2741}]}, {test_server_ctrl,run_test_cases,3, [{file,"test_server_ctrl.erl"},{line,2086}]}, {test_server_ctrl,ts_tc,3, [{file,"test_server_ctrl.erl"},{line,1231}]}, {test_server_ctrl,init_tester,10, [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating /home/buildbot/scalaris-full-slave/full-dev/build/index.html... done Updating /home/buildbot/scalaris-full-slave/full-dev/build/all_runs.html... done Test run crashed! This could be an internal error - please report! {{case_clause, {value, {'EXIT', {terminated, [{io,put_chars, [<0.25486.1>,unicode, [60,47,112,114,101,62,10,"
\n

\n", "Test run history\n | ","Top level test index\n\n

\n", ["
","Copyright © ", "2013"," ", "Open Telecom Platform
\n", "Updated: ","Tue Feb 26 2013 06:35:39", "","
\n
\n"], "
\n\n\n"]], []}, {test_server_ctrl,stop_minor_log_file,0, [{file,"test_server_ctrl.erl"},{line,1815}]}, {test_server_ctrl,run_test_cases_loop,5, [{file,"test_server_ctrl.erl"},{line,2741}]}, {test_server_ctrl,run_test_cases,3, [{file,"test_server_ctrl.erl"},{line,2086}]}, {test_server_ctrl,ts_tc,3, [{file,"test_server_ctrl.erl"},{line,1231}]}, {test_server_ctrl,init_tester,10, [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} ------------------------------- EXIT, reason {terminated, [{io,put_chars, [<0.17599.5>,unicode, [60,47,112,114,101,62,10,"
\n

\n", "Test run history\n | ","Top level test index\n\n

\n", ["
","Copyright © ", "2013"," ", "Open Telecom Platform
\n", "Updated: ","Tue Feb 26 2013 14:10:02", "","
\n
\n"], "
\n\n\n"]], []}, {test_server_ctrl,stop_minor_log_file,0, [{file,"test_server_ctrl.erl"},{line,1815}]}, {test_server_ctrl,run_test_cases_loop,5, [{file,"test_server_ctrl.erl"},{line,2741}]}, {test_server_ctrl,run_test_cases,3, [{file,"test_server_ctrl.erl"},{line,2086}]}, {test_server_ctrl,ts_tc,3, [{file,"test_server_ctrl.erl"},{line,1231}]}, {test_server_ctrl,init_tester,10, [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating /home/bzckrube/scalaris/index.html... done Updating /home/bzckrube/scalaris/all_runs.html... done =ERROR REPORT==== 26-Feb-2013::14:10:02 === Error in process <0.35.0> on node 'ct@REDACTED' with exit value: {{case_clause,{value,{'EXIT',{terminated,[{io,put_chars,[<0.17599.5>,unicode, [60,47,112,114,101,62,10,"
\n

\n","Test run history\n | ","Top lev... Test run crashed! This could be an internal error - please report! {{case_clause, {value, {'EXIT', {terminated, [{io,put_chars, [<0.17599.5>,unicode, [60,47,112,114,101,62,10,"

\n

\n", "Test run history\n | ","Top level test index\n\n

\n", ["
","Copyright © ", "2013"," ", "Open Telecom Platform
\n", "Updated: ","Tue Feb 26 2013 14:10:02", "","
\n
\n"], "
\n\n\n"]], []}, {test_server_ctrl,stop_minor_log_file,0, [{file,"test_server_ctrl.erl"},{line,1815}]}, {test_server_ctrl,run_test_cases_loop,5, [{file,"test_server_ctrl.erl"},{line,2741}]}, {test_server_ctrl,run_test_cases,3, [{file,"test_server_ctrl.erl"},{line,2086}]}, {test_server_ctrl,ts_tc,3, [{file,"test_server_ctrl.erl"},{line,1231}]}, {test_server_ctrl,init_tester,10, [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} ------------------------------- to test, checkout Scalaris from http://scalaris.googlecode.com/svn/trunk/ then configure && make test Regards Nico From erlangsiri@REDACTED Tue Feb 26 16:32:52 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 26 Feb 2013 16:32:52 +0100 Subject: [erlang-bugs] case_clause in io:put_chars during common test run In-Reply-To: <6192208.abDjT9ijVO@csr-pc40.zib.de> References: <6192208.abDjT9ijVO@csr-pc40.zib.de> Message-ID: Hi Nico - it looks like the test case HTML log has been terminated somehow. I'm not sure how this could have happened, but it was terminated prior to the error printout seen below. Could you please have a look at 1. the "common test framework log" - (ctlog.html in the ct_run.xxxx directory) 2. the unexpected io log (there is a link to this from the index page where all test cases are listed - or "find unexpected_io.log.html") to see if there is anything that could give a hint? Also the test case log where this happened is interesting of course. Thanks! /siri@REDACTED 2013/2/26 Nico Kruber > In current Erlang master I get a case_clause in io:put_chars running > Scalaris > unit tests (we use common test here). The actual test suite at which this > happens varies though. > Here are two logs: > > ------------------------------- > EXIT, reason {terminated, > [{io,put_chars, > [<0.25486.1>,unicode, > [60,47,112,114,101,62,10,"
\n

/>

\n", > " "\">Test run history\n | "," "../../../index.html", > "\">Top level test index\n\n

\n", > ["
","Copyright © ", > "2013"," ", > "Open Telecom Platform
\n", > "Updated: ","Tue Feb 26 2013 06:35:39", > "","
\n
\n"], > "
\n\n\n"]], > []}, > {test_server_ctrl,stop_minor_log_file,0, > [{file,"test_server_ctrl.erl"},{line,1815}]}, > {test_server_ctrl,run_test_cases_loop,5, > [{file,"test_server_ctrl.erl"},{line,2741}]}, > {test_server_ctrl,run_test_cases,3, > [{file,"test_server_ctrl.erl"},{line,2086}]}, > {test_server_ctrl,ts_tc,3, > [{file,"test_server_ctrl.erl"},{line,1231}]}, > {test_server_ctrl,init_tester,10, > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > /home/buildbot/scalaris-full-slave/full-dev/build/index.html... done > Updating /home/buildbot/scalaris-full-slave/full-dev/build/all_runs.html... > done > Test run crashed! This could be an internal error - please report! > > {{case_clause, > {value, > {'EXIT', > {terminated, > [{io,put_chars, > [<0.25486.1>,unicode, > [60,47,112,114,101,62,10,"
\n

/>

\n", > " "\">Test run history\n | "," "../../../index.html", > "\">Top level test index\n\n

\n", > ["
","Copyright © ", > "2013"," ", > "Open Telecom Platform
\n", > "Updated: ","Tue Feb 26 2013 06:35:39", > "","
\n
\n"], > "
\n\n\n"]], > []}, > {test_server_ctrl,stop_minor_log_file,0, > [{file,"test_server_ctrl.erl"},{line,1815}]}, > {test_server_ctrl,run_test_cases_loop,5, > [{file,"test_server_ctrl.erl"},{line,2741}]}, > {test_server_ctrl,run_test_cases,3, > [{file,"test_server_ctrl.erl"},{line,2086}]}, > {test_server_ctrl,ts_tc,3, > [{file,"test_server_ctrl.erl"},{line,1231}]}, > {test_server_ctrl,init_tester,10, > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > ------------------------------- > EXIT, reason {terminated, > [{io,put_chars, > [<0.17599.5>,unicode, > [60,47,112,114,101,62,10,"
\n

/>

\n", > " "\">Test run history\n | "," "../../../index.html", > "\">Top level test index\n\n

\n", > ["
","Copyright © ", > "2013"," ", > "Open Telecom Platform
\n", > "Updated: ","Tue Feb 26 2013 14:10:02", > "","
\n
\n"], > "
\n\n\n"]], > []}, > {test_server_ctrl,stop_minor_log_file,0, > [{file,"test_server_ctrl.erl"},{line,1815}]}, > {test_server_ctrl,run_test_cases_loop,5, > [{file,"test_server_ctrl.erl"},{line,2741}]}, > {test_server_ctrl,run_test_cases,3, > [{file,"test_server_ctrl.erl"},{line,2086}]}, > {test_server_ctrl,ts_tc,3, > [{file,"test_server_ctrl.erl"},{line,1231}]}, > {test_server_ctrl,init_tester,10, > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > /home/bzckrube/scalaris/index.html... done > Updating /home/bzckrube/scalaris/all_runs.html... done > > =ERROR REPORT==== 26-Feb-2013::14:10:02 === > Error in process <0.35.0> on node 'ct@REDACTED' with exit value: > > {{case_clause,{value,{'EXIT',{terminated,[{io,put_chars,[<0.17599.5>,unicode, > [60,47,112,114,101,62,10,"
\n

\n"," href=\"","../../../all_runs.html","\">Test run history\n | "," href=\"","../../../index.html","\">Top lev... > > Test run crashed! This could be an internal error - please report! > > {{case_clause, > {value, > {'EXIT', > {terminated, > [{io,put_chars, > [<0.17599.5>,unicode, > [60,47,112,114,101,62,10,"

\n

/>

\n", > " "\">Test run history\n | "," "../../../index.html", > "\">Top level test index\n\n

\n", > ["
","Copyright © ", > "2013"," ", > "Open Telecom Platform
\n", > "Updated: ","Tue Feb 26 2013 14:10:02", > "","
\n
\n"], > "
\n\n\n"]], > []}, > {test_server_ctrl,stop_minor_log_file,0, > [{file,"test_server_ctrl.erl"},{line,1815}]}, > {test_server_ctrl,run_test_cases_loop,5, > [{file,"test_server_ctrl.erl"},{line,2741}]}, > {test_server_ctrl,run_test_cases,3, > [{file,"test_server_ctrl.erl"},{line,2086}]}, > {test_server_ctrl,ts_tc,3, > [{file,"test_server_ctrl.erl"},{line,1231}]}, > {test_server_ctrl,init_tester,10, > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > ------------------------------- > > to test, checkout Scalaris from http://scalaris.googlecode.com/svn/trunk/then > configure && make test > > Regards > Nico > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.kruber@REDACTED Tue Feb 26 17:42:51 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Tue, 26 Feb 2013 17:42:51 +0100 Subject: [erlang-bugs] case_clause in io:put_chars during common test run In-Reply-To: References: <6192208.abDjT9ijVO@csr-pc40.zib.de> Message-ID: <11948256.QAU6jFlOKO@csr-pc40.zib.de> Hi Siri, Thank you for looking into this but, I just found the code responsible for the error - on our side: At the end of each test suite (via a common test hook) we kill all processes that have not been running before the suite was started (to make sure that previous test suites don't influence new ones). This includes processes spawned without linking to the originating process - the rest is already killed by common test. There are some exceptions and apparently something changed and we killed too many processes. In this case it was the following: initial_call: {erlang,apply,2}, current_function: {prim_file,drv_get_response,1} There is no safe way to filter that process out (based on current_function or any other process_info I'm aware of) and I'd rather use some common test functionality isolating test suites but so far I'm not aware of any... -> this would be a useful extension to common test though Nico On Tuesday 26 Feb 2013 16:32:52 Siri Hansen wrote: > Hi Nico - it looks like the test case HTML log has been terminated somehow. > I'm not sure how this could have happened, but it was terminated prior to > the error printout seen below. Could you please have a look at > > 1. the "common test framework log" - (ctlog.html in the ct_run.xxxx > directory) > 2. the unexpected io log (there is a link to this from the index page where > all test cases are listed - or "find unexpected_io.log.html") > > to see if there is anything that could give a hint? > > Also the test case log where this happened is interesting of course. > > Thanks! > /siri@REDACTED > > > 2013/2/26 Nico Kruber > > > In current Erlang master I get a case_clause in io:put_chars running > > Scalaris > > unit tests (we use common test here). The actual test suite at which this > > happens varies though. > > Here are two logs: > > > > ------------------------------- > > EXIT, reason {terminated, > > > > [{io,put_chars, > > > > [<0.25486.1>,unicode, > > > > [60,47,112,114,101,62,10,"
\n

> > > />

\n", > > > > " > "\">Test run history\n | "," > "../../../index.html", > > "\">Top level test index\n\n

\n", > > ["
","Copyright © ", > > > > "2013"," ", > > "Open Telecom Platform
\n", > > "Updated: ","Tue Feb 26 2013 06:35:39", > > "","
\n
\n"], > > > > "
\n\n\n"]], > > > > []}, > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > {test_server_ctrl,run_test_cases,3, > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > {test_server_ctrl,ts_tc,3, > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > {test_server_ctrl,init_tester,10, > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > > /home/buildbot/scalaris-full-slave/full-dev/build/index.html... done > > Updating > > /home/buildbot/scalaris-full-slave/full-dev/build/all_runs.html... > > done > > Test run crashed! This could be an internal error - please report! > > > > {{case_clause, > > > > {value, > > > > {'EXIT', > > > > {terminated, > > > > [{io,put_chars, > > > > [<0.25486.1>,unicode, > > > > [60,47,112,114,101,62,10,"
\n

> > > />

\n", > > > > " > "\">Test run history\n | "," > "../../../index.html", > > "\">Top level test index\n\n

\n", > > ["
","Copyright © ", > > > > "2013"," ", > > "Open Telecom Platform
\n", > > "Updated: ","Tue Feb 26 2013 06:35:39", > > "","
\n
\n"], > > > > "
\n\n\n"]], > > > > []}, > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > {test_server_ctrl,run_test_cases,3, > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > {test_server_ctrl,ts_tc,3, > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > {test_server_ctrl,init_tester,10, > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > > > > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > > > > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > > > > ------------------------------- > > EXIT, reason {terminated, > > > > [{io,put_chars, > > > > [<0.17599.5>,unicode, > > > > [60,47,112,114,101,62,10,"
\n

> > > />

\n", > > > > " > "\">Test run history\n | "," > "../../../index.html", > > "\">Top level test index\n\n

\n", > > ["
","Copyright © ", > > > > "2013"," ", > > "Open Telecom Platform
\n", > > "Updated: ","Tue Feb 26 2013 14:10:02", > > "","
\n
\n"], > > > > "
\n\n\n"]], > > > > []}, > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > {test_server_ctrl,run_test_cases,3, > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > {test_server_ctrl,ts_tc,3, > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > {test_server_ctrl,init_tester,10, > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > > /home/bzckrube/scalaris/index.html... done > > Updating /home/bzckrube/scalaris/all_runs.html... done > > > > =ERROR REPORT==== 26-Feb-2013::14:10:02 === > > Error in process <0.35.0> on node 'ct@REDACTED' with exit value: > > > > {{case_clause,{value,{'EXIT',{terminated,[{io,put_chars,[<0.17599.5>,unico > > de, [60,47,112,114,101,62,10,"
\n

\n"," > href=\"","../../../all_runs.html","\">Test run history\n | "," > href=\"","../../../index.html","\">Top lev... > > > > Test run crashed! This could be an internal error - please report! > > > > {{case_clause, > > > > {value, > > > > {'EXIT', > > > > {terminated, > > > > [{io,put_chars, > > > > [<0.17599.5>,unicode, > > > > [60,47,112,114,101,62,10,"

\n

> > > />

\n", > > > > " > "\">Test run history\n | "," > "../../../index.html", > > "\">Top level test index\n\n

\n", > > ["
","Copyright © ", > > > > "2013"," ", > > "Open Telecom Platform
\n", > > "Updated: ","Tue Feb 26 2013 14:10:02", > > "","
\n
\n"], > > > > "
\n\n\n"]], > > > > []}, > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > {test_server_ctrl,run_test_cases,3, > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > {test_server_ctrl,ts_tc,3, > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > {test_server_ctrl,init_tester,10, > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > > > > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > > > > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > > > > ------------------------------- > > > > to test, checkout Scalaris from > > http://scalaris.googlecode.com/svn/trunk/then configure && make test > > > > Regards > > Nico From hammingweight@REDACTED Wed Feb 27 10:54:17 2013 From: hammingweight@REDACTED (Carl Meijer) Date: Wed, 27 Feb 2013 11:54:17 +0200 Subject: [erlang-bugs] Bug in http_request module when POSTing/PUTting Zero Length Data Message-ID: If I try to POST/PUT data of zero length, the http_request module removes the "Content-Length: 0" from the HTTP headers. This results in servers returning a 411 response code. The bug can be found in lines 251-258 of http_request.erl case Headers#http_request_h.'content-length' of "0" -> undefined; _ -> key_value_str(atom_to_list(Key), Headers#http_request_h.'content-length') end; I'm not sure why there is a specific test for "0". Simply replacing the above code with key_value_str(atom_to_list(Key), Headers#http_request_h.'content-length') should work. There are legitimate cases for doing a POST or PUT with no data. At the moment, I'm hacking around this bug by sending zero bytes as chunked data :) From erlangsiri@REDACTED Wed Feb 27 12:32:12 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 27 Feb 2013 12:32:12 +0100 Subject: [erlang-bugs] case_clause in io:put_chars during common test run In-Reply-To: <11948256.QAU6jFlOKO@csr-pc40.zib.de> References: <6192208.abDjT9ijVO@csr-pc40.zib.de> <11948256.QAU6jFlOKO@csr-pc40.zib.de> Message-ID: Hi Nico - nice to see that you found the problem. There have been some changes to the logging mechanism in test_server, mainly to ensure that output is sent to the correct log when running parallel test cases. The unexpected I/O log is also added - it will be used if it can not be decided which test case a particular printout is related to. However, I don't think any of these changes could cause the problem you see. The process which is killed is probably the file descriptor process for the html log for end_per_suite (as you kill processes in the post_end_per_suite hook function), and this log has always been opened at the same time as end_per_suite - i.e. way after you collect your original set of processes. I would rather think that there is something in your filtering that does no longer work - maybe the timing has changed a bit so you more often(?) get current function of the file descriptor process to be something other than file_io_server... ?? I'm just guessing now... Anyway - I think the way to filter out such processes would be to check if it is a file descriptor and possibly check if the file name starts with your test suite name (file:pid2name/2). At least that's the only thing I can come up with right now... Good luck! /siri 2013/2/26 Nico Kruber > Hi Siri, > Thank you for looking into this but, I just found the code responsible for > the > error - on our side: > > At the end of each test suite (via a common test hook) we kill all > processes > that have not been running before the suite was started (to make sure that > previous test suites don't influence new ones). This includes processes > spawned without linking to the originating process - the rest is already > killed by common test. > > There are some exceptions and apparently something changed and we killed > too > many processes. In this case it was the following: > initial_call: {erlang,apply,2}, > current_function: {prim_file,drv_get_response,1} > > There is no safe way to filter that process out (based on current_function > or > any other process_info I'm aware of) and I'd rather use some common test > functionality isolating test suites but so far I'm not aware of any... > -> this would be a useful extension to common test though > > > Nico > > On Tuesday 26 Feb 2013 16:32:52 Siri Hansen wrote: > > Hi Nico - it looks like the test case HTML log has been terminated > somehow. > > I'm not sure how this could have happened, but it was terminated prior to > > the error printout seen below. Could you please have a look at > > > > 1. the "common test framework log" - (ctlog.html in the ct_run.xxxx > > directory) > > 2. the unexpected io log (there is a link to this from the index page > where > > all test cases are listed - or "find unexpected_io.log.html") > > > > to see if there is anything that could give a hint? > > > > Also the test case log where this happened is interesting of course. > > > > Thanks! > > /siri@REDACTED > > > > > > 2013/2/26 Nico Kruber > > > > > In current Erlang master I get a case_clause in io:put_chars running > > > Scalaris > > > unit tests (we use common test here). The actual test suite at which > this > > > happens varies though. > > > Here are two logs: > > > > > > ------------------------------- > > > EXIT, reason {terminated, > > > > > > [{io,put_chars, > > > > > > [<0.25486.1>,unicode, > > > > > > [60,47,112,114,101,62,10,"
\n

> > > > > />

\n", > > > > > > " > > "\">Test run history\n | "," > > "../../../index.html", > > > "\">Top level test index\n\n

\n", > > > ["
","Copyright © > ", > > > > > > "2013"," ", > > > "Open Telecom Platform
\n", > > > "Updated: ","Tue Feb 26 2013 06:35:39", > > > "","
\n
\n"], > > > > > > "
\n\n\n"]], > > > > > > []}, > > > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > > > {test_server_ctrl,run_test_cases,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > > > {test_server_ctrl,ts_tc,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > > > {test_server_ctrl,init_tester,10, > > > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > > > /home/buildbot/scalaris-full-slave/full-dev/build/index.html... done > > > Updating > > > /home/buildbot/scalaris-full-slave/full-dev/build/all_runs.html... > > > done > > > Test run crashed! This could be an internal error - please report! > > > > > > {{case_clause, > > > > > > {value, > > > > > > {'EXIT', > > > > > > {terminated, > > > > > > [{io,put_chars, > > > > > > [<0.25486.1>,unicode, > > > > > > [60,47,112,114,101,62,10,"
\n

> > > > > />

\n", > > > > > > " > > "\">Test run history\n | "," > > "../../../index.html", > > > "\">Top level test index\n\n

\n", > > > ["
","Copyright © > ", > > > > > > "2013"," ", > > > "Open Telecom Platform
\n", > > > "Updated: ","Tue Feb 26 2013 06:35:39", > > > "","
\n
\n"], > > > > > > "
\n\n\n"]], > > > > > > []}, > > > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > > > {test_server_ctrl,run_test_cases,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > > > {test_server_ctrl,ts_tc,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > > > {test_server_ctrl,init_tester,10, > > > > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > > > > > > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > > > > > > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > > > > > > ------------------------------- > > > EXIT, reason {terminated, > > > > > > [{io,put_chars, > > > > > > [<0.17599.5>,unicode, > > > > > > [60,47,112,114,101,62,10,"
\n

> > > > > />

\n", > > > > > > " > > "\">Test run history\n | "," > > "../../../index.html", > > > "\">Top level test index\n\n

\n", > > > ["
","Copyright © > ", > > > > > > "2013"," ", > > > "Open Telecom Platform
\n", > > > "Updated: ","Tue Feb 26 2013 14:10:02", > > > "","
\n
\n"], > > > > > > "
\n\n\n"]], > > > > > > []}, > > > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > > > {test_server_ctrl,run_test_cases,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > > > {test_server_ctrl,ts_tc,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > > > {test_server_ctrl,init_tester,10, > > > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}Updating > > > /home/bzckrube/scalaris/index.html... done > > > Updating /home/bzckrube/scalaris/all_runs.html... done > > > > > > =ERROR REPORT==== 26-Feb-2013::14:10:02 === > > > Error in process <0.35.0> on node 'ct@REDACTED' with exit value: > > > > > > > {{case_clause,{value,{'EXIT',{terminated,[{io,put_chars,[<0.17599.5>,unico > > > de, [60,47,112,114,101,62,10,"
\n

\n"," > > href=\"","../../../all_runs.html","\">Test run history\n | "," > > href=\"","../../../index.html","\">Top lev... > > > > > > Test run crashed! This could be an internal error - please report! > > > > > > {{case_clause, > > > > > > {value, > > > > > > {'EXIT', > > > > > > {terminated, > > > > > > [{io,put_chars, > > > > > > [<0.17599.5>,unicode, > > > > > > [60,47,112,114,101,62,10,"

\n

> > > > > />

\n", > > > > > > " > > "\">Test run history\n | "," > > "../../../index.html", > > > "\">Top level test index\n\n

\n", > > > ["
","Copyright © > ", > > > > > > "2013"," ", > > > "Open Telecom Platform
\n", > > > "Updated: ","Tue Feb 26 2013 14:10:02", > > > "","
\n
\n"], > > > > > > "
\n\n\n"]], > > > > > > []}, > > > > > > {test_server_ctrl,stop_minor_log_file,0, > > > > > > [{file,"test_server_ctrl.erl"},{line,1815}]}, > > > > > > {test_server_ctrl,run_test_cases_loop,5, > > > > > > [{file,"test_server_ctrl.erl"},{line,2741}]}, > > > > > > {test_server_ctrl,run_test_cases,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,2086}]}, > > > > > > {test_server_ctrl,ts_tc,3, > > > > > > [{file,"test_server_ctrl.erl"},{line,1231}]}, > > > > > > {test_server_ctrl,init_tester,10, > > > > > > > [{file,"test_server_ctrl.erl"},{line,1192}]}]}}}}, > > > > > > [{ct_run,execute_all_specs,4,[{file,"ct_run.erl"},{line,433}]}, > > > > > > {ct_run,script_start1,2,[{file,"ct_run.erl"},{line,352}]}]} > > > > > > ------------------------------- > > > > > > to test, checkout Scalaris from > > > http://scalaris.googlecode.com/svn/trunk/then configure && make test > > > > > > Regards > > > Nico > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.kruber@REDACTED Wed Feb 27 16:13:02 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 27 Feb 2013 16:13:02 +0100 Subject: [erlang-bugs] case_clause in io:put_chars during common test run In-Reply-To: References: <6192208.abDjT9ijVO@csr-pc40.zib.de> <11948256.QAU6jFlOKO@csr-pc40.zib.de> Message-ID: <1545965.7EMIxWIKHt@csr-pc40.zib.de> Hi Siri, On Wednesday 27 Feb 2013 12:32:12 Siri Hansen wrote: > Hi Nico - nice to see that you found the problem. > > There have been some changes to the logging mechanism in test_server, > mainly to ensure that output is sent to the correct log when running > parallel test cases. The unexpected I/O log is also added - it will be used > if it can not be decided which test case a particular printout is related > to. However, I don't think any of these changes could cause the problem you > see. I agree - it's rather a change in the io module now starting async processes > The process which is killed is probably the file descriptor process for the > html log for end_per_suite (as you kill processes in the post_end_per_suite > hook function), and this log has always been opened at the same time as > end_per_suite - i.e. way after you collect your original set of processes. yes - the original set of processes is collected in the init_per_suite hook. > I would rather think that there is something in your filtering that does no > longer work - maybe the timing has changed a bit so you more often(?) get > current function of the file descriptor process to be something other than > file_io_server... ?? I'm just guessing now... the only exceptions I needed so far were: --------- not (InitCall =:= {test_server_sup, timetrap, 3} andalso CurFun =:= {test_server_sup, timetrap, 3}), not (InitCall =:= {test_server_sup, timetrap, 2} andalso CurFun =:= {test_server_sup, timetrap, 2}), not (InitCall =:= {test_server_gl, init, 1}), --------- > Anyway - I think the way to filter out such processes would be to check if > it is a file descriptor and possibly check if the file name starts with > your test suite name (file:pid2name/2). At least that's the only thing I > can come up with right now... that's probably a good idea - for now the check for the current_function works (also based on the code I looked at in the io and prim_file modules) but if I hit this error again, I'll probably try this approach - thanks. > Good luck! > /siri > > > 2013/2/26 Nico Kruber > > > Hi Siri, > > Thank you for looking into this but, I just found the code responsible for > > the > > error - on our side: > > > > At the end of each test suite (via a common test hook) we kill all > > processes > > that have not been running before the suite was started (to make sure that > > previous test suites don't influence new ones). This includes processes > > spawned without linking to the originating process - the rest is already > > killed by common test. > > > > There are some exceptions and apparently something changed and we killed > > too > > many processes. In this case it was the following: > > initial_call: {erlang,apply,2}, > > current_function: {prim_file,drv_get_response,1} > > > > There is no safe way to filter that process out (based on current_function > > or > > any other process_info I'm aware of) and I'd rather use some common test > > functionality isolating test suites but so far I'm not aware of any... > > -> this would be a useful extension to common test though > > > > > > Nico From gtsiour@REDACTED Wed Feb 27 17:52:53 2013 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Wed, 27 Feb 2013 18:52:53 +0200 Subject: [erlang-bugs] make -j 16 fails when ./configure --with-dynamic-trace=systemtap In-Reply-To: <510BD9E6.5040604@softlab.ntua.gr> References: <510BD9E6.5040604@softlab.ntua.gr> Message-ID: <512E39E5.7030002@softlab.ntua.gr> Hi, On 02/01/2013 05:06 PM, Yiannis Tsiouris wrote: > I'm trying to build an Erlang/OTP system configured with > --with-dynamic-trace=systemtap and it fails with: >> beam/dtrace-wrapper.h:49:27: error: erlang_dtrace.h: No such file or >> > directory > > I attach the full log for details. > > Let me state that this works well when I do a simple make (without the > -j flag). Is this a known issue? > Has anyone done anothing for this? Because it's still failing... Thanks, yiannis -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour From eric.pailleau@REDACTED Wed Feb 27 18:37:08 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 27 Feb 2013 18:37:08 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <512B38BA.3030503@erlang.org> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> <51252CD3.4010101@wanadoo.fr> <5127935B.1050703@erlang.org> <51288573.8040802@wanadoo.fr> <512B38BA.3030503@erlang.org> Message-ID: <512E4444.8030002@wanadoo.fr> > Could you try the attached patch and see if it correctly detects your > broken fallocate? After applying the patch, you need to cd to the > patched source dir root and: > $ export ERL_TOP=`pwd` > $ ./otp_build autoconf > > Then rerun configure and see what ends up in config.h. Hopefully > HAVE_FALLOCATE should not be defined. Hello Patrick sorry for the delay, I was a bit buzzy the last days. the patch works like a charm . HAVE_FALLOCATE is not anymore in the config.h after re-running configure. Merci bien ! From pan@REDACTED Thu Feb 28 10:31:16 2013 From: pan@REDACTED (Patrik Nyblom) Date: Thu, 28 Feb 2013 10:31:16 +0100 Subject: [erlang-bugs] make -j 16 fails when ./configure --with-dynamic-trace=systemtap In-Reply-To: <512E39E5.7030002@softlab.ntua.gr> References: <510BD9E6.5040604@softlab.ntua.gr> <512E39E5.7030002@softlab.ntua.gr> Message-ID: <512F23E4.3070607@erlang.org> Hi! On 02/27/2013 05:52 PM, Yiannis Tsiouris wrote: > Hi, > > On 02/01/2013 05:06 PM, Yiannis Tsiouris wrote: >> I'm trying to build an Erlang/OTP system configured with >> --with-dynamic-trace=systemtap and it fails with: >>> beam/dtrace-wrapper.h:49:27: error: erlang_dtrace.h: No such file or >> directory >> >> I attach the full log for details. >> >> Let me state that this works well when I do a simple make (without the >> -j flag). Is this a known issue? > > Has anyone done anothing for this? Because it's still failing... Nope. Wasn't severe enough to make it into the last sprint for R16B. Can you try the attached patch and see if it works for you? > > Thanks, > yiannis > Cheers, /Patrik -------------- next part -------------- A non-text attachment was scrubbed... Name: dtrace_header_dependency.diff Type: text/x-patch Size: 1008 bytes Desc: not available URL: From pan@REDACTED Thu Feb 28 10:34:30 2013 From: pan@REDACTED (Patrik Nyblom) Date: Thu, 28 Feb 2013 10:34:30 +0100 Subject: [erlang-bugs] R16A : 2 issues in WX driver compilation In-Reply-To: <512E4444.8030002@wanadoo.fr> References: <5120BF89.9040700@wanadoo.fr> <5122923D.5050408@wanadoo.fr> <51234D79.5040302@erlang.org> <5123E9B8.2080608@wanadoo.fr> <874nh77q1k.fsf@pingviini.dyndns.org> <51252CD3.4010101@wanadoo.fr> <5127935B.1050703@erlang.org> <51288573.8040802@wanadoo.fr> <512B38BA.3030503@erlang.org> <512E4444.8030002@wanadoo.fr> Message-ID: <512F24A6.2030604@erlang.org> Hi Eric! On 02/27/2013 06:37 PM, PAILLEAU Eric wrote: >> Could you try the attached patch and see if it correctly detects your >> broken fallocate? After applying the patch, you need to cd to the >> patched source dir root and: >> $ export ERL_TOP=`pwd` >> $ ./otp_build autoconf >> >> Then rerun configure and see what ends up in config.h. Hopefully >> HAVE_FALLOCATE should not be defined. > Hello Patrick > sorry for the delay, I was a bit buzzy the last days. > > the patch works like a charm . > > HAVE_FALLOCATE is not anymore in the config.h after re-running configure. Great! Will put it into nightly testing then! > Merci bien ! De rien! > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs /Patrik From gtsiour@REDACTED Thu Feb 28 16:39:22 2013 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Thu, 28 Feb 2013 17:39:22 +0200 Subject: [erlang-bugs] make -j 16 fails when ./configure --with-dynamic-trace=systemtap In-Reply-To: <512F23E4.3070607@erlang.org> References: <510BD9E6.5040604@softlab.ntua.gr> <512E39E5.7030002@softlab.ntua.gr> <512F23E4.3070607@erlang.org> Message-ID: <512F7A2A.9030008@softlab.ntua.gr> Hi Patrik, On 02/28/2013 11:31 AM, Patrik Nyblom wrote: > On 02/27/2013 05:52 PM, Yiannis Tsiouris wrote: >> On 02/01/2013 05:06 PM, Yiannis Tsiouris wrote: >>> I'm trying to build an Erlang/OTP system configured with >>> --with-dynamic-trace=systemtap and it fails with: >>>> beam/dtrace-wrapper.h:49:27: error: erlang_dtrace.h: No such file or >>> directory >>> >>> I attach the full log for details. >>> >>> Let me state that this works well when I do a simple make (without the >>> -j flag). Is this a known issue? >> >> Has anyone done anothing for this? Because it's still failing... > Nope. Wasn't severe enough to make it into the last sprint for R16B. > > Can you try the attached patch and see if it works for you? It works great! Thanks for finding some time to work on this! I suspect that this is going to be committed in the erlang/otp/master branch (and not included in R16B), right? yiannis -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour From rr@REDACTED Thu Feb 28 18:35:23 2013 From: rr@REDACTED (Rick Reed) Date: Thu, 28 Feb 2013 09:35:23 -0800 Subject: [erlang-bugs] R16A ssl (tls1.2) handshake failure on renegotiate with client cert request Message-ID: Our R16A testing uncovered a possible problem with client connections with client certificate. Our app hits an entrypoint under https://sn1.mpns.live.net which is apparently running IIS/7.5. The initial handshake succeeds and our request is sent, but this triggers a renegotiate with client certificate request. The second handshake succeeds on R15B01, but the server immediately closes the connection at some point during the second handshake on R16A. I narrowed the problem down to the commit which changed the default to TLS v1.2. Adding {versions, [tlsv1, sslv3]} to the ssl options allows the request to succeed on R16A. I suppose this could be a bug on the IIS side. I can't tell. Rr -------------- next part -------------- An HTML attachment was scrubbed... URL: