From Ingela.Anderton.Andin@REDACTED Mon Oct 1 14:38:21 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Mon, 1 Oct 2012 14:38:21 +0200 Subject: [erlang-bugs] ssl:setopts hangs indefinitely In-Reply-To: <5064364F.30106@mgeb.org> References: <5064364F.30106@mgeb.org> Message-ID: <50698EBD.9080904@ericsson.com> Hi again! Michael Gebetsroither wrote: > Hello, > > We have a lot of gen_server processes locked up here and we suspect ssl:setopts is the cause. > The erlang vm version used is R15B01 from debian, and i'm currently testing R15B02 packages from esl. > (confirmed, R15B02 from esl also has this problem) > > The gen_server hang can be reproduced if we connect from a remote host over ssl to the server and remove the network > plug, during communication. Though we couldn't reproduce the error with a local client. > The hanging gen_server is the server process doing all the communication and housekeeping tasks on the socket. We think that the problem might be that a fsm-process hangs in an ongoing gen_tcp:send, when the network connection is lost, and waiting for the tcp timeout (which is long) and hence the following setopts-call will hang as the fsm-process is busy waiting for the tcp timeout. If this is the case setting the tcp-option send_timeout in ssl:connet/accept should help your cause and the timeout will be in the logical place! It would be good if you can test our theory. Regards Ingela Erlang/OTP team - Ericsson AB From sverker.eriksson@REDACTED Mon Oct 1 17:08:00 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 1 Oct 2012 17:08:00 +0200 Subject: [erlang-bugs] Crypto app and Solaris Openssl libraries In-Reply-To: <50659FCD.3020902@messagesystems.com> References: <506488FB.6090507@messagesystems.com> <50659FCD.3020902@messagesystems.com> Message-ID: <5069B1D0.20101@erix.ericsson.se> John Peacock wrote: > On 09/27/2012 01:12 PM, John Peacock wrote: > >> 2) Would you accept a patch for crypt.c to stub out the unsupported >> 0.9.7[x] methods with atom_notsup (much like the HAVE_SHA### stuff is >> currently handled)? >> > > It turns out that the only OpenSSL functionality newer than 0.9.7d that > the crypto app requires is DES_ede3_cfb_encrypt (introduced in 0.9.7e), > so the patch is quite simple (attached). That is still preliminary > because I haven't tested it across all of our platforms. And I still > cannot build Riak because at least one of the plugins (eleveldb) assumes > GNU tar without probing, and so the build breaks. I'll send that patch > to the Riak list directly... :-( > > John > Thanks for the patch, John. Looks reasonable. The comment about crypto being based on 0.9.7 is a documentation bug. I will fix that. We currently build crypto against openssl 0.9.8. /Sverker, Erlang/OTP From pan@REDACTED Tue Oct 2 16:09:59 2012 From: pan@REDACTED (pan@REDACTED) Date: Tue, 2 Oct 2012 16:09:59 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: Hi! It's not really obvious from the output, but the problem is the spec for open_port in erlang.erl. All the "will never return" things all boil down to rebar_utils:sh/2 and eventually the call to open_port. The option 'hide' is missing from the spec (which is new as it was before handled by the erl_bif_types.erl thing). I will update the spec in erlang.erl and you should be down to the single warning again in a few days! Cheers, /Patrik On Sat, 29 Sep 2012, Tuncer Ayaz wrote: > On Mon, Aug 6, 2012 at 7:43 PM, Tuncer Ayaz wrote: >> On Wed, May 16, 2012 at 4:54 PM, Tuncer Ayaz wrote: >>> On Wed, 16 May 2012 01:24:21 +0200, Tuncer Ayaz wrote: >>> >>>> On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: >>>>> On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: >>>>>> >>>>>> There seems to be a spec or Dialyzer regression in otp master >>>>>> revealed when dialyzing rebar. >>>>> >>>>> Since Tuncer did not submit all the info he has, let me add that the >>>>> behavior reported in his mail exists in the *master* branch of OTP >>>>> and *not* in the maint branch which works correctly in rebar's code >>>>> base. >>>> >>>> Forgot to test with maint, but will do. That's why it's not mentioned. >>> >>> Checked, maint results are the same as R15B01. >>> >>>>> It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's >>>>> code is the same in these two branches, but it's most likely either >>>>> due to some erroneous spec that was introduced/changed in the master >>>>> branch or a problem in rebar's code base. >>>> >>>> Upon review of the rebar code which provokes the warnings, the >>>> substantial changes to erl_bif_types seem like a good candidate for >>>> further analysis (commits bd941f50 03715097 9d870a01). Maybe the >>>> changes are not finished yet. >>>> >>>>> IMO, Tuncer should have checked the latter before filling the >>>>> report. It would be nice if he did that. >>>> >>>> That's a good idea. I will git bisect rebar. >>> >>> Done, found no erroneous commit in rebar. >> >> Any update on this bug? > > Same problem with today's OTP_R15B02-603-gcccf365. > > http://erlang.org/pipermail/erlang-bugs/2012-May/002902.html > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From pan@REDACTED Tue Oct 2 16:41:47 2012 From: pan@REDACTED (pan@REDACTED) Date: Tue, 2 Oct 2012 16:41:47 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: Nope, daily builds and jenkins show no such symptoms on any of our branches. Maybe you've got some icky erlang in your PATH? Try setting a newly built erlang first in the path (as the escript fails). The make doc should actually take care of this - if there is a built escript binary in the tree, it should be used, but it seems not for emd2exml. Will look into that. Menawhile, can you confirm that it works with a newly built P16 in your path? On Sat, 29 Sep 2012, Tuncer Ayaz wrote: > At least as far back as the R15B02 release 'make docs' > in the master branch fails: > > $ make docs > /tmp/otp/master/make/emd2exml /tmp/otp/master/HOWTO/DTRACE.md DTRACE.xml > (no error logger present) error: "Error in process <0.3.0> > with exit value: {badarg,[{init,request,1,[]},{erl_prim_loader,prim_init,0,[]}, > {erl_prim_loader,start_it,4,[]}]} > " > (no error logger present) error: "Error in process <0.2.0> > with exit value: {badarg,[{erl_prim_loader,request,1,[]}, > {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]} > " > {"init terminating in do_boot",{badarg,[{erl_prim_loader,request,1,[]}, > {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > make[3]: *** [DTRACE.xml] Error 1 > make[3]: Leaving directory `/tmp/otp/master/lib/runtime_tools/doc/src' > make[2]: *** [docs] Error 2 > make[2]: Leaving directory `/tmp/otp/master/lib/runtime_tools' > make[1]: *** [docs] Error 2 > make[1]: Leaving directory `/tmp/otp/master/lib' > make: *** [docs] Error 2 > > Can anybody else reproduce this? > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From tuncer.ayaz@REDACTED Tue Oct 2 16:57:33 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 2 Oct 2012 16:57:33 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: On Tue, Oct 2, 2012 at 4:41 PM, wrote: > Nope, daily builds and jenkins show no such symptoms on any of our > branches. > > Maybe you've got some icky erlang in your PATH? Try setting a newly > built erlang first in the path (as the escript fails). That's actually how I always build: $ export ERL_TOP=$PWD $ export PATH=$ERL_TOP/bin:$PATH $ ./otp_build setup -a $ make docs Same error if I install the build and use PATH=/bin:$PATH. > The make doc should actually take care of this - if there is a built > escript binary in the tree, it should be used, but it seems not for > emd2exml. Will look into that. Menawhile, can you confirm that it > works with a newly built P16 in your path? P16 == R16? Same error with OTP_R15B02-616-gaf9a8a0. > On Sat, 29 Sep 2012, Tuncer Ayaz wrote: > >> At least as far back as the R15B02 release 'make docs' >> in the master branch fails: >> >> $ make docs >> /tmp/otp/master/make/emd2exml /tmp/otp/master/HOWTO/DTRACE.md DTRACE.xml >> (no error logger present) error: "Error in process <0.3.0> >> with exit value: >> {badarg,[{init,request,1,[]},{erl_prim_loader,prim_init,0,[]}, >> {erl_prim_loader,start_it,4,[]}]} >> " >> (no error logger present) error: "Error in process <0.2.0> >> with exit value: {badarg,[{erl_prim_loader,request,1,[]}, >> {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]} >> " >> {"init terminating in do_boot",{badarg,[{erl_prim_loader,request,1,[]}, >> {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]}} >> >> Crash dump was written to: erl_crash.dump >> init terminating in do_boot () >> make[3]: *** [DTRACE.xml] Error 1 >> make[3]: Leaving directory `/tmp/otp/master/lib/runtime_tools/doc/src' >> make[2]: *** [docs] Error 2 >> make[2]: Leaving directory `/tmp/otp/master/lib/runtime_tools' >> make[1]: *** [docs] Error 2 >> make[1]: Leaving directory `/tmp/otp/master/lib' >> make: *** [docs] Error 2 >> >> Can anybody else reproduce this? From tuncer.ayaz@REDACTED Tue Oct 2 16:59:25 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 2 Oct 2012 16:59:25 +0200 Subject: [erlang-bugs] Spec or Dialyzer regression In-Reply-To: References: <4FB2BB82.7000303@cs.ntua.gr> Message-ID: On Tue, Oct 2, 2012 at 4:09 PM, wrote: > Hi! > > It's not really obvious from the output, but the problem is the spec for > open_port in erlang.erl. All the "will never return" things all boil down to > rebar_utils:sh/2 and eventually the call to open_port. The option 'hide' is > missing from the spec (which is new as it was before handled by the > erl_bif_types.erl thing). > > I will update the spec in erlang.erl and you should be down to the single > warning again in a few days! Thanks! > Cheers, > /Patrik > > > On Sat, 29 Sep 2012, Tuncer Ayaz wrote: > >> On Mon, Aug 6, 2012 at 7:43 PM, Tuncer Ayaz wrote: >>> >>> On Wed, May 16, 2012 at 4:54 PM, Tuncer Ayaz wrote: >>>> >>>> On Wed, 16 May 2012 01:24:21 +0200, Tuncer Ayaz wrote: >>>> >>>>> On Tue, May 15, 2012 at 10:24 PM, Kostis Sagonas wrote: >>>>>> >>>>>> On 05/15/2012 09:50 PM, Tuncer Ayaz wrote: >>>>>>> >>>>>>> >>>>>>> There seems to be a spec or Dialyzer regression in otp master >>>>>>> revealed when dialyzing rebar. >>>>>> >>>>>> >>>>>> Since Tuncer did not submit all the info he has, let me add that the >>>>>> behavior reported in his mail exists in the *master* branch of OTP >>>>>> and *not* in the maint branch which works correctly in rebar's code >>>>>> base. >>>>> >>>>> >>>>> Forgot to test with maint, but will do. That's why it's not mentioned. >>>> >>>> >>>> Checked, maint results are the same as R15B01. >>>> >>>>>> It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's >>>>>> code is the same in these two branches, but it's most likely either >>>>>> due to some erroneous spec that was introduced/changed in the master >>>>>> branch or a problem in rebar's code base. >>>>> >>>>> >>>>> Upon review of the rebar code which provokes the warnings, the >>>>> substantial changes to erl_bif_types seem like a good candidate for >>>>> further analysis (commits bd941f50 03715097 9d870a01). Maybe the >>>>> changes are not finished yet. >>>>> >>>>>> IMO, Tuncer should have checked the latter before filling the >>>>>> report. It would be nice if he did that. >>>>> >>>>> >>>>> That's a good idea. I will git bisect rebar. >>>> >>>> >>>> Done, found no erroneous commit in rebar. >>> >>> >>> Any update on this bug? >> >> >> Same problem with today's OTP_R15B02-603-gcccf365. >> >> http://erlang.org/pipermail/erlang-bugs/2012-May/002902.html From pan@REDACTED Tue Oct 2 17:14:27 2012 From: pan@REDACTED (pan@REDACTED) Date: Tue, 2 Oct 2012 17:14:27 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: OK, Also I've checked, the new erlang is in the PATH when running the, regardless of what you set before running make. So that's not the problem. I cannot in anyway reproduce this. So a few questions... What platform do you have? Can you run the command manually (emd2exml)? Is escript working for other scripts? Is the git directory clean? What are your configure parameters? On Tue, 2 Oct 2012, Tuncer Ayaz wrote: > On Tue, Oct 2, 2012 at 4:41 PM, wrote: >> Nope, daily builds and jenkins show no such symptoms on any of our >> branches. >> >> Maybe you've got some icky erlang in your PATH? Try setting a newly >> built erlang first in the path (as the escript fails). > > That's actually how I always build: > $ export ERL_TOP=$PWD > $ export PATH=$ERL_TOP/bin:$PATH > $ ./otp_build setup -a > $ make docs Did this exactly on clean master. No problems... > > Same error if I install the build and use PATH=/bin:$PATH. > >> The make doc should actually take care of this - if there is a built >> escript binary in the tree, it should be used, but it seems not for >> emd2exml. Will look into that. Menawhile, can you confirm that it >> works with a newly built P16 in your path? > > P16 == R16? Yup - P means it's not a release (preliminary), Ericsson nomenclature... > > Same error with OTP_R15B02-616-gaf9a8a0. Don't know what that means. How about clean R15B02? > >> On Sat, 29 Sep 2012, Tuncer Ayaz wrote: >> >>> At least as far back as the R15B02 release 'make docs' >>> in the master branch fails: >>> >>> $ make docs >>> /tmp/otp/master/make/emd2exml /tmp/otp/master/HOWTO/DTRACE.md DTRACE.xml >>> (no error logger present) error: "Error in process <0.3.0> >>> with exit value: >>> {badarg,[{init,request,1,[]},{erl_prim_loader,prim_init,0,[]}, >>> {erl_prim_loader,start_it,4,[]}]} >>> " >>> (no error logger present) error: "Error in process <0.2.0> >>> with exit value: {badarg,[{erl_prim_loader,request,1,[]}, >>> {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]} >>> " >>> {"init terminating in do_boot",{badarg,[{erl_prim_loader,request,1,[]}, >>> {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]}} >>> >>> Crash dump was written to: erl_crash.dump >>> init terminating in do_boot () >>> make[3]: *** [DTRACE.xml] Error 1 >>> make[3]: Leaving directory `/tmp/otp/master/lib/runtime_tools/doc/src' >>> make[2]: *** [docs] Error 2 >>> make[2]: Leaving directory `/tmp/otp/master/lib/runtime_tools' >>> make[1]: *** [docs] Error 2 >>> make[1]: Leaving directory `/tmp/otp/master/lib' >>> make: *** [docs] Error 2 >>> >>> Can anybody else reproduce this? > I cannot in anyway reproduce this. So a few questions... What platform do you have? Can you run the command manually (emd2exml)? Is escript working for other scripts? Is the git directory clean? What are your configure parameters? /Patrik From tuncer.ayaz@REDACTED Tue Oct 2 17:35:25 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 2 Oct 2012 17:35:25 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: On Tue, Oct 2, 2012 at 5:14 PM, wrote: > OK, > > Also I've checked, the new erlang is in the PATH when running the, > regardless of what you set before running make. So that's not the > problem. > > I cannot in anyway reproduce this. So a few questions... > What platform do you have? > Can you run the command manually (emd2exml)? > Is escript working for other scripts? > Is the git directory clean? > What are your configure parameters? It works if I override the escript's emu_args: https://github.com/erlang/otp/blob/1a4e8f6e5c/make/emd2exml.in#L3 %%! -smp disable $ ERL_FLAGS="-smp enable" make docs HiPE is enabled automatically and "-smp disable" has - as far back as I can remember - always provoked the following warning in the code loader for each module loaded: =INFO REPORT==== 2-Oct-2012::17:24:03 === Warning: not loading native code for module sets: it was compiled for an incompatible runtime system; please regenerate native code for this runtime system Thoughts? I'll do a rebuild to verify this is not caused by --enable-native-libs as I'm not sure that flag wasn't enabled in this build tree. From tuncer.ayaz@REDACTED Tue Oct 2 18:04:13 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 2 Oct 2012 18:04:13 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: > And you configure parameters are? Nothing explicit, just automatic flags, with the fresh rebuild. Not even --prefix. I'll mail you the configure.log files? Anything else? > On Tue, 2 Oct 2012, Tuncer Ayaz wrote: > >> On Tue, Oct 2, 2012 at 5:14 PM, wrote: >>> >>> OK, >>> >>> Also I've checked, the new erlang is in the PATH when running the, >>> regardless of what you set before running make. So that's not the >>> problem. >>> >>> I cannot in anyway reproduce this. So a few questions... >>> What platform do you have? >>> Can you run the command manually (emd2exml)? >>> Is escript working for other scripts? >>> Is the git directory clean? >>> What are your configure parameters? >> >> >> It works if I override the escript's emu_args: >> >> https://github.com/erlang/otp/blob/1a4e8f6e5c/make/emd2exml.in#L3 >> %%! -smp disable >> >> $ ERL_FLAGS="-smp enable" make docs >> >> HiPE is enabled automatically and "-smp disable" has - as far back as >> I can remember - always provoked the following warning in the code >> loader for each module loaded: >> =INFO REPORT==== 2-Oct-2012::17:24:03 === >> Warning: not loading native code for module sets: it >> was compiled for an incompatible runtime system; please regenerate >> native code for this runtime system > > > Hipe is specific per VM. -smp disable is another VM and the HiPE code does > not work for it. So if the HiPE code was not generated for non smp VM, this > is normal, I suppose. > > >> >> Thoughts? >> >> I'll do a rebuild to verify this is not caused by --enable-native-libs >> as I'm not sure that flag wasn't enabled in this build tree. >> > Nope, it's not that, tried it. > > What happens if you just do "erl -smp disable" with your newly built erlang > in the PATH? Actually, I just tried that before reading the mail and it fails: $ erl -smp disable (no error logger present) error: "Error in process <0.3.0> with exit value: {badarg,[{init,request,1,[]},{erl_prim_loader,prim_init,0,[]}, {erl_prim_loader,start_it,4,[]}]} " (no error logger present) error: "Error in process <0.2.0> with exit value: {badarg,[{erl_prim_loader,request,1,[]},{init,start_prim_loader,6,[]}, {init,do_boot,3,[]}]} " {"init terminating in do_boot",{badarg,[{erl_prim_loader,request,1,[]}, {init,start_prim_loader,6,[]},{init,do_boot,3,[]}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () From tuncer.ayaz@REDACTED Tue Oct 2 18:58:14 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 2 Oct 2012 18:58:14 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: > > > On Tue, 2 Oct 2012, Tuncer Ayaz wrote: > >> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>> >>> And you configure parameters are? >> >> >> Nothing explicit, just automatic flags, with the fresh rebuild. >> Not even --prefix. I'll mail you the configure.log files? Anything else? > > > Could you send me a complete log, from git clean -xfd to the crash? > And what Linux/Unix distro you use? > > BTW, what's in your ERL_FLAGS when you do no set it to "-smp disable", > anything fancy there? > > And the erl_crash.dump you get when running erl -smp disable might help. Mailed you all the info and files. > Sorry, I'm clueless on this one. Did it work in R15B02 plain? > Do you know a point when it stopped working? No, I haven't bisected. Want me to? From michael@REDACTED Wed Oct 3 15:11:42 2012 From: michael@REDACTED (Michael Gebetsroither) Date: Wed, 03 Oct 2012 15:11:42 +0200 Subject: [erlang-bugs] ssl:setopts hangs indefinitely In-Reply-To: <50698EBD.9080904@ericsson.com> References: <5064364F.30106@mgeb.org> <50698EBD.9080904@ericsson.com> Message-ID: <506C398E.80506@mgeb.org> On 2012-10-01 14:38, Ingela Anderton Andin wrote: Hi, >> We have a lot of gen_server processes locked up here and we suspect ssl:setopts is the cause. >> The erlang vm version used is R15B01 from debian, and i'm currently testing R15B02 packages from esl. >> (confirmed, R15B02 from esl also has this problem) >> >> The gen_server hang can be reproduced if we connect from a remote host over ssl to the server and remove the network >> plug, during communication. Though we couldn't reproduce the error with a local client. >> The hanging gen_server is the server process doing all the communication and housekeeping tasks on the socket. > > We think that the problem might be that a fsm-process hangs in an ongoing gen_tcp:send, when the network connection is > lost, and waiting for the tcp timeout (which is long) and hence the following setopts-call will hang as the fsm-process > is busy waiting for the tcp timeout. If this is the case setting the tcp-option send_timeout in ssl:connet/accept should > help your cause and the timeout will be in the logical place! It would be good if you can test our theory. Thx for your thoughts about the problem! I'll add logging and see if the processes still get killed by our manual ssl:setopts timeout or if the tcp connection of ssl is teared down by the timeout. Michael Gebetsroither From tuncer.ayaz@REDACTED Wed Oct 3 21:26:42 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 3 Oct 2012 21:26:42 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: > On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >> >> >> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >> >>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>> >>>> And you configure parameters are? >>> >>> >>> Nothing explicit, just automatic flags, with the fresh rebuild. >>> Not even --prefix. I'll mail you the configure.log files? Anything else? >> >> >> Could you send me a complete log, from git clean -xfd to the crash? >> And what Linux/Unix distro you use? >> >> BTW, what's in your ERL_FLAGS when you do no set it to "-smp disable", >> anything fancy there? >> >> And the erl_crash.dump you get when running erl -smp disable might help. > > Mailed you all the info and files. > >> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >> Do you know a point when it stopped working? > > No, I haven't bisected. Want me to? result of git-bisect started with OTP_R15B02=good and g3ba23ad=bad: e76262ea8ac6986a4 is the first bad commit From essen@REDACTED Thu Oct 4 10:55:47 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 04 Oct 2012 10:55:47 +0200 Subject: [erlang-bugs] Different Dialyzer results for no_return() and none() Message-ID: <506D4F13.3070209@ninenines.eu> Hey, Not sure it still happens in HEAD, I only have R15B01 handy at the moment. I found a small issue: none() doesn't behave the same as no_return(). I am implementing a special process as described by this: http://www.erlang.org/doc/design_principles/spec_proc.html I include "-Werror_handling" in my Dialyzer options. I of course get a warning about system_terminate exiting. These two specs don't behave the same: -spec system_terminate(_, _, _, _) -> no_return(). -spec system_terminate(_, _, _, _) -> none(). Only the first suppresses the warning. Typespecs documentation (http://www.erlang.org/doc/reference_manual/typespec.html) tells me no_return() stands for none() though. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From pan@REDACTED Fri Oct 5 16:16:18 2012 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 5 Oct 2012 16:16:18 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: Message-ID: <506EEBB2.1030703@erlang.org> Right, found it, a C statement with "undefined behaviour" exposed by gcc 4.7. There is actually a warning from gcc. Try this patch to master: ---------------------- diff --git a/erts/emulator/beam/erl_message.c b/erts/emulator/beam/erl_message.c index e397f07..d5b7d01 100644 --- a/erts/emulator/beam/erl_message.c +++ b/erts/emulator/beam/erl_message.c @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, } BM_SWAP_TIMER(send,system); #endif /* #ifndef ERTS_SMP */ - return; } return res; } --------------- Cheers, /Patrik On 10/03/2012 09:26 PM, Tuncer Ayaz wrote: > On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: >> On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >>> >>> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >>> >>>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>>> And you configure parameters are? >>>> >>>> Nothing explicit, just automatic flags, with the fresh rebuild. >>>> Not even --prefix. I'll mail you the configure.log files? Anything else? >>> >>> Could you send me a complete log, from git clean -xfd to the crash? >>> And what Linux/Unix distro you use? >>> >>> BTW, what's in your ERL_FLAGS when you do no set it to "-smp disable", >>> anything fancy there? >>> >>> And the erl_crash.dump you get when running erl -smp disable might help. >> Mailed you all the info and files. >> >>> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >>> Do you know a point when it stopped working? >> No, I haven't bisected. Want me to? > result of git-bisect started with OTP_R15B02=good and g3ba23ad=bad: > e76262ea8ac6986a4 is the first bad commit From tuncer.ayaz@REDACTED Fri Oct 5 16:40:18 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 5 Oct 2012 16:40:18 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: <506EEBB2.1030703@erlang.org> References: <506EEBB2.1030703@erlang.org> Message-ID: On Fri, Oct 5, 2012 at 4:16 PM, Patrik Nyblom wrote: > Right, found it, a C statement with "undefined behaviour" exposed by gcc > 4.7. There is actually a warning from gcc. Try this patch to master: > ---------------------- > diff --git a/erts/emulator/beam/erl_message.c > b/erts/emulator/beam/erl_message.c > index e397f07..d5b7d01 100644 > --- a/erts/emulator/beam/erl_message.c > +++ b/erts/emulator/beam/erl_message.c > @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, > } > BM_SWAP_TIMER(send,system); > #endif /* #ifndef ERTS_SMP */ > - return; > } > return res; > } > --------------- Thanks, that's it. > Cheers, > /Patrik > > On 10/03/2012 09:26 PM, Tuncer Ayaz wrote: >> >> On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: >>> >>> On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >>>> >>>> >>>> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >>>> >>>>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>>>> >>>>>> And you configure parameters are? >>>>> >>>>> >>>>> Nothing explicit, just automatic flags, with the fresh rebuild. >>>>> Not even --prefix. I'll mail you the configure.log files? Anything >>>>> else? >>>> >>>> >>>> Could you send me a complete log, from git clean -xfd to the crash? >>>> And what Linux/Unix distro you use? >>>> >>>> BTW, what's in your ERL_FLAGS when you do no set it to "-smp disable", >>>> anything fancy there? >>>> >>>> And the erl_crash.dump you get when running erl -smp disable might help. >>> >>> Mailed you all the info and files. >>> >>>> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >>>> Do you know a point when it stopped working? >>> >>> No, I haven't bisected. Want me to? >> >> result of git-bisect started with OTP_R15B02=good and g3ba23ad=bad: >> e76262ea8ac6986a4 is the first bad commit > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From pan@REDACTED Fri Oct 5 17:48:09 2012 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 5 Oct 2012 17:48:09 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: <506EEBB2.1030703@erlang.org> Message-ID: <506F0139.3030202@erlang.org> On 10/05/2012 04:40 PM, Tuncer Ayaz wrote: > On Fri, Oct 5, 2012 at 4:16 PM, Patrik Nyblom wrote: >> Right, found it, a C statement with "undefined behaviour" exposed by gcc >> 4.7. There is actually a warning from gcc. Try this patch to master: >> ---------------------- >> diff --git a/erts/emulator/beam/erl_message.c >> b/erts/emulator/beam/erl_message.c >> index e397f07..d5b7d01 100644 >> --- a/erts/emulator/beam/erl_message.c >> +++ b/erts/emulator/beam/erl_message.c >> @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, >> } >> BM_SWAP_TIMER(send,system); >> #endif /* #ifndef ERTS_SMP */ >> - return; >> } >> return res; >> } >> --------------- > Thanks, that's it. Great! Thanks for the help with the huge bisect and the error report! Fix will appear in master in a couple of days (hopefully :))! Cheers, /Patrik > >> Cheers, >> /Patrik >> >> On 10/03/2012 09:26 PM, Tuncer Ayaz wrote: >>> On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: >>>> On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >>>>> >>>>> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >>>>> >>>>>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>>>>> And you configure parameters are? >>>>>> >>>>>> Nothing explicit, just automatic flags, with the fresh rebuild. >>>>>> Not even --prefix. I'll mail you the configure.log files? Anything >>>>>> else? >>>>> >>>>> Could you send me a complete log, from git clean -xfd to the crash? >>>>> And what Linux/Unix distro you use? >>>>> >>>>> BTW, what's in your ERL_FLAGS when you do no set it to "-smp disable", >>>>> anything fancy there? >>>>> >>>>> And the erl_crash.dump you get when running erl -smp disable might help. >>>> Mailed you all the info and files. >>>> >>>>> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >>>>> Do you know a point when it stopped working? >>>> No, I haven't bisected. Want me to? >>> result of git-bisect started with OTP_R15B02=good and g3ba23ad=bad: >>> e76262ea8ac6986a4 is the first bad commit >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs From tuncer.ayaz@REDACTED Fri Oct 5 21:59:13 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 5 Oct 2012 21:59:13 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: <506F0139.3030202@erlang.org> References: <506EEBB2.1030703@erlang.org> <506F0139.3030202@erlang.org> Message-ID: On Fri, Oct 5, 2012 at 5:48 PM, Patrik Nyblom wrote: > On 10/05/2012 04:40 PM, Tuncer Ayaz wrote: >> >> On Fri, Oct 5, 2012 at 4:16 PM, Patrik Nyblom wrote: >>> >>> Right, found it, a C statement with "undefined behaviour" exposed >>> by gcc 4.7. There is actually a warning from gcc. Try this patch >>> to master: >>> ---------------------- >>> diff --git a/erts/emulator/beam/erl_message.c >>> b/erts/emulator/beam/erl_message.c >>> index e397f07..d5b7d01 100644 >>> --- a/erts/emulator/beam/erl_message.c >>> +++ b/erts/emulator/beam/erl_message.c >>> @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, >>> } >>> BM_SWAP_TIMER(send,system); >>> #endif /* #ifndef ERTS_SMP */ >>> - return; >>> } >>> return res; >>> } >>> --------------- >> >> Thanks, that's it. > > > Great! Thanks for the help with the huge bisect and the error > report! > > Fix will appear in master in a couple of days (hopefully :))! clang-3.2-git treats this as an error beam/erl_message.c:1099:2: error: non-void function 'erts_send_message' should return a value [-Wreturn-type] while for gcc 4.7.1 it's a warning beam/erl_message.c:1099:2: warning: 'return' with no value, in function returning non-void [-Wreturn-type] I don't have a gcc-4.8-git build to check with, but we can treat this warning as an error with gcc-4.7: $ CFLAGS="-Werror=return-type" ./otp_build setup -a [...] beam/erl_message.c:1099:2: error: 'return' with no value, in function returning non-void [-Werror=return-type] cc1: some warnings being treated as errors http://gcc.gnu.org/wiki/ClangDiagnosticsComparison > Cheers, > /Patrik >> >> >>> Cheers, >>> /Patrik >>> >>> On 10/03/2012 09:26 PM, Tuncer Ayaz wrote: >>>> >>>> On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: >>>>> >>>>> On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >>>>>> >>>>>> >>>>>> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >>>>>> >>>>>>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>>>>>> >>>>>>>> And you configure parameters are? >>>>>>> >>>>>>> >>>>>>> Nothing explicit, just automatic flags, with the fresh >>>>>>> rebuild. Not even --prefix. I'll mail you the configure.log >>>>>>> files? Anything else? >>>>>> >>>>>> >>>>>> Could you send me a complete log, from git clean -xfd to the >>>>>> crash? And what Linux/Unix distro you use? >>>>>> >>>>>> BTW, what's in your ERL_FLAGS when you do no set it to "-smp >>>>>> disable", anything fancy there? >>>>>> >>>>>> And the erl_crash.dump you get when running erl -smp disable >>>>>> might help. >>>>> >>>>> Mailed you all the info and files. >>>>> >>>>>> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >>>>>> Do you know a point when it stopped working? >>>>> >>>>> No, I haven't bisected. Want me to? >>>> >>>> result of git-bisect started with OTP_R15B02=good and >>>> g3ba23ad=bad: e76262ea8ac6986a4 is the first bad commit From hans.bolinder@REDACTED Mon Oct 8 14:07:58 2012 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 8 Oct 2012 14:07:58 +0200 Subject: [erlang-bugs] dialyzer warning - The call erl_ddll:format_error(Err::{'open_error', _}) will never return ... In-Reply-To: <915B8BA1-DFA2-41E7-B663-61EAD8282329@lovely.email.ne.jp> References: <915B8BA1-DFA2-41E7-B663-61EAD8282329@lovely.email.ne.jp> Message-ID: <4BDFBBFD8448514CAD010A2DF1F8AC6720A68D13B4@ESESSCMS0356.eemea.ericsson.se> Hi, [Joseph Wayne Norton:] > The function specification for the erl_ddll:format_error builtin seems to be incomplete. Thanks for the bug report! There will be a fix in an upcoming release. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From pan@REDACTED Wed Oct 10 16:45:21 2012 From: pan@REDACTED (Patrik Nyblom) Date: Wed, 10 Oct 2012 16:45:21 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: References: <506EEBB2.1030703@erlang.org> <506F0139.3030202@erlang.org> Message-ID: <50758A01.70205@erlang.org> On 10/05/2012 09:59 PM, Tuncer Ayaz wrote: > On Fri, Oct 5, 2012 at 5:48 PM, Patrik Nyblom wrote: >> On 10/05/2012 04:40 PM, Tuncer Ayaz wrote: >>> On Fri, Oct 5, 2012 at 4:16 PM, Patrik Nyblom wrote: >>>> Right, found it, a C statement with "undefined behaviour" exposed >>>> by gcc 4.7. There is actually a warning from gcc. Try this patch >>>> to master: >>>> ---------------------- >>>> diff --git a/erts/emulator/beam/erl_message.c >>>> b/erts/emulator/beam/erl_message.c >>>> index e397f07..d5b7d01 100644 >>>> --- a/erts/emulator/beam/erl_message.c >>>> +++ b/erts/emulator/beam/erl_message.c >>>> @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, >>>> } >>>> BM_SWAP_TIMER(send,system); >>>> #endif /* #ifndef ERTS_SMP */ >>>> - return; >>>> } >>>> return res; >>>> } >>>> --------------- >>> Thanks, that's it. >> >> Great! Thanks for the help with the huge bisect and the error >> report! >> >> Fix will appear in master in a couple of days (hopefully :))! > clang-3.2-git treats this as an error > > beam/erl_message.c:1099:2: error: non-void function 'erts_send_message' > should return a value [-Wreturn-type] > > while for gcc 4.7.1 it's a warning > > beam/erl_message.c:1099:2: warning: 'return' with no value, in > function returning non-void [-Wreturn-type] > > I don't have a gcc-4.8-git build to check with, but we can treat this > warning as an error with gcc-4.7: > > $ CFLAGS="-Werror=return-type" ./otp_build setup -a > [...] > beam/erl_message.c:1099:2: error: 'return' with no value, in function > returning non-void [-Werror=return-type] > cc1: some warnings being treated as errors Could you do a patch to configure that enables this if using gcc? That would be really nice! Cheers, /Patrik > > http://gcc.gnu.org/wiki/ClangDiagnosticsComparison > >> Cheers, >> /Patrik >>> >>>> Cheers, >>>> /Patrik >>>> >>>> On 10/03/2012 09:26 PM, Tuncer Ayaz wrote: >>>>> On Tue, Oct 2, 2012 at 6:58 PM, Tuncer Ayaz wrote: >>>>>> On Tue, Oct 2, 2012 at 6:24 PM, Patrik Nyblom wrote: >>>>>>> >>>>>>> On Tue, 2 Oct 2012, Tuncer Ayaz wrote: >>>>>>> >>>>>>>> On Tue, Oct 2, 2012 at 5:59 PM, Patrik Nyblom wrote: >>>>>>>>> And you configure parameters are? >>>>>>>> >>>>>>>> Nothing explicit, just automatic flags, with the fresh >>>>>>>> rebuild. Not even --prefix. I'll mail you the configure.log >>>>>>>> files? Anything else? >>>>>>> >>>>>>> Could you send me a complete log, from git clean -xfd to the >>>>>>> crash? And what Linux/Unix distro you use? >>>>>>> >>>>>>> BTW, what's in your ERL_FLAGS when you do no set it to "-smp >>>>>>> disable", anything fancy there? >>>>>>> >>>>>>> And the erl_crash.dump you get when running erl -smp disable >>>>>>> might help. >>>>>> Mailed you all the info and files. >>>>>> >>>>>>> Sorry, I'm clueless on this one. Did it work in R15B02 plain? >>>>>>> Do you know a point when it stopped working? >>>>>> No, I haven't bisected. Want me to? >>>>> result of git-bisect started with OTP_R15B02=good and >>>>> g3ba23ad=bad: e76262ea8ac6986a4 is the first bad commit From tuncer.ayaz@REDACTED Wed Oct 10 20:41:19 2012 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 10 Oct 2012 20:41:19 +0200 Subject: [erlang-bugs] make docs fails in git master In-Reply-To: <50758A01.70205@erlang.org> References: <506EEBB2.1030703@erlang.org> <506F0139.3030202@erlang.org> <50758A01.70205@erlang.org> Message-ID: On Wed, Oct 10, 2012 at 4:45 PM, Patrik Nyblom wrote: > On 10/05/2012 09:59 PM, Tuncer Ayaz wrote: >> >> On Fri, Oct 5, 2012 at 5:48 PM, Patrik Nyblom wrote: >>> >>> On 10/05/2012 04:40 PM, Tuncer Ayaz wrote: >>>> >>>> On Fri, Oct 5, 2012 at 4:16 PM, Patrik Nyblom wrote: >>>>> >>>>> Right, found it, a C statement with "undefined behaviour" exposed >>>>> by gcc 4.7. There is actually a warning from gcc. Try this patch >>>>> to master: >>>>> ---------------------- >>>>> diff --git a/erts/emulator/beam/erl_message.c >>>>> b/erts/emulator/beam/erl_message.c >>>>> index e397f07..d5b7d01 100644 >>>>> --- a/erts/emulator/beam/erl_message.c >>>>> +++ b/erts/emulator/beam/erl_message.c >>>>> @@ -1096,7 +1096,6 @@ erts_send_message(Process* sender, >>>>> } >>>>> BM_SWAP_TIMER(send,system); >>>>> #endif /* #ifndef ERTS_SMP */ >>>>> - return; >>>>> } >>>>> return res; >>>>> } >>>>> --------------- >>>> >>>> Thanks, that's it. >>> >>> >>> Great! Thanks for the help with the huge bisect and the error >>> report! >>> >>> Fix will appear in master in a couple of days (hopefully :))! >> >> clang-3.2-git treats this as an error >> >> beam/erl_message.c:1099:2: error: non-void function 'erts_send_message' >> should return a value [-Wreturn-type] >> >> while for gcc 4.7.1 it's a warning >> >> beam/erl_message.c:1099:2: warning: 'return' with no value, in >> function returning non-void [-Wreturn-type] >> >> I don't have a gcc-4.8-git build to check with, but we can treat this >> warning as an error with gcc-4.7: >> >> $ CFLAGS="-Werror=return-type" ./otp_build setup -a >> [...] >> beam/erl_message.c:1099:2: error: 'return' with no value, in function >> returning non-void [-Werror=return-type] >> cc1: some warnings being treated as errors > > Could you do a patch to configure that enables this if using gcc? > That would be really nice! Sure, I'll submit a patch. From be.dmitry@REDACTED Thu Oct 11 23:06:52 2012 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Fri, 12 Oct 2012 01:06:52 +0400 Subject: [erlang-bugs] prim_inet:close/1 race condition Message-ID: Some days ago we found that we have thousands of leaked sockets in our project. These sockets were ports with state like this: [{name,"tcp_inet"}, {links,[]}, {connected,<0.54.0>},...] We made investigation and found the cause of the leaks. We have inets option {exit_on_close, false} to read statistics from the socket after it was closed by the peer. Process that controls the socket does not trap_exit and is linked with some another process. At the end of connection controller calls gen_tcp:close/1 and sometimes the linked process dies at that the same moment. We found out that the gen_tcp:close/1 calls prim_inet:close/1, the first action of which is unlink from controlling process. So, when controller is unlinked from the port and is killed by the signal, port stays in the system because of exit_on_close feature. I've made a module that sometimes may reveal the problem. https://gist.github.com/3875485 On my system I half of dozen calls to close_bug:start(1000) does find such leaked ports. I haven't found the right solution for the problem yet, so no patches at the moment. Thank you for your attention. -- Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Oct 12 01:03:16 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 11 Oct 2012 19:03:16 -0400 Subject: [erlang-bugs] prim_inet:close/1 race condition In-Reply-To: References: Message-ID: <50775034.1060503@ferd.ca> I've had the same problem in my lhttpc fork, and after some concerted work with a few users of the fork at OpenX, we made the following fix in the lhttpc wrapper (https://github.com/ferd/lhttpc/blob/master/src/lhttpc_sock.erl#L172): Flag = process_flag(trap_exit, true), Res = gen_tcp:close(Socket), receive {'EXIT',_Pid,timeout} -> exit(timeout) after 0 -> process_flag(trap_exit, Flag), Res end We're able to do it because we expect, 99.999% of the time that the race condition will happen with a specific exit message we chose ourselves in that given context (we control the process where this happens 100%). I can't think of a universally good way to fix it in Erlang itself, where you'd risk eating up messages you're not supposed to handle, though. On 12-10-11 5:06 PM, Dmitry Belyaev wrote: > Some days ago we found that we have thousands of leaked sockets in our > project. > > These sockets were ports with state like this: > [{name,"tcp_inet"}, > {links,[]}, > {connected,<0.54.0>},...] > > We made investigation and found the cause of the leaks. > > We have inets option {exit_on_close, false} to read statistics from > the socket after it was closed by the peer. Process that controls the > socket does not trap_exit and is linked with some another process. > At the end of connection controller calls gen_tcp:close/1 and > sometimes the linked process dies at that the same moment. We found > out that the gen_tcp:close/1 calls prim_inet:close/1, the first action > of which is unlink from controlling process. So, when controller is > unlinked from the port and is killed by the signal, port stays in the > system because of exit_on_close feature. > > I've made a module that sometimes may reveal the problem. > https://gist.github.com/3875485 > On my system I half of dozen calls to close_bug:start(1000) does find > such leaked ports. > I haven't found the right solution for the problem yet, so no patches > at the moment. > > Thank you for your attention. > > -- > Dmitry Belyaev > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas@REDACTED Sat Oct 13 22:31:03 2012 From: thomas@REDACTED (Thomas Steen Rasmussen) Date: Sat, 13 Oct 2012 22:31:03 +0200 Subject: [erlang-bugs] epmd assumes 127.0.0.1 is always available Message-ID: <5079CF87.8030505@gibfest.dk> Hello guys, I am using erlang in a FreeBSD jail for RabbitMQ and I've hit what I belive is a wrong assumption in epmd. FreeBSD jails do not have 127.0.0.1 available. Instead you normally add the jails IP as localhost in /etc/hosts to help software that connects to localhost find the correct IP to use. However in the case of erlang, in line 198 of erl_epmd.erl: https://github.com/erlang/otp/blob/maint/lib/kernel/src/erl_epmd.erl#L198 The localhost IP is assumed to be 127.0.0.1. I believe this should be a DNS lookup of the name "localhost" to accomodate systems without a 127.0.0.1 IP. When I patched line 198 in erl_epmd.erl to use the jails IP instead of 127.0.0.1, and added the jails IP as "localhost" in /etc/hosts, it worked like a charm. Before the change, I got the following error when trying to start rabbitmq: http://pastebin.com/Aw4Bd7wm I am by no means an erlang expert, in fact today may be the first time I've really looked at erlang code, so making the change myself might be a bit much for me. But what do you think ? Do you agree that this can be considered a bug ? Best regards, Thomas Steen Rasmussen ps. Someone just reminded me that this wouldn't work in an ipv6 only environment either, just one more reason to make the change :) From humeafo@REDACTED Sun Oct 14 05:54:59 2012 From: humeafo@REDACTED (hume npx) Date: Sun, 14 Oct 2012 11:54:59 +0800 Subject: [erlang-bugs] socket reuseaddr not functional on windows Message-ID: using reuseaddr option while do UDP socket processing, it is not functional. I searched the question on google, it seems that it's caused by inet_drv.c line 5611, in fact win32 support reuseaddr, should the following #ifdef __WIN32__ continue; /* Bjorn says */ #else part be commented? case INET_OPT_REUSEADDR: #ifdef __WIN32__ continue; /* Bjorn says */ #else type = SO_REUSEADDR; DEBUGF(("inet_set_opts(%ld): s=%d, SO_REUSEADDR=%d\r\n", (long)desc->port, desc->s,ival)); break; #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From humeafo@REDACTED Sun Oct 14 05:55:49 2012 From: humeafo@REDACTED (hume npx) Date: Sun, 14 Oct 2012 11:55:49 +0800 Subject: [erlang-bugs] socket reuseaddr not functional on windows In-Reply-To: References: Message-ID: I test it under windows, according to the source code , unix should be ok. 2012/10/14 hume npx > using reuseaddr option while do UDP socket processing, it is not > functional. I searched the question on google, it seems that it's caused by > inet_drv.c line 5611, in fact win32 support reuseaddr, should the following > > #ifdef __WIN32__ > continue; /* Bjorn says */ > #else > > part be commented? > > case INET_OPT_REUSEADDR: > #ifdef __WIN32__ > continue; /* Bjorn says */ > #else > type = SO_REUSEADDR; > DEBUGF(("inet_set_opts(%ld): s=%d, SO_REUSEADDR=%d\r\n", > (long)desc->port, desc->s,ival)); > break; > #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Oct 14 10:57:47 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 14 Oct 2012 10:57:47 +0200 Subject: [erlang-bugs] epmd assumes 127.0.0.1 is always available In-Reply-To: <5079CF87.8030505@gibfest.dk> References: <5079CF87.8030505@gibfest.dk> Message-ID: <507A7E8B.9040600@wanadoo.fr> Le 13/10/2012 22:31, Thomas Steen Rasmussen a ?crit : > Hello guys, > > I am using erlang in a FreeBSD jail for RabbitMQ and I've hit what I > belive is a wrong assumption in epmd. FreeBSD jails do not have > 127.0.0.1 available. Instead you normally add the jails IP as > localhost in /etc/hosts to help software that connects to localhost > find the correct IP to use. Hello, did you try to let the erlang node bind the real IP address at start by setting the kernel directive {inet_dist_use_interface, ip_address()} and create a 127.0.0.1 dummy interface only for epmd (is it allowed in a FreeBSD jail ?) ? note that epmd always add the loopback address anyway even when overriding the listen addresses ( -address list or ERL_EPMD_ADDRESS env var) my 10 cents. From raimo+erlang-bugs@REDACTED Mon Oct 15 11:25:59 2012 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 15 Oct 2012 11:25:59 +0200 Subject: [erlang-bugs] epmd assumes 127.0.0.1 is always available In-Reply-To: <5079CF87.8030505@gibfest.dk> References: <5079CF87.8030505@gibfest.dk> Message-ID: <20121015092559.GA22236@erix.ericsson.se> On Sat, Oct 13, 2012 at 10:31:03PM +0200, Thomas Steen Rasmussen wrote: > Hello guys, > > I am using erlang in a FreeBSD jail for RabbitMQ and I've hit what I > belive is a wrong assumption in epmd. FreeBSD jails do not have > 127.0.0.1 available. Instead you normally add the jails IP as > localhost in /etc/hosts to help software that connects to localhost > find the correct IP to use. > > However in the case of erlang, in line 198 of erl_epmd.erl: > https://github.com/erlang/otp/blob/maint/lib/kernel/src/erl_epmd.erl#L198 > The localhost IP is assumed to be 127.0.0.1. I believe this should be > a DNS lookup of the name "localhost" to accomodate systems without a > 127.0.0.1 IP. > > When I patched line 198 in erl_epmd.erl to use the jails IP instead of > 127.0.0.1, and added the jails IP as "localhost" in /etc/hosts, it > worked like a charm. Before the change, I got the following error when > trying to start rabbitmq: http://pastebin.com/Aw4Bd7wm > > I am by no means an erlang expert, in fact today may be the first > time I've really looked at erlang code, so making the change myself > might be a bit much for me. But what do you think ? Do you agree that > this can be considered a bug ? Note that it is a much more common problem that the hostname "localhost" does not resolve to the right address and that the user has no power to change that name resolving. Somtimes "localhost" resolves to an external IP address, sometimes to 127.0.0.1, sometimes to 127.0.0.2 depending on OS and installation. And, of course ::1. There are C API constants that could/should be used instead i.e INADDR_LOOPBACK, IN6ADDR_LOOPBACK_INIT. From Erlang code you can use the atom 'loopback' instead of an address and it will be translated in the inet driver to one of those C API constants. Using an IP address is often safer than relying on the resolver. If 127.0.0.1 is not a loopback address of a machine there are usually more things than epmd that breaks. Often you want epmd and all erlang nodes to use the loopback address, keeping all Erlang nodes behind the host firewall. > > > Best regards, > > Thomas Steen Rasmussen > > ps. Someone just reminded me that this wouldn't work in an ipv6 only > environment either, just one more reason to make the change :) > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From pan@REDACTED Mon Oct 15 15:27:45 2012 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 15 Oct 2012 15:27:45 +0200 Subject: [erlang-bugs] socket reuseaddr not functional on windows In-Reply-To: References: Message-ID: <507C0F51.2000009@erlang.org> Windows reuseaddr is dysfunctional and will reuse an address that is not in time_wait, i.e. it can steal sockets from other programs. There is a plethora of windows specific options to use instead, of which none emulates the correct behaviour without also expecting other programs to have used windows specific options, which they usually don't. I looked into it again some months ago, hoping that this was ancient history, but unfortunately Windows 7 still has this unexpected behaviour. The only sensible thing, which allows for the best portability of code over platforms, is to ignore the option on Windows. Cheers, /Patrik On 10/14/2012 05:54 AM, hume npx wrote: > using reuseaddr option while do UDP socket processing, it is not > functional. I searched the question on google, it seems that it's > caused by inet_drv.c line 5611, in fact win32 support reuseaddr, > should the following > > #ifdef __WIN32__ > continue; /* Bjorn says */ > #else > > part be commented? > > case INET_OPT_REUSEADDR: > #ifdef __WIN32__ > continue; /* Bjorn says */ > #else > type = SO_REUSEADDR; > DEBUGF(("inet_set_opts(%ld): s=%d, SO_REUSEADDR=%d\r\n", > (long)desc->port, desc->s,ival)); > break; > #endif > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Oct 15 17:17:54 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 15 Oct 2012 17:17:54 +0200 Subject: [erlang-bugs] Process/FD leak in SSL R15B01 Message-ID: <507C2922.9090207@ninenines.eu> Hello, We are observing a constant increase in the number of ssl_connection processes. We have investigated the problem and are not sure how to go about it further, considering the results. We switched from using ssltunnel to directly speaking to the Erlang nodes in SSL for speaking with our mobile applications. We observed that we have right now around 25000 sockets in ESTABLISHED (increasing over time) and around the same in FIN_WAIT2 (also increasing over time). In total it increases at about 10000 sockets per day. Looking at the applications running it appears only the SSL application has extra processes compared to normal. The other parts of the system appear to be functioning normally. What's more alarming is that there is a lot more SSL connection processes than actual connection processes in Cowboy (between 10-15K and not increasing over time). Investigating the SSL application to find the source, I ended up applying the following snippet to the list of PIDs supervised by ssl_connection_sup: > lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of undefined -> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) of false -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, Curr + 1}) end end, [], List). [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] Not sure which one is the ESTABLISHED list and which one is the FIN_WAIT2. Of course, I can't use sys:get_status/1 on the PIDs stuck in prim_inet:recv0/3 because the receive there is quite specific. So I can't get the stacktrace. The other case doesn't seem to give anything useful (for my level of knowledge, anyway). The process that owns the SSL socket died. So the ssl_connection process must have received something. Problem is, it didn't close the socket properly, and the ssl_connection process still runs when it shouldn't. Is it a known issue? Is there a patch available? If not, how should I go about fixing it? Thanks. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From attila.r.nohl@REDACTED Mon Oct 15 18:09:48 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 15 Oct 2012 18:09:48 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507C2922.9090207@ninenines.eu> References: <507C2922.9090207@ninenines.eu> Message-ID: 2012/10/15 Lo?c Hoguin : [...] >> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of undefined -> >> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) of false >> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, Curr + >> 1}) end end, [], List). > [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] > > Not sure which one is the ESTABLISHED list and which one is the FIN_WAIT2. > Of course, I can't use sys:get_status/1 on the PIDs stuck in > prim_inet:recv0/3 because the receive there is quite specific. So I can't > get the stacktrace. The other case doesn't seem to give anything useful (for > my level of knowledge, anyway). You can get the stacktrace with erlang:process_info(Pid, backtrace). From essen@REDACTED Mon Oct 15 18:19:41 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 15 Oct 2012 18:19:41 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: References: <507C2922.9090207@ninenines.eu> Message-ID: <507C379D.7010004@ninenines.eu> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: > 2012/10/15 Lo?c Hoguin : > [...] >>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of undefined -> >>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) of false >>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, Curr + >>> 1}) end end, [], List). >> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >> >> Not sure which one is the ESTABLISHED list and which one is the FIN_WAIT2. >> Of course, I can't use sys:get_status/1 on the PIDs stuck in >> prim_inet:recv0/3 because the receive there is quite specific. So I can't >> get the stacktrace. The other case doesn't seem to give anything useful (for >> my level of knowledge, anyway). > > You can get the stacktrace with erlang:process_info(Pid, backtrace). Thanks for the tip! So yeah, this one is stuck while trying to terminate. Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) CP: 0x0000000000000000 (invalid) arity = 0 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 (ssl_connection:terminate/3 + 800) y(0) 57928 y(1) #Port<0.51824890> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) y(0) [] y(1) [] y(2) [] y(3) [] y(4) #Port<0.51824890> y(5) gen_tcp 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 (proc_lib:init_p_do_apply/3 + 56) y(0) [] y(1) {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432467004251893513795 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653778011280640103960 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604875601170644442368 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 bytes>>,true,undefined,undefined,{[],[]},false,true} y(2) connection y(3) ssl_connection y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} y(5) <0.18199.1670> y(6) normal y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) 0x00007f052e1b1f48 Return addr 0x0000000000883498 () y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From eric.pailleau@REDACTED Mon Oct 15 21:51:06 2012 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 15 Oct 2012 21:51:06 +0200 Subject: [erlang-bugs] R15B02 : wish list : missing gen_fsm state view in observer application. Message-ID: <507C692A.3020502@wanadoo.fr> Hello, not a bug but a really missing feature for observer : I found no way in interface to get the state (at least) and the state data of a gen_fsm process... For instance information of sys:get_status/1 . I would be nice to have special informations depending the behaviour of processes, in particular gen_fsm... regards. From vinoski@REDACTED Mon Oct 15 22:19:59 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Mon, 15 Oct 2012 16:19:59 -0400 Subject: [erlang-bugs] R15B02 : wish list : missing gen_fsm state view in observer application. In-Reply-To: <507C692A.3020502@wanadoo.fr> References: <507C692A.3020502@wanadoo.fr> Message-ID: On Mon, Oct 15, 2012 at 3:51 PM, PAILLEAU Eric wrote: > Hello, > > not a bug but a really missing feature for observer : > > I found no way in interface to get the state (at least) and the state > data of a gen_fsm process... > > For instance information of sys:get_status/1 . > > I would be nice to have special informations depending the behaviour of > processes, in particular gen_fsm... Have you considered supplying your own custom version of gen_fsm:format_status/2 for your fsm? http://www.erlang.org/doc/man/gen_fsm.html#Module:format_status-2 --steve From dgud@REDACTED Tue Oct 16 09:15:15 2012 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 16 Oct 2012 09:15:15 +0200 Subject: [erlang-bugs] R15B02 : wish list : missing gen_fsm state view in observer application. In-Reply-To: References: <507C692A.3020502@wanadoo.fr> Message-ID: I agree, that would be nice..added to the observer wishlist.. Another tab in process info window (for gen processes) would be good. A patch will make it happen sooner :-) /Dan On Mon, Oct 15, 2012 at 10:19 PM, Steve Vinoski wrote: > On Mon, Oct 15, 2012 at 3:51 PM, PAILLEAU Eric wrote: >> Hello, >> >> not a bug but a really missing feature for observer : >> >> I found no way in interface to get the state (at least) and the state >> data of a gen_fsm process... >> >> For instance information of sys:get_status/1 . >> >> I would be nice to have special informations depending the behaviour of >> processes, in particular gen_fsm... > > Have you considered supplying your own custom version of > gen_fsm:format_status/2 for your fsm? > > http://www.erlang.org/doc/man/gen_fsm.html#Module:format_status-2 > > --steve > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Ingela.Anderton.Andin@REDACTED Tue Oct 16 11:18:04 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 16 Oct 2012 11:18:04 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507C379D.7010004@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> Message-ID: <507D264C.7040102@ericsson.com> Hi! This sounds really strange it would be interesting to see all process_info available for the process. Something you could try is to comment out the invocation of the function workaround_transport_delivery_problems in the terminate function of the ssl_connection-process. This function can call recv(S, 0) and sounds like the probable recv that hangs even though it should not. Regards Ingela Erlang/OTP team - Ericsson AB Lo?c Hoguin wrote: > On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >> 2012/10/15 Lo?c Hoguin : >> [...] >>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of undefined -> >>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) >>>> of false >>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, >>>> Curr + >>>> 1}) end end, [], List). >>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>> >>> Not sure which one is the ESTABLISHED list and which one is the >>> FIN_WAIT2. >>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>> prim_inet:recv0/3 because the receive there is quite specific. So I >>> can't >>> get the stacktrace. The other case doesn't seem to give anything >>> useful (for >>> my level of knowledge, anyway). >> >> You can get the stacktrace with erlang:process_info(Pid, backtrace). > > Thanks for the tip! > > So yeah, this one is stuck while trying to terminate. > > Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) > CP: 0x0000000000000000 (invalid) > arity = 0 > > 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 > (ssl_connection:terminate/3 + 800) > y(0) 57928 > y(1) #Port<0.51824890> > > 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 + > 168) > y(0) [] > y(1) [] > y(2) [] > y(3) [] > y(4) #Port<0.51824890> > y(5) gen_tcp > > 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 > (proc_lib:init_p_do_apply/3 + 56) > y(0) [] > y(1) > {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 > bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 > bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 > bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 > bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 > bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 > bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 > bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 > bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 > bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 > bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 > bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 > bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 > bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 > bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 > bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 > bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,728945610618363694299524400013974044353817910988106666265500093396272804476922137563271036849773495653880241216909921636277708729194269519499432595651857072787205775416315535781104441756800626584698817814422133825685692237962420898234801884324670042 51893513795 > > 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,16537780112 80640103960 > > 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',179769313486231590770839156793787453197860296048756011 70644442368 > > 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 > bytes>>,true,undefined,undefined,{[],[]},false,true} > y(2) connection > y(3) ssl_connection > y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} > y(5) <0.18199.1670> > y(6) normal > y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) > > 0x00007f052e1b1f48 Return addr 0x0000000000883498 ( normally>) > y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) > From essen@REDACTED Tue Oct 16 11:22:15 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 16 Oct 2012 11:22:15 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D264C.7040102@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> Message-ID: <507D2747.8040602@ninenines.eu> Hey, Here's one: [{current_function,{prim_inet,recv0,3}}, {initial_call,{proc_lib,init_p,5}}, {status,waiting}, {message_queue_len,2}, {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, get_status}, {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, {links,[<0.897.0>,#Port<0.51824890>]}, {dictionary,[{ssl_manager,ssl_manager}, {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, {'$initial_call',{ssl_connection,init,1}}]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.893.0>}, {total_heap_size,10946}, {heap_size,4181}, {stack_size,21}, {reductions,8272}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,10}, {minor_gcs,1}]}, {suspending,[]}] The two get_status were me trying to inspect and getting a timeout. Will try commenting the function, that was my guess also. Doesn't explain the other half of the processes though which still seem to be running happily despite the process owning the socket being dead for days. On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: > Hi! > > This sounds really strange it would be interesting to see all > process_info available for the process. > > Something you could try is to comment out the invocation of the function > workaround_transport_delivery_problems in the terminate function of the > ssl_connection-process. This function can call recv(S, 0) and sounds > like the probable recv that hangs even though it should not. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Lo?c Hoguin wrote: >> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>> 2012/10/15 Lo?c Hoguin : >>> [...] >>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of undefined -> >>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) >>>>> of false >>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, >>>>> Curr + >>>>> 1}) end end, [], List). >>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>> >>>> Not sure which one is the ESTABLISHED list and which one is the >>>> FIN_WAIT2. >>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>> prim_inet:recv0/3 because the receive there is quite specific. So I >>>> can't >>>> get the stacktrace. The other case doesn't seem to give anything >>>> useful (for >>>> my level of knowledge, anyway). >>> >>> You can get the stacktrace with erlang:process_info(Pid, backtrace). >> >> Thanks for the tip! >> >> So yeah, this one is stuck while trying to terminate. >> >> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >> CP: 0x0000000000000000 (invalid) >> arity = 0 >> >> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >> (ssl_connection:terminate/3 + 800) >> y(0) 57928 >> y(1) #Port<0.51824890> >> >> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 >> + 168) >> y(0) [] >> y(1) [] >> y(2) [] >> y(3) [] >> y(4) #Port<0.51824890> >> y(5) gen_tcp >> >> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >> (proc_lib:init_p_do_apply/3 + 56) >> y(0) [] >> y(1) >> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >> bytes>>,<<2 bytes>>,<<2 >> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,728945610618363694299524400013974044353817910988106666265500093396272804476922137563271036849773495653880241216909921636277708729194269519499432595651857072787205775416315535781104441756800626584698817814422133825685692237962420898234801884324670042 >> > 51893513795 >> >> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,16537780112 >> > 80640103960 >> >> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',179769313486231590770839156793787453197860296048756011 >> > 70644442368 >> >> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >> bytes>>,true,undefined,undefined,{[],[]},false,true} >> y(2) connection >> y(3) ssl_connection >> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >> y(5) <0.18199.1670> >> y(6) normal >> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >> >> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (> normally>) >> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Tue Oct 16 11:55:32 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 16 Oct 2012 11:55:32 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D2747.8040602@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> Message-ID: <507D2F14.4020705@ericsson.com> Hi! Ok, next question can you do a port_info on the linked port? Regards Ingela Erlang/OTP Team - Ericsson AB Lo?c Hoguin wrote: > Hey, > > Here's one: > > [{current_function,{prim_inet,recv0,3}}, > {initial_call,{proc_lib,init_p,5}}, > {status,waiting}, > {message_queue_len,2}, > {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, > get_status}, > {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, > {links,[<0.897.0>,#Port<0.51824890>]}, > {dictionary,[{ssl_manager,ssl_manager}, > {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, > {'$initial_call',{ssl_connection,init,1}}]}, > {trap_exit,false}, > {error_handler,error_handler}, > {priority,normal}, > {group_leader,<0.893.0>}, > {total_heap_size,10946}, > {heap_size,4181}, > {stack_size,21}, > {reductions,8272}, > {garbage_collection,[{min_bin_vheap_size,46368}, > {min_heap_size,233}, > {fullsweep_after,10}, > {minor_gcs,1}]}, > {suspending,[]}] > > The two get_status were me trying to inspect and getting a timeout. > > Will try commenting the function, that was my guess also. Doesn't > explain the other half of the processes though which still seem to be > running happily despite the process owning the socket being dead for days. > > On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >> Hi! >> >> This sounds really strange it would be interesting to see all >> process_info available for the process. >> >> Something you could try is to comment out the invocation of the function >> workaround_transport_delivery_problems in the terminate function of the >> ssl_connection-process. This function can call recv(S, 0) and sounds >> like the probable recv that hangs even though it should not. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Lo?c Hoguin wrote: >>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>> 2012/10/15 Lo?c Hoguin : >>>> [...] >>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>> undefined -> >>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) >>>>>> of false >>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, >>>>>> Curr + >>>>>> 1}) end end, [], List). >>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>> >>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>> FIN_WAIT2. >>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>> prim_inet:recv0/3 because the receive there is quite specific. So I >>>>> can't >>>>> get the stacktrace. The other case doesn't seem to give anything >>>>> useful (for >>>>> my level of knowledge, anyway). >>>> >>>> You can get the stacktrace with erlang:process_info(Pid, backtrace). >>> >>> Thanks for the tip! >>> >>> So yeah, this one is stuck while trying to terminate. >>> >>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>> CP: 0x0000000000000000 (invalid) >>> arity = 0 >>> >>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>> (ssl_connection:terminate/3 + 800) >>> y(0) 57928 >>> y(1) #Port<0.51824890> >>> >>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 >>> + 168) >>> y(0) [] >>> y(1) [] >>> y(2) [] >>> y(3) [] >>> y(4) #Port<0.51824890> >>> y(5) gen_tcp >>> >>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>> (proc_lib:init_p_do_apply/3 + 56) >>> y(0) [] >>> y(1) >>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>> >>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>> bytes>>,<<2 bytes>>,<<2 >>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>> >>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>> >>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>> >>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>> >>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>> >>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,7289456106183636942995244000139740443538179109881066662655000933962728044769221375632710368497734956538802412169099216362777087291942695194994325956518570727872057754163155357811044417568006265846988178144221338256856922379624208982348018843246700 42 >>> >>> >> 51893513795 >>> >>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,165377801 12 >>> >>> >> 80640103960 >>> >>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',1797693134862315907708391567937874531978602960487560 11 >>> >>> >> 70644442368 >>> >>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>> >>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>> y(2) connection >>> y(3) ssl_connection >>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>> y(5) <0.18199.1670> >>> y(6) normal >>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>> >>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>> normally>) >>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>> >> > > From essen@REDACTED Tue Oct 16 11:59:29 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 16 Oct 2012 11:59:29 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D2F14.4020705@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> Message-ID: <507D3001.6000307@ninenines.eu> 103> erlang:port_info(Port). [{name,"tcp_inet"}, {links,[<0.18199.1670>]}, {id,51824890}, {connected,<0.18199.1670>}, {input,0}, {output,3583}] 104> Pid. <0.18199.1670> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: > Hi! > > Ok, next question can you do a port_info on the linked port? > > Regards Ingela Erlang/OTP Team - Ericsson AB > > Lo?c Hoguin wrote: >> Hey, >> >> Here's one: >> >> [{current_function,{prim_inet,recv0,3}}, >> {initial_call,{proc_lib,init_p,5}}, >> {status,waiting}, >> {message_queue_len,2}, >> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >> get_status}, >> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >> {links,[<0.897.0>,#Port<0.51824890>]}, >> {dictionary,[{ssl_manager,ssl_manager}, >> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >> {'$initial_call',{ssl_connection,init,1}}]}, >> {trap_exit,false}, >> {error_handler,error_handler}, >> {priority,normal}, >> {group_leader,<0.893.0>}, >> {total_heap_size,10946}, >> {heap_size,4181}, >> {stack_size,21}, >> {reductions,8272}, >> {garbage_collection,[{min_bin_vheap_size,46368}, >> {min_heap_size,233}, >> {fullsweep_after,10}, >> {minor_gcs,1}]}, >> {suspending,[]}] >> >> The two get_status were me trying to inspect and getting a timeout. >> >> Will try commenting the function, that was my guess also. Doesn't >> explain the other half of the processes though which still seem to be >> running happily despite the process owning the socket being dead for >> days. >> >> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>> Hi! >>> >>> This sounds really strange it would be interesting to see all >>> process_info available for the process. >>> >>> Something you could try is to comment out the invocation of the function >>> workaround_transport_delivery_problems in the terminate function of the >>> ssl_connection-process. This function can call recv(S, 0) and sounds >>> like the probable recv that hangs even though it should not. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> Lo?c Hoguin wrote: >>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>> 2012/10/15 Lo?c Hoguin : >>>>> [...] >>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>> undefined -> >>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) >>>>>>> of false >>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, >>>>>>> Curr + >>>>>>> 1}) end end, [], List). >>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>> >>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>> FIN_WAIT2. >>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>> prim_inet:recv0/3 because the receive there is quite specific. So I >>>>>> can't >>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>> useful (for >>>>>> my level of knowledge, anyway). >>>>> >>>>> You can get the stacktrace with erlang:process_info(Pid, backtrace). >>>> >>>> Thanks for the tip! >>>> >>>> So yeah, this one is stuck while trying to terminate. >>>> >>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>> CP: 0x0000000000000000 (invalid) >>>> arity = 0 >>>> >>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>> (ssl_connection:terminate/3 + 800) >>>> y(0) 57928 >>>> y(1) #Port<0.51824890> >>>> >>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 >>>> + 168) >>>> y(0) [] >>>> y(1) [] >>>> y(2) [] >>>> y(3) [] >>>> y(4) #Port<0.51824890> >>>> y(5) gen_tcp >>>> >>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>> (proc_lib:init_p_do_apply/3 + 56) >>>> y(0) [] >>>> y(1) >>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>> >>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>> bytes>>,<<2 bytes>>,<<2 >>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>> >>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>> >>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>> >>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>> >>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>> >>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,7289456106183636942995244000139740443538179109881066662655000933962728044769221375632710368497734956538802412169099216362777087291942695194994325956518570727872057754163155357811044417568006265846988178144221338256856922379624208982348018843246700 >>>> > 42 >>>> >>>> >>> 51893513795 >>>> >>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,165377801 >>>> > 12 >>>> >>>> >>> 80640103960 >>>> >>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',1797693134862315907708391567937874531978602960487560 >>>> > 11 >>>> >>>> >>> 70644442368 >>>> >>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>> >>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>> y(2) connection >>>> y(3) ssl_connection >>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>> y(5) <0.18199.1670> >>>> y(6) normal >>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>> >>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>> normally>) >>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>>> >>> >> >> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From robert.virding@REDACTED Tue Oct 16 12:15:03 2012 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 16 Oct 2012 11:15:03 +0100 (BST) Subject: [erlang-bugs] R15B02 : wish list : missing gen_fsm state view in observer application. In-Reply-To: Message-ID: <17a12712-8d8e-4ba3-94a6-1722c2186bfc@knuth> A very simple work-around is to use gen_fsm:sync_send_all_state_event/2 and ask it. You can then return whatever you need. Using this call you don't need to add the event to every state. By staying in the same state it is effectively a no-op. Robert ----- Original Message ----- > From: "Dan Gudmundsson" > To: erlang-bugs@REDACTED > Sent: Tuesday, 16 October, 2012 9:15:15 AM > Subject: Re: [erlang-bugs] R15B02 : wish list : missing gen_fsm state view in observer application. > > I agree, that would be nice..added to the observer wishlist.. > Another tab in process info window (for gen processes) would > be good. > > A patch will make it happen sooner :-) > > /Dan > > On Mon, Oct 15, 2012 at 10:19 PM, Steve Vinoski > wrote: > > On Mon, Oct 15, 2012 at 3:51 PM, PAILLEAU Eric > > wrote: > >> Hello, > >> > >> not a bug but a really missing feature for observer : > >> > >> I found no way in interface to get the state (at least) and the > >> state > >> data of a gen_fsm process... > >> > >> For instance information of sys:get_status/1 . > >> > >> I would be nice to have special informations depending the > >> behaviour of > >> processes, in particular gen_fsm... > > > > Have you considered supplying your own custom version of > > gen_fsm:format_status/2 for your fsm? > > > > http://www.erlang.org/doc/man/gen_fsm.html#Module:format_status-2 > > > > --steve > > _______________________________________________ > > 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 essen@REDACTED Tue Oct 16 18:35:54 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 16 Oct 2012 18:35:54 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D264C.7040102@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> Message-ID: <507D8CEA.4020909@ninenines.eu> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: > Something you could try is to comment out the invocation of the function > workaround_transport_delivery_problems in the terminate function of the > ssl_connection-process. This function can call recv(S, 0) and sounds > like the probable recv that hangs even though it should not. Preliminary observations seem to indicate that this does not solve anything. Server with patch has same number of sockets open as server without patch. [{{prim_inet,recv0,3},34087},{{gen_fsm,loop,7},35167}] Difference is probably due to now being peak time. I'll have definite confirmation tomorrow. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Tue Oct 16 18:39:31 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 16 Oct 2012 18:39:31 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D3001.6000307@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> Message-ID: <507D8DC3.6050507@ericsson.com> Hi! This is puzzling. Links seems to be intact. And the supervisor should have killed the gen_fsm-process if it gets stuck in terminate. I tried to recreate your problem, I did get a process leak problem, however it did not manifest itself in quite the same way as yours. In my case I have an active process that seems to not have received the tcp_close message. The fsm procss emulates active option as it uses active once to receive TLS packets. If I set the active option the process will terminate. At the moment I am have not found the root of why it is not working as expected e.i. if it is the emulating code that does something wrong or it perhaps is the inet driver. Will have to keep digging. Regards Ingela Erlang/OTP team - Ericsson AB Lo?c Hoguin wrote: > 103> erlang:port_info(Port). > [{name,"tcp_inet"}, > {links,[<0.18199.1670>]}, > {id,51824890}, > {connected,<0.18199.1670>}, > {input,0}, > {output,3583}] > 104> Pid. > <0.18199.1670> > > On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >> Hi! >> >> Ok, next question can you do a port_info on the linked port? >> >> Regards Ingela Erlang/OTP Team - Ericsson AB >> >> Lo?c Hoguin wrote: >>> Hey, >>> >>> Here's one: >>> >>> [{current_function,{prim_inet,recv0,3}}, >>> {initial_call,{proc_lib,init_p,5}}, >>> {status,waiting}, >>> {message_queue_len,2}, >>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>> get_status}, >>> >>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>> {links,[<0.897.0>,#Port<0.51824890>]}, >>> {dictionary,[{ssl_manager,ssl_manager}, >>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>> {'$initial_call',{ssl_connection,init,1}}]}, >>> {trap_exit,false}, >>> {error_handler,error_handler}, >>> {priority,normal}, >>> {group_leader,<0.893.0>}, >>> {total_heap_size,10946}, >>> {heap_size,4181}, >>> {stack_size,21}, >>> {reductions,8272}, >>> {garbage_collection,[{min_bin_vheap_size,46368}, >>> {min_heap_size,233}, >>> {fullsweep_after,10}, >>> {minor_gcs,1}]}, >>> {suspending,[]}] >>> >>> The two get_status were me trying to inspect and getting a timeout. >>> >>> Will try commenting the function, that was my guess also. Doesn't >>> explain the other half of the processes though which still seem to be >>> running happily despite the process owning the socket being dead for >>> days. >>> >>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> This sounds really strange it would be interesting to see all >>>> process_info available for the process. >>>> >>>> Something you could try is to comment out the invocation of the >>>> function >>>> workaround_transport_delivery_problems in the terminate function of the >>>> ssl_connection-process. This function can call recv(S, 0) and sounds >>>> like the probable recv that hangs even though it should not. >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>> Lo?c Hoguin wrote: >>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>> 2012/10/15 Lo?c Hoguin : >>>>>> [...] >>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>> undefined -> >>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, Sum) >>>>>>>> of false >>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, {XXX, >>>>>>>> Curr + >>>>>>>> 1}) end end, [], List). >>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>> >>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>> FIN_WAIT2. >>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>> prim_inet:recv0/3 because the receive there is quite specific. So I >>>>>>> can't >>>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>>> useful (for >>>>>>> my level of knowledge, anyway). >>>>>> >>>>>> You can get the stacktrace with erlang:process_info(Pid, backtrace). >>>>> >>>>> Thanks for the tip! >>>>> >>>>> So yeah, this one is stuck while trying to terminate. >>>>> >>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>> CP: 0x0000000000000000 (invalid) >>>>> arity = 0 >>>>> >>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>> (ssl_connection:terminate/3 + 800) >>>>> y(0) 57928 >>>>> y(1) #Port<0.51824890> >>>>> >>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 (gen_fsm:terminate/7 >>>>> + 168) >>>>> y(0) [] >>>>> y(1) [] >>>>> y(2) [] >>>>> y(3) [] >>>>> y(4) #Port<0.51824890> >>>>> y(5) gen_tcp >>>>> >>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>> y(0) [] >>>>> y(1) >>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>> >>>>> >>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>> bytes>>,<<2 bytes>>,<<2 >>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>> >>>>> >>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>> >>>>> >>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>> >>>>> >>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 bytes>>,<<32 >>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>> >>>>> >>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>> >>>>> >>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432467 00 >>>>> >>>>> >> 42 >>>>> >>>>> >>>> 51893513795 >>>>> >>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653778 01 >>>>> >>>>> >> 12 >>>>> >>>>> >>>> 80640103960 >>>>> >>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604875 60 >>>>> >>>>> >> 11 >>>>> >>>>> >>>> 70644442368 >>>>> >>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>> >>>>> >>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>> y(2) connection >>>>> y(3) ssl_connection >>>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>> y(5) <0.18199.1670> >>>>> y(6) normal >>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>> >>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>> normally>) >>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>>>> >>>> >>> >>> >> > > From ingela.anderton.andin@REDACTED Wed Oct 17 09:51:45 2012 From: ingela.anderton.andin@REDACTED (Ingela Anderton Andin) Date: Wed, 17 Oct 2012 09:51:45 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D8DC3.6050507@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> Message-ID: <507E6391.7070304@erix.ericsson.se> Hi! My problem goes away with the following patch diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl index 7788f75..771bfa5 100644 --- a/lib/ssl/src/ssl.erl +++ b/lib/ssl/src/ssl.erl @@ -869,10 +869,10 @@ internal_inet_values() -> socket_options(InetValues) -> #socket_options{ - mode = proplists:get_value(mode, InetValues), - header = proplists:get_value(header, InetValues), - active = proplists:get_value(active, InetValues), - packet = proplists:get_value(packet, InetValues), + mode = proplists:get_value(mode, InetValues, lists), + header = proplists:get_value(header, InetValues, 0), + active = proplists:get_value(active, InetValues, active), + packet = proplists:get_value(packet, InetValues, 0), packet_size = proplists:get_value(packet_size, InetValues) }. e.i. default values where not properly handled. I know to little about your configuration to say if this is your problem too. If not it would be great if you could give me a way to recreate your problem. Regards Ingela Erlang/OTP team - Ericsson AB Ingela Anderton Andin wrote: > Hi! > > This is puzzling. Links seems to be intact. And the supervisor should > have killed the gen_fsm-process if it gets stuck in terminate. > > I tried to recreate your problem, I did get a process leak problem, > however it did not manifest itself in quite the same way as yours. > > In my case I have an active process that seems to not have received > the tcp_close message. The fsm procss emulates active option as it > uses active once to receive TLS packets. If I set the active option > the process will terminate. At the moment I am have not found the root > of why it is not working as expected e.i. if it is the emulating code > that does something wrong or it perhaps is the inet driver. Will have > to keep digging. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Lo?c Hoguin wrote: >> 103> erlang:port_info(Port). >> [{name,"tcp_inet"}, >> {links,[<0.18199.1670>]}, >> {id,51824890}, >> {connected,<0.18199.1670>}, >> {input,0}, >> {output,3583}] >> 104> Pid. >> <0.18199.1670> >> >> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >>> Hi! >>> >>> Ok, next question can you do a port_info on the linked port? >>> >>> Regards Ingela Erlang/OTP Team - Ericsson AB >>> >>> Lo?c Hoguin wrote: >>>> Hey, >>>> >>>> Here's one: >>>> >>>> [{current_function,{prim_inet,recv0,3}}, >>>> {initial_call,{proc_lib,init_p,5}}, >>>> {status,waiting}, >>>> {message_queue_len,2}, >>>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>>> get_status}, >>>> >>>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>>> {links,[<0.897.0>,#Port<0.51824890>]}, >>>> {dictionary,[{ssl_manager,ssl_manager}, >>>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>>> {'$initial_call',{ssl_connection,init,1}}]}, >>>> {trap_exit,false}, >>>> {error_handler,error_handler}, >>>> {priority,normal}, >>>> {group_leader,<0.893.0>}, >>>> {total_heap_size,10946}, >>>> {heap_size,4181}, >>>> {stack_size,21}, >>>> {reductions,8272}, >>>> {garbage_collection,[{min_bin_vheap_size,46368}, >>>> {min_heap_size,233}, >>>> {fullsweep_after,10}, >>>> {minor_gcs,1}]}, >>>> {suspending,[]}] >>>> >>>> The two get_status were me trying to inspect and getting a timeout. >>>> >>>> Will try commenting the function, that was my guess also. Doesn't >>>> explain the other half of the processes though which still seem to be >>>> running happily despite the process owning the socket being dead for >>>> days. >>>> >>>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>>> Hi! >>>>> >>>>> This sounds really strange it would be interesting to see all >>>>> process_info available for the process. >>>>> >>>>> Something you could try is to comment out the invocation of the >>>>> function >>>>> workaround_transport_delivery_problems in the terminate function >>>>> of the >>>>> ssl_connection-process. This function can call recv(S, 0) and >>>>> sounds >>>>> like the probable recv that hangs even though it should not. >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>>> Lo?c Hoguin wrote: >>>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>>> 2012/10/15 Lo?c Hoguin : >>>>>>> [...] >>>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>>> undefined -> >>>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, >>>>>>>>> Sum) >>>>>>>>> of false >>>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, >>>>>>>>> {XXX, >>>>>>>>> Curr + >>>>>>>>> 1}) end end, [], List). >>>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>>> >>>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>>> FIN_WAIT2. >>>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>>> prim_inet:recv0/3 because the receive there is quite specific. >>>>>>>> So I >>>>>>>> can't >>>>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>>>> useful (for >>>>>>>> my level of knowledge, anyway). >>>>>>> >>>>>>> You can get the stacktrace with erlang:process_info(Pid, >>>>>>> backtrace). >>>>>> >>>>>> Thanks for the tip! >>>>>> >>>>>> So yeah, this one is stuck while trying to terminate. >>>>>> >>>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>>> CP: 0x0000000000000000 (invalid) >>>>>> arity = 0 >>>>>> >>>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>>> (ssl_connection:terminate/3 + 800) >>>>>> y(0) 57928 >>>>>> y(1) #Port<0.51824890> >>>>>> >>>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 >>>>>> (gen_fsm:terminate/7 >>>>>> + 168) >>>>>> y(0) [] >>>>>> y(1) [] >>>>>> y(2) [] >>>>>> y(3) [] >>>>>> y(4) #Port<0.51824890> >>>>>> y(5) gen_tcp >>>>>> >>>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>>> y(0) [] >>>>>> y(1) >>>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>>> >>>>>> >>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>> bytes>>,<<2 bytes>>,<<2 >>>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>>> >>>>>> >>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>> bytes>>,<<32 >>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>> >>>>>> >>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>>> >>>>>> >>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>> bytes>>,<<32 >>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>> >>>>>> >>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>>> >>>>>> >>>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >>>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432467 >>>>>> > 00 >>>>>> >>>>>> >>> 42 >>>>>> >>>>>> >>>>> 51893513795 >>>>>> >>>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653778 >>>>>> > 01 >>>>>> >>>>>> >>> 12 >>>>>> >>>>>> >>>>> 80640103960 >>>>>> >>>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604875 >>>>>> > 60 >>>>>> >>>>>> >>> 11 >>>>>> >>>>>> >>>>> 70644442368 >>>>>> >>>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>>> >>>>>> >>>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>>> y(2) connection >>>>>> y(3) ssl_connection >>>>>> y(4) >>>>>> {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>>> y(5) <0.18199.1670> >>>>>> y(6) normal >>>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>>> >>>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>>> process >>>>>> normally>) >>>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>>>>> >>>>> >>>> >>>> >>> >> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From be.dmitry@REDACTED Thu Oct 18 14:39:10 2012 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Thu, 18 Oct 2012 16:39:10 +0400 Subject: [erlang-bugs] prim_inet:close/1 race condition In-Reply-To: References: Message-ID: <68978949-C924-4393-BFE0-670A6E5B79A4@gmail.com> Is it known bug? Can anyone propose a patch for prim_inet? Thank you. On 12.10.2012, at 1:06, Dmitry Belyaev wrote: > Some days ago we found that we have thousands of leaked sockets in our project. > > These sockets were ports with state like this: > [{name,"tcp_inet"}, > {links,[]}, > {connected,<0.54.0>},...] > > We made investigation and found the cause of the leaks. > > We have inets option {exit_on_close, false} to read statistics from the socket after it was closed by the peer. Process that controls the socket does not trap_exit and is linked with some another process. > At the end of connection controller calls gen_tcp:close/1 and sometimes the linked process dies at that the same moment. We found out that the gen_tcp:close/1 calls prim_inet:close/1, the first action of which is unlink from controlling process. So, when controller is unlinked from the port and is killed by the signal, port stays in the system because of exit_on_close feature. > > I've made a module that sometimes may reveal the problem. https://gist.github.com/3875485 > On my system a half of dozen calls to close_bug:start(1000) do find such leaked ports. > I haven't found the right solution for the problem yet, so no patches at the moment. > > Thank you for your attention. > > -- > Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Oct 18 17:32:42 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 18 Oct 2012 17:32:42 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507E6391.7070304@erix.ericsson.se> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> Message-ID: <5080211A.2060805@ninenines.eu> This doesn't make a difference so far. On 10/17/2012 09:51 AM, Ingela Anderton Andin wrote: > Hi! > > My problem goes away with the following patch > > diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl > index 7788f75..771bfa5 100644 > --- a/lib/ssl/src/ssl.erl > +++ b/lib/ssl/src/ssl.erl > @@ -869,10 +869,10 @@ internal_inet_values() -> > > socket_options(InetValues) -> > #socket_options{ > - mode = proplists:get_value(mode, InetValues), > - header = proplists:get_value(header, InetValues), > - active = proplists:get_value(active, InetValues), > - packet = proplists:get_value(packet, InetValues), > + mode = proplists:get_value(mode, InetValues, lists), > + header = proplists:get_value(header, InetValues, 0), > + active = proplists:get_value(active, InetValues, active), > + packet = proplists:get_value(packet, InetValues, 0), > packet_size = proplists:get_value(packet_size, InetValues) > }. > > > e.i. default values where not properly handled. I know to little > about your configuration to say if this is your problem too. If not > it would be great if you could > give me a way to recreate your problem. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Ingela Anderton Andin wrote: >> Hi! >> >> This is puzzling. Links seems to be intact. And the supervisor should >> have killed the gen_fsm-process if it gets stuck in terminate. >> >> I tried to recreate your problem, I did get a process leak problem, >> however it did not manifest itself in quite the same way as yours. >> >> In my case I have an active process that seems to not have received >> the tcp_close message. The fsm procss emulates active option as it >> uses active once to receive TLS packets. If I set the active option >> the process will terminate. At the moment I am have not found the root >> of why it is not working as expected e.i. if it is the emulating code >> that does something wrong or it perhaps is the inet driver. Will have >> to keep digging. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Lo?c Hoguin wrote: >>> 103> erlang:port_info(Port). >>> [{name,"tcp_inet"}, >>> {links,[<0.18199.1670>]}, >>> {id,51824890}, >>> {connected,<0.18199.1670>}, >>> {input,0}, >>> {output,3583}] >>> 104> Pid. >>> <0.18199.1670> >>> >>> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> Ok, next question can you do a port_info on the linked port? >>>> >>>> Regards Ingela Erlang/OTP Team - Ericsson AB >>>> >>>> Lo?c Hoguin wrote: >>>>> Hey, >>>>> >>>>> Here's one: >>>>> >>>>> [{current_function,{prim_inet,recv0,3}}, >>>>> {initial_call,{proc_lib,init_p,5}}, >>>>> {status,waiting}, >>>>> {message_queue_len,2}, >>>>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>>>> get_status}, >>>>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>>>> {links,[<0.897.0>,#Port<0.51824890>]}, >>>>> {dictionary,[{ssl_manager,ssl_manager}, >>>>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>>>> {'$initial_call',{ssl_connection,init,1}}]}, >>>>> {trap_exit,false}, >>>>> {error_handler,error_handler}, >>>>> {priority,normal}, >>>>> {group_leader,<0.893.0>}, >>>>> {total_heap_size,10946}, >>>>> {heap_size,4181}, >>>>> {stack_size,21}, >>>>> {reductions,8272}, >>>>> {garbage_collection,[{min_bin_vheap_size,46368}, >>>>> {min_heap_size,233}, >>>>> {fullsweep_after,10}, >>>>> {minor_gcs,1}]}, >>>>> {suspending,[]}] >>>>> >>>>> The two get_status were me trying to inspect and getting a timeout. >>>>> >>>>> Will try commenting the function, that was my guess also. Doesn't >>>>> explain the other half of the processes though which still seem to be >>>>> running happily despite the process owning the socket being dead for >>>>> days. >>>>> >>>>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>>>> Hi! >>>>>> >>>>>> This sounds really strange it would be interesting to see all >>>>>> process_info available for the process. >>>>>> >>>>>> Something you could try is to comment out the invocation of the >>>>>> function >>>>>> workaround_transport_delivery_problems in the terminate function >>>>>> of the >>>>>> ssl_connection-process. This function can call recv(S, 0) and >>>>>> sounds >>>>>> like the probable recv that hangs even though it should not. >>>>>> >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>>> >>>>>> Lo?c Hoguin wrote: >>>>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>>>> 2012/10/15 Lo?c Hoguin : >>>>>>>> [...] >>>>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>>>> undefined -> >>>>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, >>>>>>>>>> Sum) >>>>>>>>>> of false >>>>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, >>>>>>>>>> {XXX, >>>>>>>>>> Curr + >>>>>>>>>> 1}) end end, [], List). >>>>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>>>> >>>>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>>>> FIN_WAIT2. >>>>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>>>> prim_inet:recv0/3 because the receive there is quite specific. >>>>>>>>> So I >>>>>>>>> can't >>>>>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>>>>> useful (for >>>>>>>>> my level of knowledge, anyway). >>>>>>>> >>>>>>>> You can get the stacktrace with erlang:process_info(Pid, >>>>>>>> backtrace). >>>>>>> >>>>>>> Thanks for the tip! >>>>>>> >>>>>>> So yeah, this one is stuck while trying to terminate. >>>>>>> >>>>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>>>> CP: 0x0000000000000000 (invalid) >>>>>>> arity = 0 >>>>>>> >>>>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>>>> (ssl_connection:terminate/3 + 800) >>>>>>> y(0) 57928 >>>>>>> y(1) #Port<0.51824890> >>>>>>> >>>>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 >>>>>>> (gen_fsm:terminate/7 >>>>>>> + 168) >>>>>>> y(0) [] >>>>>>> y(1) [] >>>>>>> y(2) [] >>>>>>> y(3) [] >>>>>>> y(4) #Port<0.51824890> >>>>>>> y(5) gen_tcp >>>>>>> >>>>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>>>> y(0) [] >>>>>>> y(1) >>>>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>>>> >>>>>>> >>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>> bytes>>,<<2 bytes>>,<<2 >>>>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>>>> >>>>>>> >>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>> bytes>>,<<32 >>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>> >>>>>>> >>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>>>> >>>>>>> >>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>> bytes>>,<<32 >>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>> >>>>>>> >>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>>>> >>>>>>> >>>>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 bytes>>},[],12308,{session,<<32 >>>>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432467 >>>>>>> >> 00 >>>>>>> >>>>>>> >>>> 42 >>>>>>> >>>>>>> >>>>>> 51893513795 >>>>>>> >>>>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653778 >>>>>>> >> 01 >>>>>>> >>>>>>> >>>> 12 >>>>>>> >>>>>>> >>>>>> 80640103960 >>>>>>> >>>>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604875 >>>>>>> >> 60 >>>>>>> >>>>>>> >>>> 11 >>>>>>> >>>>>>> >>>>>> 70644442368 >>>>>>> >>>>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>>>> >>>>>>> >>>>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>>>> y(2) connection >>>>>>> y(3) ssl_connection >>>>>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>>>> y(5) <0.18199.1670> >>>>>>> y(6) normal >>>>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>>>> >>>>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>>>> process >>>>>>> normally>) >>>>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From erlang@REDACTED Thu Oct 18 19:39:26 2012 From: erlang@REDACTED (Jesper Larsson) Date: Thu, 18 Oct 2012 19:39:26 +0200 Subject: [erlang-bugs] Problem with nested opaque types Message-ID: <75211ED1-02DA-41B0-B06B-B4290A6DFE3E@avadeaux.net> Hi, This seems related to http://erlang.org/pipermail/erlang-bugs/2010-July/001904.html which is allegedly fixed, but the problem described below still exists. I have Erlang R15B02 and Dialyzer reports version v2.5.2. (I couldn't find how to map these numbers to each other.) I boiled it down to this: %% ======== exporter.erl -module(exporter). -export([traverser/1]). -export_type([trav/0, tree/0]). -opaque tree() :: {tuple()}. -opaque trav() :: {non_neg_integer(), tree()}. -spec traverser(tree()) -> trav(). traverser(Rftree) -> {1, Rftree}. %% ======== importer.erl -module(importer). -export([foo/1]). -spec foo(exporter:tree()) -> float(). foo(Rftree) -> cwl(exporter:traverser(Rftree)). -spec cwl(exporter:trav()) -> float(). cwl(_Trav) -> 0.0. I get the following Dialyzer errors: importer.erl:5: Function foo/1 has no local return importer.erl:6: The call importer:cwl(exporter:trav()) contains an opaque term as 1st argument when an opaque term of type exporter:trav() is expected importer.erl:8: Invalid type specification for function importer:cwl/1. The success typing is (exporter:trav()) -> float() So it complains about the type specification for cwl but gives me exactly the same as success typing. I got around the problems with the following workaround, which I feel should not be necessary, or at least the error message should be nicer. %% ======== workaround exporter.erl -module(exporter). -export([traverser/1]). -export_type([trav/0, tree/0]). -define(tree_def, {tuple()}). -opaque tree() :: ?tree_def. -opaque trav() :: {non_neg_integer(), ?tree_def}. -spec traverser(tree()) -> trav(). traverser(Rftree) -> {1, Rftree}. /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Oct 18 23:07:30 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Oct 2012 23:07:30 +0200 Subject: [erlang-bugs] Problem with nested opaque types In-Reply-To: <75211ED1-02DA-41B0-B06B-B4290A6DFE3E@avadeaux.net> References: <75211ED1-02DA-41B0-B06B-B4290A6DFE3E@avadeaux.net> Message-ID: <50806F92.6040002@cs.ntua.gr> On 10/18/2012 07:39 PM, Jesper Larsson wrote: > Hi, > > This seems related to > http://erlang.org/pipermail/erlang-bugs/2010-July/001904.html which is > allegedly fixed, but the problem described below still exists. I have > Erlang R15B02 and Dialyzer reports version v2.5.2. (I couldn't find how > to map these numbers to each other.) > > I boiled it down to this: ... Hi Jesper, Thanks for the bug report. Yes, I would call this a bug. We are aware that there are still issues with opaque datatypes -- note that they are not documented and this is for a reason. But we will investigate this nonetheless. Kostis PS. Another way of shutting off the warnings (though I am not sure why) is to define the spec in module exporter as: -spec traverser(exporter:tree()) -> exporter:trav(). But I am not suggesting this as a long term "solution". From erlang@REDACTED Fri Oct 19 13:10:05 2012 From: erlang@REDACTED (Jesper Larsson) Date: Fri, 19 Oct 2012 13:10:05 +0200 Subject: [erlang-bugs] Problem with nested opaque types In-Reply-To: <50806F92.6040002@cs.ntua.gr> References: <75211ED1-02DA-41B0-B06B-B4290A6DFE3E@avadeaux.net> <50806F92.6040002@cs.ntua.gr> Message-ID: <7A6F69CF-155D-41C0-8EE2-0BEF434542B8@avadeaux.net> On Oct 18, 2012, at 23:07, Kostis Sagonas wrote: > Yes, I would call this a bug. We are aware that there are still issues with opaque datatypes -- note that they are not documented and this is for a reason. But we will investigate this nonetheless. Thanks, I had no idea opaques were "not documented". This doesn't count as documentation, then? http://www.erlang.org/doc/reference_manual/typespec.html > PS. Another way of shutting off the warnings (though I am not sure why) is to define the spec in module exporter as: > > -spec traverser(exporter:tree()) -> exporter:trav(). In the more complex real situation where I encountered the problem, this trick reduced the number of Dialyzer errors, but I couldn't get them to completely go away no matter how many "exporter:" I put in. /Jesper From ali.sabil@REDACTED Fri Oct 19 15:58:06 2012 From: ali.sabil@REDACTED (Ali Sabil) Date: Fri, 19 Oct 2012 15:58:06 +0200 Subject: [erlang-bugs] xmerl and unicode data Message-ID: Hi all, I was wondering if anyone came across the following behaviour? Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] [dtrace] Eshell V5.9.2 (abort with ^G) 1> xmerl_scan:string("?? Bj?rk"). 3414- fatal: {error,{wfc_Legal_Character,{error,{bad_character,20320}}}} ** exception exit: {fatal,{{error,{wfc_Legal_Character,{error,{bad_character,20320}}}}, {file,file_name_unknown}, {line,1}, {col,47}}} in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, line 2703) in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, line 2615) in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2128) in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 570) in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) 2> 2> xmerl_scan:string("?? Bj?rk", [{encoding, latin1}]). {{xmlElement,test,test,[], {xmlNamespace,[],[]}, [],1,[], [{xmlText,[{test,1}], 1,[], [20320,22909,32,66,106,246,114,107], text}], [],"/Users/asabil/test", undeclared}, []} 3> 3> io:getopts(). [{expand_fun,#Fun}, {echo,true}, {binary,false}, {encoding,unicode}] Thanks, Ali From n.oxyde@REDACTED Fri Oct 19 17:01:00 2012 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 19 Oct 2012 17:01:00 +0200 Subject: [erlang-bugs] xmerl and unicode data In-Reply-To: References: Message-ID: <115A9693-59D7-4E3B-9330-67C105A07BAD@gmail.com> Le 19 oct. 2012 ? 15:58, Ali Sabil a ?crit : > Hi all, > > I was wondering if anyone came across the following behaviour? > > > Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] > [async-threads:0] [hipe] [kernel-poll:false] [dtrace] > > Eshell V5.9.2 (abort with ^G) > 1> xmerl_scan:string(" encoding=\"utf-8\"?>?? Bj?rk"). > 3414- fatal: {error,{wfc_Legal_Character,{error,{bad_character,20320}}}} > ** exception exit: > {fatal,{{error,{wfc_Legal_Character,{error,{bad_character,20320}}}}, > {file,file_name_unknown}, > {line,1}, > {col,47}}} > in function xmerl_scan:fatal/2 (xmerl_scan.erl, line 4102) > in call from xmerl_scan:scan_char_data/5 (xmerl_scan.erl, line 2703) > in call from xmerl_scan:scan_content/11 (xmerl_scan.erl, line 2615) > in call from xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2128) > in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 570) > in call from xmerl_scan:string/2 (xmerl_scan.erl, line 286) > 2> > 2> xmerl_scan:string(" encoding=\"utf-8\"?>?? Bj?rk", [{encoding, latin1}]). > {{xmlElement,test,test,[], > {xmlNamespace,[],[]}, > [],1,[], > [{xmlText,[{test,1}], > 1,[], > [20320,22909,32,66,106,246,114,107], > text}], > [],"/Users/asabil/test", > undeclared}, > []} > 3> > 3> io:getopts(). > [{expand_fun,#Fun}, > {echo,true}, > {binary,false}, > {encoding,unicode}] > > > Thanks, > Ali Hi, From my vague souvenirs of xmerl's innards, I'm pretty sure it happens because xmerl_scan:string expects a list of bytes and does not check whether a given byte is valid latin1. Regards, -- Anthony Ramine From erlang@REDACTED Fri Oct 19 17:04:59 2012 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Fri, 19 Oct 2012 17:04:59 +0200 Subject: [erlang-bugs] Wrong dialyzer spec for erlang:process_info/2 Message-ID: Hey, Let's define a function which is supposed to return us a list of links for a given process: -spec links(pid()) -> [port() | pid()]. links(Pid) -> {links, Links} = process_info(Pid, links), Links. Now let's run the dialyzer on the beam file: dialyzer -Wno_return -Wunderspecs --fullpath --plt .plt pi.beam Checking whether the PLT .plt is up-to-date... yes Proceeding with analysis... pi.erl:5: Type specification pi:links(pid()) -> [port() | pid()] is a supertype of the success typing: pi:links(pid()) -> [pid()] done in 0m1.45s done (warnings were emitted) However it's clearly not right. For instance: (mynode@REDACTED)1> erlang:process_info(whereis(erl_prim_loader), links). {links,[#Port<0.1>,<0.0.0>]} I wanted to fix it by myself, however could not find the right place to apply the patch. Where can I find specs for ERTS BIFs? Thanks, Michal From pan@REDACTED Fri Oct 19 17:24:05 2012 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 19 Oct 2012 17:24:05 +0200 Subject: [erlang-bugs] Wrong dialyzer spec for erlang:process_info/2 In-Reply-To: References: Message-ID: <50817095.5030402@erlang.org> On 10/19/2012 05:04 PM, Micha? Ptaszek wrote: > Hey, > > Let's define a function which is supposed to return us a list of links > for a given process: > > -spec links(pid()) -> [port() | pid()]. > links(Pid) -> > {links, Links} = process_info(Pid, links), > Links. > > Now let's run the dialyzer on the beam file: > > dialyzer -Wno_return -Wunderspecs --fullpath --plt .plt pi.beam > Checking whether the PLT .plt is up-to-date... yes > Proceeding with analysis... > pi.erl:5: Type specification pi:links(pid()) -> [port() | pid()] is a > supertype of the success typing: pi:links(pid()) -> [pid()] > done in 0m1.45s > done (warnings were emitted) > > However it's clearly not right. For instance: > (mynode@REDACTED)1> erlang:process_info(whereis(erl_prim_loader), links). > {links,[#Port<0.1>,<0.0.0>]} > > I wanted to fix it by myself, however could not find the right place > to apply the patch. Where can I find specs for ERTS BIFs? In master branch, they are in $ERL_TOP/erts/preloaded/src/erlang.erl You need to do a ./otp_build update_preloaded --no-commit and then a make in $ERL_TOP to get it tested. in maint branch, they are 'hardcoded' in erl_bif_types.erl in the hipe application. My recommendation is to *not* go there... > > Thanks, > Michal > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Cheers, /Patrik From kostis@REDACTED Fri Oct 19 18:02:47 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 19 Oct 2012 18:02:47 +0200 Subject: [erlang-bugs] Wrong dialyzer spec for erlang:process_info/2 In-Reply-To: References: Message-ID: <508179A7.9060901@cs.ntua.gr> On 10/19/2012 05:04 PM, Micha? Ptaszek wrote: > Hey, > > Let's define a function which is supposed to return us a list of links > for a given process: > > -spec links(pid()) -> [port() | pid()]. > links(Pid) -> > {links, Links} = process_info(Pid, links), > Links. > > Now let's run the dialyzer on the beam file: > > dialyzer -Wno_return -Wunderspecs --fullpath --plt .plt pi.beam > Checking whether the PLT .plt is up-to-date... yes > Proceeding with analysis... > pi.erl:5: Type specification pi:links(pid()) -> [port() | pid()] is a > supertype of the success typing: pi:links(pid()) -> [pid()] > done in 0m1.45s > done (warnings were emitted) > > However it's clearly not right. For instance: > (mynode@REDACTED)1> erlang:process_info(whereis(erl_prim_loader), links). > {links,[#Port<0.1>,<0.0.0>]} Ah, the hard-coded type information again. The main problem is that this information was obtained by faithfully reading (decrypting?) the Erlang/OTP documentation. Sometimes, this documentation specifies only half the truth... (Also sometimes, this is done on purpose.) For example, the published documentation of process_info/2 reads that the function returns: ... {links, Pids} Pids is a list of pids, with processes to which the process has a link. (See http://erlang.org/doc/man/erlang.html#process_info-2) So, it's not so clear whether the fact that it occasionally also returns ports as well as pids is to be relied upon in applications or not, though most probably it is. *Aside*: I would suggest to the OTP folks to also correct such incomplete inaccurate documentation of the BIFs, not only the specs. > I wanted to fix it by myself, however could not find the right place > to apply the patch. Where can I find specs for ERTS BIFs? In Erlang/OTP R15B02 (and previous) or in 'maint' the hard-coded type information is in lib/hipe/cerl/erl_bif_types.erl. Contrary to what Patrik suggested, in most cases it's actually pretty easy to understand what's going on. For example, the relevant line (in 'maint') is 1270. It currently reads: ['links'] -> t_tuple([InfoItem, t_list(t_pid())]); Change it to: ['links'] -> t_tuple([InfoItem, t_list(t_sup(t_pid(), t_port()))]); Then on the top-level just issue 'make hipe'. The next time you try to run dialyzer it will automatically find out that the PLT is out of date and will rebuild it. Kostis From erlang@REDACTED Fri Oct 19 18:21:14 2012 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Fri, 19 Oct 2012 18:21:14 +0200 Subject: [erlang-bugs] Wrong dialyzer spec for erlang:process_info/2 In-Reply-To: <508179A7.9060901@cs.ntua.gr> References: <508179A7.9060901@cs.ntua.gr> Message-ID: On Fri, Oct 19, 2012 at 6:02 PM, Kostis Sagonas wrote: > On 10/19/2012 05:04 PM, Micha? Ptaszek wrote: >> >> Hey, >> >> Let's define a function which is supposed to return us a list of links >> for a given process: >> >> -spec links(pid()) -> [port() | pid()]. >> links(Pid) -> >> {links, Links} = process_info(Pid, links), >> Links. >> >> Now let's run the dialyzer on the beam file: >> >> dialyzer -Wno_return -Wunderspecs --fullpath --plt .plt pi.beam >> Checking whether the PLT .plt is up-to-date... yes >> Proceeding with analysis... >> pi.erl:5: Type specification pi:links(pid()) -> [port() | pid()] is a >> supertype of the success typing: pi:links(pid()) -> [pid()] >> done in 0m1.45s >> done (warnings were emitted) >> >> However it's clearly not right. For instance: >> (mynode@REDACTED)1> erlang:process_info(whereis(erl_prim_loader), >> links). >> {links,[#Port<0.1>,<0.0.0>]} > > > Ah, the hard-coded type information again. The main problem is that this > information was obtained by faithfully reading (decrypting?) the Erlang/OTP > documentation. Sometimes, this documentation specifies only half the > truth... (Also sometimes, this is done on purpose.) > > For example, the published documentation of process_info/2 reads that the > function returns: > ... > {links, Pids} > Pids is a list of pids, with processes to which the process has a link. > > (See http://erlang.org/doc/man/erlang.html#process_info-2) > > So, it's not so clear whether the fact that it occasionally also returns > ports as well as pids is to be relied upon in applications or not, though > most probably it is. > > *Aside*: I would suggest to the OTP folks to also correct such incomplete > inaccurate documentation of the BIFs, not only the specs. > > >> I wanted to fix it by myself, however could not find the right place >> to apply the patch. Where can I find specs for ERTS BIFs? > > > In Erlang/OTP R15B02 (and previous) or in 'maint' the hard-coded type > information is in lib/hipe/cerl/erl_bif_types.erl. Contrary to what Patrik > suggested, in most cases it's actually pretty easy to understand what's > going on. For example, the relevant line (in 'maint') is 1270. It currently > reads: > > ['links'] -> t_tuple([InfoItem, t_list(t_pid())]); > > Change it to: > > ['links'] -> t_tuple([InfoItem, t_list(t_sup(t_pid(), t_port()))]); > > Then on the top-level just issue 'make hipe'. The next time you try to run > dialyzer it will automatically find out that the PLT is out of date and will > rebuild it. > > Kostis Sure, have done that, patch is available in https://github.com/paulgray/otp/tree/process_info_links_dialyzer_fix Thanks, Michal Ptaszek From fritchie@REDACTED Fri Oct 19 22:57:44 2012 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 19 Oct 2012 15:57:44 -0500 Subject: [erlang-bugs] Escript and fun local_func/arity runtime error Message-ID: <78979.1350680264@snookles.snookles.com> Hi, all. A colleague noticed this less-than-helpful runtime error when using: * escript * "fun local_func/1" syntax The error message: % /usr/local/erlang/R15B02.64bit/bin/escript ~/foo Starting main.... escript: exception error: undefined function erl_eval:bar/0 See the example script below. If your script doesn't have any initial output (as the example does), then the error message could lead the unsuspecting soul to believe that there's a compile-time error. Well, except that escripts aren't really compiled by default, but ... believe that there's a syntax error detected prior to executing main(). But main() really is executing. I don't see fun syntax difference documented in the http://www.erlang.org/doc/man/escript.html reference. Yes, the problem disappears if "-mode(compile)." is added to the script. -Scott --- snip --- snip --- snip --- snip --- snip --- snip --- #!/usr/bin/env escript %%! -args_file ./data/ssl_distribution.args_file %% -*- mode: erlang;erlang-indent-level: 4;indent-tabs-mode: nil -*- %% ex: ft=erlang ts=4 sw=4 et %% ------------------------------------------------------------------- main( _) -> io:format("Starting main....\n"), X = fun() -> foo() end, Y = fun bar/0, X(), Y(). foo() -> io:format("Hello, foo!\n"). bar() -> io:format("Hello, bar!\n"). From mononcqc@REDACTED Fri Oct 19 23:08:31 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 19 Oct 2012 17:08:31 -0400 Subject: [erlang-bugs] Escript and fun local_func/arity runtime error In-Reply-To: <78979.1350680264@snookles.snookles.com> References: <78979.1350680264@snookles.snookles.com> Message-ID: <5081C14F.4060008@ferd.ca> If I recall this error correctly, the fun gets attributed to erl_eval during the evaluation rather than the escript itself. You can solve the problem by adding a -module declaration to the top of the file, if I remember. Regards, Fred. On 12-10-19 4:57 PM, Scott Lystig Fritchie wrote: > Hi, all. A colleague noticed this less-than-helpful runtime error when > using: > > * escript > * "fun local_func/1" syntax > > The error message: > > % /usr/local/erlang/R15B02.64bit/bin/escript ~/foo > Starting main.... > escript: exception error: undefined function erl_eval:bar/0 > > See the example script below. If your script doesn't have any initial > output (as the example does), then the error message could lead the > unsuspecting soul to believe that there's a compile-time error. Well, > except that escripts aren't really compiled by default, but ... believe > that there's a syntax error detected prior to executing main(). But > main() really is executing. > > I don't see fun syntax difference documented in the > http://www.erlang.org/doc/man/escript.html reference. > > Yes, the problem disappears if "-mode(compile)." is added to the script. > > -Scott > > --- snip --- snip --- snip --- snip --- snip --- snip --- > > #!/usr/bin/env escript > %%! -args_file ./data/ssl_distribution.args_file > %% -*- mode: erlang;erlang-indent-level: 4;indent-tabs-mode: nil -*- > %% ex: ft=erlang ts=4 sw=4 et > %% ------------------------------------------------------------------- > > main( _) -> > io:format("Starting main....\n"), > X = fun() -> foo() end, > Y = fun bar/0, > X(), > Y(). > > foo() -> > io:format("Hello, foo!\n"). > > bar() -> > io:format("Hello, bar!\n"). > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From jared@REDACTED Sat Oct 20 00:00:03 2012 From: jared@REDACTED (Jared Morrow) Date: Fri, 19 Oct 2012 16:00:03 -0600 Subject: [erlang-bugs] Escript and fun local_func/arity runtime error In-Reply-To: <5081C14F.4060008@ferd.ca> References: <78979.1350680264@snookles.snookles.com> <5081C14F.4060008@ferd.ca> Message-ID: I was the "colleague" who first hit the issue and was stumped. It is fixed now with the -mode(compile) setting, so chalk this "bug" up to a documentation bug possibly or a "better error should be printed" bug. I had 7 or 8 `fun F/A` callouts in the escript and only the first one in call chain showed the `escript: exception error: undefined function ...` error which led me down a typo, syntax, etc., etc. rabbit hole. Thanks, Jared On Fri, Oct 19, 2012 at 3:08 PM, Fred Hebert wrote: > If I recall this error correctly, the fun gets attributed to erl_eval > during the evaluation rather than the escript itself. You can solve the > problem by adding a -module declaration to the top of the file, if I > remember. > > Regards, > Fred. > > > On 12-10-19 4:57 PM, Scott Lystig Fritchie wrote: > >> Hi, all. A colleague noticed this less-than-helpful runtime error when >> using: >> >> * escript >> * "fun local_func/1" syntax >> >> The error message: >> >> % /usr/local/erlang/R15B02.**64bit/bin/escript ~/foo >> Starting main.... >> escript: exception error: undefined function erl_eval:bar/0 >> >> See the example script below. If your script doesn't have any initial >> output (as the example does), then the error message could lead the >> unsuspecting soul to believe that there's a compile-time error. Well, >> except that escripts aren't really compiled by default, but ... believe >> that there's a syntax error detected prior to executing main(). But >> main() really is executing. >> >> I don't see fun syntax difference documented in the >> http://www.erlang.org/doc/man/**escript.htmlreference. >> >> Yes, the problem disappears if "-mode(compile)." is added to the script. >> >> -Scott >> >> --- snip --- snip --- snip --- snip --- snip --- snip --- >> >> #!/usr/bin/env escript >> %%! -args_file ./data/ssl_distribution.args_**file >> %% -*- mode: erlang;erlang-indent-level: 4;indent-tabs-mode: nil -*- >> %% ex: ft=erlang ts=4 sw=4 et >> %% ------------------------------**------------------------------** >> ------- >> >> main( _) -> >> io:format("Starting main....\n"), >> X = fun() -> foo() end, >> Y = fun bar/0, >> X(), >> Y(). >> >> foo() -> >> io:format("Hello, foo!\n"). >> >> bar() -> >> io:format("Hello, bar!\n"). >> ______________________________**_________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-bugs >> > > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Mon Oct 22 14:53:03 2012 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 22 Oct 2012 14:53:03 +0200 Subject: [erlang-bugs] Wrong dialyzer spec for erlang:process_info/2 In-Reply-To: <508179A7.9060901@cs.ntua.gr> References: <508179A7.9060901@cs.ntua.gr> Message-ID: <508541AF.9020909@erlang.org> Hi Kostis and Micha?! On 10/19/2012 06:02 PM, Kostis Sagonas wrote: > On 10/19/2012 05:04 PM, Micha? Ptaszek wrote: >> Hey, >> >> Let's define a function which is supposed to return us a list of links >> for a given process: >> >> -spec links(pid()) -> [port() | pid()]. >> links(Pid) -> >> {links, Links} = process_info(Pid, links), >> Links. >> >> Now let's run the dialyzer on the beam file: >> >> dialyzer -Wno_return -Wunderspecs --fullpath --plt .plt pi.beam >> Checking whether the PLT .plt is up-to-date... yes >> Proceeding with analysis... >> pi.erl:5: Type specification pi:links(pid()) -> [port() | pid()] is a >> supertype of the success typing: pi:links(pid()) -> [pid()] >> done in 0m1.45s >> done (warnings were emitted) >> >> However it's clearly not right. For instance: >> (mynode@REDACTED)1> erlang:process_info(whereis(erl_prim_loader), >> links). >> {links,[#Port<0.1>,<0.0.0>]} > > Ah, the hard-coded type information again. The main problem is that > this information was obtained by faithfully reading (decrypting?) the > Erlang/OTP documentation. Sometimes, this documentation specifies only > half the truth... (Also sometimes, this is done on purpose.) > > For example, the published documentation of process_info/2 reads that > the function returns: > ... > {links, Pids} > Pids is a list of pids, with processes to which the process has a > link. > > (See http://erlang.org/doc/man/erlang.html#process_info-2) > > So, it's not so clear whether the fact that it occasionally also > returns ports as well as pids is to be relied upon in applications or > not, though most probably it is. > > *Aside*: I would suggest to the OTP folks to also correct such > incomplete inaccurate documentation of the BIFs, not only the specs. You'll be happy to hear that the documentation is derived from the specs for most functions, built in or not, in R16 (which was a lot harder in R15, due to erl_bif_types). So, what's in the docs will be what's in the specs - though for builtin functions, there may be discrepancies between the spec and the implementation, as in this case, which is still wrong in master (until I fix it :)). > >> I wanted to fix it by myself, however could not find the right place >> to apply the patch. Where can I find specs for ERTS BIFs? > > In Erlang/OTP R15B02 (and previous) or in 'maint' the hard-coded type > information is in lib/hipe/cerl/erl_bif_types.erl. Contrary to what > Patrik suggested, in most cases it's actually pretty easy to > understand what's going on. For example, the relevant line (in > 'maint') is 1270. It currently reads: > > ['links'] -> t_tuple([InfoItem, t_list(t_pid())]); > > Change it to: > > ['links'] -> t_tuple([InfoItem, t_list(t_sup(t_pid(), t_port()))]); > > Then on the top-level just issue 'make hipe'. The next time you try > to run dialyzer it will automatically find out that the PLT is out of > date and will rebuild it. > The thing is that it's kind of wasting time doing a change in maint as the mechanism is totally changed in master. Changes to maint in this area can not in any way be automatically merged to master - so better to do it in the new way and use Micha?s valuable time to correct the error in master. That's why I said don't go there, not because I thought it was hard to fix there :) > Kostis Cheers, /Patrik > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From essen@REDACTED Mon Oct 22 17:11:08 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 22 Oct 2012 17:11:08 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <507D8DC3.6050507@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> Message-ID: <5085620C.80904@ninenines.eu> Waaaaiiiiit. On 10/16/2012 06:39 PM, Ingela Anderton Andin wrote: > Lo?c Hoguin wrote: >> 103> erlang:port_info(Port). >> [{name,"tcp_inet"}, >> {links,[<0.18199.1670>]}, >> {id,51824890}, >> {connected,<0.18199.1670>}, >> {input,0}, I don't understand this here. Isn't this the total number of bytes read on the port? Does that mean it didn't read anything? Perhaps the port never sent anything? >> {output,3583}] >> 104> Pid. >> <0.18199.1670> -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Mon Oct 22 18:07:29 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 22 Oct 2012 18:07:29 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <5085620C.80904@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <5085620C.80904@ninenines.eu> Message-ID: <50856F41.7050100@ninenines.eu> The processes that work have this in the logs: (Reason, StateName, Stacktrace) 2012-10-22 18:01:09.394 [error] <0.550.3862> normal connection [] (erlang:port_info) 2012-10-22 18:01:09.395 [error] <0.550.3862> [{name,"tcp_inet"},{links,[<0.550.3862>]},{id,56382467},{connected,<0.550.3862>},{input,0},{output,6709}] (log from right after it worked) 2012-10-22 18:01:11.143 [error] <0.550.3862> ok The ones that didn't come from the 2nd terminate clause and have this: 2012-10-22 18:01:02.484 [error] <0.11277.3891> normal connection [{ssl_certificate,'-find_issuer/2-fun-0-',3,[{file,"ssl_certificate.erl"},{line,234}]},{lists,foldl,3,[{file,"lists.erl"},{line,1197}]},{ets,do_foldl,4,[{file,"ets.erl"},{line,198}]},{ets,foldl,3,[{file,"ets.erl"},{line,187}]},{ssl_certificate,find_issuer,2,[{file,"ssl_certificate.erl"},{line,242}]},{ssl_certificate,certificate_chain,5,[{file,"ssl_certificate.erl"},{line,196}]},{ssl_handshake,certificate,4,[{file,"ssl_handshake.erl"},{line,248}]},{ssl_connection,certify_server,1,[{file,"ssl_connection.erl"},{line,1412}]}] 2012-10-22 18:01:02.485 [error] <0.11277.3891> [{name,"tcp_inet"},{links,[<0.11277.3891>]},{id,57414295},{connected,<0.11277.3891>},{input,0},{output,3885}] Or this: 2012-10-22 18:01:04.554 [error] <0.3464.3901> normal connection [] 2012-10-22 18:01:04.609 [error] <0.3464.3901> [{name,"tcp_inet"},{links,[<0.3464.3901>]},{id,57763881},{connected,<0.3464.3901>},{input,0},{output,1794}] I also observe all processes on the third terminate clause to return the same values in the workaround function: {error, einval} from inet:setopts and {error, closed} from Transport:shutdown. Didn't check the recv return value but this clause always work anyway. Thoughts? What next? On 10/22/2012 05:11 PM, Lo?c Hoguin wrote: > Waaaaiiiiit. > > On 10/16/2012 06:39 PM, Ingela Anderton Andin wrote: >> Lo?c Hoguin wrote: >>> 103> erlang:port_info(Port). >>> [{name,"tcp_inet"}, >>> {links,[<0.18199.1670>]}, >>> {id,51824890}, >>> {connected,<0.18199.1670>}, >>> {input,0}, > > I don't understand this here. Isn't this the total number of bytes read > on the port? > > Does that mean it didn't read anything? Perhaps the port never sent > anything? > >>> {output,3583}] >>> 104> Pid. >>> <0.18199.1670> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Wed Oct 24 11:24:50 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 24 Oct 2012 11:24:50 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <5080211A.2060805@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> <5080211A.2060805@ninenines.eu> Message-ID: <5087B3E2.6070009@ericsson.com> Hi! Lo?c Hoguin wrote: > This doesn't make a difference so far. This would only make a differnce if you do not set active explicitly. Anyway I have a theory that perhaps the inet driver can hang if you try to do recv on a socket that has been shutdown for writing from the other side or maybe some strange race condition. I have no evidence that this is so, for now I just think it fits the scenario of what seems to happen. I think that ssl should have a new terminate clause that avoids doing socket operations that are logically not necessary, even if it can be considered a bug that the inet driver hangs. So first step try this patch and see if your problem goes away. If yes that is the solution for you and the ssl-application and we will have to try and pinpoint the actual problem in the inet driver and fix that. diff --git a/lib/ssl/src/ssl_connection.erl b/lib/ssl/src/ssl_connection.erl index 1319b54..c9c162b 100644 --- a/lib/ssl/src/ssl_connection.erl +++ b/lib/ssl/src/ssl_connection.erl @@ -984,7 +984,7 @@ handle_info({CloseTag, Socket}, StateName, ok end, handle_normal_shutdown(?ALERT_REC(?FATAL, ?CLOSE_NOTIFY), StateName, State), - {stop, normal, State}; + {stop, {shutdown, transport_closed}, State}; handle_info({ErrorTag, Socket, econnaborted}, StateName, #state{socket = Socket, start_or_recv_from = StartFrom, role = Role, @@ -1022,6 +1022,14 @@ terminate(_, _, #state{terminated = true}) -> %% we want to guarantee that Transport:close has been called %% when ssl:close/1 returns. ok; + +terminate({shutdown, transport_closed}, _, #state{negotiated_version = Version, + send_queue = SendQueue, + renegotiation = Renegotiate} = State) -> + handle_trusted_certs_db(State), + notify_senders(SendQueue), + notify_renegotiater(Renegotiate); + terminate(Reason, connection, #state{negotiated_version = Version, connection_states = ConnectionStates, transport_cb = Transport, Regards Ingela Erlang/OTP team - Ericsson AB > On 10/17/2012 09:51 AM, Ingela Anderton Andin wrote: >> Hi! >> >> My problem goes away with the following patch >> >> diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl >> index 7788f75..771bfa5 100644 >> --- a/lib/ssl/src/ssl.erl >> +++ b/lib/ssl/src/ssl.erl >> @@ -869,10 +869,10 @@ internal_inet_values() -> >> >> socket_options(InetValues) -> >> #socket_options{ >> - mode = proplists:get_value(mode, InetValues), >> - header = proplists:get_value(header, InetValues), >> - active = proplists:get_value(active, InetValues), >> - packet = proplists:get_value(packet, InetValues), >> + mode = proplists:get_value(mode, InetValues, lists), >> + header = proplists:get_value(header, InetValues, 0), >> + active = proplists:get_value(active, InetValues, active), >> + packet = proplists:get_value(packet, InetValues, 0), >> packet_size = proplists:get_value(packet_size, >> InetValues) >> }. >> >> >> e.i. default values where not properly handled. I know to little >> about your configuration to say if this is your problem too. If not >> it would be great if you could >> give me a way to recreate your problem. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >> Ingela Anderton Andin wrote: >>> Hi! >>> >>> This is puzzling. Links seems to be intact. And the supervisor should >>> have killed the gen_fsm-process if it gets stuck in terminate. >>> >>> I tried to recreate your problem, I did get a process leak problem, >>> however it did not manifest itself in quite the same way as yours. >>> >>> In my case I have an active process that seems to not have received >>> the tcp_close message. The fsm procss emulates active option as it >>> uses active once to receive TLS packets. If I set the active option >>> the process will terminate. At the moment I am have not found the root >>> of why it is not working as expected e.i. if it is the emulating code >>> that does something wrong or it perhaps is the inet driver. Will have >>> to keep digging. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> Lo?c Hoguin wrote: >>>> 103> erlang:port_info(Port). >>>> [{name,"tcp_inet"}, >>>> {links,[<0.18199.1670>]}, >>>> {id,51824890}, >>>> {connected,<0.18199.1670>}, >>>> {input,0}, >>>> {output,3583}] >>>> 104> Pid. >>>> <0.18199.1670> >>>> >>>> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >>>>> Hi! >>>>> >>>>> Ok, next question can you do a port_info on the linked port? >>>>> >>>>> Regards Ingela Erlang/OTP Team - Ericsson AB >>>>> >>>>> Lo?c Hoguin wrote: >>>>>> Hey, >>>>>> >>>>>> Here's one: >>>>>> >>>>>> [{current_function,{prim_inet,recv0,3}}, >>>>>> {initial_call,{proc_lib,init_p,5}}, >>>>>> {status,waiting}, >>>>>> {message_queue_len,2}, >>>>>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>>>>> get_status}, >>>>>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>>>>> {links,[<0.897.0>,#Port<0.51824890>]}, >>>>>> {dictionary,[{ssl_manager,ssl_manager}, >>>>>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>>>>> {'$initial_call',{ssl_connection,init,1}}]}, >>>>>> {trap_exit,false}, >>>>>> {error_handler,error_handler}, >>>>>> {priority,normal}, >>>>>> {group_leader,<0.893.0>}, >>>>>> {total_heap_size,10946}, >>>>>> {heap_size,4181}, >>>>>> {stack_size,21}, >>>>>> {reductions,8272}, >>>>>> {garbage_collection,[{min_bin_vheap_size,46368}, >>>>>> {min_heap_size,233}, >>>>>> {fullsweep_after,10}, >>>>>> {minor_gcs,1}]}, >>>>>> {suspending,[]}] >>>>>> >>>>>> The two get_status were me trying to inspect and getting a timeout. >>>>>> >>>>>> Will try commenting the function, that was my guess also. Doesn't >>>>>> explain the other half of the processes though which still seem to be >>>>>> running happily despite the process owning the socket being dead for >>>>>> days. >>>>>> >>>>>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>>>>> Hi! >>>>>>> >>>>>>> This sounds really strange it would be interesting to see all >>>>>>> process_info available for the process. >>>>>>> >>>>>>> Something you could try is to comment out the invocation of the >>>>>>> function >>>>>>> workaround_transport_delivery_problems in the terminate function >>>>>>> of the >>>>>>> ssl_connection-process. This function can call recv(S, 0) and >>>>>>> sounds >>>>>>> like the probable recv that hangs even though it should not. >>>>>>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> >>>>>>> >>>>>>> Lo?c Hoguin wrote: >>>>>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>>>>> 2012/10/15 Lo?c Hoguin : >>>>>>>>> [...] >>>>>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>>>>> undefined -> >>>>>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, >>>>>>>>>>> Sum) >>>>>>>>>>> of false >>>>>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, >>>>>>>>>>> {XXX, >>>>>>>>>>> Curr + >>>>>>>>>>> 1}) end end, [], List). >>>>>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>>>>> >>>>>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>>>>> FIN_WAIT2. >>>>>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>>>>> prim_inet:recv0/3 because the receive there is quite specific. >>>>>>>>>> So I >>>>>>>>>> can't >>>>>>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>>>>>> useful (for >>>>>>>>>> my level of knowledge, anyway). >>>>>>>>> >>>>>>>>> You can get the stacktrace with erlang:process_info(Pid, >>>>>>>>> backtrace). >>>>>>>> >>>>>>>> Thanks for the tip! >>>>>>>> >>>>>>>> So yeah, this one is stuck while trying to terminate. >>>>>>>> >>>>>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>>>>> CP: 0x0000000000000000 (invalid) >>>>>>>> arity = 0 >>>>>>>> >>>>>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>>>>> (ssl_connection:terminate/3 + 800) >>>>>>>> y(0) 57928 >>>>>>>> y(1) #Port<0.51824890> >>>>>>>> >>>>>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 >>>>>>>> (gen_fsm:terminate/7 >>>>>>>> + 168) >>>>>>>> y(0) [] >>>>>>>> y(1) [] >>>>>>>> y(2) [] >>>>>>>> y(3) [] >>>>>>>> y(4) #Port<0.51824890> >>>>>>>> y(5) gen_tcp >>>>>>>> >>>>>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>>>>> y(0) [] >>>>>>>> y(1) >>>>>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>> bytes>>,<<2 bytes>>,<<2 >>>>>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>> bytes>>,<<32 >>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>> bytes>>,<<32 >>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 >>>>>>>> bytes>>},[],12308,{session,<<32 >>>>>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432 467 >>>>>>>> >>>>>>>> >>> 00 >>>>>>>> >>>>>>>> >>>>> 42 >>>>>>>> >>>>>>>> >>>>>>> 51893513795 >>>>>>>> >>>>>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653 778 >>>>>>>> >>>>>>>> >>> 01 >>>>>>>> >>>>>>>> >>>>> 12 >>>>>>>> >>>>>>>> >>>>>>> 80640103960 >>>>>>>> >>>>>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604 875 >>>>>>>> >>>>>>>> >>> 60 >>>>>>>> >>>>>>>> >>>>> 11 >>>>>>>> >>>>>>>> >>>>>>> 70644442368 >>>>>>>> >>>>>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>>>>> y(2) connection >>>>>>>> y(3) ssl_connection >>>>>>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>>>>> y(5) <0.18199.1670> >>>>>>>> y(6) normal >>>>>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>>>>> >>>>>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>>>>> process >>>>>>>> normally>) >>>>>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + 88) >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> > > From matthias@REDACTED Wed Oct 24 11:49:50 2012 From: matthias@REDACTED (Matthias Radestock) Date: Wed, 24 Oct 2012 10:49:50 +0100 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <5087B3E2.6070009@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> <5080211A.2060805@ninenines.eu> <5087B3E2.6070009@ericsson.com> Message-ID: <5087B9BE.8000806@rabbitmq.com> Ingela, On 24/10/12 10:24, Ingela Anderton Andin wrote: > Anyway I have a theory that perhaps the inet driver can hang > if you try to do recv on a socket that has been shutdown for > writing from the other side or maybe some strange race condition. > I have no evidence that this is so, for now I just think it fits the > scenario of what seems to happen. > > I think that ssl should have a new terminate clause that > avoids doing socket operations that are logically not necessary, even if > it can be considered a bug that the inet driver hangs. The following code & explanation from RabbitMQ might be pertinent: http://hg.rabbitmq.com/rabbitmq-server/file/518a3f494190/src/rabbit_net.erl#l153 Regards, Matthias. From essen@REDACTED Wed Oct 24 14:14:35 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 24 Oct 2012 14:14:35 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <5087B3E2.6070009@ericsson.com> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> <5080211A.2060805@ninenines.eu> <5087B3E2.6070009@ericsson.com> Message-ID: <5087DBAB.8090403@ninenines.eu> Hey, I would like to try but this patch isn't correct for R15B01. :) handle_trusted_certs_db doesn't seem to exist. On 10/24/2012 11:24 AM, Ingela Anderton Andin wrote: > Hi! > > Lo?c Hoguin wrote: >> This doesn't make a difference so far. > > This would only make a differnce if you do not set active > explicitly. > > Anyway I have a theory that perhaps the inet driver can hang > if you try to do recv on a socket that has been shutdown for > writing from the other side or maybe some strange race condition. > I have no evidence that this is so, for now I just think it fits the > scenario of what seems to happen. > > I think that ssl should have a new terminate clause that > avoids doing socket operations that are logically not necessary, even if > it can be considered a bug that the inet driver hangs. > > So first step try this patch and see if your problem goes away. If yes > that is the solution for you and the ssl-application and we will have > to try and pinpoint the actual problem in the inet driver and fix that. > > > diff --git a/lib/ssl/src/ssl_connection.erl > b/lib/ssl/src/ssl_connection.erl > index 1319b54..c9c162b 100644 > --- a/lib/ssl/src/ssl_connection.erl > +++ b/lib/ssl/src/ssl_connection.erl > @@ -984,7 +984,7 @@ handle_info({CloseTag, Socket}, StateName, > ok > end, > handle_normal_shutdown(?ALERT_REC(?FATAL, ?CLOSE_NOTIFY), > StateName, State), > - {stop, normal, State}; > + {stop, {shutdown, transport_closed}, State}; > > handle_info({ErrorTag, Socket, econnaborted}, StateName, > #state{socket = Socket, start_or_recv_from = StartFrom, > role = Role, > @@ -1022,6 +1022,14 @@ terminate(_, _, #state{terminated = true}) -> > %% we want to guarantee that Transport:close has been called > %% when ssl:close/1 returns. > ok; > + > +terminate({shutdown, transport_closed}, _, #state{negotiated_version = > Version, > + send_queue = SendQueue, > + renegotiation = > Renegotiate} = State) -> > + handle_trusted_certs_db(State), > + notify_senders(SendQueue), > + notify_renegotiater(Renegotiate); > + > terminate(Reason, connection, #state{negotiated_version = Version, > connection_states = > ConnectionStates, > transport_cb = Transport, > > > Regards Ingela Erlang/OTP team - Ericsson AB > > >> On 10/17/2012 09:51 AM, Ingela Anderton Andin wrote: >>> Hi! >>> >>> My problem goes away with the following patch >>> >>> diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl >>> index 7788f75..771bfa5 100644 >>> --- a/lib/ssl/src/ssl.erl >>> +++ b/lib/ssl/src/ssl.erl >>> @@ -869,10 +869,10 @@ internal_inet_values() -> >>> >>> socket_options(InetValues) -> >>> #socket_options{ >>> - mode = proplists:get_value(mode, InetValues), >>> - header = proplists:get_value(header, InetValues), >>> - active = proplists:get_value(active, InetValues), >>> - packet = proplists:get_value(packet, InetValues), >>> + mode = proplists:get_value(mode, InetValues, lists), >>> + header = proplists:get_value(header, InetValues, 0), >>> + active = proplists:get_value(active, InetValues, >>> active), >>> + packet = proplists:get_value(packet, InetValues, 0), >>> packet_size = proplists:get_value(packet_size, >>> InetValues) >>> }. >>> >>> >>> e.i. default values where not properly handled. I know to little >>> about your configuration to say if this is your problem too. If not >>> it would be great if you could >>> give me a way to recreate your problem. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> This is puzzling. Links seems to be intact. And the supervisor should >>>> have killed the gen_fsm-process if it gets stuck in terminate. >>>> >>>> I tried to recreate your problem, I did get a process leak problem, >>>> however it did not manifest itself in quite the same way as yours. >>>> >>>> In my case I have an active process that seems to not have received >>>> the tcp_close message. The fsm procss emulates active option as it >>>> uses active once to receive TLS packets. If I set the active option >>>> the process will terminate. At the moment I am have not found the root >>>> of why it is not working as expected e.i. if it is the emulating code >>>> that does something wrong or it perhaps is the inet driver. Will have >>>> to keep digging. >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>> Lo?c Hoguin wrote: >>>>> 103> erlang:port_info(Port). >>>>> [{name,"tcp_inet"}, >>>>> {links,[<0.18199.1670>]}, >>>>> {id,51824890}, >>>>> {connected,<0.18199.1670>}, >>>>> {input,0}, >>>>> {output,3583}] >>>>> 104> Pid. >>>>> <0.18199.1670> >>>>> >>>>> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >>>>>> Hi! >>>>>> >>>>>> Ok, next question can you do a port_info on the linked port? >>>>>> >>>>>> Regards Ingela Erlang/OTP Team - Ericsson AB >>>>>> >>>>>> Lo?c Hoguin wrote: >>>>>>> Hey, >>>>>>> >>>>>>> Here's one: >>>>>>> >>>>>>> [{current_function,{prim_inet,recv0,3}}, >>>>>>> {initial_call,{proc_lib,init_p,5}}, >>>>>>> {status,waiting}, >>>>>>> {message_queue_len,2}, >>>>>>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>>>>>> get_status}, >>>>>>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>>>>>> {links,[<0.897.0>,#Port<0.51824890>]}, >>>>>>> {dictionary,[{ssl_manager,ssl_manager}, >>>>>>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>>>>>> {'$initial_call',{ssl_connection,init,1}}]}, >>>>>>> {trap_exit,false}, >>>>>>> {error_handler,error_handler}, >>>>>>> {priority,normal}, >>>>>>> {group_leader,<0.893.0>}, >>>>>>> {total_heap_size,10946}, >>>>>>> {heap_size,4181}, >>>>>>> {stack_size,21}, >>>>>>> {reductions,8272}, >>>>>>> {garbage_collection,[{min_bin_vheap_size,46368}, >>>>>>> {min_heap_size,233}, >>>>>>> {fullsweep_after,10}, >>>>>>> {minor_gcs,1}]}, >>>>>>> {suspending,[]}] >>>>>>> >>>>>>> The two get_status were me trying to inspect and getting a timeout. >>>>>>> >>>>>>> Will try commenting the function, that was my guess also. Doesn't >>>>>>> explain the other half of the processes though which still seem >>>>>>> to be >>>>>>> running happily despite the process owning the socket being dead for >>>>>>> days. >>>>>>> >>>>>>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> This sounds really strange it would be interesting to see all >>>>>>>> process_info available for the process. >>>>>>>> >>>>>>>> Something you could try is to comment out the invocation of the >>>>>>>> function >>>>>>>> workaround_transport_delivery_problems in the terminate function >>>>>>>> of the >>>>>>>> ssl_connection-process. This function can call recv(S, 0) and >>>>>>>> sounds >>>>>>>> like the probable recv that hangs even though it should not. >>>>>>>> >>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>> >>>>>>>> >>>>>>>> Lo?c Hoguin wrote: >>>>>>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>>>>>> 2012/10/15 Lo?c Hoguin : >>>>>>>>>> [...] >>>>>>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>>>>>> undefined -> >>>>>>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, >>>>>>>>>>>> Sum) >>>>>>>>>>>> of false >>>>>>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, >>>>>>>>>>>> {XXX, >>>>>>>>>>>> Curr + >>>>>>>>>>>> 1}) end end, [], List). >>>>>>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>>>>>> >>>>>>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>>>>>> FIN_WAIT2. >>>>>>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>>>>>> prim_inet:recv0/3 because the receive there is quite specific. >>>>>>>>>>> So I >>>>>>>>>>> can't >>>>>>>>>>> get the stacktrace. The other case doesn't seem to give anything >>>>>>>>>>> useful (for >>>>>>>>>>> my level of knowledge, anyway). >>>>>>>>>> >>>>>>>>>> You can get the stacktrace with erlang:process_info(Pid, >>>>>>>>>> backtrace). >>>>>>>>> >>>>>>>>> Thanks for the tip! >>>>>>>>> >>>>>>>>> So yeah, this one is stuck while trying to terminate. >>>>>>>>> >>>>>>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>>>>>> CP: 0x0000000000000000 (invalid) >>>>>>>>> arity = 0 >>>>>>>>> >>>>>>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>>>>>> (ssl_connection:terminate/3 + 800) >>>>>>>>> y(0) 57928 >>>>>>>>> y(1) #Port<0.51824890> >>>>>>>>> >>>>>>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 >>>>>>>>> (gen_fsm:terminate/7 >>>>>>>>> + 168) >>>>>>>>> y(0) [] >>>>>>>>> y(1) [] >>>>>>>>> y(2) [] >>>>>>>>> y(3) [] >>>>>>>>> y(4) #Port<0.51824890> >>>>>>>>> y(5) gen_tcp >>>>>>>>> >>>>>>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>>>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>>>>>> y(0) [] >>>>>>>>> y(1) >>>>>>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>>> bytes>>,<<2 bytes>>,<<2 >>>>>>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>>> bytes>>,<<32 >>>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>>> bytes>>,<<32 >>>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 >>>>>>>>> bytes>>},[],12308,{session,<<32 >>>>>>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>>>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,72894561061836369429952440001397404435381791098810666626550009339627280447692213756327103684977349565388024121690992163627770872919426951949943259565185707278720577541631553578110444175680062658469881781442213382568569223796242089823480188432 >>>>>>>>> > 467 >>>>>>>>> >>>>>>>>> >>>> 00 >>>>>>>>> >>>>>>>>> >>>>>> 42 >>>>>>>>> >>>>>>>>> >>>>>>>> 51893513795 >>>>>>>>> >>>>>>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,1653 >>>>>>>>> > 778 >>>>>>>>> >>>>>>>>> >>>> 01 >>>>>>>>> >>>>>>>>> >>>>>> 12 >>>>>>>>> >>>>>>>>> >>>>>>>> 80640103960 >>>>>>>>> >>>>>>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',17976931348623159077083915679378745319786029604 >>>>>>>>> > 875 >>>>>>>>> >>>>>>>>> >>>> 60 >>>>>>>>> >>>>>>>>> >>>>>> 11 >>>>>>>>> >>>>>>>>> >>>>>>>> 70644442368 >>>>>>>>> >>>>>>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>>>>>> y(2) connection >>>>>>>>> y(3) ssl_connection >>>>>>>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>>>>>> y(5) <0.18199.1670> >>>>>>>>> y(6) normal >>>>>>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>>>>>> >>>>>>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>>>>>> process >>>>>>>>> normally>) >>>>>>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + >>>>>>>>> 88) >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>> >>> >> >> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From Ingela.Anderton.Andin@REDACTED Wed Oct 24 14:59:25 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 24 Oct 2012 14:59:25 +0200 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <5087DBAB.8090403@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> <5080211A.2060805@ninenines.eu> <5087B3E2.6070009@ericsson.com> <5087DBAB.8090403@ninenines.eu> Message-ID: <5087E62D.3040304@ericsson.com> Hi! Lo?c Hoguin wrote: > Hey, > > I would like to try but this patch isn't correct for R15B01. :) > > handle_trusted_certs_db doesn't seem to exist. Sorry it was based on master. It should work for R15B01 if you remove the handle_trusted_certs_db(State), line. Regards Ingela Erlang/OTP team > > On 10/24/2012 11:24 AM, Ingela Anderton Andin wrote: >> Hi! >> >> Lo?c Hoguin wrote: >>> This doesn't make a difference so far. >> >> This would only make a differnce if you do not set active >> explicitly. >> >> Anyway I have a theory that perhaps the inet driver can hang >> if you try to do recv on a socket that has been shutdown for >> writing from the other side or maybe some strange race condition. >> I have no evidence that this is so, for now I just think it fits the >> scenario of what seems to happen. >> >> I think that ssl should have a new terminate clause that >> avoids doing socket operations that are logically not necessary, even if >> it can be considered a bug that the inet driver hangs. >> >> So first step try this patch and see if your problem goes away. If yes >> that is the solution for you and the ssl-application and we will have >> to try and pinpoint the actual problem in the inet driver and fix that. >> >> >> diff --git a/lib/ssl/src/ssl_connection.erl >> b/lib/ssl/src/ssl_connection.erl >> index 1319b54..c9c162b 100644 >> --- a/lib/ssl/src/ssl_connection.erl >> +++ b/lib/ssl/src/ssl_connection.erl >> @@ -984,7 +984,7 @@ handle_info({CloseTag, Socket}, StateName, >> ok >> end, >> handle_normal_shutdown(?ALERT_REC(?FATAL, ?CLOSE_NOTIFY), >> StateName, State), >> - {stop, normal, State}; >> + {stop, {shutdown, transport_closed}, State}; >> >> handle_info({ErrorTag, Socket, econnaborted}, StateName, >> #state{socket = Socket, start_or_recv_from = StartFrom, >> role = Role, >> @@ -1022,6 +1022,14 @@ terminate(_, _, #state{terminated = true}) -> >> %% we want to guarantee that Transport:close has been called >> %% when ssl:close/1 returns. >> ok; >> + >> +terminate({shutdown, transport_closed}, _, #state{negotiated_version = >> Version, >> + send_queue = SendQueue, >> + renegotiation = >> Renegotiate} = State) -> >> + handle_trusted_certs_db(State), >> + notify_senders(SendQueue), >> + notify_renegotiater(Renegotiate); >> + >> terminate(Reason, connection, #state{negotiated_version = Version, >> connection_states = >> ConnectionStates, >> transport_cb = Transport, >> >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> On 10/17/2012 09:51 AM, Ingela Anderton Andin wrote: >>>> Hi! >>>> >>>> My problem goes away with the following patch >>>> >>>> diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl >>>> index 7788f75..771bfa5 100644 >>>> --- a/lib/ssl/src/ssl.erl >>>> +++ b/lib/ssl/src/ssl.erl >>>> @@ -869,10 +869,10 @@ internal_inet_values() -> >>>> >>>> socket_options(InetValues) -> >>>> #socket_options{ >>>> - mode = proplists:get_value(mode, InetValues), >>>> - header = proplists:get_value(header, InetValues), >>>> - active = proplists:get_value(active, InetValues), >>>> - packet = proplists:get_value(packet, InetValues), >>>> + mode = proplists:get_value(mode, InetValues, lists), >>>> + header = proplists:get_value(header, InetValues, 0), >>>> + active = proplists:get_value(active, InetValues, >>>> active), >>>> + packet = proplists:get_value(packet, InetValues, 0), >>>> packet_size = proplists:get_value(packet_size, >>>> InetValues) >>>> }. >>>> >>>> >>>> e.i. default values where not properly handled. I know to little >>>> about your configuration to say if this is your problem too. If not >>>> it would be great if you could >>>> give me a way to recreate your problem. >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>> Ingela Anderton Andin wrote: >>>>> Hi! >>>>> >>>>> This is puzzling. Links seems to be intact. And the supervisor should >>>>> have killed the gen_fsm-process if it gets stuck in terminate. >>>>> >>>>> I tried to recreate your problem, I did get a process leak problem, >>>>> however it did not manifest itself in quite the same way as yours. >>>>> >>>>> In my case I have an active process that seems to not have received >>>>> the tcp_close message. The fsm procss emulates active option as it >>>>> uses active once to receive TLS packets. If I set the active option >>>>> the process will terminate. At the moment I am have not found the root >>>>> of why it is not working as expected e.i. if it is the emulating code >>>>> that does something wrong or it perhaps is the inet driver. Will have >>>>> to keep digging. >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>>> Lo?c Hoguin wrote: >>>>>> 103> erlang:port_info(Port). >>>>>> [{name,"tcp_inet"}, >>>>>> {links,[<0.18199.1670>]}, >>>>>> {id,51824890}, >>>>>> {connected,<0.18199.1670>}, >>>>>> {input,0}, >>>>>> {output,3583}] >>>>>> 104> Pid. >>>>>> <0.18199.1670> >>>>>> >>>>>> On 10/16/2012 11:55 AM, Ingela Anderton Andin wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Ok, next question can you do a port_info on the linked port? >>>>>>> >>>>>>> Regards Ingela Erlang/OTP Team - Ericsson AB >>>>>>> >>>>>>> Lo?c Hoguin wrote: >>>>>>>> Hey, >>>>>>>> >>>>>>>> Here's one: >>>>>>>> >>>>>>>> [{current_function,{prim_inet,recv0,3}}, >>>>>>>> {initial_call,{proc_lib,init_p,5}}, >>>>>>>> {status,waiting}, >>>>>>>> {message_queue_len,2}, >>>>>>>> {messages,[{system,{<0.1523.2358>,#Ref<0.0.9161.247946>}, >>>>>>>> get_status}, >>>>>>>> {system,{<0.19941.2364>,#Ref<0.0.9166.119462>},get_status}]}, >>>>>>>> {links,[<0.897.0>,#Port<0.51824890>]}, >>>>>>>> {dictionary,[{ssl_manager,ssl_manager}, >>>>>>>> >>>>>>>> {'$ancestors',[ssl_connection_sup,ssl_sup,<0.894.0>]}, >>>>>>>> {'$initial_call',{ssl_connection,init,1}}]}, >>>>>>>> {trap_exit,false}, >>>>>>>> {error_handler,error_handler}, >>>>>>>> {priority,normal}, >>>>>>>> {group_leader,<0.893.0>}, >>>>>>>> {total_heap_size,10946}, >>>>>>>> {heap_size,4181}, >>>>>>>> {stack_size,21}, >>>>>>>> {reductions,8272}, >>>>>>>> {garbage_collection,[{min_bin_vheap_size,46368}, >>>>>>>> {min_heap_size,233}, >>>>>>>> {fullsweep_after,10}, >>>>>>>> {minor_gcs,1}]}, >>>>>>>> {suspending,[]}] >>>>>>>> >>>>>>>> The two get_status were me trying to inspect and getting a timeout. >>>>>>>> >>>>>>>> Will try commenting the function, that was my guess also. Doesn't >>>>>>>> explain the other half of the processes though which still seem >>>>>>>> to be >>>>>>>> running happily despite the process owning the socket being dead >>>>>>>> for >>>>>>>> days. >>>>>>>> >>>>>>>> On 10/16/2012 11:18 AM, Ingela Anderton Andin wrote: >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> This sounds really strange it would be interesting to see all >>>>>>>>> process_info available for the process. >>>>>>>>> >>>>>>>>> Something you could try is to comment out the invocation of the >>>>>>>>> function >>>>>>>>> workaround_transport_delivery_problems in the terminate function >>>>>>>>> of the >>>>>>>>> ssl_connection-process. This function can call recv(S, 0) and >>>>>>>>> sounds >>>>>>>>> like the probable recv that hangs even though it should not. >>>>>>>>> >>>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>>> >>>>>>>>> >>>>>>>>> Lo?c Hoguin wrote: >>>>>>>>>> On 10/15/2012 06:09 PM, Attila Rajmund Nohl wrote: >>>>>>>>>>> 2012/10/15 Lo?c Hoguin : >>>>>>>>>>> [...] >>>>>>>>>>>>> lists:foldl(fun(X, Sum) -> case erlang:process_info(X) of >>>>>>>>>>>>> undefined -> >>>>>>>>>>>>> Sum; [{current_function, XXX}|_] -> case lists:keyfind(XXX, 1, >>>>>>>>>>>>> Sum) >>>>>>>>>>>>> of false >>>>>>>>>>>>> -> Curr = 0; {_, Curr} -> ok end, lists:keystore(XXX, 1, Sum, >>>>>>>>>>>>> {XXX, >>>>>>>>>>>>> Curr + >>>>>>>>>>>>> 1}) end end, [], List). >>>>>>>>>>>> [{{prim_inet,recv0,3},25856},{{gen_fsm,loop,7},26574}] >>>>>>>>>>>> >>>>>>>>>>>> Not sure which one is the ESTABLISHED list and which one is the >>>>>>>>>>>> FIN_WAIT2. >>>>>>>>>>>> Of course, I can't use sys:get_status/1 on the PIDs stuck in >>>>>>>>>>>> prim_inet:recv0/3 because the receive there is quite specific. >>>>>>>>>>>> So I >>>>>>>>>>>> can't >>>>>>>>>>>> get the stacktrace. The other case doesn't seem to give >>>>>>>>>>>> anything >>>>>>>>>>>> useful (for >>>>>>>>>>>> my level of knowledge, anyway). >>>>>>>>>>> >>>>>>>>>>> You can get the stacktrace with erlang:process_info(Pid, >>>>>>>>>>> backtrace). >>>>>>>>>> >>>>>>>>>> Thanks for the tip! >>>>>>>>>> >>>>>>>>>> So yeah, this one is stuck while trying to terminate. >>>>>>>>>> >>>>>>>>>> Program counter: 0x00007f05fd6a5608 (prim_inet:recv0/3 + 224) >>>>>>>>>> CP: 0x0000000000000000 (invalid) >>>>>>>>>> arity = 0 >>>>>>>>>> >>>>>>>>>> 0x00007f052e1b1eb0 Return addr 0x00007f05a3248a98 >>>>>>>>>> (ssl_connection:terminate/3 + 800) >>>>>>>>>> y(0) 57928 >>>>>>>>>> y(1) #Port<0.51824890> >>>>>>>>>> >>>>>>>>>> 0x00007f052e1b1ec8 Return addr 0x00007f05a3b29670 >>>>>>>>>> (gen_fsm:terminate/7 >>>>>>>>>> + 168) >>>>>>>>>> y(0) [] >>>>>>>>>> y(1) [] >>>>>>>>>> y(2) [] >>>>>>>>>> y(3) [] >>>>>>>>>> y(4) #Port<0.51824890> >>>>>>>>>> y(5) gen_tcp >>>>>>>>>> >>>>>>>>>> 0x00007f052e1b1f00 Return addr 0x00007f05a3bb41d0 >>>>>>>>>> (proc_lib:init_p_do_apply/3 + 56) >>>>>>>>>> y(0) [] >>>>>>>>>> y(1) >>>>>>>>>> {state,server,{#Ref<0.0.8553.184512>,<0.18913.1670>},gen_tcp,tcp,tcp_closed,tcp_error,"localhost",8443,#Port<0.51824890>,{ssl_options,[],verify_none,{#Fun,[]},false,false,undefined,1,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cert.pem",undefined,undefined,undefined,"/home/obfuscated/obfuscatedrlang/lib/obfuscatedunchat-1.6.0/priv/ssl/cacert.pem",undefined,undefined,[<<2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>>>> bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 bytes>>,<<2 >>>>>>>>>> bytes>>,<<2 bytes>>,<<2 >>>>>>>>>> bytes>>],#Fun,true,268435456,false,[],undefined,false},{socket_options,binary,0,0,0,once},{connection_states,{connection_state,{security_parameters,<<2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>>>> bytes>>,<<32 >>>>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>>>> bytes>>,undefined},<<20 bytes>>,6,true,<<12 bytes>>,<<12 >>>>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined},{connection_state,{security_parameters,<<2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,0,7,1,16,128,16,unknown,2,20,0,<<48 bytes>>,<<32 >>>>>>>>>> bytes>>,<<32 >>>>>>>>>> bytes>>,undefined},undefined,{cipher_state,<<16 bytes>>,<<16 >>>>>>>>>> bytes>>,undefined},<<20 bytes>>,13,true,<<12 bytes>>,<<12 >>>>>>>>>> bytes>>},{connection_state,{security_parameters,undefined,0,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,undefined,<<32 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,undefined},undefined,undefined,undefined,undefined,true,undefined,undefined}},[],<<0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,<<0 bytes>>,{<<0 bytes>>,<<0 >>>>>>>>>> bytes>>},[],12308,{session,<<32 >>>>>>>>>> bytes>>,undefined,<<1257 bytes>>,0,<<2 bytes>>,<<48 >>>>>>>>>> bytes>>,true,63517514196},24599,ssl_session_cache,{3,1},undefined,false,rsa,undefined,{'RSAPrivateKey','two-prime',26952275589898844250103204854000460899755240864557148991279029405309749386179997816352098133722767607711339559172144166023544257819579600281768301281374192936110073288270279982220728800798557215504319561694659173220853716332492625335748497090542115981135939145850167689577529567336032326581411005966667046488818079418004669621093520594249388264789813277716494693460309931110183497107534349074298533842111855672958994036657571757894555006279600552417098362361837531438833518633912632305124934722467790401548511827982945839067677876435394001531838872958423949934302335970305331259903589271491819721745867851063767101711,65537,728945610618363694299524400013974044353817910988106666265500093396272804476922137563271036849773495653880241216909921636277708729194269519499432595651857072787205775416315535781104441756800626584698817814422133825685692237962420898234801884 32 >>>>>>>>>> >>>>>>>>>> >> 467 >>>>>>>>>> >>>>>>>>>> >>>>> 00 >>>>>>>>>> >>>>>>>>>> >>>>>>> 42 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 51893513795 >>>>>>>>>> >>>>>>>>>> 29032795180763714863835283712338222389782464852044908949559099608779063302276133782734662944988246892889439189879440128304200546026414115176004328650285319262737051106741309180479178565669060188052206153201268137707738579437817066853295089724557953207910831295502502266942720391639060038564028714207644340973116764361586980768047522941109290140269958017673,175687943987452481712482925881452602286249755596049611520304319723586191396077353211979651292293422727226888628810410185730059847194115171473543563960899974179642474882228165413574970142069071147678024461620581964093179873537217082000749319715442644574561869121959620883833054096268955094522609955548334417459,153409932282113553454184543331491108535630917003675738115171976005561046830080906444372373873384261619709596605477733172587334100633359814892598660495299494503111498422936185897687222105679379604880102069501875829087474529350923531274442007552106843129760936560325773227109973336264866827986047857553670280629,16 53 >>>>>>>>>> >>>>>>>>>> >> 778 >>>>>>>>>> >>>>>>>>>> >>>>> 01 >>>>>>>>>> >>>>>>>>>> >>>>>>> 12 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 80640103960 >>>>>>>>>> >>>>>>>>>> 32533996867303777118782862747708688208092956158440780252498542811490728487320772469810738971008968489145399289747151126453392805772011338882217952599871103786463875892748648418527046734444999723398379211505851743415571090610985953725319559986129544296274474768880307859595812559810466567,99372239273086723091338362047522171285756194037567212940251777246259022537354389739788150444373539745180764989177727522509078951433348961072685633082784597107680994416138776015512122203187528006871997391618377904030112283443023112892909533616156365176077807633229316646127723088806569214057154029767435353361,7323400945433254897172443884831966307350890604864415567101495881249115607826271555845873590083141172347084964771961315371798965570031721570889013199060717814694355367862624287469661994309269724835502396215672690851146331180228281917872372949595188776597872289445053324786304898777105863585382475713592590505,asn1_NOVALUE},{'DHParameter',179769313486231590770839156793787453197860296 04 >>>>>>>>>> >>>>>>>>>> >> 875 >>>>>>>>>> >>>>>>>>>> >>>>> 60 >>>>>>>>>> >>>>>>>>>> >>>>>>> 11 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 70644442368 >>>>>>>>>> >>>>>>>>>> 4197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007,2,asn1_NOVALUE},undefined,undefined,#Ref<0.0.0.13264>,{<0.1092.0>,#Ref<0.0.8553.179746>},0,<<0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bytes>>,true,undefined,undefined,{[],[]},false,true} >>>>>>>>>> y(2) connection >>>>>>>>>> y(3) ssl_connection >>>>>>>>>> y(4) {'DOWN',#Ref<0.0.8553.184512>,process,<0.18913.1670>,normal} >>>>>>>>>> y(5) <0.18199.1670> >>>>>>>>>> y(6) normal >>>>>>>>>> y(7) Catch 0x00007f05a3b29670 (gen_fsm:terminate/7 + 168) >>>>>>>>>> >>>>>>>>>> 0x00007f052e1b1f48 Return addr 0x0000000000883498 (>>>>>>>>> process >>>>>>>>>> normally>) >>>>>>>>>> y(0) Catch 0x00007f05a3bb41f0 (proc_lib:init_p_do_apply/3 + >>>>>>>>>> 88) >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>> >>>> >>> >>> >> > > From thomas.jarvstrand@REDACTED Fri Oct 26 11:58:21 2012 From: thomas.jarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Fri, 26 Oct 2012 11:58:21 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors Message-ID: Hi! from the file-module: > *path_open_first([Path|Rest], Name, Mode, LastError) -> > case file_name(Path) of > {error, _} = Error -> > Error; > FilePath -> > FileName = fname_join(FilePath, Name), > case open(FileName, Mode) of > {ok, Fd} -> > {ok, Fd, FileName}; > {error, enoent} -> > path_open_first(Rest, Name, Mode, LastError); > Error -> > Error > end > end;* > For some reason that I haven't deduced yet, my os seems to return enotdir instead of enoent when resolving a relative include. Compiling module with include-directives relative to the source in the shell will result in the call file:path_open([".", "path/to/src.erl"],"../../../relative/path/to/include", [read]), which fails because the second path in the list is never tried due to file:open/2 returning enotdir. I have not yet figured out why I get this return value from the c-code, but shouldn't this be more permissive regardless? I feel that at in addition to enoent there should at least be support for eisdir and enotdir. Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.jarvstrand@REDACTED Fri Oct 26 13:39:16 2012 From: thomas.jarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Fri, 26 Oct 2012 13:39:16 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: Figured out what the error was and this is definitely a bug. Steps to reproduce: Create a "project" with the following tree * * > > * test-project $ tree* > *.* > *|-- include* > *| `-- f.hrl* > *`-- src* > * `-- one.erl* > f.hrl: > *-define(foo, foo).* > one.erl: > *-module(one). > -include("../include/f.hrl"). > one() -> ?hej.* > Now: > * src $ cd test-project/ > test-project $ touch ../include > test-project $ erl > ... > 1> c("src/one.erl"). > src/one.erl:2: can't find include file "../include/f.hrl" > src/one.erl:3: undefined macro 'foo' > error > * So, this fails because a component of the filename relative to cwd is not a directory, whereas relative to the location of the source-file, it would be a directory. Thomas On Fri, Oct 26, 2012 at 11:58 AM, Thomas J?rvstrand < thomas.jarvstrand@REDACTED> wrote: > Hi! > > from the file-module: > >> *path_open_first([Path|Rest], Name, Mode, LastError) -> >> case file_name(Path) of >> {error, _} = Error -> >> Error; >> FilePath -> >> FileName = fname_join(FilePath, Name), >> case open(FileName, Mode) of >> {ok, Fd} -> >> {ok, Fd, FileName}; >> {error, enoent} -> >> path_open_first(Rest, Name, Mode, LastError); >> Error -> >> Error >> end >> end;* >> > > For some reason that I haven't deduced yet, my os seems to return enotdir > instead of enoent when resolving a relative include. Compiling module with > include-directives relative to the source in the shell will result in the > call file:path_open([".", > "path/to/src.erl"],"../../../relative/path/to/include", [read]), which > fails because the second path in the list is never tried due to file:open/2 > returning enotdir. > > I have not yet figured out why I get this return value from the c-code, > but shouldn't this be more permissive regardless? I feel that at in > addition to enoent there should at least be support for eisdir and enotdir. > > Regards > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.harju@REDACTED Fri Oct 26 15:17:49 2012 From: alexander.harju@REDACTED (Alexander Harju) Date: Fri, 26 Oct 2012 15:17:49 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: I don't think this is a bug at all. -include(...) should not contain a path. Use compile:file("one.erl", [{i, Dir},...]) // Alex On Fri, Oct 26, 2012 at 1:39 PM, Thomas J?rvstrand < thomas.jarvstrand@REDACTED> wrote: > Figured out what the error was and this is definitely a bug. > > Steps to reproduce: > Create a "project" with the following tree > * > * >> >> * test-project $ tree* >> *.* >> *|-- include* >> *| `-- f.hrl* >> *`-- src* >> * `-- one.erl* >> > > f.hrl: > >> *-define(foo, foo).* >> > > one.erl: > >> *-module(one). >> -include("../include/f.hrl"). >> one() -> ?hej.* >> > > Now: > >> * src $ cd test-project/ >> test-project $ touch ../include >> test-project $ erl >> ... >> 1> c("src/one.erl"). >> src/one.erl:2: can't find include file "../include/f.hrl" >> src/one.erl:3: undefined macro 'foo' >> error >> * > > > So, this fails because a component of the filename relative to cwd is not > a directory, whereas relative to the location of the source-file, it would > be a directory. > > Thomas > > On Fri, Oct 26, 2012 at 11:58 AM, Thomas J?rvstrand < > thomas.jarvstrand@REDACTED> wrote: > >> Hi! >> >> from the file-module: >> >>> *path_open_first([Path|Rest], Name, Mode, LastError) -> >>> case file_name(Path) of >>> {error, _} = Error -> >>> Error; >>> FilePath -> >>> FileName = fname_join(FilePath, Name), >>> case open(FileName, Mode) of >>> {ok, Fd} -> >>> {ok, Fd, FileName}; >>> {error, enoent} -> >>> path_open_first(Rest, Name, Mode, LastError); >>> Error -> >>> Error >>> end >>> end;* >>> >> >> For some reason that I haven't deduced yet, my os seems to return enotdir >> instead of enoent when resolving a relative include. Compiling module with >> include-directives relative to the source in the shell will result in the >> call file:path_open([".", >> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which >> fails because the second path in the list is never tried due to file:open/2 >> returning enotdir. >> >> I have not yet figured out why I get this return value from the c-code, >> but shouldn't this be more permissive regardless? I feel that at in >> addition to enoent there should at least be support for eisdir and enotdir. >> >> Regards >> Thomas >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.jarvstrand@REDACTED Fri Oct 26 16:26:18 2012 From: thomas.jarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Fri, 26 Oct 2012 16:26:18 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: Well, the correctness of the include-directive can definitely be questioned, I didn't write it, I was just the one who ran into a problem with it :P Regardless, in the general case I don't think that file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail just because path1 happens to contain a regular file called foo. Thomas On Fri, Oct 26, 2012 at 3:17 PM, Alexander Harju < alexander.harju@REDACTED> wrote: > I don't think this is a bug at all. > -include(...) should not contain a path. > Use compile:file("one.erl", [{i, Dir},...]) > > // Alex > > On Fri, Oct 26, 2012 at 1:39 PM, Thomas J?rvstrand < > thomas.jarvstrand@REDACTED> wrote: > >> Figured out what the error was and this is definitely a bug. >> >> Steps to reproduce: >> Create a "project" with the following tree >> * >> * >>> >>> * test-project $ tree* >>> *.* >>> *|-- include* >>> *| `-- f.hrl* >>> *`-- src* >>> * `-- one.erl* >>> >> >> f.hrl: >> >>> *-define(foo, foo).* >>> >> >> one.erl: >> >>> *-module(one). >>> -include("../include/f.hrl"). >>> one() -> ?hej.* >>> >> >> Now: >> >>> * src $ cd test-project/ >>> test-project $ touch ../include >>> test-project $ erl >>> ... >>> 1> c("src/one.erl"). >>> src/one.erl:2: can't find include file "../include/f.hrl" >>> src/one.erl:3: undefined macro 'foo' >>> error >>> * >> >> >> So, this fails because a component of the filename relative to cwd is not >> a directory, whereas relative to the location of the source-file, it would >> be a directory. >> >> Thomas >> >> On Fri, Oct 26, 2012 at 11:58 AM, Thomas J?rvstrand < >> thomas.jarvstrand@REDACTED> wrote: >> >>> Hi! >>> >>> from the file-module: >>> >>>> *path_open_first([Path|Rest], Name, Mode, LastError) -> >>>> case file_name(Path) of >>>> {error, _} = Error -> >>>> Error; >>>> FilePath -> >>>> FileName = fname_join(FilePath, Name), >>>> case open(FileName, Mode) of >>>> {ok, Fd} -> >>>> {ok, Fd, FileName}; >>>> {error, enoent} -> >>>> path_open_first(Rest, Name, Mode, LastError); >>>> Error -> >>>> Error >>>> end >>>> end;* >>>> >>> >>> For some reason that I haven't deduced yet, my os seems to return >>> enotdir instead of enoent when resolving a relative include. Compiling >>> module with include-directives relative to the source in the shell will >>> result in the call file:path_open([".", >>> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which >>> fails because the second path in the list is never tried due to file:open/2 >>> returning enotdir. >>> >>> I have not yet figured out why I get this return value from the c-code, >>> but shouldn't this be more permissive regardless? I feel that at in >>> addition to enoent there should at least be support for eisdir and enotdir. >>> >>> Regards >>> Thomas >>> >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.jarvstrand@REDACTED Fri Oct 26 16:31:43 2012 From: thomas.jarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Fri, 26 Oct 2012 16:31:43 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: Please ignore the double negation in my previous email :) file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail just because path1 happens to contain a regular file called foo. T On Fri, Oct 26, 2012 at 4:26 PM, Thomas J?rvstrand < thomas.jarvstrand@REDACTED> wrote: > Well, the correctness of the include-directive can definitely be > questioned, I didn't write it, I was just the one who ran into a problem > with it :P > > Regardless, in the general case I don't think that > file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail > just because path1 happens to contain a regular file called foo. > > Thomas > > On Fri, Oct 26, 2012 at 3:17 PM, Alexander Harju < > alexander.harju@REDACTED> wrote: > >> I don't think this is a bug at all. >> -include(...) should not contain a path. >> Use compile:file("one.erl", [{i, Dir},...]) >> >> // Alex >> >> On Fri, Oct 26, 2012 at 1:39 PM, Thomas J?rvstrand < >> thomas.jarvstrand@REDACTED> wrote: >> >>> Figured out what the error was and this is definitely a bug. >>> >>> Steps to reproduce: >>> Create a "project" with the following tree >>> * >>> * >>>> >>>> * test-project $ tree* >>>> *.* >>>> *|-- include* >>>> *| `-- f.hrl* >>>> *`-- src* >>>> * `-- one.erl* >>>> >>> >>> f.hrl: >>> >>>> *-define(foo, foo).* >>>> >>> >>> one.erl: >>> >>>> *-module(one). >>>> -include("../include/f.hrl"). >>>> one() -> ?hej.* >>>> >>> >>> Now: >>> >>>> * src $ cd test-project/ >>>> test-project $ touch ../include >>>> test-project $ erl >>>> ... >>>> 1> c("src/one.erl"). >>>> src/one.erl:2: can't find include file "../include/f.hrl" >>>> src/one.erl:3: undefined macro 'foo' >>>> error >>>> * >>> >>> >>> So, this fails because a component of the filename relative to cwd is >>> not a directory, whereas relative to the location of the source-file, it >>> would be a directory. >>> >>> Thomas >>> >>> On Fri, Oct 26, 2012 at 11:58 AM, Thomas J?rvstrand < >>> thomas.jarvstrand@REDACTED> wrote: >>> >>>> Hi! >>>> >>>> from the file-module: >>>> >>>>> *path_open_first([Path|Rest], Name, Mode, LastError) -> >>>>> case file_name(Path) of >>>>> {error, _} = Error -> >>>>> Error; >>>>> FilePath -> >>>>> FileName = fname_join(FilePath, Name), >>>>> case open(FileName, Mode) of >>>>> {ok, Fd} -> >>>>> {ok, Fd, FileName}; >>>>> {error, enoent} -> >>>>> path_open_first(Rest, Name, Mode, LastError); >>>>> Error -> >>>>> Error >>>>> end >>>>> end;* >>>>> >>>> >>>> For some reason that I haven't deduced yet, my os seems to return >>>> enotdir instead of enoent when resolving a relative include. Compiling >>>> module with include-directives relative to the source in the shell will >>>> result in the call file:path_open([".", >>>> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which >>>> fails because the second path in the list is never tried due to file:open/2 >>>> returning enotdir. >>>> >>>> I have not yet figured out why I get this return value from the c-code, >>>> but shouldn't this be more permissive regardless? I feel that at in >>>> addition to enoent there should at least be support for eisdir and enotdir. >>>> >>>> Regards >>>> Thomas >>>> >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.jarvstrand@REDACTED Fri Oct 26 16:54:18 2012 From: thomas.jarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Fri, 26 Oct 2012 16:54:18 +0200 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: Also, the below examples are from the erlang preprocessor documentation so the ability to use relative paths in the include-directive is definitely intentional and as such it should work in a predictable way. > -include("my_records.hrl"). > -include("incdir/my_records.hrl"). > -include("/home/user/proj/my_records.hrl"). > -include("$PROJ_ROOT/my_records.hrl"). > > I do agree with the sentiment that relative paths (and even include-directives without the _lib) should be avoided entirely if at all possible. T On Fri, Oct 26, 2012 at 4:31 PM, Thomas J?rvstrand < thomas.jarvstrand@REDACTED> wrote: > Please ignore the double negation in my previous email :) > > file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail > just because path1 happens to contain a regular file called foo. > > T > > On Fri, Oct 26, 2012 at 4:26 PM, Thomas J?rvstrand < > thomas.jarvstrand@REDACTED> wrote: > >> Well, the correctness of the include-directive can definitely be >> questioned, I didn't write it, I was just the one who ran into a problem >> with it :P >> >> Regardless, in the general case I don't think that >> file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail >> just because path1 happens to contain a regular file called foo. >> >> Thomas >> >> On Fri, Oct 26, 2012 at 3:17 PM, Alexander Harju < >> alexander.harju@REDACTED> wrote: >> >>> I don't think this is a bug at all. >>> -include(...) should not contain a path. >>> Use compile:file("one.erl", [{i, Dir},...]) >>> >>> // Alex >>> >>> On Fri, Oct 26, 2012 at 1:39 PM, Thomas J?rvstrand < >>> thomas.jarvstrand@REDACTED> wrote: >>> >>>> Figured out what the error was and this is definitely a bug. >>>> >>>> Steps to reproduce: >>>> Create a "project" with the following tree >>>> * >>>> * >>>>> >>>>> * test-project $ tree* >>>>> *.* >>>>> *|-- include* >>>>> *| `-- f.hrl* >>>>> *`-- src* >>>>> * `-- one.erl* >>>>> >>>> >>>> f.hrl: >>>> >>>>> *-define(foo, foo).* >>>>> >>>> >>>> one.erl: >>>> >>>>> *-module(one). >>>>> -include("../include/f.hrl"). >>>>> one() -> ?hej.* >>>>> >>>> >>>> Now: >>>> >>>>> * src $ cd test-project/ >>>>> test-project $ touch ../include >>>>> test-project $ erl >>>>> ... >>>>> 1> c("src/one.erl"). >>>>> src/one.erl:2: can't find include file "../include/f.hrl" >>>>> src/one.erl:3: undefined macro 'foo' >>>>> error >>>>> * >>>> >>>> >>>> So, this fails because a component of the filename relative to cwd is >>>> not a directory, whereas relative to the location of the source-file, it >>>> would be a directory. >>>> >>>> Thomas >>>> >>>> On Fri, Oct 26, 2012 at 11:58 AM, Thomas J?rvstrand < >>>> thomas.jarvstrand@REDACTED> wrote: >>>> >>>>> Hi! >>>>> >>>>> from the file-module: >>>>> >>>>>> *path_open_first([Path|Rest], Name, Mode, LastError) -> >>>>>> case file_name(Path) of >>>>>> {error, _} = Error -> >>>>>> Error; >>>>>> FilePath -> >>>>>> FileName = fname_join(FilePath, Name), >>>>>> case open(FileName, Mode) of >>>>>> {ok, Fd} -> >>>>>> {ok, Fd, FileName}; >>>>>> {error, enoent} -> >>>>>> path_open_first(Rest, Name, Mode, LastError); >>>>>> Error -> >>>>>> Error >>>>>> end >>>>>> end;* >>>>>> >>>>> >>>>> For some reason that I haven't deduced yet, my os seems to return >>>>> enotdir instead of enoent when resolving a relative include. Compiling >>>>> module with include-directives relative to the source in the shell will >>>>> result in the call file:path_open([".", >>>>> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which >>>>> fails because the second path in the list is never tried due to file:open/2 >>>>> returning enotdir. >>>>> >>>>> I have not yet figured out why I get this return value from the >>>>> c-code, but shouldn't this be more permissive regardless? I feel that at in >>>>> addition to enoent there should at least be support for eisdir and enotdir. >>>>> >>>>> Regards >>>>> Thomas >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Sat Oct 27 12:16:40 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 27 Oct 2012 12:16:40 +0200 Subject: [erlang-bugs] Guard clauses using not, binaries and andalso blows up the compiler chain Message-ID: Hello everyone, The following function cannot compile on Erlang R15B02: format(Datetime, << H, T / binary >>) when not ((H >= $a) andalso (H =< $z)) andalso not ((H >= $A) andalso (H =< $Z)) -> { Datetime, T }. Here is a snippet of the failure: format_test.erl:none: internal error in v3_codegen; crash reason: {{case_clause, {'EXIT', {function_clause, [{v3_codegen,bsm_rename_ctx, I believe the current code to be valid Erlang and it should not blow up the compiler chain. :) Furthermore, simply adding other clauses to this function (without touching it) makes the error go away. I have put more information about the failure and a full sample module in a gist: https://gist.github.com/dd4c1240a1510711b26a I tried to further debug the issue, but I could not pinpoint exactly the failure. Let me know if I can help any further. Thanks for your time, PS: I have sent this same e-mail one week ago but it didn't appear on the erlang-bugs mailing list. So I am sending it again. Apologies if it appears twice. * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Mon Oct 29 16:37:29 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 29 Oct 2012 16:37:29 +0100 Subject: [erlang-bugs] Guard clauses using not, binaries and andalso blows up the compiler chain In-Reply-To: References: Message-ID: On Sat, Oct 27, 2012 at 12:16 PM, Jos? Valim wrote: > Hello everyone, > > The following function cannot compile on Erlang R15B02: > > format(Datetime, << H, T / binary >>) when not ((H >= $a) andalso (H =< > $z)) andalso > not ((H >= $A) andalso (H =< $Z)) -> > { Datetime, T }. > Thanks! We will fix the problem in either R15B03 or R16B. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From hq@REDACTED Mon Oct 29 23:56:19 2012 From: hq@REDACTED (Adam Rutkowski) Date: Mon, 29 Oct 2012 23:56:19 +0100 Subject: [erlang-bugs] Weird exception error return involving bitstrings Message-ID: Hi, I am facing weird behaviour for the following code: -module(foo). -export([bar/1]). -include_lib("eunit/include/eunit.hrl"). bar(<<>>) -> ok; bar(Bin) when is_bitstring(Bin) andalso not is_binary(Bin) -> bar(<>); bar(<<_:8/integer, Rest/binary>>) -> bar(Rest). foobar1_test() -> ok = bar(<<1,2,3>>). foobar2_test() -> ok = bar(<<256:8>>). foobar3_test() -> ok = bar(<<256:7>>). foobar4_test() -> ok = bar(<<1,2,3>>). The code is obviously wrong - it should be bar(<>) in the second clause, however: % erl Erlang R15B02 (erts-5.9.2) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.2 (abort with ^G) 1> c(foo). {ok,foo} 2> foo:bar(<<256:7>>). ok 3> foo:foobar3_test(). ** exception error: bad argument in function foo:bar/1 (foo.erl, line 6) in call from foo:foobar3_test/0 (foo.erl, line 18) 4> foo:foobar3_test(). ** exception error: [] 5> catch(foo:foobar3_test()). {'EXIT',{[],[]}} Notice I have called the same function twice getting different exceptions. Eunit looks confused too: 1> eunit:test(foo). foo: foobar3_test...*failed* in function eunit_proc:get_next_item/1 (eunit_proc.erl, line 465) in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 429) **throw:{module_not_found,foo_tests} -- Adam From samuelrivas@REDACTED Tue Oct 30 08:40:22 2012 From: samuelrivas@REDACTED (Samuel) Date: Tue, 30 Oct 2012 08:40:22 +0100 Subject: [erlang-bugs] file:path_open chokes on anything but enoent errors In-Reply-To: References: Message-ID: > I don't think this is a bug at all. > -include(...) should not contain a path. > Use compile:file("one.erl", [{i, Dir},...]) Where is that specified? The documentation does not state that restriction as far as I can see. And as already pointed out, the bug is quite clear in file:path_open/3 code, the effect on -include is just a symptom . -- Samuel From bgustavsson@REDACTED Tue Oct 30 08:56:05 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 30 Oct 2012 08:56:05 +0100 Subject: [erlang-bugs] Weird exception error return involving bitstrings In-Reply-To: References: Message-ID: On Mon, Oct 29, 2012 at 11:56 PM, Adam Rutkowski wrote: > Hi, > > I am facing weird behaviour for the following code: > > -module(foo). > -export([bar/1]). > -include_lib("eunit/include/eunit.hrl"). > > bar(<<>>) -> ok; > bar(Bin) when is_bitstring(Bin) andalso not is_binary(Bin) -> > bar(<>); > bar(<<_:8/integer, Rest/binary>>) -> > bar(Rest). > > foobar1_test() -> ok = bar(<<1,2,3>>). > foobar2_test() -> ok = bar(<<256:8>>). > foobar3_test() -> ok = bar(<<256:7>>). > foobar4_test() -> ok = bar(<<1,2,3>>). > Yes, there are two bugs in the error handling when appending to a binary. * If the binary has not been previously been appended to, the exception type would not be set if an exception was generated, leading to random exceptions. * If the binary had been previously appended to, no exception would be generated if (for example) unit was set to 8 bits and the size of the binary was not a multiple of 8 bits. We will fix both bugs in R15B03. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Ingela.Anderton.Andin@REDACTED Tue Oct 30 17:50:18 2012 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 30 Oct 2012 17:50:18 +0100 Subject: [erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01 In-Reply-To: <508EB773.2080508@ninenines.eu> References: <507C2922.9090207@ninenines.eu> <507C379D.7010004@ninenines.eu> <507D264C.7040102@ericsson.com> <507D2747.8040602@ninenines.eu> <507D2F14.4020705@ericsson.com> <507D3001.6000307@ninenines.eu> <507D8DC3.6050507@ericsson.com> <507E6391.7070304@erix.ericsson.se> <5080211A.2060805@ninenines.eu> <5087B3E2.6070009@ericsson.com> <5087DBAB.8090403@ninenines.eu> <5087E62D.3040304@ericsson.com> <508E6034.7020003@ninenines.eu> <508E8A12.5020009@ericsson.com> <508EB773.2080508@ninenines.eu> Message-ID: <5090054A.5080405@ericsson.com> Hi! Lo?c Hoguin wrote: > I don't understand why there's no timeout though. Wouldn't it make sense > to have a small timeout to avoid this and any related problem entirely? > Well yes and no ;) ssl:close should conceptually not fail so you should not need a timeout. The problem seems to be that be that the cleaning up code sometimes could cause a unforeseen hanging problem, as in the rabbitmq case. Although in your case it seems that the problem is something else, at least some of the times. Currently I am thinking that maybe the close function is incorrectly implemented and that it should utilize supervisor:terminate_child so that the OTP-supervisor will kill the process if it hangs in terminate. (It has a timeout) I will work on making sush a patch. I suppose in the meantime you could implement a timeout to ssl-close and verify that this timeout would solve your problem. As then my suggested way should solve it too just more OTPish and without the need of extending the API. Regards Ingela Erlang/OTP team - Ericsson AB