From henrik.nord@REDACTED Tue Nov 2 16:10:20 2010 From: henrik.nord@REDACTED (Henrik Nord) Date: Tue, 2 Nov 2010 15:10:20 +0000 (GMT) Subject: Crash in SSL-connection format_reply R13B04 In-Reply-To: <419167059.30041288710358879.JavaMail.root@zimbra> Message-ID: <938088055.30091288710620087.JavaMail.root@zimbra> We get a crash in ssl_connection when trying to receive an http packet: Here are some traces: call ssl_connection:format_reply({socket_options,list,http,0,0,false},{http_request,'GET',{abs_path,"/"},{1,1}}) (<0.659.0>) call ssl_connection:format_reply(list,0,{http_request,'GET',{abs_path,"/"},{1,1}}) (<0.659.0>) exception_from {ssl_connection,format_reply,3} {error,badarg} (<0.659.0>) exception_from {ssl_connection,format_reply,2} {error,badarg} *failed* ::exit:{econnrefused,[{lhttpc_client,send_request,1}, {lhttpc_client,execute,9}, {lhttpc_client,request,9}]} in function lhttpc:request/9 in call from tl_async:'-call/3-fun-0-'/3 (<0.659.0>) call ssl_connection:terminate({badarg,[{erlang,binary_to_list,[{http_request,'GET',{abs_path,"/"},{1,1}}]}, {ssl_connection,format_reply,3}, {ssl_connection,format_reply,2}, {ssl_connection,deliver_app_data,4}, {ssl_connection,application_data,2}, {ssl_connection,handle_event,3}, Relevant Code: in ssl_connection.erl format_reply(list, _, Data) -> binary_to_list(Data); format_reply(binary, 0, Data) -> Data; format_reply(binary, raw, Data) -> Data; format_reply(binary, N, Data) -> % Header mode <> = Data, [binary_to_list(Header), Rest]. Is this already fixed in R14, and/or can we get a patch for R13B04 ? Thanks From ingela@REDACTED Tue Nov 2 17:35:54 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 02 Nov 2010 17:35:54 +0100 Subject: [erlang-bugs] Crash in SSL-connection format_reply R13B04 In-Reply-To: <938088055.30091288710620087.JavaMail.root@zimbra> References: <938088055.30091288710620087.JavaMail.root@zimbra> Message-ID: <4CD03DEA.4040800@erix.ericsson.se> Hi! This is fixed in R14B. Regards Ingela Erlang/OTP -team Ericsson AB Henrik Nord wrote: > We get a crash in ssl_connection when trying to receive an http packet: > > Here are some traces: > > call ssl_connection:format_reply({socket_options,list,http,0,0,false},{http_request,'GET',{abs_path,"/"},{1,1}}) > (<0.659.0>) call ssl_connection:format_reply(list,0,{http_request,'GET',{abs_path,"/"},{1,1}}) > (<0.659.0>) exception_from {ssl_connection,format_reply,3} {error,badarg} > (<0.659.0>) exception_from {ssl_connection,format_reply,2} {error,badarg} > *failed* > ::exit:{econnrefused,[{lhttpc_client,send_request,1}, > {lhttpc_client,execute,9}, > {lhttpc_client,request,9}]} > in function lhttpc:request/9 > in call from tl_async:'-call/3-fun-0-'/3 > > > (<0.659.0>) call ssl_connection:terminate({badarg,[{erlang,binary_to_list,[{http_request,'GET',{abs_path,"/"},{1,1}}]}, > {ssl_connection,format_reply,3}, > {ssl_connection,format_reply,2}, > {ssl_connection,deliver_app_data,4}, > {ssl_connection,application_data,2}, > {ssl_connection,handle_event,3}, > > > Relevant Code: > in ssl_connection.erl > format_reply(list, _, Data) -> binary_to_list(Data); > format_reply(binary, 0, Data) -> Data; > format_reply(binary, raw, Data) -> Data; > format_reply(binary, N, Data) -> % Header mode > <> = Data, > [binary_to_list(Header), Rest]. > > > Is this already fixed in R14, and/or can we get a patch for R13B04 ? > > Thanks > From klas.johansson@REDACTED Thu Nov 4 21:52:29 2010 From: klas.johansson@REDACTED (Klas Johansson) Date: Thu, 4 Nov 2010 21:52:29 +0100 Subject: dialyzer: false function has no local return warning in R14B? Message-ID: Hi, I get a warning from dialyzer when using ets:select (test case attached), but it seems like a false warning. The fact that the key (#r.k) is a tuple rather than an atom seems important - there's no warning if it's an atom. This is on R14B (as well as earlier versions). Any ideas? Thanks, Klas -------------- next part -------------- A non-text attachment was scrubbed... Name: x.erl Type: application/octet-stream Size: 330 bytes Desc: not available URL: From kostis@REDACTED Thu Nov 4 23:22:12 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 05 Nov 2010 00:22:12 +0200 Subject: [erlang-bugs] dialyzer: false function has no local return warning in R14B? In-Reply-To: References: Message-ID: <4CD33214.1090209@cs.ntua.gr> Klas Johansson wrote: > Hi, > > I get a warning from dialyzer when using ets:select (test case > attached), but it seems like a false warning. The fact that the key > (#r.k) is a tuple rather than an atom seems important - there's no > warning if it's an atom. > > This is on R14B (as well as earlier versions). > > Any ideas? You are sort of right that this is related to the declaration of #r{} and its fields. But this is not a dialyzer bug! Instead, it's a bug in the ms_transform parse transformation which is not aware of type declarations in records and messes up things. To verify that this is the case either comment out the line: -include_lib("stdlib/include/ms_transform.hrl"). which enables the parse transform, or simply take out the type declaration from the record. Dialyzer will then like your module :-) I am leaving this to the person responsible for the ms parse transform to fix. Kostis From spawn.think@REDACTED Thu Nov 4 22:33:25 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 4 Nov 2010 22:33:25 +0100 Subject: Dialyzer expand_files bug Message-ID: Hi there, While using the dialyzer GUI, i found this bug. When you add a set of files and directories (or directories only). The dialyzer will run analysis only on one of the directories (last one processed). The reason for that is the function expand_files/3 in module dialyzer_analysis_callgraph. The function iterates over a list of files and directories, when an item is a directory, it will replace the accumulator with the list of files under that directory. It will continue that behavior so eventually the output list is the last directory processed plus files processed after it (but not other directories). Please note that the command line version doesn't get affected by that cause it does expand the directories into the list of underlying files before sending them to dialyzer_analysis_callgraph module. (so it only gets a list of files not directories). Steps to reproduce: 1- dialyzer:gui(). 2- Add dir1. 3- Add dir2. 4- Run analysis. I will submit a patch soon. -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From klas.johansson@REDACTED Thu Nov 4 23:20:59 2010 From: klas.johansson@REDACTED (Klas Johansson) Date: Thu, 4 Nov 2010 23:20:59 +0100 Subject: [erlang-bugs] dialyzer: false function has no local return warning in R14B? In-Reply-To: <4CD33214.1090209@cs.ntua.gr> References: <4CD33214.1090209@cs.ntua.gr> Message-ID: On Thu, Nov 4, 2010 at 11:22 PM, Kostis Sagonas wrote: > Klas Johansson wrote: >> >> Hi, >> >> I get a warning from dialyzer when using ets:select (test case >> attached), but it seems like a false warning. ?The fact that the key >> (#r.k) is a tuple rather than an atom seems important - there's no >> warning if it's an atom. >> >> This is on R14B (as well as earlier versions). >> >> Any ideas? > > You are sort of right that this is related to the declaration of #r{} and > its fields. But this is not a dialyzer bug! > > Instead, it's a bug in the ms_transform parse transformation which is not > aware of type declarations in records and messes up things. > > To verify that this is the case either comment out the line: > > -include_lib("stdlib/include/ms_transform.hrl"). > > which enables the parse transform, or simply take out the type declaration > from the record. ?Dialyzer will then like your module :-) > > I am leaving this to the person responsible for the ms parse transform to > fix. Ah, I see what's happening here. The parse transform generates this match specification for me: [{{r,'_'},[],['$_']}] which is the same as [{#r{_='_'},[],['$_']}] ... but this doesn't match the type specs ('_' is an atom, not a tuple): -type k() :: {term(), term()}. -record(r, {k :: k()}). Tricky. Thanks for your help. BR, Klas From per.melin@REDACTED Fri Nov 5 20:27:52 2010 From: per.melin@REDACTED (Per Melin) Date: Fri, 5 Nov 2010 20:27:52 +0100 Subject: xmerl_sax_parser:stream/2 doesn't know when to stop Message-ID: (I've only tested with R13B04 but there is nothing in the release notes that indicates that this would be different in R14B.) Without the continuation_fun option xmerl_sax_parser:stream/2 works as I would expect. But with a continuation_fun it needs to be fed at least one extra character after a complete document. 1> EventFun = fun(E, _, S) -> erlang:display(E), S end. #Fun 2> ContFun = fun(S) -> {io:get_line(">> "), S} end. #Fun 3> xmerl_sax_parser:stream("", [{event_fun, EventFun}, {continuation_fun, ContFun}]). startDocument {startElement,[],"foo",{[],"foo"},[]} {endElement,[],"foo",{[],"foo"}} >> Here it has called ContFun and is waiting for additional input. It will accept anything that is not whitespace, and then return it as a rest. Let's give it an "x". >> x endDocument {ok,undefined,"x\n"} 4> It seems this used to be a problem even without continuation_fun, but the patch described here painted over it: http://www.erlang.org/cgi-bin/ezmlm-cgi/4/46754 From fauli@REDACTED Mon Nov 8 18:05:20 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Mon, 8 Nov 2010 18:05:20 +0100 Subject: File naming Message-ID: <20101108180520.3a61b6cc@gentoo.org> Hi, the binary run_test is a badly chosen name as it is really generic and collides with a binary of the same name in the speech_dispatcher package. Is a rename to something more special like run_erlang_test possible without any sideeffects? V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lukas@REDACTED Thu Nov 11 10:21:45 2010 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 11 Nov 2010 10:21:45 +0100 Subject: [erlang-bugs] File naming In-Reply-To: <20101108180520.3a61b6cc@gentoo.org> References: <20101108180520.3a61b6cc@gentoo.org> Message-ID: <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> Hello! The run_test executable has been part of Erlang too long for it to be renamed at this point without affecting a lot of projects. It has just recently been moved into the default path of an installed Erlang system which is probably why you haven't run into this issue before. It is unfortunate that such a generic name was chosen (ct_run would have been better imo) but alas there are too many people depending on that name right now. It is also strange that a voice synthesizer software has a exectutable called run_test, but I guess they have the same reasons as we do for not wanting to change that. Lukas On Mon, 2010-11-08 at 18:05 +0100, Christian Faulhammer wrote: > Hi, > > the binary run_test is a badly chosen name as it is really generic and > collides with a binary of the same name in the speech_dispatcher > package. Is a rename to something more special like run_erlang_test > possible without any sideeffects? > > V-Li > From ft@REDACTED Thu Nov 11 10:34:00 2010 From: ft@REDACTED (Fredrik Thulin) Date: Thu, 11 Nov 2010 10:34:00 +0100 Subject: [erlang-bugs] File naming In-Reply-To: <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> References: <20101108180520.3a61b6cc@gentoo.org> <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> Message-ID: <1289468040.20911.24.camel@ft-laptop.thulin.net> On Thu, 2010-11-11 at 10:21 +0100, Lukas Larsson wrote: > Hello! > > The run_test executable has been part of Erlang too long for it to be > renamed at this point without affecting a lot of projects. It has just > recently been moved into the default path of an installed Erlang system > which is probably why you haven't run into this issue before. > > It is unfortunate that such a generic name was chosen (ct_run would have > been better imo) but alas there are too many people depending on that > name right now. Rename 'run_test' to 'ct_test', add a new 'run_test' that prints a warning and executes 'ct_test' and then remove the 'run_test' completely in the next major version or two? I agree with the OP - having a /usr/bin/run_test in my Ubuntu system that I guess runs a test suite for a voice synthesizer is... suboptimal. /Fredrik From fauli@REDACTED Thu Nov 11 14:37:26 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Thu, 11 Nov 2010 14:37:26 +0100 Subject: [erlang-bugs] File naming In-Reply-To: <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> References: <20101108180520.3a61b6cc@gentoo.org> <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> Message-ID: <20101111143726.5aacae6a@gentoo.org> Hi, Lukas Larsson : > The run_test executable has been part of Erlang too long for it to be > renamed at this point without affecting a lot of projects. It has just > recently been moved into the default path of an installed Erlang > system which is probably why you haven't run into this issue before. Ah ok, so I could just remove the symlink into /usr/bin > It is unfortunate that such a generic name was chosen (ct_run would > have been better imo) but alas there are too many people depending on > that name right now. You want to carry that cruft for the rest of Erlang's life then? Deprecate it by providing both and give a warning when called. Remove it in 15B or 16B. > It is also strange that a voice synthesizer software has a exectutable > called run_test, but I guess they have the same reasons as we do for > not wanting to change that. I discussed with the Gentoo accessibility team and they told me that run_test is on its way out of speech_dispatcher, they kindly removed it for me in a newer version. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lukas@REDACTED Thu Nov 11 18:58:04 2010 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 11 Nov 2010 18:58:04 +0100 Subject: [erlang-bugs] File naming In-Reply-To: <20101111143726.5aacae6a@gentoo.org> References: <20101108180520.3a61b6cc@gentoo.org> <1289467305.16432.14.camel@ancalagon.du.uab.ericsson.se> <20101111143726.5aacae6a@gentoo.org> Message-ID: <1289498284.16432.19.camel@ancalagon.du.uab.ericsson.se> Good point, I'll do the rename for the next minor release (R14B01) and introduce a warning into the old version when using it. It'll be a couple of years until we can remove run_test permanently, but as you say better late than never. Thanks for your input, Lukas On Thu, 2010-11-11 at 14:37 +0100, Christian Faulhammer wrote: > Hi, > > Lukas Larsson : > > The run_test executable has been part of Erlang too long for it to be > > renamed at this point without affecting a lot of projects. It has just > > recently been moved into the default path of an installed Erlang > > system which is probably why you haven't run into this issue before. > > Ah ok, so I could just remove the symlink into /usr/bin > > > It is unfortunate that such a generic name was chosen (ct_run would > > have been better imo) but alas there are too many people depending on > > that name right now. > > You want to carry that cruft for the rest of Erlang's life then? > Deprecate it by providing both and give a warning when called. Remove > it in 15B or 16B. > > > It is also strange that a voice synthesizer software has a exectutable > > called run_test, but I guess they have the same reasons as we do for > > not wanting to change that. > > I discussed with the Gentoo accessibility team and they told me that > run_test is on its way out of speech_dispatcher, they kindly removed > it for me in a newer version. > > V-Li > From lars@REDACTED Fri Nov 12 13:22:41 2010 From: lars@REDACTED (Lars Thorsen) Date: Fri, 12 Nov 2010 13:22:41 +0100 Subject: [erlang-bugs] xmerl_sax_parser:stream/2 doesn't know when to stop In-Reply-To: References: Message-ID: <4CDD3191.1090800@erix.ericsson.se> Hi, the problem you have encountered has nothing to do with the patch http://www.erlang.org/cgi-bin/ezmlm-cgi/4/46754 . The effect is also expected and I shall try to explain why. According to the XML a document is defined as: document ::= prolog element Misc* Misc ::= Comment | PI | S In the case you just give a string/binary to xmerl_sax_parser:stream/2 without a continuation function to the parser it assumes that this is all input it will get and therefor it ends parsing (there is no default continuation function). But if you have defined a continuation function it will be called after the starting string/binary is parsed to see if there is more and in your case the problem is that your function doesn't give anything that stops input. io:getline gives at least a newline even if you just hit enter which is legal input at the end of the xml document. As far as the parser knows it could come 10 newline and then a process instruction in the end. When you type an x before hitting enter you got something that's not allowed at the end of the document. The parser then returns that it got the end of a correct document and a rest value. If you have an input that consists just of one document the rest should be [] (or <<>> depending on input). This function is parsing a stream and the rest can be the start of a new document on the stream. The rest can then be used as a start of a new call to xmerl_sax_parser:stream/2. If you just want to read one document from input the continuation function must return a [] or <<>> (depending on the input) to end the document. Ex: ContFun = fun(S) -> case io:get_line(">> ") of "\n" -> {"",S} ; X -> {X,S} end end. Regards Lars Thorsen OTP Team Per Melin wrote: > (I've only tested with R13B04 but there is nothing in the release > notes that indicates that this would be different in R14B.) > > Without the continuation_fun option xmerl_sax_parser:stream/2 works as > I would expect. But with a continuation_fun it needs to be fed at > least one extra character after a complete document. > > 1> EventFun = fun(E, _, S) -> erlang:display(E), S end. > #Fun > 2> ContFun = fun(S) -> {io:get_line(">> "), S} end. > #Fun > 3> xmerl_sax_parser:stream("", [{event_fun, EventFun}, > {continuation_fun, ContFun}]). > startDocument > {startElement,[],"foo",{[],"foo"},[]} > {endElement,[],"foo",{[],"foo"}} > > Here it has called ContFun and is waiting for additional input. It > will accept anything that is not whitespace, and then return it as a > rest. Let's give it an "x". > >>> x > endDocument > {ok,undefined,"x\n"} > 4> > > It seems this used to be a problem even without continuation_fun, but > the patch described here painted over it: > http://www.erlang.org/cgi-bin/ezmlm-cgi/4/46754 > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From per.melin@REDACTED Fri Nov 12 15:07:15 2010 From: per.melin@REDACTED (Per Melin) Date: Fri, 12 Nov 2010 15:07:15 +0100 Subject: [erlang-bugs] xmerl_sax_parser:stream/2 doesn't know when to stop In-Reply-To: <4CDD3191.1090800@erix.ericsson.se> References: <4CDD3191.1090800@erix.ericsson.se> Message-ID: On Fri, Nov 12, 2010 at 1:22 PM, Lars Thorsen wrote: > The effect is also expected and I shall try to explain why. > > According to the XML a document is defined as: > > document ? ? ? ? ::= ? ?prolog element Misc* > Misc ? ? ::= ? ?Comment | PI | ?S I see I didn't do my research properly. Sorry. My problem is that I'm receiving a constant stream of (not entirely correct) XML documents over a socket. There is nothing signaling the end of a document other than the end of the root element. I can't use a throw from the event callback at the root endElement to terminate early because I then lose the rest of the unprocessed buffer, which may contain the start of the next document. But, no worries, I have a workaround. It's just not as pretty. Again, sorry for the noise. From matthias@REDACTED Thu Nov 18 16:00:04 2010 From: matthias@REDACTED (Matthias Lang) Date: Thu, 18 Nov 2010 16:00:04 +0100 Subject: reproduceable livelock (?) in R13B04 Message-ID: <20101118150004.GA11523@corelatus.se> Hi, while chasing a related bug, I found that the program below can get the beam VM into a state where it eats CPU but fails to make forward progress. I expect the program to print _something_ new at one second intervals, no matter what. Here's the program: -module(poll). -export([go/0]). go() -> file:delete("/tmp/pid"), spawn(fun() -> os:cmd("sleep 1; echo -n $? > /tmp/pid") end), wait_for_ev(), go(). wait_for_ev() -> case file:read_file("/tmp/pid") of {ok, <<>>} -> io:fwrite("race!\n"); {ok, _} -> io:fwrite("."); {error, enoent} -> wait_for_ev(); X -> io:fwrite("unexpected: ~p\n", [X]) end. On my dual-core 64-bit dual core desktop machine (SMP, the program runs as expected for a few minutes, printing various things, but then it produces no more output. 'top' says it's eating 100% CPU. That's happened within three minutes three times in a row now, i.e. it's reproduceable on that particular machine. Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Linux contorpis.corelatus.se 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux On my single-core 32-bit laptop, I can't provoke the same hang, i.e. the program runs as it should. On a single-core MIPS system, I also get the hang. On the MIPS system, strace shows me: read(8, "", 262144) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 494810314}) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 495844944}) = 0 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, events=POLLIN|POLLRDNORM}], 3, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 498175425}) = 0 read(8, "", 262144) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 501869833}) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 502907388}) = 0 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, events=POLLIN|POLLRDNORM}], 3, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 505240833}) = 0 read(8, "", 262144) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 507228944}) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 508265759}) = 0 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, events=POLLIN|POLLRDNORM}], 3, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 513049685}) = 0 read(8, "", 262144) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 515038870}) = 0 gettimeofday({1290081697, 234682}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 517034759}) = 0 poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, events=POLLIN|POLLRDNORM}], 3, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {56121, 519364425}) = 0 I can see that FD=8 is /tmp/pid. I haven't tried reproducing this on R14B (yet). I can't see anything in the R14B release notes which matches my symptoms, OTP-8773 is the closest. Is this a known problem? Matt From xramtsov@REDACTED Thu Nov 18 19:19:11 2010 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Fri, 19 Nov 2010 03:19:11 +0900 Subject: [erlang-bugs] reproduceable livelock (?) in R13B04 In-Reply-To: <20101118150004.GA11523@corelatus.se> References: <20101118150004.GA11523@corelatus.se> Message-ID: <4CE56E1F.4090207@gmail.com> 19.11.2010 00:00, Matthias Lang wrote: > Hi, > > while chasing a related bug, I found that the program below can get > the beam VM into a state where it eats CPU but fails to make forward > progress. > > I expect the program to print _something_ new at one second intervals, > no matter what. Here's the program: > > -module(poll). > -export([go/0]). > > go() -> > file:delete("/tmp/pid"), > spawn(fun() -> os:cmd("sleep 1; echo -n $?> /tmp/pid") end), > wait_for_ev(), > go(). > > wait_for_ev() -> > case file:read_file("/tmp/pid") of > {ok,<<>>} -> io:fwrite("race!\n"); > {ok, _} -> io:fwrite("."); > {error, enoent} -> wait_for_ev(); > X -> io:fwrite("unexpected: ~p\n", [X]) > end. > > On my dual-core 64-bit dual core desktop machine (SMP, the program runs as > expected for a few minutes, printing various things, but then it > produces no more output. 'top' says it's eating 100% CPU. That's happened > within three minutes three times in a row now, i.e. it's reproduceable on > that particular machine. > Can't reproduce on R14B. Your program only eats CPU and prints "race!". I was waiting for several minutes and got no any locks. I have four-core 64-bit machine. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From matthias@REDACTED Thu Nov 18 23:30:03 2010 From: matthias@REDACTED (Matthias Lang) Date: Thu, 18 Nov 2010 23:30:03 +0100 Subject: reproduceable livelock (?) in R13B04 In-Reply-To: <20101118150004.GA11523@corelatus.se> References: <20101118150004.GA11523@corelatus.se> Message-ID: <20101118223003.GA15353@corelatus.se> Hi, more information: I can't reproduce it with R14B. I went through git commits and 3e645422ef4 looked promising ("fix livelock in erts_poll_info_kp()"), but applying it to R13B04 didn't make the problem go away. Not entirely unexpected; the problem fixed isn't consistent with the strace I got on MIPS. This might be a good time to try out git-bisect. Matt ---------------------------------------------------------------------- On Thursday, November 18, Matthias Lang wrote: > Hi, > > while chasing a related bug, I found that the program below can get > the beam VM into a state where it eats CPU but fails to make forward > progress. > > I expect the program to print _something_ new at one second intervals, > no matter what. Here's the program: > > -module(poll). > -export([go/0]). > > go() -> > file:delete("/tmp/pid"), > spawn(fun() -> os:cmd("sleep 1; echo -n $? > /tmp/pid") end), > wait_for_ev(), > go(). > > wait_for_ev() -> > case file:read_file("/tmp/pid") of > {ok, <<>>} -> io:fwrite("race!\n"); > {ok, _} -> io:fwrite("."); > {error, enoent} -> wait_for_ev(); > X -> io:fwrite("unexpected: ~p\n", [X]) > end. > > On my dual-core 64-bit dual core desktop machine (SMP, the program runs as > expected for a few minutes, printing various things, but then it > produces no more output. 'top' says it's eating 100% CPU. That's happened > within three minutes three times in a row now, i.e. it's reproduceable on > that particular machine. > > Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > Linux contorpis.corelatus.se 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux > > On my single-core 32-bit laptop, I can't provoke the same hang, i.e. the > program runs as it should. > > On a single-core MIPS system, I also get the hang. On the MIPS system, > strace shows me: > > read(8, "", 262144) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 494810314}) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 495844944}) = 0 > poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, > events=POLLIN|POLLRDNORM}], 3, 0) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 498175425}) = 0 > read(8, "", 262144) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 501869833}) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 502907388}) = 0 > poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, > events=POLLIN|POLLRDNORM}], 3, 0) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 505240833}) = 0 > read(8, "", 262144) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 507228944}) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 508265759}) = 0 > poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, > events=POLLIN|POLLRDNORM}], 3, 0) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 513049685}) = 0 > read(8, "", 262144) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 515038870}) = 0 > gettimeofday({1290081697, 234682}, NULL) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 517034759}) = 0 > poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5, events=POLLIN|POLLRDNORM}, {fd=0, > events=POLLIN|POLLRDNORM}], 3, 0) = 0 > clock_gettime(CLOCK_MONOTONIC, {56121, 519364425}) = 0 > > I can see that FD=8 is /tmp/pid. > > I haven't tried reproducing this on R14B (yet). I can't see anything in > the R14B release notes which matches my symptoms, OTP-8773 is the closest. > > Is this a known problem? > > Matt From evgeny.khirin@REDACTED Fri Nov 19 09:11:40 2010 From: evgeny.khirin@REDACTED (Evgeny Khirin) Date: Fri, 19 Nov 2010 10:11:40 +0200 Subject: Wrong result of erl_compare_ext for lists Message-ID: <201011191011.40159.evgeny.khirin@erlios.com> Hi, Function erl_compare_ext of erl_interface library returns 1 instead -1 when comparing lists like [0] and [0, 1000]. The patch below fixes the problem for R12B5. Current Erlang sources still have the bug. Regards, Evgeny. === modified file 'otp_src_R12B-5/lib/erl_interface/src/legacy/erl_marshal.c' --- otp_src_R12B-5/lib/erl_interface/src/legacy/erl_marshal.c 2009-12-18 11:49:04 +0000 +++ otp_src_R12B-5/lib/erl_interface/src/legacy/erl_marshal.c 2010-11-17 13:35:52 +0000 @@ -1530,8 +1530,11 @@ min = (i < j) ? i : j; k = 0; while (1) { - if (k++ == min) - return compare_top_ext(e1 , e2); + if (k++ == min){ + if (i == j) return 0; + if (i < j) return -1; + return 1; + } if ((ret = compare_top_ext(e1 , e2)) == 0) continue; return ret; From fauli@REDACTED Wed Nov 24 02:14:56 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Wed, 24 Nov 2010 02:14:56 +0100 Subject: Runtime failures with LDFLAGS=--as-needed and wxWidgets interface Message-ID: <20101124021456.17aa141f@gentoo.org> Hi, attached patch fixes the following issue when linking with --as-needed and then trying to run the wxWidgets stuff: 1> wx:new(). =ERROR REPORT==== 24-Nov-2010::00:33:32 === WX Failed loading "wxe_driver"@"/usr/lib64/erlang/lib/wx-0.98.7/priv/x86_64-pc-linux-gnu" ** exception error: {load_driver,"undefined symbol: gluNewTess"} V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-14.2-respect_LDFLAGS-wx.patch Type: text/x-patch Size: 505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dangud@REDACTED Wed Nov 24 09:56:53 2010 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 24 Nov 2010 09:56:53 +0100 Subject: [erlang-bugs] Runtime failures with LDFLAGS=--as-needed and wxWidgets interface In-Reply-To: <20101124021456.17aa141f@gentoo.org> References: <20101124021456.17aa141f@gentoo.org> Message-ID: I have remade the opengl part of wx to a separate dll, will merge to dev any day now. So this should already be fixed in there. /Dan On Wed, Nov 24, 2010 at 2:14 AM, Christian Faulhammer wrote: > Hi, > > attached patch fixes the following issue when linking with --as-needed > and then trying to run the wxWidgets stuff: > > 1> wx:new(). > > =ERROR REPORT==== 24-Nov-2010::00:33:32 === > WX Failed loading > "wxe_driver"@"/usr/lib64/erlang/lib/wx-0.98.7/priv/x86_64-pc-linux-gnu" > ** exception error: {load_driver,"undefined symbol: gluNewTess"} > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > , #gentoo-lisp on FreeNode > > > From fauli@REDACTED Wed Nov 24 11:15:53 2010 From: fauli@REDACTED (Christian Faulhammer) Date: Wed, 24 Nov 2010 11:15:53 +0100 Subject: [erlang-bugs] Runtime failures with LDFLAGS=--as-needed and wxWidgets interface In-Reply-To: References: <20101124021456.17aa141f@gentoo.org> Message-ID: <20101124111553.2a226c53@gentoo.org> Hi, Dan Gudmundsson : > I have remade the opengl part of wx to a separate dll, will merge to > dev any day now. > So this should already be fixed in there. I don't care as long as it got fixed. Thanks. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ali.yakout@REDACTED Wed Nov 24 12:36:27 2010 From: ali.yakout@REDACTED (Ali Yakout) Date: Wed, 24 Nov 2010 12:36:27 +0100 Subject: io_lib:format probable bug Message-ID: <591FA96352AC9946A403D860A601665203E4CC9F@ESESSCMS0357.eemea.ericsson.se> Hi, I found a strange behaviour in io:format and io_lib:format, that I think is a bug. The format string works in a different way than I use to know in other languages like (C, Java, Perl, Bash...). The precision field is taken into consideration only if the field width is greater than the string length! For example: 1> io:format("-~-6.3s-~n",["Hello"]). -Hel - ok 2> io:format("-~-5.3s-~n",["Hello"]). -Hello- ok 3> io:format("-~-4.3s-~n",["Hello"]). -Hell- ok The format string in 2 and 3 ignores the precision, when I expected the result to be like: DB<1> printf("-%-6.3s-\n","Hello"); -Hel - DB<2> printf("-%-5.3s-\n","Hello"); -Hel - DB<3> printf("-%-4.3s-\n","Hello"); -Hel - I've committed a fix at https://github.com/ayakout/otp/commit/349880780455989d186f961de11d655c97da98aa Regards, Ali