From n.oxyde@REDACTED Tue Jul 1 01:20:30 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jul 2014 01:20:30 +0200 Subject: [erlang-bugs] filelib:ensure_dir/1 and symlink to dir In-Reply-To: References: Message-ID: <344535D8-406B-4158-8A27-09029C37BDE4@gmail.com> https://github.com/erlang/otp/pull/417 -- Anthony Ramine Le 30 juin 2014 ? 21:45, Jos? Valim a ?crit : > Danil, I am assuming you are running on Erlang 17.1. If so, this bug has been reported in a previous thread: > > http://erlang.org/pipermail/erlang-bugs/2014-June/004465.html > > > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Sun, Jun 29, 2014 at 11:02 PM, Danil Zagoskin wrote: > For example, I have a directory "foo" and a symlink "bar" to "foo". > While I can access file, I get error trying to ensure_dir: > 2> file:read_file("bar/baz"). > {ok,<<>>} > 3> filelib:ensure_dir("bar/baz"). > {error,eexist} > > This is because filelib:do_is_dir/2 does not expect a symlink to dir. > > Is it expected behavior or should I submit a patch for that? > (This breaks at least lager which does filelib:ensure_dir before opening a log) > > -- > Danil Zagoskin | z@REDACTED > > _______________________________________________ > 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 n.oxyde@REDACTED Tue Jul 1 01:20:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jul 2014 01:20:41 +0200 Subject: [erlang-bugs] filelib:ensure_dir/1 broken with symlinks In-Reply-To: References: Message-ID: <32383ADC-0A42-4EC2-ADE0-D3382E83D91D@gmail.com> https://github.com/erlang/otp/pull/417 -- Anthony Ramine Le 28 juin 2014 ? 12:01, Anthony Ramine a ?crit : > Also, wildcard/2 is broken if passed prim_file, because eval_read_file_info/2?s third clause will still call Mod:read_file_info/1 instead of Mod:read_link_info/1. > > Wrote a preliminary patch of which I am dubious of its quality, please comment: > > https://github.com/nox/otp/commit/d3ba773f81ffcef449dbf574ba15824996e7c479 > > Regards, > > -- > Anthony Ramine > > Le 27 juin 2014 ? 22:14, Jos? Valim a ?crit : > >> Unfortunately the commit shown above also seems to have broken: >> >> * filelib:is_regular/1 >> * filelib:is_dir/1 >> * filelib:is_file/1 >> >> As they no longer traverse symlinks and rather return the symlink information. >> >> filelib:last_modified/1 and filelib:file_size/1 are likely broken too (basically all functions that use eval_read_file_info/2 besides filelib:wildcard/3). >> >> >> Jos? Valim >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From n.oxyde@REDACTED Tue Jul 1 01:26:42 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jul 2014 01:26:42 +0200 Subject: [erlang-bugs] bug at alarm_handler or at documentation In-Reply-To: <1658D9CC-B62A-44AB-A7A1-CA50B2D304C0@gmail.com> References: <1658D9CC-B62A-44AB-A7A1-CA50B2D304C0@gmail.com> Message-ID: <69DBE4ED-C0A0-45CA-A864-A5DF56071DA0@gmail.com> I would say the bug is in the code, if I had 10 alarms for low memory during the night, I would like to clear them all at once once I fixed the problem. What does the OTP team say? -- Anthony Ramine Le 25 juin 2014 ? 10:47, Dmitry Kolesnikov a ?crit : > Hello, > > The alarm_handler documentation says: > http://www.erlang.org/doc/man/alarm_handler.html > > ? CLIP ? > clear_alarm(AlarmId) -> void() > > Clears all alarms with id AlarmId. > ? CLIP ? > > but code does not clears all alarms, it clears the last one > > https://github.com/erlang/otp/blob/maint/lib/sasl/src/alarm_handler.erl#L83 > > ? CLIP ? > {ok, lists:keydelete(AlarmId, 1, Alarms)}; > ? CLIP ? > > I can patch alarm_handler if needed but I think the bug in documentation? > > Best Regards, > Dmitry > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From n.oxyde@REDACTED Tue Jul 1 01:32:46 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jul 2014 01:32:46 +0200 Subject: [erlang-bugs] r15b03-1 SEGV in erts_port_task_execute() In-Reply-To: <21409.27689.585481.110836@gargle.gargle.HOWL> References: <21409.27689.585481.110836@gargle.gargle.HOWL> Message-ID: The pop_task() function was removed in 6e01408aba71e26884c5db81b8e4fa89bd803576, which was in R16A. -- Anthony Ramine Le 18 juin 2014 ? 12:38, Mikael Pettersson a ?crit : > One of our nodes running OTP r15b03-1 segfaulted yesterday evening. > Unfortunately it didn't produce a usable core dump (configuration > problem, sigh), but the kernel logged the address of the instruction > that faulted and the address it tried to access. The segfault > turned out to be in erts_port_task_execute: > > int > erts_port_task_execute(ErtsRunQueue *runq, Port **curr_port_pp) > { > int port_was_enqueued = 0; > Port *pp; > ErtsPortTaskQueue *ptqp; > ErtsPortTask *ptp; > int res = 0; > int reds = ERTS_PORT_REDS_EXECUTE; > erts_aint_t io_tasks_executed = 0; > int fpe_was_unmasked; > Uint64 start_time = 0; > > ERTS_SMP_LC_ASSERT(erts_smp_lc_runq_is_locked(runq)); > > ERTS_PT_CHK_PORTQ(runq); > > pp = pop_port(runq); > if (!pp) { > res = 0; > goto done; > } > > ERTS_PORT_NOT_IN_RUNQ(pp); > > *curr_port_pp = pp; > > ASSERT(pp->sched.taskq); > ASSERT(pp->sched.taskq->first); > ptqp = pp->sched.taskq; > pp->sched.taskq = NULL; > > ASSERT(!pp->sched.exe_taskq); > pp->sched.exe_taskq = ptqp; > > if (erts_smp_port_trylock(pp) == EBUSY) { > erts_smp_runq_unlock(runq); > erts_smp_port_lock(pp); > erts_smp_runq_lock(runq); > } > > if (erts_sched_stat.enabled) { > ErtsSchedulerData *esdp = erts_get_scheduler_data(); > Uint old = ERTS_PORT_SCHED_ID(pp, esdp->no); > int migrated = old && old != esdp->no; > > erts_smp_spin_lock(&erts_sched_stat.lock); > erts_sched_stat.prio[ERTS_PORT_PRIO_LEVEL].total_executed++; > erts_sched_stat.prio[ERTS_PORT_PRIO_LEVEL].executed++; > if (migrated) { > erts_sched_stat.prio[ERTS_PORT_PRIO_LEVEL].total_migrated++; > erts_sched_stat.prio[ERTS_PORT_PRIO_LEVEL].migrated++; > } > erts_smp_spin_unlock(&erts_sched_stat.lock); > } > > /* trace port scheduling, in */ > if (IS_TRACED_FL(pp, F_TRACE_SCHED_PORTS)) { > trace_sched_ports(pp, am_in); > } > > ERTS_SMP_LC_ASSERT(erts_lc_is_port_locked(pp)); > > ERTS_PT_CHK_PRES_PORTQ(runq, pp); > ptp = pop_task(ptqp); > > At this point ptqp is NULL, so the initial load in the pop_task() > code faults. This is not a debug build, so the assertions above > didn't catch this condition. > > I don't know if this is repeatable; we've never seen it before. > The machine was doing a lot of port I/O at the time (generating > pdf report files). > > This is mostly an FYI at this point. If someone thinks they recognize > the problem and can point to a fix in a later release that'd be great. > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From n.oxyde@REDACTED Tue Jul 1 02:58:24 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jul 2014 02:58:24 +0200 Subject: [erlang-bugs] repl previous command result incompatible with maps manipulation In-Reply-To: References: Message-ID: https://github.com/erlang/otp/pull/418 -- Anthony Ramine Le 20 mai 2014 ? 13:44, Danil Zagoskin a ?crit : > Hello! > Currently it's impossible to use v(N) result as map: > > Erlang/OTP 17 [DEVELOPMENT] [erts-6.1] [source-a3c5de1] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.1 (abort with ^G) > 1> #{a => 1}. > #{a => 1} > 2> (v(1)). > #{a => 1} > 3> (v(1))#{a := 2}. > ** exception error: undefined shell command v/1 > > > -- > Danil Zagoskin | z@REDACTED > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From anders.nygren@REDACTED Tue Jul 1 03:45:35 2014 From: anders.nygren@REDACTED (Anders Nygren) Date: Mon, 30 Jun 2014 20:45:35 -0500 Subject: [erlang-bugs] bug at alarm_handler or at documentation In-Reply-To: <69DBE4ED-C0A0-45CA-A864-A5DF56071DA0@gmail.com> References: <1658D9CC-B62A-44AB-A7A1-CA50B2D304C0@gmail.com> <69DBE4ED-C0A0-45CA-A864-A5DF56071DA0@gmail.com> Message-ID: You shouldn't raise the same alarm several times. Once it is raised the alarm state exists until You clear it. In my opinion the bug is that several copies of the alarm is saved, not that they are not all cleared. I think that the default alarm handler should be considered as just a primitive example. The documentation says "One simple event handler is installed in the alarm handler at start-up, but users are encouraged to write and install their own handlers." On Mon, Jun 30, 2014 at 6:26 PM, Anthony Ramine wrote: > I would say the bug is in the code, if I had 10 alarms for low memory > during the night, I would like to clear them all at once once I fixed the > problem. > > What does the OTP team say? > > -- > Anthony Ramine > > Le 25 juin 2014 ? 10:47, Dmitry Kolesnikov a > ?crit : > > > Hello, > > > > The alarm_handler documentation says: > > http://www.erlang.org/doc/man/alarm_handler.html > > > > ? CLIP ? > > clear_alarm(AlarmId) -> void() > > > > Clears all alarms with id AlarmId. > > ? CLIP ? > > > > but code does not clears all alarms, it clears the last one > > > > > https://github.com/erlang/otp/blob/maint/lib/sasl/src/alarm_handler.erl#L83 > > > > ? CLIP ? > > {ok, lists:keydelete(AlarmId, 1, Alarms)}; > > ? CLIP ? > > > > I can patch alarm_handler if needed but I think the bug in documentation? > > > > Best Regards, > > Dmitry > > _______________________________________________ > > 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 Ingela.Anderton.Andin@REDACTED Tue Jul 1 10:50:22 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 1 Jul 2014 10:50:22 +0200 Subject: [erlang-bugs] SSH Bugs In-Reply-To: References: Message-ID: <53B2764E.6060807@ericsson.com> Hi! On 06/30/2014 10:37 PM, Michael.K.Schmidt@REDACTED wrote: > > Hi, > > Does anyone know what the final resolution was with this bug? > http://erlang.org/pipermail/erlang-patches/2013-December/004499.html Humm I can not remeber seeing this patch before! Maybe it got lost in the process some how :( > The patch given by Anton Ryabkov seems to address the immediate bug. Is > this fix ok? Or is there a better way? > > With Anton's patch I am able to get this example to run: > https://github.com/erlang/otp/blob/maint/lib/ssh/examples/ssh_sample_cli.erl > > It works with Tera Term as the client, but when I try to use PuTTY I get > the following error: > "Disconnected: Server protocol violation: unexpected > SSH2_MSG_CHANNEL_SUCCESS packet" > > I believe this worked with PuTTY before R16B03. Did an edge case get > missed with this refactor? > https://github.com/erlang/otp/commit/68263a48bfbdac4dc219a91f06af3d535d881850 Possible! Have you tried it with 17.1? I think the 17.1 code semantically seems to be doing the same as the patch. Regards Ingela Erlang/OTP team - Ericsson AB From z@REDACTED Tue Jul 1 09:08:02 2014 From: z@REDACTED (Danil Zagoskin) Date: Tue, 1 Jul 2014 11:08:02 +0400 Subject: [erlang-bugs] filelib:ensure_dir/1 and symlink to dir In-Reply-To: <344535D8-406B-4158-8A27-09029C37BDE4@gmail.com> References: <344535D8-406B-4158-8A27-09029C37BDE4@gmail.com> Message-ID: Jos?, Anthony, thank you. I didn't notice the previous thread. Sorry for that. On Tue, Jul 1, 2014 at 3:20 AM, Anthony Ramine wrote: > https://github.com/erlang/otp/pull/417 > > -- > Anthony Ramine > > Le 30 juin 2014 ? 21:45, Jos? Valim a > ?crit : > > > Danil, I am assuming you are running on Erlang 17.1. If so, this bug has > been reported in a previous thread: > > > > http://erlang.org/pipermail/erlang-bugs/2014-June/004465.html > > > > > > > > Jos? Valim > > www.plataformatec.com.br > > Skype: jv.ptec > > Founder and Lead Developer > > > > > > On Sun, Jun 29, 2014 at 11:02 PM, Danil Zagoskin wrote: > > For example, I have a directory "foo" and a symlink "bar" to "foo". > > While I can access file, I get error trying to ensure_dir: > > 2> file:read_file("bar/baz"). > > {ok,<<>>} > > 3> filelib:ensure_dir("bar/baz"). > > {error,eexist} > > > > This is because filelib:do_is_dir/2 does not expect a symlink to dir. > > > > Is it expected behavior or should I submit a patch for that? > > (This breaks at least lager which does filelib:ensure_dir before opening > a log) > > > > -- > > Danil Zagoskin | z@REDACTED > > > > _______________________________________________ > > 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 > > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Jul 1 15:06:09 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 1 Jul 2014 15:06:09 +0200 Subject: [erlang-bugs] bug at alarm_handler or at documentation In-Reply-To: References: <1658D9CC-B62A-44AB-A7A1-CA50B2D304C0@gmail.com> <69DBE4ED-C0A0-45CA-A864-A5DF56071DA0@gmail.com> Message-ID: Given the fact that the alarm_handler has not been touched since R13B03 (i.e. as far back as the git history goes) and probably far beyond that, I do not believe that it has been very much used. We are quite settled on spending as little time as possible on this - especially since the default handler is really too simple for production use anyway and, as stated earlier in this thread, the user is encouraged to install an own handler to do the job. So we will take the simplest way out and fix the documentation. Thanks for reporting the problem. Regards /siri 2014-07-01 3:45 GMT+02:00 Anders Nygren : > You shouldn't raise the same alarm several times. Once it is raised the > alarm state exists until You clear it. In my opinion the bug is that > several copies of the alarm is saved, not that they are not all cleared. > > I think that the default alarm handler should be considered as just a > primitive example. The documentation says > "One simple event handler is installed in the alarm handler at start-up, > but users are encouraged to write and install their own handlers." > > > > On Mon, Jun 30, 2014 at 6:26 PM, Anthony Ramine wrote: > >> I would say the bug is in the code, if I had 10 alarms for low memory >> during the night, I would like to clear them all at once once I fixed the >> problem. >> >> What does the OTP team say? >> >> -- >> Anthony Ramine >> >> Le 25 juin 2014 ? 10:47, Dmitry Kolesnikov a >> ?crit : >> >> > Hello, >> > >> > The alarm_handler documentation says: >> > http://www.erlang.org/doc/man/alarm_handler.html >> > >> > ? CLIP ? >> > clear_alarm(AlarmId) -> void() >> > >> > Clears all alarms with id AlarmId. >> > ? CLIP ? >> > >> > but code does not clears all alarms, it clears the last one >> > >> > >> https://github.com/erlang/otp/blob/maint/lib/sasl/src/alarm_handler.erl#L83 >> > >> > ? CLIP ? >> > {ok, lists:keydelete(AlarmId, 1, Alarms)}; >> > ? CLIP ? >> > >> > I can patch alarm_handler if needed but I think the bug in >> documentation? >> > >> > Best Regards, >> > Dmitry >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.K.Schmidt@REDACTED Tue Jul 1 15:14:48 2014 From: Michael.K.Schmidt@REDACTED (Michael.K.Schmidt@REDACTED) Date: Tue, 1 Jul 2014 08:14:48 -0500 Subject: [erlang-bugs] SSH Bugs In-Reply-To: <53B2764E.6060807@ericsson.com> References: <53B2764E.6060807@ericsson.com> Message-ID: Hi Angela, > Ingela Anderton Andin > Sent by: erlang-bugs-bounces@REDACTED > > 07/01/2014 03:50 AM > > To > > , > > cc > > Subject > > Re: [erlang-bugs] SSH Bugs > > Hi! > > On 06/30/2014 10:37 PM, Michael.K.Schmidt@REDACTED wrote: > > > > Hi, > > > > Does anyone know what the final resolution was with this bug? > > http://erlang.org/pipermail/erlang-patches/2013-December/004499.html > > Humm I can not remeber seeing this patch before! Maybe it got lost in > the process some how :( No worries! When I didn't see it in 17.1, I thought I would check to see if that was the case. > > > > The patch given by Anton Ryabkov seems to address the immediate bug. Is > > this fix ok? Or is there a better way? > > > > With Anton's patch I am able to get this example to run: > > https://github.com/erlang/otp/blob/maint/lib/ssh/examples/ssh_sample_cli.erl > > > > It works with Tera Term as the client, but when I try to use PuTTY I get > > the following error: > > "Disconnected: Server protocol violation: unexpected > > SSH2_MSG_CHANNEL_SUCCESS packet" > > > > I believe this worked with PuTTY before R16B03. Did an edge case get > > missed with this refactor? > > https://github.com/erlang/otp/commit/ > 68263a48bfbdac4dc219a91f06af3d535d881850 > > Possible! > > Have you tried it with 17.1? I think the 17.1 code semantically seems to > be doing the same as the patch. I'm still having trouble with 17.1. When I make Anton's changes, TeraTerm seems to work. As far as PuTTY, I assume the root cause is somewhere in ssh_connection.erl:handle_cli_msg() : handle_cli_msg(#connection{channel_cache = Cache} = Connection, #channel{user = undefined, remote_id = RemoteId, local_id = ChannelId} = Channel0, Reply0) -> case (catch start_cli(Connection, ChannelId)) of {ok, Pid} -> erlang:monitor(process, Pid), Channel = Channel0#channel{user = Pid}, ssh_channel:cache_update(Cache, Channel), Reply = {connection_reply, channel_success_msg(RemoteId)}, {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; _Other -> Reply = {connection_reply, channel_failure_msg(RemoteId)}, {{replies, [Reply]}, Connection} end; We start_cli() and send channel_success_msg(). Prior to the refactor I believe this was reply_msg() instead. If I change Reply = {connection_reply, channel_success_msg(RemoteId)}, {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; To: {Reply, Connection1} = reply_msg(Channel, Connection, Reply0), {{replies, [Reply]}, Connection1}; Then PuTTY seems happy again. Does this seem OK? Or am I messing something else up by "fixing" this. Thanks again for all the help, Mike From knutin@REDACTED Tue Jul 1 16:26:54 2014 From: knutin@REDACTED (Knut Nesheim) Date: Tue, 1 Jul 2014 16:26:54 +0200 Subject: [erlang-bugs] Missing comma between maps results in merge Message-ID: Hi, I was recently bitten by a combination of my own mistakes and a unexpected syntax with maps. I'm not sure if this is a bug or intended behaviour. 1> #{foo => bar, foo => quux}. #{foo => quux} 2> #{foo => bar} #{foo => quux}. #{foo => quux} In the second case, two maps are merged due to missing a separating comma between them. I would expect it to fail with a syntax error. Is this intended behaviour? Regards Knut -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Jul 1 16:42:54 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 1 Jul 2014 16:42:54 +0200 Subject: [erlang-bugs] Missing comma between maps results in merge In-Reply-To: References: Message-ID: <53B2C8EE.2060509@erlang.org> On 2014-07-01 16:26, Knut Nesheim wrote: > Hi, > > I was recently bitten by a combination of my own mistakes and a > unexpected syntax with maps. I'm not sure if this is a bug or intended > behaviour. > > 1> #{foo => bar, foo => quux}. > #{foo => quux} > 2> #{foo => bar} #{foo => quux}. > #{foo => quux} > > In the second case, two maps are merged due to missing a separating > comma between them. I would expect it to fail with a syntax error. It is the same behaviour as for records: 3> rr(t). [rec] 4> [#rec{foo=bar} #rec{foo=baz}]. [#rec{foo = baz}] > > Is this intended behaviour? The similarity with records is intentional .. but I agree that this behaviour should be revisited. I'm not convinced of it usefulness. Thank you for your feedback! > > Regards > Knut > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ingela.Anderton.Andin@REDACTED Tue Jul 1 17:22:24 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 1 Jul 2014 17:22:24 +0200 Subject: [erlang-bugs] SSH Bugs In-Reply-To: References: <53B2764E.6060807@ericsson.com> Message-ID: <53B2D230.2020809@ericsson.com> Hi! On 07/01/2014 03:14 PM, Michael.K.Schmidt@REDACTED wrote: > Hi Angela, ^^^^^^^^ It is a Swedish name starts with I ;) >> Ingela Anderton Andin >> Sent by: erlang-bugs-bounces@REDACTED >> >> 07/01/2014 03:50 AM >> >> To >> >> , >> >> cc >> >> Subject >> >> Re: [erlang-bugs] SSH Bugs >> >> Hi! >> >> On 06/30/2014 10:37 PM, Michael.K.Schmidt@REDACTED wrote: >>> >>> Hi, >>> >>> Does anyone know what the final resolution was with this bug? >>> http://erlang.org/pipermail/erlang-patches/2013-December/004499.html >> >> Humm I can not remeber seeing this patch before! Maybe it got lost in >> the process some how :( > > No worries! When I didn't see it in 17.1, I thought I would check to see if > that was the case. > >> >> >>> The patch given by Anton Ryabkov seems to address the immediate bug. > Is >>> this fix ok? Or is there a better way? >>> >>> With Anton's patch I am able to get this example to run: >>> > https://github.com/erlang/otp/blob/maint/lib/ssh/examples/ssh_sample_cli.erl > >>> >>> It works with Tera Term as the client, but when I try to use PuTTY I > get >>> the following error: >>> "Disconnected: Server protocol violation: unexpected >>> SSH2_MSG_CHANNEL_SUCCESS packet" >>> >>> I believe this worked with PuTTY before R16B03. Did an edge case get >>> missed with this refactor? >>> https://github.com/erlang/otp/commit/ >> 68263a48bfbdac4dc219a91f06af3d535d881850 >> >> Possible! >> >> Have you tried it with 17.1? I think the 17.1 code semantically seems to >> be doing the same as the patch. > > I'm still having trouble with 17.1. When I make Anton's changes, TeraTerm > seems to work. > > As far as PuTTY, I assume the root cause is somewhere in > ssh_connection.erl:handle_cli_msg() : > > handle_cli_msg(#connection{channel_cache = Cache} = Connection, > #channel{user = undefined, > remote_id = RemoteId, > local_id = ChannelId} = Channel0, Reply0) -> > > case (catch start_cli(Connection, ChannelId)) of > {ok, Pid} -> > erlang:monitor(process, Pid), > Channel = Channel0#channel{user = Pid}, > ssh_channel:cache_update(Cache, Channel), > Reply = {connection_reply, > channel_success_msg(RemoteId)}, > {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; > _Other -> > Reply = {connection_reply, > channel_failure_msg(RemoteId)}, > {{replies, [Reply]}, Connection} > end; > > We start_cli() and send channel_success_msg(). Prior to the refactor I > believe this was reply_msg() instead. If I change > Reply = {connection_reply, > channel_success_msg(RemoteId)}, > {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; > To: > {Reply, Connection1} = reply_msg(Channel, Connection, Reply0), > {{replies, [Reply]}, Connection1}; > > Then PuTTY seems happy again. Does this seem OK? Or am I messing something > else up by "fixing" this. Humm ... looks like the refactor went wrong, when I make this change which also conform with the next clause, the ssh test SUITE still passes. It would be great if you could make a pull-request and add a test case for this. I will make a ticket for this issue, but it is vacation times now so it will take a while for someone to look into the ticket. Regards Ingela Erlang/OTP team - Ericsson AB From Michael.K.Schmidt@REDACTED Tue Jul 1 22:43:55 2014 From: Michael.K.Schmidt@REDACTED (Michael.K.Schmidt@REDACTED) Date: Tue, 1 Jul 2014 15:43:55 -0500 Subject: [erlang-bugs] SSH Bugs In-Reply-To: <53B2D230.2020809@ericsson.com> References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> Message-ID: Ingela Anderton Andin wrote on 07/01/2014 10:22:24 AM: > Ingela Anderton Andin > 07/01/2014 10:22 AM > > To > > , > > cc > > , > > Subject > > Re: [erlang-bugs] SSH Bugs > > Hi! > > On 07/01/2014 03:14 PM, Michael.K.Schmidt@REDACTED wrote: > > Hi Angela, > > ^^^^^^^^ > > It is a Swedish name starts with I ;) I apologize!!! > > >> Ingela Anderton Andin > >> Sent by: erlang-bugs-bounces@REDACTED > >> > >> 07/01/2014 03:50 AM > >> > >> To > >> > >> , > >> > >> cc > >> > >> Subject > >> > >> Re: [erlang-bugs] SSH Bugs > >> > >> Hi! > >> > >> On 06/30/2014 10:37 PM, Michael.K.Schmidt@REDACTED wrote: > >>> > >>> Hi, > >>> > >>> Does anyone know what the final resolution was with this bug? > >>> http://erlang.org/pipermail/erlang-patches/2013-December/004499.html > >> > >> Humm I can not remeber seeing this patch before! Maybe it got lost in > >> the process some how :( > > > > No worries! When I didn't see it in 17.1, I thought I would check to see if > > that was the case. > > > >> > >> > >>> The patch given by Anton Ryabkov seems to address the immediate bug. > > Is > >>> this fix ok? Or is there a better way? > >>> > >>> With Anton's patch I am able to get this example to run: > >>> > > https://github.com/erlang/otp/blob/maint/lib/ssh/examples/ssh_sample_cli.erl > > > >>> > >>> It works with Tera Term as the client, but when I try to use PuTTY I > > get > >>> the following error: > >>> "Disconnected: Server protocol violation: unexpected > >>> SSH2_MSG_CHANNEL_SUCCESS packet" > >>> > >>> I believe this worked with PuTTY before R16B03. Did an edge case get > >>> missed with this refactor? > >>> https://github.com/erlang/otp/commit/ > >> 68263a48bfbdac4dc219a91f06af3d535d881850 > >> > >> Possible! > >> > >> Have you tried it with 17.1? I think the 17.1 code semantically seems to > >> be doing the same as the patch. > > > > I'm still having trouble with 17.1. When I make Anton's changes, TeraTerm > > seems to work. > > > > As far as PuTTY, I assume the root cause is somewhere in > > ssh_connection.erl:handle_cli_msg() : > > > > handle_cli_msg(#connection{channel_cache = Cache} = Connection, > > #channel{user = undefined, > > remote_id = RemoteId, > > local_id = ChannelId} = Channel0, Reply0) -> > > > > case (catch start_cli(Connection, ChannelId)) of > > {ok, Pid} -> > > erlang:monitor(process, Pid), > > Channel = Channel0#channel{user = Pid}, > > ssh_channel:cache_update(Cache, Channel), > > Reply = {connection_reply, > > channel_success_msg(RemoteId)}, > > {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; > > _Other -> > > Reply = {connection_reply, > > channel_failure_msg(RemoteId)}, > > {{replies, [Reply]}, Connection} > > end; > > > > We start_cli() and send channel_success_msg(). Prior to the refactor I > > believe this was reply_msg() instead. If I change > > Reply = {connection_reply, > > channel_success_msg(RemoteId)}, > > {{replies, [{channel_data, Pid, Reply0}, Reply]}, Connection}; > > To: > > {Reply, Connection1} = reply_msg(Channel, Connection, Reply0), > > {{replies, [Reply]}, Connection1}; > > > > Then PuTTY seems happy again. Does this seem OK? Or am I messing something > > else up by "fixing" this. > > Humm ... looks like the refactor went wrong, when I make this change > which also conform with the next clause, the ssh test SUITE still > passes. It would be great if you could make a pull-request and add a > test case for this. I will make a ticket for this issue, but it is > vacation times now so it will take a while for someone to look into the > ticket. How important is adding the ssh test SUITE? The reason I ask is that I am running on Windows at the moment, which not the easiest thing to get OTP to compile on. I have been just modifying the code shipped with the release and then recompiling :) Thanks! Mike > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > ______________________________________________________________________ From erlangsiri@REDACTED Wed Jul 2 11:54:36 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 2 Jul 2014 11:54:36 +0200 Subject: [erlang-bugs] Allow code upgrade for the code_server itself In-Reply-To: References: Message-ID: Stavros, you are right! Of course the change_code system message does not help. The only thing it does is to call system_code_change/4 in the new version of the module, but when it returns, the process keeps executing the old code. Your suggested change, to make the system_continue call on line 184 qualified, will solve the problem. It will, however, also make (almost) any system message effectuate a code change (if new code_server code is loaded), e.g. Erlang/OTP 18 [DEVELOPMENT] [erts-7.0] [source-a6de62b] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.0 (abort with ^G) 1> l(code_server). {module,code_server} 2> sys:get_status(code_server). {status,<0.20.0>, {module,code_server}, [[{any_native_code_loaded,false}], running,<0.11.0>,[], {state,<0.11.0>,"/ldisk/siri/git/otp", [".","/ldisk/siri/git/otp/lib/kernel/ebin", "/ldisk/siri/git/otp/lib/stdlib/ebin", [...]|...], 13,4110,no_cache,interactive,[]}]} 3> erlang:check_process_code(whereis(code_server),code_server). false I don't know if this is a good thing... On the other hand, that is the same as would happen for e.g. gen_server or any of the other gen* behaviour so maybe it is ok. Another potential problem is that if you do the suspend - change_code - resume sequence, then system_code_change would be called in the new code, but then the old code would run again after its return and until the resume message was handled. Depending on which part of the code that was actually changed, this could be fatal. In the gen* behaviour case this is not a problem since the code running in between is in sys and not in gen*. A bit more code, and exporting the suspend_loop function, could of course solve this problem... I think I need to discuss this a bit further with my team - if it is something we would want to do or not. Please let me know if such a change is at all desirable. Comments from others on the list are of course also welcome. Regards /siri 2014-06-27 14:11 GMT+02:00 Stavros Aronis : > > Hi Siri! > > You are right. I had a modification on the actual code_server.erl, which I hadn't removed when generating the previous report. With a clean R17 I cannot reproduce it so apologies for the false alarm. > > Back to the main topic, this sequence does not seem to work either, as the code_server is still stuck in old code: > > ~$ diff ~/git/otp/lib/kernel/src/code_server.erl ~/code_server.erl > 1263a1264 > > erlang:display(foo), > ~$ erlc code_server.erl > ~$ erl -nostick > Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.0 (abort with ^G) > 1> l(code_server). > {module,code_server} > 2> code:which(code_server). > "/home/stavros/code_server.beam" > 3> erlang:check_old_code(code_server). > true > 4> code:soft_purge(code_server). > false > 5> erlang:check_process_code(whereis(code_server),code_server). > true > 6> sys:suspend(code_server). > ok > 7> sys:change_code(code_server, code_server, ignored, ignored). > ok > 8> sys:resume(code_server). > ok > 9> erlang:check_process_code(whereis(code_server),code_server). > true > > Regards, > > Stavros > > > On Fri, Jun 27, 2014 at 1:31 PM, Siri Hansen wrote: >> >> Hi Stavros! >> >> 2014-06-23 11:48 GMT+02:00 Stavros Aronis : >> >>> a lot of time has passed indeed, and I have put in place a different kind of instrumentation, which works for what I want to do. Unfortunately I currently don't have the time to test again, but I suspect that the issue remains, for the reasons I explained. >> >> >> Yes, I assume nothing has changed - my point was that when receiving a change_code system message, code_server does a qualified call to system_code_change. This is where the actual code change is expected to happen - not in the call to system_continue at line 184. >> >> I would think that the reason that sys uses a qualified call is that the module in question is not ?MODULE, but rather a callback. >> >>> >>> >>> Here is another bug, admittedly unrelated (since I am not trying to update the code of the code_server *process*): >>> >>> 1) Copied code_server.erl to my home directory and added an "erlang:display(foo)" call before the single erlang:load_module/1 call in the module. >>> 2) Run the following: >>> $ erlc code_server.erl >>> $ erl -nostick >>> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] >>> >>> Eshell V6.0 (abort with ^G) >>> 1> l(code_server). >>> {module,code_server} >>> 2> code:which(code_server). >>> "/home/stavros/code_server.beam" >>> 3> erlang:check_old_code(code_server). >>> true >>> 4> code:soft_purge(code_server). >>> true >>> 5> l(te *TAB* >>> Crash dump was written to: erl_crash.dump >>> Internal error: Invalid reference count found on #Fun: About to erase fun still referred by code. >>> Aborted >>> >>> I would expect the soft_purge to fail and the system not to crash. >> >> >> Yes, I would also expect that. And I can not reproduce the problem :( >> >> $ erlc code_server.erl >> $ erl -nostick >> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V6.0 (abort with ^G) >> 1> l(code_server). >> {module,code_server} >> 2> code:which(code_server). >> "/home/siri/code_server.beam" >> 3> erlang:check_old_code(code_server). >> true >> 4> code:soft_purge(code_server). >> false >> >> I also have >> 5> erlang:check_process_code(whereis(code_server),code_server). >> true >> >> Do you have any other patches, or is it a plain 17.0? (Sorry - I don't have any other ideas right now :( ) >> >> /siri >> >>> >>> >>> On Thu, Jun 19, 2014 at 11:26 AM, Siri Hansen wrote: >>>> >>>> Hi Stavros, I'm sorry for the very long delay! Are you still struggling with this problem or did you find a way around it? Would a code_change system message while the process is suspended possibly solve the problem? >>>> Regards >>>> /siri >>>> >>>> >>>> 2014-03-10 23:02 GMT+01:00 Stavros Aronis : >>>>> >>>>> Hello! >>>>> >>>>> I am playing around with code instrumentation and trying to hack the code server so that it applies some transformation whenever it loads *any* module. The hack itself is relatively simple: >>>>> >>>>> 1) Instrument and reload any already loaded modules (come to think about it, during this process more modules may be loaded, but let's assume a fixpoint). This is to avoid the case where in order to load A, you have to instrument A, and the instrumenter itself needs a call to X, which is not yet loaded so you have to load X, so you have to instrument X, etc... >>>>> 2) Get the Core Erlang code of the codeserver and wrap the second argument of erlang:load_module (Line 1264) with a call to my instrumenter (which is a function from binary() -> binary()) >>>>> 3) Load the patched code_server code >>>>> 4) Move the code_server process from the old code to the new one. >>>>> >>>>> I am having trouble with the last step. As far as I understand it, the reason is that the call to system_continue (Line 184) is not qualified, as is the similar call in sys.erl (Line 324). >>>>> >>>>> Is there a reason why this is so? Is there any possibility for this to be patched? >>>>> >>>>> Cheers, >>>>> >>>>> Stavros >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-bugs mailing list >>>>> erlang-bugs@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabbe.fogelholm@REDACTED Wed Jul 2 14:56:26 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Wed, 2 Jul 2014 14:56:26 +0200 Subject: [erlang-bugs] Misspelled word "seperator" In-Reply-To: References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> Message-ID: <53B4017A.3070508@ericsson.com> When using Erlide there is help that may pop up when hovering over source items. Hovering over a string:tokens/2 function call causes the following to pop up: +------------------------ | tokens(String, Seperators). | Return a list of tokens seperated by characters in Seperators. +----------------------------------- The misspelled words (seperated etc) appear to come from the Erlang source code, in this case lib/stdlib/src/string.erl. Probably this cosmetic flaw can be seen in more places. A case-insensitive search for the string 'seperat' in the source tree yields these hits: ./lib/inets/src/inets_app/inets_regexp.erl ./lib/hipe/llvm/hipe_rtl_to_llvm.erl ./lib/parsetools/src/leex.erl ./lib/stdlib/src/edlin_expand.erl ./lib/stdlib/src/string.erl ./lib/stdlib/src/erl_lint.erl ./lib/stdlib/src/io_lib.erl ./lib/stdlib/src/edlin.erl ./lib/public_key/test/pkits_SUITE.erl ./lib/xmerl/src/xmerl_regexp.erl Rabbe Fogelholm, Ericsson, Stockholm From rabbe.fogelholm@REDACTED Wed Jul 2 15:02:08 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Wed, 2 Jul 2014 15:02:08 +0200 Subject: [erlang-bugs] Missing apostrophe In-Reply-To: References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> Message-ID: <53B402D0.9070607@ericsson.com> On this page http://www.erlang.org/doc/man/httpd.html#info-1 the sentence ... are the same as the servers start options ought to be ... are the same as the server's start options Rabbe Fogelholm, Ericsson, Stockholm From essen@REDACTED Thu Jul 3 13:51:46 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 03 Jul 2014 13:51:46 +0200 Subject: [erlang-bugs] Small oddities Message-ID: <53B543D2.9070909@ninenines.eu> Observing this on my Arch Linux install: $ erl -man 6 ssl ssl(7) Erlang Application Definition ssl(7) $ erl -man 7 ssl No manual entry for ssl in section 7 $ erl -man 6 common_test common_test(3) Erlang Module Definition common_test(3) Probably for others too. So now I'm not sure if I should use 6 or 7 for the "application" man page. Any hint appreciated. :-) -- Lo?c Hoguin http://ninenines.eu From lukas@REDACTED Thu Jul 3 14:46:34 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 3 Jul 2014 14:46:34 +0200 Subject: [erlang-bugs] Misspelled word "seperator" In-Reply-To: <53B4017A.3070508@ericsson.com> References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> <53B4017A.3070508@ericsson.com> Message-ID: <53B550AA.5020300@erlang.org> Hello, Thanks for reporting this. All of the places that you list below (including string:tokens/2) are internal comments or function that are not supposed to be exposed to the user of Erlang/OTP. I suppose that Erlide detects it as edoc style documentation and therefore uses it. That being said I found some other places where the word was misspelled and I've included them together with the servers -> server's fixes in a doc branch to be included in the next minor release. Thanks, Lukas On 02/07/14 14:56, Rabbe Fogelholm wrote: > When using Erlide there is help that may pop up when hovering over > source items. > > Hovering over a string:tokens/2 function call causes the following > to pop up: > > +------------------------ > | tokens(String, Seperators). > | Return a list of tokens seperated by characters in Seperators. > +----------------------------------- > > The misspelled words (seperated etc) appear to come from the Erlang > source code, in this case lib/stdlib/src/string.erl. > > Probably this cosmetic flaw can be seen in more places. A > case-insensitive search for the string 'seperat' in the source > tree yields these hits: > > ./lib/inets/src/inets_app/inets_regexp.erl > ./lib/hipe/llvm/hipe_rtl_to_llvm.erl > ./lib/parsetools/src/leex.erl > ./lib/stdlib/src/edlin_expand.erl > ./lib/stdlib/src/string.erl > ./lib/stdlib/src/erl_lint.erl > ./lib/stdlib/src/io_lib.erl > ./lib/stdlib/src/edlin.erl > ./lib/public_key/test/pkits_SUITE.erl > ./lib/xmerl/src/xmerl_regexp.erl > > Rabbe Fogelholm, Ericsson, Stockholm > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From rabbe.fogelholm@REDACTED Thu Jul 3 14:48:40 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Thu, 3 Jul 2014 14:48:40 +0200 Subject: [erlang-bugs] Typo in http://www.erlang.org/doc/man/httpd.html#Module:do-1 In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <53B55128.1080900@ericsson.com> The page http://www.erlang.org/doc/man/httpd.html#Module:do-1 has the mistyped word StausCode Rabbe fogelholm, Ericsson, Stockholm From magnus.liden@REDACTED Thu Jul 3 15:13:10 2014 From: magnus.liden@REDACTED (Magnus Liden) Date: Thu, 3 Jul 2014 15:13:10 +0200 Subject: [erlang-bugs] Small oddities In-Reply-To: <53B543D2.9070909@ninenines.eu> References: <53B543D2.9070909@ninenines.eu> Message-ID: <53B556E6.5030003@ericsson.com> Hi, There seems to be even more oddities in there.. wonder why Typing 'man man' shows the different sections and section 6 is games ;) Thanks for reporting! Regards, Magnus Lid?n Erlang/OTP On 07/03/2014 01:51 PM, Lo?c Hoguin wrote: > Observing this on my Arch Linux install: > > $ erl -man 6 ssl > ssl(7) Erlang > Application Definition > ssl(7) > > $ erl -man 7 ssl > No manual entry for ssl in section 7 > > $ erl -man 6 common_test > common_test(3) Erlang Module > Definition common_test(3) > > Probably for others too. > > So now I'm not sure if I should use 6 or 7 for the "application" man > page. Any hint appreciated. :-) > From jose.valim@REDACTED Fri Jul 4 17:10:31 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Fri, 4 Jul 2014 17:10:31 +0200 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends Message-ID: Hello everyone, I have found the documentation or implementation file:read/2 to be misleading when working with unicode devices in binary mode. I will use file:read_line/1 in the examples below but the issue applies to file:read/2, file:pread/1 and etc. $ echo "h?llo" > foo $ erl 1> {ok, F} = file:open("foo", [binary, unicode]). {ok,<0.34.0>} 2> {ok, Bin} = file:read_line(F). {ok,<<"h?llo\n">>} 3> <>. <<104,233,108,108,111,10, 0>> Not the result is not the one desired because I expected a binary containing <<"h?llo\n"/utf8>>, or more explicitly, I expected it to contain the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 as result. With char lists, we would get "h?llo\n" but the function will fail for any codepoint > 255. Note this behaviour also happens if I use file:read_line/1 on any other IO device set to unicode (like standard_io). The trouble I have with the function is that it is aimed to byte-oriented but it only really works for latin1 files. If you have a unicode file, the behaviour seems to be broken for binaries, and it only works for a limited range of codepoints when using char lists. It is interesting to notice those functions use the old {get_line, Prompt} messages which, according to the I/O protocol guide , should not exist beyond R15B (section 1.3). The same section above suggests to translate {get_line, Prompt} to {get_line, latin1, Prompt} which seems to be the root cause of the issues above: those functions were never meant to work with unicode devices. Unless I am terribly wrong, I can think of some ways to fix those functions: 1. Keep its dual aspect of returning bytes and/or characters but fix the bug when working with unicode. This means the {get_line, Prompt} should rather translate to {get_line, EncodingOfTheIODevice, Prompt} 2. Make them crash if the encoding of the device is not latin1. This means we translate {get_line, Prompt} to {get_line, latin1, Prompt} only if the encoding of the device is latin1. 3. Make it always work at the byte level, regardless of the encoding of the IO device. This would require assigning new meaning to the {get_line, Prompt} message, so I believe it is not going to happen (although it would be a useful feature in my opinion). Given that the original IO messages were never meant to work with unicode, maybe 2) is the best way to go here. Both 1) and 2) would require a small amendment to the current I/O protocol advice but I would argue it is necessary to fix the current limitations/bugs when working with unicode. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Jul 4 19:33:10 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 4 Jul 2014 13:33:10 -0400 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: <20140704173309.GB51530@ferdair.local> On 07/04, Jos? Valim wrote: > Hello everyone, > > I have found the documentation or implementation file:read/2 to be > misleading when working with unicode devices in binary mode. I will use > file:read_line/1 in the examples below but the issue applies to > file:read/2, file:pread/1 and etc. > > $ echo "h?llo" > foo > > $ erl > 1> {ok, F} = file:open("foo", [binary, unicode]). > {ok,<0.34.0>} > 2> {ok, Bin} = file:read_line(F). > {ok,<<"h?llo\n">>} > 3> <>. > <<104,233,108,108,111,10, 0>> > > > Not the result is not the one desired because I expected a binary > containing <<"h?llo\n"/utf8>>, or more explicitly, I expected it to contain > the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 as > result. With char lists, we would get "h?llo\n" but the function will fail > for any codepoint > 255. > What you got isn't latin1: 1> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary]), file:read_line(F) end]). {ok,<<104,195,169,108,108,111,10>>} 2> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,latin1}]), file:read_line(F) end]). {ok,<<104,195,169,108,108,111,10>>} 3> f(F), io:format("~p~n",[begin {ok, F} = file:open("foo", [binary, {encoding,latin1}]), file:read_line(F) end]). {ok,<<"h??llo\n">>} 4> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,unicode}]), file:read_line(F) end]). {ok,<<104,233,108,108,111,10>>} 5> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,utf16}]), file:read_line(F) end]). {error,collect_line} You can see the latin1 reading does not modify the ? (195,169) value, it interprets it as-is. On the other hand, the UTF-8 version converts it. '?' can be represented both as U+00E9 (233) as a codepoint or UTF16 value. The appropriate Unicode representation for that one is indeed <<195,169>> (0xC3 0xA9), or alternatively <<101,204,129>> (if you used the e+combining ' form). So what you got I think isn't the latin1 result (because latin1 interprets things as they are) -- what you got is the decoded codepoint that would usually be stuck in a list, and had it turned directly into a binary without the proper UTF8 encoding: 6> unicode:characters_to_binary([104,233,108,108,111,10]). <<"h?llo\n"/utf8>> Here's an interesting one: $ echo "h?llo<0001f603>" > foo (which is $ echo "h?llo??" > foo with emoji, if the email client supports it) 1> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,latin1}]), file:read_line(F) end]). {ok,<<104,195,169,108,108,111,240,159,152,131,10>>} ok 2> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,unicode}]), file:read_line(F) end]). {error,collect_line} I'd be ready to bet that the collect_line error comes from something a bit like a list_to_binary(Str) call on a list, assuming what we had were still a byte stream rather than a unicode string. Regards, Fred. From jose.valim@REDACTED Fri Jul 4 20:37:37 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Fri, 4 Jul 2014 20:37:37 +0200 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: <20140704173309.GB51530@ferdair.local> References: <20140704173309.GB51530@ferdair.local> Message-ID: I had a fruitful discussion with Fred on IRC. Fred pointed out that this works: $ echo "h?llo<0001f603>" > foo (which is $ echo "h?llo??" > foo with emoji, if the email client supports it) $ erl 1> io:format("~w~n",[begin {ok, F} = file:open("foo", [{encoding,unicode}]), file:read_line(F) end]). {ok,[104,233,108,108,111,128515,10]} According to the docs of file:read_line/1, this is not supposed to happen: "If encoding is set to something else than latin1, the read_line/1 call will fail if the data contains characters larger than 255, why the io(3) module is to be preferred when reading such a file." If the IO device is meant to return all unicode codepoints as above, it means {get_line, Prompt} should translate to {get_line, IODeviceEncoding, Prompt} and we need to amend the I/O protocol to say so. However, if the result is meant to be invalid, it means file:read_line/1 does an implicit conversion to latin1, since {get_line, Prompt} translates to {get_line, latin1, Prompt}. We could document it but I would rather disallow it by making the requests fail if the IO device encoding is not latin1. I tried to sum up the possible solutions, in no particular order, to the best of my analysis: 1. Make it explicit that file:read_line/1 does a latin1 conversion. This means we need to fix the code to raise for codepoints > 255 when returning char lists (but the translation is a confusing behaviour imo) 2. Make it explicit that file:read_line/1 only works if the IO device is encoded in latin1. This means we need to change the code to fail for non latin1 encodings. The old I/O protocol messages would have to be amended to say (addition in bold): These should behave as {get_until, latin1, Prompt, Module, Function, ExtraArgs}, {get_chars, latin1, Prompt, N} and {get_line, latin1, Prompt} respectively *if the device is encoded in latin1, otherwise it should return an error *(error to be specified). 3. Make file:read_line/1 return in the encoding of the I/O device. This means we need to change the code to translate {get_line, Prompt} to {get_line, IODeviceEncoding, Prompt}. However, this change implies the function is no longer byte-oriented. In any case, the old I/O protocol messages would have to be amended to say (addition in bold): These should behave as {get_until, DeviceEncoding, Prompt, Module, Function, ExtraArgs}, {get_chars, DeviceEncoding, Prompt, N} and {get_line, DeviceEncoding, Prompt} respectively*, where DeviceEncoding is the encoding of the device.* 4. Make file:read_line/1 always read bytes, regardless of the encoding. This is arguably the behaviour of those messages before unicode was added. This means however the devices would need to implement specific logic for those messages as they cannot simply translate {get_line, Prompt} to {get_line, latin1, Prompt}. To me, the best solutions are 2 and 4, because they preserve the byte-oriented aspect. Regardless, it seems the implementation of file:read_line/1 has a bug. :) *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Fri, Jul 4, 2014 at 7:33 PM, Fred Hebert wrote: > On 07/04, Jos? Valim wrote: > > Hello everyone, > > > > I have found the documentation or implementation file:read/2 to be > > misleading when working with unicode devices in binary mode. I will use > > file:read_line/1 in the examples below but the issue applies to > > file:read/2, file:pread/1 and etc. > > > > $ echo "h?llo" > foo > > > > $ erl > > 1> {ok, F} = file:open("foo", [binary, unicode]). > > {ok,<0.34.0>} > > 2> {ok, Bin} = file:read_line(F). > > {ok,<<"h?llo\n">>} > > 3> <>. > > <<104,233,108,108,111,10, 0>> > > > > > > Not the result is not the one desired because I expected a binary > > containing <<"h?llo\n"/utf8>>, or more explicitly, I expected it to > contain > > the bytes <<195, 169>> instead of <<233>>. In other words, I got latin1 > as > > result. With char lists, we would get "h?llo\n" but the function will > fail > > for any codepoint > 255. > > > > What you got isn't latin1: > > 1> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary]), > file:read_line(F) end]). > {ok,<<104,195,169,108,108,111,10>>} > 2> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,latin1}]), file:read_line(F) end]). > {ok,<<104,195,169,108,108,111,10>>} > 3> f(F), io:format("~p~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,latin1}]), file:read_line(F) end]). > {ok,<<"h??llo\n">>} > 4> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,unicode}]), file:read_line(F) end]). > {ok,<<104,233,108,108,111,10>>} > 5> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,utf16}]), file:read_line(F) end]). > {error,collect_line} > > You can see the latin1 reading does not modify the ? (195,169) value, it > interprets it as-is. > > On the other hand, the UTF-8 version converts it. '?' can be represented > both as U+00E9 (233) as a codepoint or UTF16 value. The appropriate > Unicode representation for that one is indeed <<195,169>> (0xC3 0xA9), > or alternatively <<101,204,129>> (if you used the e+combining ' form). > > So what you got I think isn't the latin1 result (because latin1 > interprets things as they are) -- what you got is the decoded codepoint > that would usually be stuck in a list, and had it turned directly into a > binary without the proper UTF8 encoding: > > 6> unicode:characters_to_binary([104,233,108,108,111,10]). > <<"h?llo\n"/utf8>> > > Here's an interesting one: > > $ echo "h?llo<0001f603>" > foo > (which is $ echo "h?llo??" > foo with emoji, if the email client supports > it) > > 1> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,latin1}]), file:read_line(F) end]). > {ok,<<104,195,169,108,108,111,240,159,152,131,10>>} > ok > 2> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, > {encoding,unicode}]), file:read_line(F) end]). > {error,collect_line} > > I'd be ready to bet that the collect_line error comes from something a > bit like a list_to_binary(Str) call on a list, assuming what we had were > still a byte stream rather than a unicode string. > > > Regards, > Fred. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Jul 4 20:56:38 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 4 Jul 2014 14:56:38 -0400 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: <20140704173309.GB51530@ferdair.local> Message-ID: <20140704185637.GD51530@ferdair.local> On 07/04, Jos? Valim wrote: > I had a fruitful discussion with Fred on IRC. Fred pointed out that this > works: > > $ echo "h?llo<0001f603>" > foo > (which is $ echo "h?llo??" > foo with emoji, if the email client supports > it) > > $ erl > 1> io:format("~w~n",[begin {ok, F} = file:open("foo", > [{encoding,unicode}]), file:read_line(F) end]). > {ok,[104,233,108,108,111,128515,10]} > > According to the docs of file:read_line/1, this is not supposed to happen: > > "If encoding is set to something else than latin1, the read_line/1 call > will fail if the data contains characters larger than 255, why the io(3) > module is to be preferred when reading such a file." > > If the IO device is meant to return all unicode codepoints as above, it > means {get_line, Prompt} should translate to {get_line, IODeviceEncoding, > Prompt} and we need to amend the I/O protocol to say so. > This example case not only shows the bug mentioned by Jos? here, 1> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [{encoding,unicode}]), file:read_line(F) end]). {ok,[104,233,108,108,111,128515,10]} ok 2> f(F), io:format("~w~n",[begin {ok, F} = file:open("foo", [binary, {encoding,unicode}]), file:read_line(F) end]). {error,collect_line} ok In this case, what I suspect goes on (without looking at the source) is that the conversion to a binary is done only *after* everything has been read as unicode, and a bland 'list_to_binary/1' is applied where a 'characters:unicode_to_binary/1' would have been appropriate, if it is decided that returning bytes > 255 is to be supported. Regards, Fred. From define.null@REDACTED Fri Jul 4 22:47:10 2014 From: define.null@REDACTED (Vasily Demidenok) Date: Sat, 5 Jul 2014 00:47:10 +0400 Subject: [erlang-bugs] Weird behaviour of gen_tcp:send/2 and erlang:port_command/3 with nosuspend to the same port on R16B03 In-Reply-To: <53A9B544.1080508@erlang.org> References: <53A9B544.1080508@erlang.org> Message-ID: The problem remains even if only erlang:port_command/3 with nosuspend option is used. (no calls for gen_tcp:send and many processes write to the same socket) 2014-06-24 21:28 GMT+04:00 Lukas Larsson : > Hello, > > I was able to reproduce your testcase after removing all the "msg" > printouts and starting a couple of clients at the same time. It seems that > the sockets are hitting the high_msgq_watermark limit and then as data gets > flushes they are not set to run again. I'll see if I can dig out what it is > that is causing this behavior. > > Lukas > > On 24/06/14 16:56, Vasily Demidenok wrote: > > Hello list, we faced with some gen_tcp related problems after switch > from erlang R15B03 to R16B03-01 > > The problem is as following: When server produce data faster then > consumer can handle, after > the out server's buffers are full and incoming client's buffers are full > gen_tcp:send/2 call on server side blocks forever in > erts_internal:port_command/3. After this, even when client consumes all > the data and the buffers are empty server process remains to be suspended > in that call > > This problem does not occur always, but quite often. > > Some details on implementation are below, I also shrink the example to > this small app so you can check the code: > https://github.com/define-null/tcp_failing_ex > > Server is implemented in such a way, that it listen on 8899 port, then > when client connect to it spawn main srv process and plenty of workers, > which start to write to this port after client send some special msg. The > main process is responsible for commands from the client and send responses > via gen_tcp:send/2, while workers try to write some stream data to the > client and use erang:port_command with no-suspend. So workers send only > up-to-date data, dropping any in case client is slow. > > The behaviour which we see is as following: > At first phase producer fills OS and erlang driver's buffers. Consumer > read data as it arrives and server drop data which it cannot send. So we > see buffer size growing on both side out queue of the server and in queue > of the client respectively > > After some moment in time, i guess when the buffers are completely > filled, server try respond to > ping message of the client, using gen_tcp:send/2 call. After that, it > blocks there forever, even after client consumes all the messages. The > situation does not change and the srv process remains in the suspended > state, while it's incoming buffer begins to grow when client send more ping > messages. > > Below is the output on the system with two slow clients, where for the > first client server's process is already blocked in gen_tcp:send/2 call, > while the second is served well. > > Every 2.0s: netstat -al | grep 8899 > > Tue Jun 24 16:34:51 2014 > > tcp4 36 0 localhost.8899 localhost.63263 > ESTABLISHED > tcp4 0 0 localhost.63263 localhost.8899 > ESTABLISHED > tcp4 0 130990 localhost.8899 localhost.63257 > ESTABLISHED > tcp4 619190 0 localhost.63257 localhost.8899 ESTABLISHED > tcp4 0 0 *.8899 *.* LISTEN > > This is the output for the client process from github example, where we > see that > after send operation (ping msg) no incoming msg come any more. > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,28}}: msg > {{2014,6,24},{16,33,48}} before send > {{2014,6,24},{16,33,48}} after send ok > {{2014,6,24},{16,34,9}} before send > {{2014,6,24},{16,34,9}} after send ok > {{2014,6,24},{16,34,30}} before send > {{2014,6,24},{16,34,30}} after send ok > {{2014,6,24},{16,34,51}} before send > {{2014,6,24},{16,34,51}} after send ok > {{2014,6,24},{16,35,12}} before send > .... > > Server blocked process output: > > {{2014,6,24},{16,33,21}}: <0.95.0> ping > {{2014,6,24},{16,33,21}} bsend: <0.95.0> > {{2014,6,24},{16,33,21}} asend: <0.95.0> ok > {{2014,6,24},{16,33,48}}: <0.95.0> ping > {{2014,6,24},{16,33,48}} bsend: <0.95.0> > %% (no asend message after it) > > (tcp_failing_node@REDACTED)1> erlang:process_info(pid(0,95,0)). > [{current_function,{erts_internal,port_command,3}}, > {initial_call,{proc_lib,init_p,5}}, > > Bug is not always reproducible, but occurs quite often. The problem is > that even > after server's out buffers are empty data does not arrive to the client, > and incoming buffer grow > as client send ping messages to the server. (So erlang:port_command/3 with > no-suspend always return false > when another main server process for this connection is suspended in > gen_tcp:send/2) > > And then it's getting only worse as already mentioned > > Every 2.0s: netstat -al | grep 8899 > > Tue Jun 24 16:56:59 2014 > > tcp4 804 0 localhost.8899 localhost.63263 > ESTABLISHED > tcp4 0 0 localhost.63263 localhost.8899 > ESTABLISHED > tcp4 0 0 localhost.8899 localhost.63257 > ESTABLISHED > tcp4 0 0 localhost.63257 localhost.8899 > ESTABLISHED > tcp4 0 0 *.8899 *.* LISTEN > > We faced with this after switching to R16B03 from R15B03, I know there > were some changes in port_command handling, i guess why we got such > behaviour? > > > _______________________________________________ > erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Jul 7 12:32:24 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Mon, 7 Jul 2014 12:32:24 +0200 Subject: [erlang-bugs] Missing comma between maps results in merge In-Reply-To: <53B2C8EE.2060509@erlang.org> References: <53B2C8EE.2060509@erlang.org> Message-ID: FWIW, I don't see the automatic maps merge behaviour being useful to justify itself or even the possible confusion it may cause. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Tue, Jul 1, 2014 at 4:42 PM, Bj?rn-Egil Dahlberg wrote: > On 2014-07-01 16:26, Knut Nesheim wrote: > > Hi, > > I was recently bitten by a combination of my own mistakes and a > unexpected syntax with maps. I'm not sure if this is a bug or intended > behaviour. > > 1> #{foo => bar, foo => quux}. > #{foo => quux} > 2> #{foo => bar} #{foo => quux}. > #{foo => quux} > > In the second case, two maps are merged due to missing a separating > comma between them. I would expect it to fail with a syntax error. > > > It is the same behaviour as for records: > > 3> rr(t). > [rec] > 4> [#rec{foo=bar} #rec{foo=baz}]. > [#rec{foo = baz}] > > > Is this intended behaviour? > > > The similarity with records is intentional .. but I agree that this > behaviour should be revisited. I'm not convinced of it usefulness. > > Thank you for your feedback! > > > Regards > Knut > > > _______________________________________________ > erlang-bugs mailing listerlang-bugs@REDACTED://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 pierrefenoll@REDACTED Mon Jul 7 14:52:26 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Mon, 7 Jul 2014 14:52:26 +0200 Subject: [erlang-bugs] Missing comma between maps results in merge In-Reply-To: References: <53B2C8EE.2060509@erlang.org> Message-ID: I believe there are 2 ways to inhibit this behavior: ? Change the behavior of the merge of maps/records literals (non backwards compatible) ? introduce a new maps/records syntax that is not prefix (backwards compatible) Using a non-prefix syntax for maps and records would single-handedly allow for making .,; separators redundant and thus optional. > On 07 Jul 2014, at 12:32, Jos? Valim wrote: > > FWIW, I don't see the automatic maps merge behaviour being useful to justify itself or even the possible confusion it may cause. From pcooper@REDACTED Fri Jul 11 16:42:29 2014 From: pcooper@REDACTED (Peter Cooper) Date: Fri, 11 Jul 2014 10:42:29 -0400 Subject: [erlang-bugs] SSL Client Certificate Request types with EC certificates Message-ID: It's entirely possible (even likely) I'm misunderstanding something about how these SSL ciphers are supposed to work, but the behavior I'm seeing looks like an Erlang issue to me. I'm trying to use RabbitMQ on Erlang 17.1 on 64-bit Windows 7, requiring a connection using SSL with a client certificate. All the certificates are using elliptic curve (secp256k1) keys. However, my client (in Java) isn't sending its client certificate because the CertificateRequest message from the RabbitMQ/Erlang server is saying that it's requesting an RSA certificate, whereas all I have is an EC certificate. I'm trying to use cipher suite {ecdhe_ecdsa, aes_128_cbc, sha256} which I think is the correct one, but the place that specifies what types of certificates to request (ssl_handshake's certificate_types function) at https://github.com/erlang/otp/blob/maint-17/lib/ssl/src/ssl_handshake.erl#L1110 doesn't seem to handle this case correctly and always asks for just RSA rather than ECDSA certificate. When I connect to the server using the same keys with "openssl s_client", the connection is established and the certificate gets sent fine, which leads me to think that openssl isn't checking for the type in the CertificateRequest message and is just sending the certificate I specify. So it looks like Erlang's SSL module can handle the certificate just fine if the client ignores the list of requested types. Thanks for any help you could provide. -- Peter Cooper Jr. Sr. Software Engineer EFI From pcooper@REDACTED Fri Jul 11 18:21:02 2014 From: pcooper@REDACTED (Peter Cooper) Date: Fri, 11 Jul 2014 12:21:02 -0400 Subject: [erlang-bugs] SSL Client Certificate Request types with EC certificates In-Reply-To: References: Message-ID: > -----Original Message----- > From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs- > bounces@REDACTED] On Behalf Of Peter Cooper > Sent: Friday, July 11, 2014 10:42 AM > To: 'erlang-bugs@REDACTED' > Subject: [erlang-bugs] SSL Client Certificate Request types with EC > certificates > > It's entirely possible (even likely) I'm misunderstanding something > about how these SSL ciphers are supposed to work, but the behavior I'm > seeing looks like an Erlang issue to me. I'm trying to use RabbitMQ on > Erlang 17.1 on 64-bit Windows 7, requiring a connection using SSL with > a client certificate. All the certificates are using elliptic curve > (secp256k1) keys. However, my client (in Java) isn't sending its client > certificate because the CertificateRequest message from the > RabbitMQ/Erlang server is saying that it's requesting an RSA > certificate, whereas all I have is an EC certificate. I'm trying to use > cipher suite {ecdhe_ecdsa, aes_128_cbc, sha256} which I think is the > correct one, but the place that specifies what types of certificates to > request (ssl_handshake's certificate_types function) at > https://github.com/erlang/otp/blob/maint- > 17/lib/ssl/src/ssl_handshake.erl#L1110 > doesn't seem to handle this case correctly and always asks for just RSA > rather than ECDSA certificate. > > When I connect to the server using the same keys with "openssl > s_client", the connection is established and the certificate gets sent > fine, which leads me to think that openssl isn't checking for the type > in the CertificateRequest message and is just sending the certificate I > specify. So it looks like Erlang's SSL module can handle the > certificate just fine if the client ignores the list of requested > types. > > Thanks for any help you could provide. My apologies for the double-post, but I thought that showing a patch of a change that made the system work as expected for me would be helpful. This clearly isn't the way one should do this in general, as it's just handling the particular cipher I've chosen, but it looks like by the time it is figuring out the certificate type the cipher suite has already been mapped to the OpenSSL-equivalent name, and that name is what it's using to match. I'm not sure which ciphers accept just ECDSA, just RSA, or both, but since at least one accepts ECDSA there needs to be some more checking here of some sort. In the meantime, I've applied this patch to my system so I can continue developing my project. Thanks! --- ssl-5.3.5\src\ssl_handshake.erl Mon Jun 23 17:24:48 2014 +++ ssl-5.3.5-mod\src\ssl_handshake.erl Fri Jul 11 12:05:21 2014 @@ -1110,6 +1110,10 @@ KeyExchange == dhe_ecdsa -> <>; +certificate_types(Cipher) + when Cipher == ?TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 -> + <>; + certificate_types(_) -> <>. -- Peter Cooper Jr. Sr. Software Engineer EFI From louis-philippe.gauthier@REDACTED Fri Jul 18 06:46:56 2014 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Fri, 18 Jul 2014 00:46:56 -0400 Subject: [erlang-bugs] --enable-native-libs is broken Message-ID: Hi, I've been trying to compile 17.1 with native libs... without any success. I get different errors on Linux and OSX. Linux: % build tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ ./configure --enable-smp-support --enable-threads --enable-kernel-poll --enable-hipe --enable-native-libs make % install sudo su rm -rf /usr/local/lib/erlang/ make install % test erl Erlang/OTP 17 [erts-6.1] [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.1 (abort with ^G) 1> code:is_loaded(gen_server). {file,"/usr/local/lib/erlang/lib/stdlib-2.1/ebin/gen_server.beam"} 2> code:is_module_native(gen_server). false OSX: % build tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ ./configure --enable-smp-support --enable-threads --enable-kernel-poll --enable-hipe --enable-native-libs --enable-darwin-64bit --with-dynamic-trace=dtrace make % error === Entering application hipe ERLC ../ebin/hipe_rtl.beam hipe_rtl.erl: internal error in native_compile; crash reason: undef full stacktrace: https://gist.github.com/lpgauth/74aea9a99b9763a6ffdb -------------- next part -------------- An HTML attachment was scrubbed... URL: From boost.subscribing@REDACTED Fri Jul 18 07:57:32 2014 From: boost.subscribing@REDACTED (Du Felix) Date: Fri, 18 Jul 2014 13:57:32 +0800 Subject: [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when cross compiling Message-ID: Hi everyone. I did a cross compiling with the command: ./configure --host=arm-linux-gnueabif Duiring compilation, I got such error: === Entering application hipe make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' ERLC ../ebin/hipe_consttab.beam /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1: /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word unexpected (expecting ")") make[3]: *** [../ebin/hipe_consttab.beam] Error 2 make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib' make: *** [secondary_bootstrap_build] Error 2 When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't find hipe_consttab.beam. I could successfully compiled a x86 erlang on my linux mint, but got that error while cross compling. From kostis@REDACTED Fri Jul 18 09:18:21 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 18 Jul 2014 10:18:21 +0300 Subject: [erlang-bugs] --enable-native-libs is broken In-Reply-To: References: Message-ID: <53C8CA3D.9070509@cs.ntua.gr> On 07/18/2014 07:46 AM, Louis-Philippe Gauthier wrote: > Hi, > I've been trying to compile 17.1 with native libs... without any > success. I get different errors on Linux and OSX. > > Linux: > > % build > > tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ > ./configure --enable-smp-support --enable-threads --enable-kernel-poll > --enable-hipe --enable-native-libs > make > > % install > > sudo su > rm -rf /usr/local/lib/erlang/ > make install > > % test > > erl > Erlang/OTP 17 [erts-6.1] [source] [64-bit] [smp:2:2] [async-threads:10] > [hipe] [kernel-poll:false] > > Eshell V6.1 (abort with ^G) > 1> code:is_loaded(gen_server). > {file,"/usr/local/lib/erlang/lib/stdlib-2.1/ebin/gen_server.beam"} > 2> code:is_module_native(gen_server). > false This is a known issue. It's due to the fact that the tar balls that are distributed by Ericsson have prebuilt .beam files in them, which do not contain native code. For these files, the options supplied to configure are ineffective. (I would actually classify this as a bug.) So, one needs to do a make clean after unpacking. Try the following sequence of commands: tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ make clean ./configure --enable-smp-support --enable-threads --enable-kernel-poll --enable-hipe --enable-native-libs make This should give you a system with .beam files containing native code for the main applications (e.g. kernel, stdlib, compiler, ...) For the OSX issues I cannot help you much I am afraid since I do not have access to such an environment to try it out. Kostis From louis-philippe.gauthier@REDACTED Fri Jul 18 14:57:20 2014 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Fri, 18 Jul 2014 08:57:20 -0400 Subject: [erlang-bugs] --enable-native-libs is broken In-Reply-To: <53C8CA3D.9070509@cs.ntua.gr> References: <53C8CA3D.9070509@cs.ntua.gr> Message-ID: Hi Kostis, Doing make clean doesn't work since the Makefiles are not generated yet... Downloads $ tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ otp_src_17.1 $ make clean make: *** No rule to make target `clean'. Stop. I've written a new Gentoo Ebuild that installs from Git and everything works as expected. I'll just install from Git when I need native libs. ebuild: https://gist.github.com/lpgauth/00d16e006be059b75d26 h052 erlang # erl Erlang/OTP 17 [erts-6.1.2] [source] [64-bit] [smp:32:32] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.1.2 (abort with ^G) 1> code:is_loaded(gen_server). {file,"/usr/lib64/erlang/lib/stdlib-2.1.1/ebin/gen_server.beam"} 2> code:is_module_native(gen_server). true By the way, I've tried reproducing the HiPE binary "corruption" issue I was experiencing on R16 and it seems fixed. Thanks, LP On Fri, Jul 18, 2014 at 3:18 AM, Kostis Sagonas wrote: > On 07/18/2014 07:46 AM, Louis-Philippe Gauthier wrote: > >> Hi, >> I've been trying to compile 17.1 with native libs... without any >> success. I get different errors on Linux and OSX. >> >> Linux: >> >> % build >> >> tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ >> ./configure --enable-smp-support --enable-threads --enable-kernel-poll >> --enable-hipe --enable-native-libs >> make >> >> % install >> >> sudo su >> rm -rf /usr/local/lib/erlang/ >> make install >> >> % test >> >> erl >> Erlang/OTP 17 [erts-6.1] [source] [64-bit] [smp:2:2] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> Eshell V6.1 (abort with ^G) >> 1> code:is_loaded(gen_server). >> {file,"/usr/local/lib/erlang/lib/stdlib-2.1/ebin/gen_server.beam"} >> 2> code:is_module_native(gen_server). >> false >> > > This is a known issue. It's due to the fact that the tar balls that are > distributed by Ericsson have prebuilt .beam files in them, which do not > contain native code. For these files, the options supplied to configure > are ineffective. (I would actually classify this as a bug.) > > So, one needs to do a make clean after unpacking. Try the following > sequence of commands: > > > tar -xzf otp_src_17.1.tar.gz && cd otp_src_17.1/ > make clean > > ./configure --enable-smp-support --enable-threads --enable-kernel-poll > --enable-hipe --enable-native-libs > make > > This should give you a system with .beam files containing native code for > the main applications (e.g. kernel, stdlib, compiler, ...) > > > For the OSX issues I cannot help you much I am afraid since I do not have > access to such an environment to try it out. > > Kostis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.K.Schmidt@REDACTED Fri Jul 18 18:17:29 2014 From: Michael.K.Schmidt@REDACTED (Michael.K.Schmidt@REDACTED) Date: Fri, 18 Jul 2014 11:17:29 -0500 Subject: [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when cross compiling In-Reply-To: References: Message-ID: erlang-bugs-bounces@REDACTED wrote on 07/18/2014 12:57:32 AM: > Du Felix > Sent by: erlang-bugs-bounces@REDACTED > > 07/18/2014 12:57 AM > > To > > erlang-bugs@REDACTED, > > cc > > Subject > > [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when > cross compiling > > Hi everyone. > I did a cross compiling with the command: > ./configure --host=arm-linux-gnueabif > Duiring compilation, I got such error: > > === Entering application hipe > make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > ERLC ../ebin/hipe_consttab.beam > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1: > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word > unexpected (expecting ")") > make[3]: *** [../ebin/hipe_consttab.beam] Error 2 > make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > make[2]: *** [opt] Error 2 > make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe' > make[1]: *** [opt] Error 2 > make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib' > make: *** [secondary_bootstrap_build] Error 2 > > When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't > find hipe_consttab.beam. > > I could successfully compiled a x86 erlang on my linux mint, but > got that error while cross compling. Cross compiling to ARM is a little involved. See if either of these projects meet your needs: Nerves: http://nerves-project.org/ Is based on Buildroot. If Erlang is the only thing you are putting on your ARM image, then this is a good option Yocto: http://www.yoctoproject.org/ https://github.com/joaohf/meta-erlang Yocto is arguably more full featured, but some assembly is required. See joahf's layer for adding Erlang to a build. It is fairly easy to modify his source to point to a newer release if you need it. I believe both projects have to patch the OTP source in order to build correctly. Hope that helps, Mike From jose.valim@REDACTED Sat Jul 19 18:11:13 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Sat, 19 Jul 2014 18:11:13 +0200 Subject: [erlang-bugs] Warning shows the wrong operator when useless operator is inside a useless contruction Message-ID: Given the following code: -module(foo). -compile(export_all). bar() -> [{foo, hello:world() == bar}], ok. When compiled, it reports: foo.erl:5: Warning: a term is constructed, but never used foo.erl:5: Warning: use of operator '=:=' has no effect The second warning is wrong. It must be refer to the operator '==' and not '=:='. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.abrahamsson@REDACTED Sun Jul 20 03:27:29 2014 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sun, 20 Jul 2014 03:27:29 +0200 Subject: [erlang-bugs] enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1 Message-ID: Hi, I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1 and my nif, and now enif_make_int64 creates -0 for INT64_MIN. % make test erl -s int64nif go -s erlang halt Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10] [kernel-poll:false] -0 When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808, I've attached the test programs, here are the important lines: go() -> io:format("~p~n", [int64_from_nif()]). The NIF C-code contains: static ERL_NIF_TERM int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) { return enif_make_int64(env, INT64_MIN); } System information: OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable) Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag. gcc: initially: gcc (Debian 4.8.1-10) 4.8.1 with this one, it prints -9223372036854775808 gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1 with this one, it prints -0 The only change I did was apt-get install gcc and then rebuilding Erlang. BRs Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: int64nif.tar.gz Type: application/x-gzip Size: 851 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Sun Jul 20 22:00:13 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 20 Jul 2014 22:00:13 +0200 Subject: [erlang-bugs] enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1 In-Reply-To: References: Message-ID: On Sun, Jul 20, 2014 at 3:27 AM, Tomas Abrahamsson wrote: > Hi, > > I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1 > and my nif, and now enif_make_int64 creates -0 for INT64_MIN. > > % make test > erl -s int64nif go -s erlang halt > Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10] > [kernel-poll:false] > > -0 > > When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808, > I've attached the test programs, here are the important lines: > > go() -> > io:format("~p~n", [int64_from_nif()]). > > The NIF C-code contains: > > static ERL_NIF_TERM > int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) > { > return enif_make_int64(env, INT64_MIN); > } > > System information: > > OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable) > Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag. > gcc: initially: gcc (Debian 4.8.1-10) 4.8.1 > with this one, it prints -9223372036854775808 > gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1 > with this one, it prints -0 > > The only change I did was apt-get install gcc and then rebuilding Erlang. I can confirm this on linux amd64. 17.1.2 gcc 4.8.2 -> -9223372036854775808 17.1.2 gcc 4.9.0 -> -0 17.1.2 gcc 4.9.1 -> -0 16B03-1 gcc 4.8.2 -> -9223372036854775808 16B03-1 gcc 4.9.0 -> 0 16B03-1 gcc 4.9.1 -> 0 I suppose you're not able to distill this to stand-alone C code, right? I don't think it will reveal anything, but it's an easy way to find bugs, so maybe you can try building with -fsanitize=undefined. If you want to do that, I'd suggest to apply the patch available at https://github.com/erlang/otp/pull/429 and run "configure --enable-sanitizers=undefined". From tomas.abrahamsson@REDACTED Sun Jul 20 23:56:59 2014 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Sun, 20 Jul 2014 23:56:59 +0200 Subject: [erlang-bugs] enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1 In-Reply-To: References: Message-ID: Hi, that sanitizer branch was most useful! I hope it will make it into erlang. This is a run of the previous code with the sanitizers merged into OTP-17.1.1: Erlang/OTP 17 [erts-6.1.2] [source-cc894a7] [smp:4:4] [async-threads:10] [kernel-poll:false] beam/utils.c:453:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself beam/big.c:1548:4: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself The relevant files do indeed look like they are negating INT64_MIN. (by the way, in utils.c, the erts_bld_sint64 takes else branch, as expected, but advances szp by 0.) Cramming in an (unsigned long long int) cast in there like the sanitizer error says, actually does make it print -9223372036854775808 in the erlang code, and no sanitizer error is printed anymore. utils.c 443 Eterm 444 erts_bld_sint64(Uint **hpp, Uint *szp, Sint64 si64) 445 { 446 Eterm res = THE_NON_VALUE; 447 if (IS_SSMALL(si64)) { 448 if (hpp) 449 res = make_small((Sint) si64); 450 } 451 else { 452 if (szp) 453 *szp += ERTS_SINT64_HEAP_SIZE(si64); 454 if (hpp) 455 res = erts_sint64_to_big(si64, hpp); 456 } 457 return res; 458 } big.h 101 #define ERTS_SINT64_HEAP_SIZE(X) \ 102 (IS_SSMALL((X)) \ 103 ? 0 \ 104 : ERTS_UINT64_BIG_HEAP_SIZE__((X) >= 0 ? (X) : -(X))) big.c 1540 Eterm erts_sint64_to_big(Sint64 x, Eterm **hpp) 1541 { 1542 Eterm *hp = *hpp; 1543 int neg; 1544 if (x >= 0) 1545 neg = 0; 1546 else { 1547 neg = 1; 1548 x = -x; 1549 } ... I tried changing big.h:104 into: : ERTS_UINT64_BIG_HEAP_SIZE__((X) >= 0 ? (X) : -((unsigned long long int)X))) and big.c:1548 into: x = -(unsigned long long int)x; This could be an interesting quick check property, to verify no undefined behaviours for various programs and values. BRs Tomas On Sun, Jul 20, 2014 at 10:00 PM, Tuncer Ayaz wrote: > On Sun, Jul 20, 2014 at 3:27 AM, Tomas Abrahamsson wrote: >> Hi, >> >> I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1 >> and my nif, and now enif_make_int64 creates -0 for INT64_MIN. >> >> % make test >> erl -s int64nif go -s erlang halt >> Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10] >> [kernel-poll:false] >> >> -0 >> >> When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808, >> I've attached the test programs, here are the important lines: >> >> go() -> >> io:format("~p~n", [int64_from_nif()]). >> >> The NIF C-code contains: >> >> static ERL_NIF_TERM >> int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) >> { >> return enif_make_int64(env, INT64_MIN); >> } >> >> System information: >> >> OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable) >> Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag. >> gcc: initially: gcc (Debian 4.8.1-10) 4.8.1 >> with this one, it prints -9223372036854775808 >> gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1 >> with this one, it prints -0 >> >> The only change I did was apt-get install gcc and then rebuilding Erlang. > > I can confirm this on linux amd64. > > 17.1.2 gcc 4.8.2 -> -9223372036854775808 > 17.1.2 gcc 4.9.0 -> -0 > 17.1.2 gcc 4.9.1 -> -0 > > 16B03-1 gcc 4.8.2 -> -9223372036854775808 > 16B03-1 gcc 4.9.0 -> 0 > 16B03-1 gcc 4.9.1 -> 0 > > > I suppose you're not able to distill this to stand-alone C code, right? > > I don't think it will reveal anything, but it's an easy way to find > bugs, so maybe you can try building with -fsanitize=undefined. If you > want to do that, I'd suggest to apply the patch available at > https://github.com/erlang/otp/pull/429 and run > "configure --enable-sanitizers=undefined". From tuncer.ayaz@REDACTED Mon Jul 21 00:34:25 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 21 Jul 2014 00:34:25 +0200 Subject: [erlang-bugs] enif_make_int64 => -0 for INT64_MIN with gcc 4.9.1 In-Reply-To: References: Message-ID: On Sun, Jul 20, 2014 at 11:56 PM, Tomas Abrahamsson wrote: > Hi, that sanitizer branch was most useful! I hope it will make it > into erlang. This is a run of the previous code with the sanitizers > merged into OTP-17.1.1: There are more sanitizers you can try out. Usan is comparatively low-impact, but the others cause considerable slowdowns, so don't be surprised about that. Asan and Tsan are not cheap, but easier to use than Valgrind. Also, you can try the same sanitizers with clang, but the names might differ. > Erlang/OTP 17 [erts-6.1.2] [source-cc894a7] [smp:4:4] > [async-threads:10] [kernel-poll:false] > > beam/utils.c:453:14: runtime error: negation of -9223372036854775808 > cannot be represented in type 'long long int'; cast to an unsigned > type to negate this value to itself > > beam/big.c:1548:4: runtime error: negation of -9223372036854775808 > cannot be represented in type 'long long int'; cast to an unsigned > type to negate this value to itself I just tried and found beam/big.c:1548:4, too. > The relevant files do indeed look like they are negating INT64_MIN. > (by the way, in utils.c, the erts_bld_sint64 takes else branch, > as expected, but advances szp by 0.) > > Cramming in an (unsigned long long int) cast in there > like the sanitizer error says, actually does make it > print -9223372036854775808 in the erlang code, > and no sanitizer error is printed anymore. > > utils.c > 443 Eterm > 444 erts_bld_sint64(Uint **hpp, Uint *szp, Sint64 si64) > 445 { > 446 Eterm res = THE_NON_VALUE; > 447 if (IS_SSMALL(si64)) { > 448 if (hpp) > 449 res = make_small((Sint) si64); > 450 } > 451 else { > 452 if (szp) > 453 *szp += ERTS_SINT64_HEAP_SIZE(si64); > 454 if (hpp) > 455 res = erts_sint64_to_big(si64, hpp); > 456 } > 457 return res; > 458 } > > big.h > 101 #define ERTS_SINT64_HEAP_SIZE(X) \ > 102 (IS_SSMALL((X)) \ > 103 ? 0 \ > 104 : ERTS_UINT64_BIG_HEAP_SIZE__((X) >= 0 ? (X) : -(X))) > > big.c > 1540 Eterm erts_sint64_to_big(Sint64 x, Eterm **hpp) > 1541 { > 1542 Eterm *hp = *hpp; > 1543 int neg; > 1544 if (x >= 0) > 1545 neg = 0; > 1546 else { > 1547 neg = 1; > 1548 x = -x; > 1549 } > ... > > I tried changing big.h:104 into: > : ERTS_UINT64_BIG_HEAP_SIZE__((X) >= 0 ? (X) : -((unsigned > long long int)X))) > and big.c:1548 into: > x = -(unsigned long long int)x; > > This could be an interesting quick check property, to verify no > undefined behaviours for various programs and values. > > BRs > Tomas > > On Sun, Jul 20, 2014 at 10:00 PM, Tuncer Ayaz wrote: > > On Sun, Jul 20, 2014 at 3:27 AM, Tomas Abrahamsson wrote: > > > Hi, > > > > > > I upgraded gcc from version 4.8.1 to 4.9.1, recompiled Erlang/OTP-17.1.1 > > > and my nif, and now enif_make_int64 creates -0 for INT64_MIN. > > > > > > % make test > > > erl -s int64nif go -s erlang halt > > > Erlang/OTP 17 [erts-6.1.1] [source] [smp:4:4] [async-threads:10] > > > [kernel-poll:false] > > > > > > -0 > > > > > > When Erlang was compiled with gcc-4.8.1, it printed -9223372036854775808, > > > I've attached the test programs, here are the important lines: > > > > > > go() -> > > > io:format("~p~n", [int64_from_nif()]). > > > > > > The NIF C-code contains: > > > > > > static ERL_NIF_TERM > > > int64_from_nif(ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) > > > { > > > return enif_make_int64(env, INT64_MIN); > > > } > > > > > > System information: > > > > > > OS: linux, 32-bit core i5, 3.14-1-686-pae (debian unstable) > > > Erlang/OTP: built from scratch (both times) from the OTP-17.1.1 git tag. > > > gcc: initially: gcc (Debian 4.8.1-10) 4.8.1 > > > with this one, it prints -9223372036854775808 > > > gcc: after upgrade: gcc (Debian 4.9.1-1) 4.9.1 > > > with this one, it prints -0 > > > > > > The only change I did was apt-get install gcc and then > > > rebuilding Erlang. > > > > I can confirm this on linux amd64. > > > > 17.1.2 gcc 4.8.2 -> -9223372036854775808 > > 17.1.2 gcc 4.9.0 -> -0 > > 17.1.2 gcc 4.9.1 -> -0 > > > > 16B03-1 gcc 4.8.2 -> -9223372036854775808 > > 16B03-1 gcc 4.9.0 -> 0 > > 16B03-1 gcc 4.9.1 -> 0 > > > > > > I suppose you're not able to distill this to stand-alone C code, right? > > > > I don't think it will reveal anything, but it's an easy way to > > find bugs, so maybe you can try building with > > -fsanitize=undefined. If you want to do that, I'd suggest to apply > > the patch available at https://github.com/erlang/otp/pull/429 and > > run "configure --enable-sanitizers=undefined". From mjtruog@REDACTED Tue Jul 22 00:55:22 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 21 Jul 2014 15:55:22 -0700 Subject: [erlang-bugs] Dialyzer Bugs Message-ID: <53CD9A5A.7000306@gmail.com> There are two dialyzer bugs that I ran into recently: 1) In 17.1 passing a symbolic link to the --plt option doesn't work as it once did (it is still ok to have ~/.dialyzer_plt as a symbolic link) 2) -Wrace_conditions causes the dialyzer execution time to vary with the possibility that dialyzer execution will not finish. The memory of dialyzer can also grow to much larger sizes >1GB while this occurs. I had this occur awhile ago with R16B03-1 while leaving dialyzer to run and it refused to finish after roughly 40 minutes when a normal run takes 1 minute (roughly). I recently talked to a person on IRC (freenode in the #erlang room) which had the same problem where the person's dev machine was affected but the CI server never had any problem completing the dialyzer runs. It seems like this appears only when a sufficiently large amount of Erlang source code is used for the dialyzer run. The person suspected that a corrupt file might have caused the problem to appear, but I doubted that -Wrace_conditions would be modifying any state on disk (it wouldn't be changing a PLT file, right?). Thanks, Michael From kostis@REDACTED Tue Jul 22 07:24:49 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 22 Jul 2014 08:24:49 +0300 Subject: [erlang-bugs] Dialyzer Bugs In-Reply-To: <53CD9A5A.7000306@gmail.com> References: <53CD9A5A.7000306@gmail.com> Message-ID: <53CDF5A1.7090500@cs.ntua.gr> On 07/22/2014 01:55 AM, Michael Truog wrote: > There are two dialyzer bugs that I ran into recently: > 1) In 17.1 passing a symbolic link to the --plt option doesn't work as > it once did (it is still ok to have ~/.dialyzer_plt as a symbolic link) An example, or even better a git bisect, that shows the regression compared to some previous version would help here. > 2) -Wrace_conditions causes the dialyzer execution time to vary with the > possibility that dialyzer execution will not finish. The memory of > dialyzer can also grow to much larger sizes >1GB while this occurs. I > had this occur awhile ago with R16B03-1 while leaving dialyzer to run > and it refused to finish after roughly 40 minutes when a normal run > takes 1 minute (roughly). I recently talked to a person on IRC > (freenode in the #erlang room) which had the same problem where the > person's dev machine was affected but the CI server never had any > problem completing the dialyzer runs. It seems like this appears only > when a sufficiently large amount of Erlang source code is used for the > dialyzer run. The person suspected that a corrupt file might have > caused the problem to appear, but I doubted that -Wrace_conditions would > be modifying any state on disk (it wouldn't be changing a PLT file, > right?). This is a known issue. The analysis that finds data races performs intra-procedural data flow analysis and can sometimes explode in time. Hence it is not enabled by default. Enable it at your own risk. Kostis From essen@REDACTED Tue Jul 22 08:58:59 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 22 Jul 2014 08:58:59 +0200 Subject: [erlang-bugs] Dialyzer Bugs In-Reply-To: <53CD9A5A.7000306@gmail.com> References: <53CD9A5A.7000306@gmail.com> Message-ID: <53CE0BB3.7020000@ninenines.eu> On 07/22/2014 12:55 AM, Michael Truog wrote: > There are two dialyzer bugs that I ran into recently: > 1) In 17.1 passing a symbolic link to the --plt option doesn't work as > it once did (it is still ok to have ~/.dialyzer_plt as a symbolic link) Have you tried this one with 17.1.2? 17.1 had symlinks handling in the file module broken and that got fixed in .2. -- Lo?c Hoguin http://ninenines.eu From henrik@REDACTED Tue Jul 22 10:03:51 2014 From: henrik@REDACTED (Henrik Nord) Date: Tue, 22 Jul 2014 10:03:51 +0200 Subject: [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when cross compiling In-Reply-To: References: Message-ID: <53CE1AE7.50005@erlang.org> Hi! Have you tried to cross compile without HiPE? There might be some issues trying to cross compile HiPE. Se this thread for hints: http://erlang.org/pipermail/erlang-questions/2012-March/064838.html you should be able to cross compile to arm without HiPE ./configure --disable-hipe --host=arm-linux-gnueabif On 2014-07-18 07:57, Du Felix wrote: > Hi everyone. > I did a cross compiling with the command: > ./configure --host=arm-linux-gnueabif > Duiring compilation, I got such error: > > === Entering application hipe > make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > ERLC ../ebin/hipe_consttab.beam > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1: > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word > unexpected (expecting ")") > make[3]: *** [../ebin/hipe_consttab.beam] Error 2 > make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > make[2]: *** [opt] Error 2 > make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe' > make[1]: *** [opt] Error 2 > make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib' > make: *** [secondary_bootstrap_build] Error 2 > > When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't > find hipe_consttab.beam. > > I could successfully compiled a x86 erlang on my linux mint, but > got that error while cross compling. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP From dmkolesnikov@REDACTED Tue Jul 22 10:30:13 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 22 Jul 2014 11:30:13 +0300 Subject: [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when cross compiling In-Reply-To: <53CE1AE7.50005@erlang.org> References: <53CE1AE7.50005@erlang.org> Message-ID: <5F3B908F-0624-40AB-8773-98BE527ECD44@gmail.com> Hello, I also had an issue to compile HiPE on ARM. - Dmitry On 22 Jul 2014, at 11:03, Henrik Nord wrote: > Hi! > > Have you tried to cross compile without HiPE? > > There might be some issues trying to cross compile HiPE. > Se this thread for hints: > http://erlang.org/pipermail/erlang-questions/2012-March/064838.html > > you should be able to cross compile to arm without HiPE > > ./configure --disable-hipe --host=arm-linux-gnueabif > > > > On 2014-07-18 07:57, Du Felix wrote: >> Hi everyone. >> I did a cross compiling with the command: >> ./configure --host=arm-linux-gnueabif >> Duiring compilation, I got such error: >> >> === Entering application hipe >> make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' >> ERLC ../ebin/hipe_consttab.beam >> /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1: >> /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word >> unexpected (expecting ")") >> make[3]: *** [../ebin/hipe_consttab.beam] Error 2 >> make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' >> make[2]: *** [opt] Error 2 >> make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe' >> make[1]: *** [opt] Error 2 >> make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib' >> make: *** [secondary_bootstrap_build] Error 2 >> >> When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't >> find hipe_consttab.beam. >> >> I could successfully compiled a x86 erlang on my linux mint, but >> got that error while cross compling. >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > -- > /Henrik Nord Erlang/OTP > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From mikpelinux@REDACTED Tue Jul 22 14:37:03 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Tue, 22 Jul 2014 14:37:03 +0200 Subject: [erlang-bugs] Syntax error: word unexpected (expecting ")" ) when cross compiling In-Reply-To: References: Message-ID: <21454.23279.864517.2992@gargle.gargle.HOWL> Du Felix writes: > Hi everyone. > I did a cross compiling with the command: > ./configure --host=arm-linux-gnueabif > Duiring compilation, I got such error: > > === Entering application hipe > make[3]: Entering directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > ERLC ../ebin/hipe_consttab.beam > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: 1: > /home/dmy/App/otp_src_17.0/bootstrap/bin/erlc: Syntax error: word > unexpected (expecting ")") > make[3]: *** [../ebin/hipe_consttab.beam] Error 2 > make[3]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe/misc' > make[2]: *** [opt] Error 2 > make[2]: Leaving directory `/home/dmy/App/otp_src_17.0/lib/hipe' > make[1]: *** [opt] Error 2 > make[1]: Leaving directory `/home/dmy/App/otp_src_17.0/lib' > make: *** [secondary_bootstrap_build] Error 2 > > When I went to /home/dmy/App/otp_src_17.0/lib/hipe/ebin, I didn't > find hipe_consttab.beam. > > I could successfully compiled a x86 erlang on my linux mint, but > got that error while cross compling. I cannot reproduce this error. To cross-compile for ARM, I simply did: 0. Made sure a native otp-17.1 and a GNU cross toolchain to armv5tel-unknown-linux-gnueabi are in my PATH. The native otp-17.1 is just to eliminate the bootstrap step one otherwise has to do (as per HOWTO/INSTALL-CROSS.md). 1. tar zxf otp_src_17.1.tar.gz 2. cd otp_src_17.1 3. ./configure --host=armv5tel-unknown-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/tmp/otp-17 --without-termcap 4. make 5. make install hipe_consttab is pure Erlang code and does get built even when HiPE is disabled. Compiling it to BEAM should not fail. Did you perhaps start with a source tree where a previous native build had been done? I'd suggest trying again with a pristine source tree. From mjtruog@REDACTED Wed Jul 23 04:46:47 2014 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 22 Jul 2014 19:46:47 -0700 Subject: [erlang-bugs] Dialyzer Bugs In-Reply-To: <53CDF5A1.7090500@cs.ntua.gr> References: <53CD9A5A.7000306@gmail.com> <53CDF5A1.7090500@cs.ntua.gr> Message-ID: <53CF2217.2090900@gmail.com> On 07/21/2014 10:24 PM, Kostis Sagonas wrote: > On 07/22/2014 01:55 AM, Michael Truog wrote: >> There are two dialyzer bugs that I ran into recently: >> 1) In 17.1 passing a symbolic link to the --plt option doesn't work as >> it once did (it is still ok to have ~/.dialyzer_plt as a symbolic link) > > An example, or even better a git bisect, that shows the regression compared to some previous version would help here. I checked the source tree at 17.1.2 as Lo?c suggested and there is no longer a problem. > >> 2) -Wrace_conditions causes the dialyzer execution time to vary with the >> possibility that dialyzer execution will not finish. The memory of >> dialyzer can also grow to much larger sizes >1GB while this occurs. I >> had this occur awhile ago with R16B03-1 while leaving dialyzer to run >> and it refused to finish after roughly 40 minutes when a normal run >> takes 1 minute (roughly). I recently talked to a person on IRC >> (freenode in the #erlang room) which had the same problem where the >> person's dev machine was affected but the CI server never had any >> problem completing the dialyzer runs. It seems like this appears only >> when a sufficiently large amount of Erlang source code is used for the >> dialyzer run. The person suspected that a corrupt file might have >> caused the problem to appear, but I doubted that -Wrace_conditions would >> be modifying any state on disk (it wouldn't be changing a PLT file, >> right?). > > This is a known issue. The analysis that finds data races performs intra-procedural data flow analysis and can sometimes explode in time. Hence it is not enabled by default. Enable it at your own risk. It makes sense that this is a known issue, but it would be nice if the dialyzer HTML documentation warned about it. Thanks, Michael From magnus@REDACTED Wed Jul 23 11:56:55 2014 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 23 Jul 2014 10:56:55 +0100 Subject: [erlang-bugs] Dialyzer Bugs In-Reply-To: <53CF2217.2090900@gmail.com> (Michael Truog's message of "Tue, 22 Jul 2014 19:46:47 -0700") References: <53CD9A5A.7000306@gmail.com> <53CDF5A1.7090500@cs.ntua.gr> <53CF2217.2090900@gmail.com> Message-ID: Michael Truog writes: >>> 2) -Wrace_conditions causes the dialyzer execution time to vary with the >>> possibility that dialyzer execution will not finish. The memory of >>> dialyzer can also grow to much larger sizes >1GB while this occurs. I >>> had this occur awhile ago with R16B03-1 while leaving dialyzer to run >>> and it refused to finish after roughly 40 minutes when a normal run >>> takes 1 minute (roughly). I recently talked to a person on IRC >>> (freenode in the #erlang room) which had the same problem where the >>> person's dev machine was affected but the CI server never had any >>> problem completing the dialyzer runs. It seems like this appears only >>> when a sufficiently large amount of Erlang source code is used for the >>> dialyzer run. The person suspected that a corrupt file might have >>> caused the problem to appear, but I doubted that -Wrace_conditions would >>> be modifying any state on disk (it wouldn't be changing a PLT file, >>> right?). >> >> This is a known issue. The analysis that finds data races performs >> intra-procedural data flow analysis and can sometimes explode in >> time. Hence it is not enabled by default. Enable it at your own risk. > It makes sense that this is a known issue, but it would be nice if the > dialyzer HTML documentation warned about it. Like this? https://github.com/erlang/otp/pull/437/files Regards, Magnus From mjtruog@REDACTED Wed Jul 23 18:18:04 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 23 Jul 2014 09:18:04 -0700 Subject: [erlang-bugs] Dialyzer Bugs In-Reply-To: References: <53CD9A5A.7000306@gmail.com> <53CDF5A1.7090500@cs.ntua.gr> <53CF2217.2090900@gmail.com> Message-ID: <53CFE03C.704@gmail.com> On 07/23/2014 02:56 AM, Magnus Henoch wrote: > Michael Truog writes: > >>>> 2) -Wrace_conditions causes the dialyzer execution time to vary with the >>>> possibility that dialyzer execution will not finish. The memory of >>>> dialyzer can also grow to much larger sizes >1GB while this occurs. I >>>> had this occur awhile ago with R16B03-1 while leaving dialyzer to run >>>> and it refused to finish after roughly 40 minutes when a normal run >>>> takes 1 minute (roughly). I recently talked to a person on IRC >>>> (freenode in the #erlang room) which had the same problem where the >>>> person's dev machine was affected but the CI server never had any >>>> problem completing the dialyzer runs. It seems like this appears only >>>> when a sufficiently large amount of Erlang source code is used for the >>>> dialyzer run. The person suspected that a corrupt file might have >>>> caused the problem to appear, but I doubted that -Wrace_conditions would >>>> be modifying any state on disk (it wouldn't be changing a PLT file, >>>> right?). >>> This is a known issue. The analysis that finds data races performs >>> intra-procedural data flow analysis and can sometimes explode in >>> time. Hence it is not enabled by default. Enable it at your own risk. >> It makes sense that this is a known issue, but it would be nice if the >> dialyzer HTML documentation warned about it. > Like this? https://github.com/erlang/otp/pull/437/files Thanks, that should help make it clearer. From 53817681@REDACTED Thu Jul 24 05:03:06 2014 From: 53817681@REDACTED (=?utf-8?B?b+m4oeibi+m7hG8=?=) Date: Thu, 24 Jul 2014 11:03:06 +0800 Subject: [erlang-bugs] erlang vm crash/coredump Message-ID: Jul 23 19:11:31 imtestserver kernel: [27024.541714] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies. Check SNMP counters. Jul 23 19:12:14 imtestserver kernel: [27067.574868] beam.smp[7347]: segfault at 20 ip 00000000005342d4 sp 00007f343baf5d00 error 4 in beam.smp[400000+267000] Jul 23 19:14:22 imtestserver kernel: [27196.203390] TCP: TCP: Possible SYN flooding on port 5222. Sending cookies. Check SNMP counters. Jul 23 19:15:01 imtestserver CRON[7894]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jul 23 19:19:32 imtestserver kernel: [27505.432769] beam.smp[7643]: segfault at 20 ip 00000000005342d4 sp 00007f2d98f76d00 error 4 in beam.smp[400000+267000] ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From louis-philippe.gauthier@REDACTED Fri Jul 25 17:49:51 2014 From: louis-philippe.gauthier@REDACTED (Louis-Philippe Gauthier) Date: Fri, 25 Jul 2014 11:49:51 -0400 Subject: [erlang-bugs] erl_lock_count segfault Message-ID: Hi, Looks like in some certain conditions I get a segfault when starting the VM when compiled with lock counter. https://gist.github.com/lpgauth/27e66f7a2104d8b5af74 LP -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Sun Jul 27 22:56:04 2014 From: shayan@REDACTED (Shayan Pooya) Date: Sun, 27 Jul 2014 16:56:04 -0400 Subject: [erlang-bugs] Warning shows the wrong operator when useless operator is inside a useless contruction In-Reply-To: References: Message-ID: I created this PR for this issue: https://github.com/erlang/otp/pull/439 On Sat, Jul 19, 2014 at 12:11 PM, Jos? Valim < jose.valim@REDACTED> wrote: > Given the following code: > > -module(foo). > -compile(export_all). > > bar() -> > [{foo, hello:world() == bar}], > ok. > > > When compiled, it reports: > > foo.erl:5: Warning: a term is constructed, but never used > foo.erl:5: Warning: use of operator '=:=' has no effect > > > The second warning is wrong. It must be refer to the operator '==' and not > '=:='. > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From define.null@REDACTED Mon Jul 28 11:16:56 2014 From: define.null@REDACTED (Vasily Demidenok) Date: Mon, 28 Jul 2014 13:16:56 +0400 Subject: [erlang-bugs] Weird behaviour of gen_tcp:send/2 and erlang:port_command/3 with nosuspend to the same port on R16B03 In-Reply-To: References: <53A9B544.1080508@erlang.org> Message-ID: Hello again The friend of mine faced with the same problem. He assumes it's not tcp driver related problem, but port internals changes made in R16 release. Downgrading to R15B03 fixed their problem. +n options with d/s/a params also did not help. The app to reproduce bug: https://github.com/kudryashov-sv/ErlangCPort.git 2014-07-05 0:47 GMT+04:00 Vasily Demidenok : > The problem remains even if only erlang:port_command/3 with nosuspend > option is used. (no calls for gen_tcp:send and many processes write to the > same socket) > > > 2014-06-24 21:28 GMT+04:00 Lukas Larsson : > > Hello, >> >> I was able to reproduce your testcase after removing all the "msg" >> printouts and starting a couple of clients at the same time. It seems that >> the sockets are hitting the high_msgq_watermark limit and then as data gets >> flushes they are not set to run again. I'll see if I can dig out what it is >> that is causing this behavior. >> >> Lukas >> >> On 24/06/14 16:56, Vasily Demidenok wrote: >> >> Hello list, we faced with some gen_tcp related problems after switch >> from erlang R15B03 to R16B03-01 >> >> The problem is as following: When server produce data faster then >> consumer can handle, after >> the out server's buffers are full and incoming client's buffers are full >> gen_tcp:send/2 call on server side blocks forever in >> erts_internal:port_command/3. After this, even when client consumes all >> the data and the buffers are empty server process remains to be >> suspended in that call >> >> This problem does not occur always, but quite often. >> >> Some details on implementation are below, I also shrink the example to >> this small app so you can check the code: >> https://github.com/define-null/tcp_failing_ex >> >> Server is implemented in such a way, that it listen on 8899 port, then >> when client connect to it spawn main srv process and plenty of workers, >> which start to write to this port after client send some special msg. The >> main process is responsible for commands from the client and send responses >> via gen_tcp:send/2, while workers try to write some stream data to the >> client and use erang:port_command with no-suspend. So workers send only >> up-to-date data, dropping any in case client is slow. >> >> The behaviour which we see is as following: >> At first phase producer fills OS and erlang driver's buffers. Consumer >> read data as it arrives and server drop data which it cannot send. So we >> see buffer size growing on both side out queue of the server and in queue >> of the client respectively >> >> After some moment in time, i guess when the buffers are completely >> filled, server try respond to >> ping message of the client, using gen_tcp:send/2 call. After that, it >> blocks there forever, even after client consumes all the messages. The >> situation does not change and the srv process remains in the suspended >> state, while it's incoming buffer begins to grow when client send more ping >> messages. >> >> Below is the output on the system with two slow clients, where for the >> first client server's process is already blocked in gen_tcp:send/2 call, >> while the second is served well. >> >> Every 2.0s: netstat -al | grep 8899 >> >> Tue Jun 24 16:34:51 2014 >> >> tcp4 36 0 localhost.8899 localhost.63263 >> ESTABLISHED >> tcp4 0 0 localhost.63263 localhost.8899 >> ESTABLISHED >> tcp4 0 130990 localhost.8899 localhost.63257 >> ESTABLISHED >> tcp4 619190 0 localhost.63257 localhost.8899 >> ESTABLISHED >> tcp4 0 0 *.8899 *.* LISTEN >> >> This is the output for the client process from github example, where we >> see that >> after send operation (ping msg) no incoming msg come any more. >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,28}}: msg >> {{2014,6,24},{16,33,48}} before send >> {{2014,6,24},{16,33,48}} after send ok >> {{2014,6,24},{16,34,9}} before send >> {{2014,6,24},{16,34,9}} after send ok >> {{2014,6,24},{16,34,30}} before send >> {{2014,6,24},{16,34,30}} after send ok >> {{2014,6,24},{16,34,51}} before send >> {{2014,6,24},{16,34,51}} after send ok >> {{2014,6,24},{16,35,12}} before send >> .... >> >> Server blocked process output: >> >> {{2014,6,24},{16,33,21}}: <0.95.0> ping >> {{2014,6,24},{16,33,21}} bsend: <0.95.0> >> {{2014,6,24},{16,33,21}} asend: <0.95.0> ok >> {{2014,6,24},{16,33,48}}: <0.95.0> ping >> {{2014,6,24},{16,33,48}} bsend: <0.95.0> >> %% (no asend message after it) >> >> (tcp_failing_node@REDACTED)1> erlang:process_info(pid(0,95,0)). >> [{current_function,{erts_internal,port_command,3}}, >> {initial_call,{proc_lib,init_p,5}}, >> >> Bug is not always reproducible, but occurs quite often. The problem is >> that even >> after server's out buffers are empty data does not arrive to the client, >> and incoming buffer grow >> as client send ping messages to the server. (So erlang:port_command/3 >> with no-suspend always return false >> when another main server process for this connection is suspended in >> gen_tcp:send/2) >> >> And then it's getting only worse as already mentioned >> >> Every 2.0s: netstat -al | grep 8899 >> >> Tue Jun 24 16:56:59 2014 >> >> tcp4 804 0 localhost.8899 localhost.63263 >> ESTABLISHED >> tcp4 0 0 localhost.63263 localhost.8899 >> ESTABLISHED >> tcp4 0 0 localhost.8899 localhost.63257 >> ESTABLISHED >> tcp4 0 0 localhost.63257 localhost.8899 >> ESTABLISHED >> tcp4 0 0 *.8899 *.* LISTEN >> >> We faced with this after switching to R16B03 from R15B03, I know there >> were some changes in port_command handling, i guess why we got such >> behaviour? >> >> >> _______________________________________________ >> erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 53817681@REDACTED Mon Jul 28 11:41:54 2014 From: 53817681@REDACTED (=?utf-8?B?b+m4oeibi+m7hG8=?=) Date: Mon, 28 Jul 2014 17:41:54 +0800 Subject: [erlang-bugs] =?utf-8?b?5Zue5aSN77yaICBXZWlyZCBiZWhhdmlvdXIgb2Yg?= =?utf-8?q?gen=5Ftcp=3Asend/2_anderlang=3Aport=5Fcommand/3_with_nosuspend_?= =?utf-8?q?to_the_same_port_on_R16B03?= In-Reply-To: References: <53A9B544.1080508@erlang.org> Message-ID: Dear, a bug? in erlang vm sourcecode , port_get_data_1 process arg is NULL , I had fixed it,thanks. ------------------ ???? ------------------ ???: "Vasily Demidenok";; ????: 2014?7?28?(???) ??5:16 ???: "Lukas Larsson"; ??: "erlang-bugs"; ??: Re: [erlang-bugs] Weird behaviour of gen_tcp:send/2 anderlang:port_command/3 with nosuspend to the same port on R16B03 Hello again The friend of mine faced with the same problem. He assumes it's not tcp driver related problem, but port internals changes made in R16 release.Downgrading to R15B03 fixed their problem. +n options with d/s/a params also did not help. The app to reproduce bug: https://github.com/kudryashov-sv/ErlangCPort.git 2014-07-05 0:47 GMT+04:00 Vasily Demidenok : The problem remains even if only erlang:port_command/3 with nosuspend option is used. (no calls for gen_tcp:send and many processes write to the same socket) 2014-06-24 21:28 GMT+04:00 Lukas Larsson : Hello, I was able to reproduce your testcase after removing all the "msg" printouts and starting a couple of clients at the same time. It seems that the sockets are hitting the high_msgq_watermark limit and then as data gets flushes they are not set to run again. I'll see if I can dig out what it is that is causing this behavior. Lukas On 24/06/14 16:56, Vasily Demidenok wrote: Hello list, we faced with some gen_tcp related problems after switch from erlang R15B03 to R16B03-01 The problem is as following: When server produce data faster then consumer can handle, after the out server's buffers are full and incoming client's buffers are full gen_tcp:send/2 call on server side blocks forever in erts_internal:port_command/3. After this, even when client consumes all the data and the buffers are empty server process remains to be suspended in that call This problem does not occur always, but quite often. Some details on implementation are below, I also shrink the example to this small app so you can check the code: https://github.com/define-null/tcp_failing_ex Server is implemented in such a way, that it listen on 8899 port, then when client connect to it spawn main srv process and plenty of workers, which start to write to this port after client send some special msg. The main process is responsible for commands from the client and send responses via gen_tcp:send/2, while workers try to write some stream data to the client and use erang:port_command with no-suspend. So workers send only up-to-date data, dropping any in case client is slow. The behaviour which we see is as following: At first phase producer fills OS and erlang driver's buffers. Consumer read data as it arrives and server drop data which it cannot send. So we see buffer size growing on both side out queue of the server and in queue of the client respectively After some moment in time, i guess when the buffers are completely filled, server try respond to ping message of the client, using gen_tcp:send/2 call. After that, it blocks there forever, even after client consumes all the messages. The situation does not change and the srv process remains in the suspended state, while it's incoming buffer begins to grow when client send more ping messages. Below is the output on the system with two slow clients, where for the first client server's process is already blocked in gen_tcp:send/2 call, while the second is served well. Every 2.0s: netstat -al | grep 8899 Tue Jun 24 16:34:51 2014 tcp4 36 0 localhost.8899 localhost.63263 ESTABLISHED tcp4 0 0 localhost.63263 localhost.8899 ESTABLISHED tcp4 0 130990 localhost.8899 localhost.63257 ESTABLISHED tcp4 619190 0 localhost.63257 localhost.8899 ESTABLISHED tcp4 0 0 *.8899 *.* LISTEN This is the output for the client process from github example, where we see that after send operation (ping msg) no incoming msg come any more. {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,28}}: msg {{2014,6,24},{16,33,48}} before send {{2014,6,24},{16,33,48}} after send ok {{2014,6,24},{16,34,9}} before send {{2014,6,24},{16,34,9}} after send ok {{2014,6,24},{16,34,30}} before send {{2014,6,24},{16,34,30}} after send ok {{2014,6,24},{16,34,51}} before send {{2014,6,24},{16,34,51}} after send ok {{2014,6,24},{16,35,12}} before send .... Server blocked process output: {{2014,6,24},{16,33,21}}: <0.95.0> ping {{2014,6,24},{16,33,21}} bsend: <0.95.0> {{2014,6,24},{16,33,21}} asend: <0.95.0> ok {{2014,6,24},{16,33,48}}: <0.95.0> ping {{2014,6,24},{16,33,48}} bsend: <0.95.0> %% (no asend message after it) (tcp_failing_node@REDACTED)1> erlang:process_info(pid(0,95,0)). [{current_function,{erts_internal,port_command,3}}, {initial_call,{proc_lib,init_p,5}}, Bug is not always reproducible, but occurs quite often. The problem is that even after server's out buffers are empty data does not arrive to the client, and incoming buffer grow as client send ping messages to the server. (So erlang:port_command/3 with no-suspend always return false when another main server process for this connection is suspended in gen_tcp:send/2) And then it's getting only worse as already mentioned Every 2.0s: netstat -al | grep 8899 Tue Jun 24 16:56:59 2014 tcp4 804 0 localhost.8899 localhost.63263 ESTABLISHED tcp4 0 0 localhost.63263 localhost.8899 ESTABLISHED tcp4 0 0 localhost.8899 localhost.63257 ESTABLISHED tcp4 0 0 localhost.63257 localhost.8899 ESTABLISHED tcp4 0 0 *.8899 *.* LISTEN We faced with this after switching to R16B03 from R15B03, I know there were some changes in port_command handling, i guess why we got such behaviour? _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From define.null@REDACTED Mon Jul 28 12:19:58 2014 From: define.null@REDACTED (Vasily Demidenok) Date: Mon, 28 Jul 2014 14:19:58 +0400 Subject: [erlang-bugs] =?utf-8?b?5Zue5aSN77yaICBXZWlyZCBiZWhhdmlvdXIgb2Yg?= =?utf-8?q?gen=5Ftcp=3Asend/2_anderlang=3Aport=5Fcommand/3_with_nos?= =?utf-8?q?uspend_to_the_same_port_on_R16B03?= In-Reply-To: References: <53A9B544.1080508@erlang.org> Message-ID: Great to hear, that you have already fixed that bug. Can you kindly point me to the patch, or to the branch with that fix? We would like to merge and do not wait for it to appear in new R17 release if it's production ready. 2014-07-28 13:41 GMT+04:00 o???o <53817681@REDACTED>: > Dear, > > a bug? in erlang vm sourcecode , port_get_data_1 process arg is > NULL , I had fixed it,thanks. > > > ------------------ ???? ------------------ > *???:* "Vasily Demidenok";; > *????:* 2014?7?28?(???) ??5:16 > *???:* "Lukas Larsson"; > *??:* "erlang-bugs"; > *??:* Re: [erlang-bugs] Weird behaviour of gen_tcp:send/2 > anderlang:port_command/3 with nosuspend to the same port on R16B03 > > Hello again > The friend of mine faced with the same problem. He assumes it's not tcp > driver related problem, but port internals changes made in R16 release. > Downgrading to R15B03 fixed their problem. +n options with d/s/a params > also did not help. > > The app to reproduce bug: > https://github.com/kudryashov-sv/ErlangCPort.git > > > 2014-07-05 0:47 GMT+04:00 Vasily Demidenok : > >> The problem remains even if only erlang:port_command/3 with nosuspend >> option is used. (no calls for gen_tcp:send and many processes write to the >> same socket) >> >> >> 2014-06-24 21:28 GMT+04:00 Lukas Larsson : >> >> Hello, >>> >>> I was able to reproduce your testcase after removing all the "msg" >>> printouts and starting a couple of clients at the same time. It seems that >>> the sockets are hitting the high_msgq_watermark limit and then as data gets >>> flushes they are not set to run again. I'll see if I can dig out what it is >>> that is causing this behavior. >>> >>> Lukas >>> >>> On 24/06/14 16:56, Vasily Demidenok wrote: >>> >>> Hello list, we faced with some gen_tcp related problems after switch >>> from erlang R15B03 to R16B03-01 >>> >>> The problem is as following: When server produce data faster then >>> consumer can handle, after >>> the out server's buffers are full and incoming client's buffers are full >>> gen_tcp:send/2 call on server side blocks forever in >>> erts_internal:port_command/3. After this, even when client consumes all >>> the data and the buffers are empty server process remains to be >>> suspended in that call >>> >>> This problem does not occur always, but quite often. >>> >>> Some details on implementation are below, I also shrink the example to >>> this small app so you can check the code: >>> https://github.com/define-null/tcp_failing_ex >>> >>> Server is implemented in such a way, that it listen on 8899 port, then >>> when client connect to it spawn main srv process and plenty of workers, >>> which start to write to this port after client send some special msg. The >>> main process is responsible for commands from the client and send responses >>> via gen_tcp:send/2, while workers try to write some stream data to the >>> client and use erang:port_command with no-suspend. So workers send only >>> up-to-date data, dropping any in case client is slow. >>> >>> The behaviour which we see is as following: >>> At first phase producer fills OS and erlang driver's buffers. Consumer >>> read data as it arrives and server drop data which it cannot send. So we >>> see buffer size growing on both side out queue of the server and in queue >>> of the client respectively >>> >>> After some moment in time, i guess when the buffers are completely >>> filled, server try respond to >>> ping message of the client, using gen_tcp:send/2 call. After that, it >>> blocks there forever, even after client consumes all the messages. The >>> situation does not change and the srv process remains in the suspended >>> state, while it's incoming buffer begins to grow when client send more ping >>> messages. >>> >>> Below is the output on the system with two slow clients, where for the >>> first client server's process is already blocked in gen_tcp:send/2 call, >>> while the second is served well. >>> >>> Every 2.0s: netstat -al | grep 8899 >>> >>> Tue Jun 24 16:34:51 2014 >>> >>> tcp4 36 0 localhost.8899 localhost.63263 >>> ESTABLISHED >>> tcp4 0 0 localhost.63263 localhost.8899 >>> ESTABLISHED >>> tcp4 0 130990 localhost.8899 localhost.63257 >>> ESTABLISHED >>> tcp4 619190 0 localhost.63257 localhost.8899 >>> ESTABLISHED >>> tcp4 0 0 *.8899 *.* >>> LISTEN >>> >>> This is the output for the client process from github example, where >>> we see that >>> after send operation (ping msg) no incoming msg come any more. >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,28}}: msg >>> {{2014,6,24},{16,33,48}} before send >>> {{2014,6,24},{16,33,48}} after send ok >>> {{2014,6,24},{16,34,9}} before send >>> {{2014,6,24},{16,34,9}} after send ok >>> {{2014,6,24},{16,34,30}} before send >>> {{2014,6,24},{16,34,30}} after send ok >>> {{2014,6,24},{16,34,51}} before send >>> {{2014,6,24},{16,34,51}} after send ok >>> {{2014,6,24},{16,35,12}} before send >>> .... >>> >>> Server blocked process output: >>> >>> {{2014,6,24},{16,33,21}}: <0.95.0> ping >>> {{2014,6,24},{16,33,21}} bsend: <0.95.0> >>> {{2014,6,24},{16,33,21}} asend: <0.95.0> ok >>> {{2014,6,24},{16,33,48}}: <0.95.0> ping >>> {{2014,6,24},{16,33,48}} bsend: <0.95.0> >>> %% (no asend message after it) >>> >>> (tcp_failing_node@REDACTED)1> erlang:process_info(pid(0,95,0)). >>> [{current_function,{erts_internal,port_command,3}}, >>> {initial_call,{proc_lib,init_p,5}}, >>> >>> Bug is not always reproducible, but occurs quite often. The problem is >>> that even >>> after server's out buffers are empty data does not arrive to the client, >>> and incoming buffer grow >>> as client send ping messages to the server. (So erlang:port_command/3 >>> with no-suspend always return false >>> when another main server process for this connection is suspended in >>> gen_tcp:send/2) >>> >>> And then it's getting only worse as already mentioned >>> >>> Every 2.0s: netstat -al | grep 8899 >>> >>> Tue Jun 24 16:56:59 2014 >>> >>> tcp4 804 0 localhost.8899 localhost.63263 >>> ESTABLISHED >>> tcp4 0 0 localhost.63263 localhost.8899 >>> ESTABLISHED >>> tcp4 0 0 localhost.8899 localhost.63257 >>> ESTABLISHED >>> tcp4 0 0 localhost.63257 localhost.8899 >>> ESTABLISHED >>> tcp4 0 0 *.8899 *.* LISTEN >>> >>> We faced with this after switching to R16B03 from R15B03, I know there >>> were some changes in port_command handling, i guess why we got such >>> behaviour? >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Mon Jul 28 16:27:23 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 28 Jul 2014 16:27:23 +0200 Subject: [erlang-bugs] r15b03-1 SEGV in erts_port_task_schedule() Message-ID: <21462.24011.626017.696972@gargle.gargle.HOWL> This is a followup to my previous report in , but it's for a different function in erl_port_task.c. We've gotten a new SEGV with r15b03-1. This time we managed to capture a truncated core dump (just threads list and registers, no thread stacks or heap memory): Program terminated with signal 11, Segmentation fault. #0 enqueue_task (ptp=, ptqp=) at beam/erl_port_task.c:327 327 ptp->prev = ptqp->last; (gdb) bt #0 enqueue_task (ptp=, ptqp=) at beam/erl_port_task.c:327 #1 erts_port_task_schedule (id=, id@REDACTED=, pthp=, type=, event=, event_data=) at beam/erl_port_task.c:615 (gdb) The code that faulted is 0x00000000004b8203 <+419>: mov 0x10(%r15),%rax 0x00000000004b8207 <+423>: mov 0x10(%rsp),%rbx 0x00000000004b820c <+428>: movq $0x0,0x8(%rbx) => 0x00000000004b8214 <+436>: mov 0x8(%rax),%rcx 0x00000000004b8218 <+440>: mov %rax,0x10(%rbx) 0x00000000004b821c <+444>: mov %rcx,(%rbx) which is enqueue_task() [line 327] as inlined in erts_port_task_schedule() [line 615]. At this point, %rax is zero according to gdb's registers dump. The relevant part of erts_port_task_schedule() is: ==snip== if (!pp->sched.taskq) pp->sched.taskq = port_taskq_init(port_taskq_alloc(), pp); ASSERT(ptp); ptp->type = type; ptp->event = event; ptp->event_data = event_data; set_handle(ptp, pthp); switch (type) { case ERTS_PORT_TASK_FREE: erl_exit(ERTS_ABORT_EXIT, "erts_port_task_schedule(): Cannot schedule free task\n"); break; case ERTS_PORT_TASK_INPUT: case ERTS_PORT_TASK_OUTPUT: case ERTS_PORT_TASK_EVENT: erts_smp_atomic_inc_relb(&erts_port_task_outstanding_io_tasks); /* Fall through... */ default: enqueue_task(pp->sched.taskq, ptp); break; } ==snip== The SEGV implies that pp->sched.taskq is NULL at the call to enqueue_task(). The erts_smp_atomic_inc_relb() and set_handle() calls do not affect *pp, and I don't see any aliasing between *ptp and *pp, so the assignments to *ptp do not affect *pp either. So for pp->sched.taskq to be NULL at the bottom it would have to be NULL after the call to port_taskq_init(), which implies that port_taskq_alloc() returned NULL. port_taskq_alloc() is generated via ERTS_SCHED_PREF_QUICK_ALLOC_IMPL; if one expands that it becomes: void erts_alloc_n_enomem(ErtsAlcType_t,Uint) __attribute__((noreturn)); static __inline__ void *erts_alloc(ErtsAlcType_t type, Uint size) { void *res; res = (*erts_allctrs[(((type) >> (0)) & (15))].alloc)( (((type) >> (7)) & (255)), erts_allctrs[(((type) >> (0)) & (15))].extra, size); if (!res) erts_alloc_n_enomem((((type) >> (7)) & (255)), size); return res; } static __inline__ ErtsPortTaskQueue * port_taskq_alloc(void) { ErtsPortTaskQueue *res = port_taskq_pre_alloc(); if (!res) res = erts_alloc((4564), sizeof(ErtsPortTaskQueue)); return res; } But given this code, I don't see how erts_alloc() or port_taskq_alloc() could ever return NULL. Which leads me to suspect that there's a concurrency bug that's causing *pp to be clobbered behind our backs. Ideas? /Mikael From eric.pailleau@REDACTED Mon Jul 28 23:56:33 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 28 Jul 2014 23:56:33 +0200 Subject: [erlang-bugs] 17.0 : dialyzer issue on boolean type in record. Message-ID: <53D6C711.2050107@wanadoo.fr> Hi, please considere below minimal module : ---8<---------------------------------------------------- -module(test). -export([test/0]). -record(test, { bool = 'true' :: boolean()} ). test() -> test(#test{}). test(R) -> case R#test.bool of true -> ok ; false -> ok end. ---8<---------------------------------------------------- dialyzer raise an error : test.erl:11: The pattern 'false' can never match the type 'true'. Looks like dialyzer considere #test.bool to be of type 'true' while it is of type boolean() and default value to 'true'. Documentation says : "In the presence of initial values for fields, the type must be declared after the initialization as in the following: -record(rec, {field1 = [] :: Type1, field2, field3 = 42 :: Type3}). Naturally, the initial values for fields should be compatible with (i.e. a member of) the corresponding types. " A bug, isn't it ? Regards. From vinoski@REDACTED Tue Jul 29 00:25:20 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Mon, 28 Jul 2014 18:25:20 -0400 Subject: [erlang-bugs] 17.0 : dialyzer issue on boolean type in record. In-Reply-To: <53D6C711.2050107@wanadoo.fr> References: <53D6C711.2050107@wanadoo.fr> Message-ID: On Mon, Jul 28, 2014 at 5:56 PM, PAILLEAU Eric wrote: > Hi, > please considere below minimal module : > ---8<---------------------------------------------------- > -module(test). > > -export([test/0]). > > -record(test, { bool = 'true' :: boolean()} ). > > test() -> test(#test{}). > > test(R) -> case R#test.bool of > true -> ok ; > false -> ok > end. > ---8<---------------------------------------------------- > dialyzer raise an error : > > test.erl:11: The pattern 'false' can never match the type 'true'. > > Looks like dialyzer considere #test.bool to be of type 'true' while it is > of type boolean() and default value to 'true'. > > Documentation says : > "In the presence of initial values for fields, the type must be declared > after the initialization as in the following: > > -record(rec, {field1 = [] :: Type1, field2, field3 = 42 :: Type3}). > > Naturally, the initial values for fields should be compatible with (i.e. a > member of) the corresponding types. " > > > A bug, isn't it ? > I don't think it's a bug since the only way test/1 can be called is via test/0, and the latter passes a #test{} record instance containing only default values. In this case, the default value of the bool field is true, so dialyzer is correct that false can never match. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Tue Jul 29 00:34:55 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 29 Jul 2014 00:34:55 +0200 Subject: [erlang-bugs] 17.0 : dialyzer issue on boolean type in record. In-Reply-To: <53D6C711.2050107@wanadoo.fr> References: <53D6C711.2050107@wanadoo.fr> Message-ID: <53D6D00F.3000204@wanadoo.fr> Hi Steve, dialyzer is right, yes, in a sens, because the default value is not dynamically set, but what about below code ? dialyzer raise an error, because too smart, probably, while code is valid... This indeed imply to only set the type and not default value... Regards. ---8<---------------------------------------------------- -module(test). -export([test/0]). -ifdef(TEST). -record(test, { bool = 'true' :: boolean()} ). -else. -record(test, { bool = 'false' :: boolean()} ). -endif. test() -> test(#test{}). test(R) -> case R#test.bool of true -> true ; false -> false end. ---8<---------------------------------------------------- From ulf@REDACTED Tue Jul 29 13:26:39 2014 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 29 Jul 2014 13:26:39 +0200 Subject: [erlang-bugs] 17.0 : dialyzer issue on boolean type in record. In-Reply-To: <53D6D00F.3000204@wanadoo.fr> References: <53D6C711.2050107@wanadoo.fr> <53D6D00F.3000204@wanadoo.fr> Message-ID: Dialyzer doesn?t consider ifdef alternatives in its analysis. The default mode is to analyze (debug-)compiled code, in which the ifdefs have already been resolved. You can tell dialyzer to start from the source code, but then, you need to provide values for the defines, using the -D flag*. See the dialyzer man page for details. BR, Ulf W * For it to work otherwise, dialyzer would have to use its own preprocessor. As it is, dialyzer uses the standard compiler (using the undocumented option combo [to_pp, binary | _] to compile:file/2), and thus never sees the defines. On 29 Jul 2014, at 00:34, PAILLEAU Eric wrote: > Hi Steve, > > dialyzer is right, yes, in a sens, because the default value is not dynamically set, but what about below code ? > > dialyzer raise an error, because too smart, probably, > while code is valid... > > This indeed imply to only set the type and not default value... > Regards. > > ---8<---------------------------------------------------- > -module(test). > > -export([test/0]). > > -ifdef(TEST). > -record(test, { bool = 'true' :: boolean()} ). > -else. > -record(test, { bool = 'false' :: boolean()} ). > -endif. > > test() -> test(#test{}). > > test(R) -> case R#test.bool of > true -> true ; > false -> false > end. > ---8<---------------------------------------------------- > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From kostis@REDACTED Tue Jul 29 13:35:02 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 29 Jul 2014 14:35:02 +0300 Subject: [erlang-bugs] 17.0 : dialyzer issue on boolean type in record. In-Reply-To: <53D6D00F.3000204@wanadoo.fr> References: <53D6C711.2050107@wanadoo.fr> <53D6D00F.3000204@wanadoo.fr> Message-ID: <53D786E6.30300@cs.ntua.gr> On 07/29/2014 01:34 AM, PAILLEAU Eric wrote: > Hi Steve, > > dialyzer is right, yes, in a sens, because the default value is not > dynamically set, but what about below code ? > > dialyzer raise an error, because too smart, probably, > while code is valid... What you are experiencing (in your previous example) is due to your test/1 function being module local, which allows dialyzer to infer that all calls to it will be with a particular boolean value, not both. Simply export it and the warning will disappear. If you want to have it module local then what dialyzer tells you is that you can simplify its code by taking out one clause of the case statement. In the program you show below, dialyzer is also right. The ifdefs are handled by the preprocessor and ONLY ONE branch is part of the code at any dialyzer run, not both. Kostis > ---8<---------------------------------------------------- > -module(test). > > -export([test/0]). > > -ifdef(TEST). > -record(test, { bool = 'true' :: boolean()} ). > -else. > -record(test, { bool = 'false' :: boolean()} ). > -endif. > > test() -> test(#test{}). > > test(R) -> case R#test.bool of > true -> true ; > false -> false > end. > ---8<---------------------------------------------------- > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From mikpelinux@REDACTED Tue Jul 29 16:30:37 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Tue, 29 Jul 2014 16:30:37 +0200 Subject: [erlang-bugs] r15b03-1 SEGV in erts_port_task_schedule() In-Reply-To: <21462.24011.626017.696972@gargle.gargle.HOWL> References: <21462.24011.626017.696972@gargle.gargle.HOWL> Message-ID: <21463.45069.249946.809608@gargle.gargle.HOWL> Mikael Pettersson writes: > This is a followup to my previous report in > , > but it's for a different function in erl_port_task.c. > > We've gotten a new SEGV with r15b03-1. This time we managed to > capture a truncated core dump (just threads list and registers, > no thread stacks or heap memory): > > Program terminated with signal 11, Segmentation fault. > #0 enqueue_task (ptp=, > ptqp=) > at beam/erl_port_task.c:327 > 327 ptp->prev = ptqp->last; > (gdb) bt > #0 enqueue_task (ptp=, > ptqp=) > at beam/erl_port_task.c:327 > #1 erts_port_task_schedule (id=, > id@REDACTED=, > pthp=, > type=, > event=, > event_data=) > at beam/erl_port_task.c:615 > (gdb) > > The code that faulted is > > 0x00000000004b8203 <+419>: mov 0x10(%r15),%rax > 0x00000000004b8207 <+423>: mov 0x10(%rsp),%rbx > 0x00000000004b820c <+428>: movq $0x0,0x8(%rbx) > => 0x00000000004b8214 <+436>: mov 0x8(%rax),%rcx > 0x00000000004b8218 <+440>: mov %rax,0x10(%rbx) > 0x00000000004b821c <+444>: mov %rcx,(%rbx) > > which is enqueue_task() [line 327] as inlined in erts_port_task_schedule() > [line 615]. At this point, %rax is zero according to gdb's registers dump. > > The relevant part of erts_port_task_schedule() is: > > ==snip== > if (!pp->sched.taskq) > pp->sched.taskq = port_taskq_init(port_taskq_alloc(), pp); > > ASSERT(ptp); > > ptp->type = type; > ptp->event = event; > ptp->event_data = event_data; > > set_handle(ptp, pthp); > > switch (type) { > case ERTS_PORT_TASK_FREE: > erl_exit(ERTS_ABORT_EXIT, > "erts_port_task_schedule(): Cannot schedule free task\n"); > break; > case ERTS_PORT_TASK_INPUT: > case ERTS_PORT_TASK_OUTPUT: > case ERTS_PORT_TASK_EVENT: > erts_smp_atomic_inc_relb(&erts_port_task_outstanding_io_tasks); > /* Fall through... */ > default: > enqueue_task(pp->sched.taskq, ptp); > break; > } > ==snip== > > The SEGV implies that pp->sched.taskq is NULL at the call to enqueue_task(). > > The erts_smp_atomic_inc_relb() and set_handle() calls do not affect *pp, > and I don't see any aliasing between *ptp and *pp, so the assignments to > *ptp do not affect *pp either. > > So for pp->sched.taskq to be NULL at the bottom it would have to be NULL > after the call to port_taskq_init(), which implies that port_taskq_alloc() > returned NULL. > > port_taskq_alloc() is generated via ERTS_SCHED_PREF_QUICK_ALLOC_IMPL; > if one expands that it becomes: > > void erts_alloc_n_enomem(ErtsAlcType_t,Uint) > __attribute__((noreturn)); > > static __inline__ > void *erts_alloc(ErtsAlcType_t type, Uint size) > { > void *res; > res = (*erts_allctrs[(((type) >> (0)) & (15))].alloc)( > (((type) >> (7)) & (255)), > erts_allctrs[(((type) >> (0)) & (15))].extra, > size); > if (!res) > erts_alloc_n_enomem((((type) >> (7)) & (255)), size); > return res; > } > > static __inline__ ErtsPortTaskQueue * port_taskq_alloc(void) > { > ErtsPortTaskQueue *res = port_taskq_pre_alloc(); > if (!res) > res = erts_alloc((4564), sizeof(ErtsPortTaskQueue)); > return res; > } > > But given this code, I don't see how erts_alloc() or port_taskq_alloc() > could ever return NULL. > > Which leads me to suspect that there's a concurrency bug that's > causing *pp to be clobbered behind our backs. > > Ideas? I've studied erl_port_task.c and some related code, and think I understand how the locking is _supposed_ to work: Before you can access port->sched you have to erts_smp_runq_lock() the runq stored (as an atomic integer) in port->run_queue. runq = erts_port_runq(port); does this automatically, but you then end up with two variables that must stay coherent until you unlock. Q1. I see a number of places in erl_port_task.c where the code temporarily releases the runq lock, calls out somewhere, and then just locks the runq while still holding on to the original port. What, if anything, guarantees that these two items still belong together. Can't the port migrate to another runq while the runq was unlocked? If so, then it seems we have to reload runq (if the port is the object of interest) or revalidate and possibly bail out if they are now no longer connected. Q2. Is erts_check_emigration_need(runq) _guaranteed_ to return a value that is different from the given runq? Looking at the code, that's not obviously true. If it ever returned the same runq it was given, very bad things(TM) would happen... /Mikael From bjorn@REDACTED Wed Jul 30 11:38:34 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 30 Jul 2014 11:38:34 +0200 Subject: [erlang-bugs] Warning shows the wrong operator when useless operator is inside a useless contruction In-Reply-To: References: Message-ID: On Sat, Jul 19, 2014 at 6:11 PM, Jos? Valim wrote: > Given the following code: > > -module(foo). > -compile(export_all). > > bar() -> > [{foo, hello:world() == bar}], > ok. > > > When compiled, it reports: > > foo.erl:5: Warning: a term is constructed, but never used > foo.erl:5: Warning: use of operator '=:=' has no effect Unfortunately it is not that easy to fix. The compiler rewrites '==' to '=:=' if it can know that the result will be the same ('=:=' is slightly more efficient than '=='). It does that rewriting before it has found out that the result of the expression is not used. While I can think of a few ways to fix the problem, they are all more complex than I would like. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From tony@REDACTED Wed Jul 30 13:41:01 2014 From: tony@REDACTED (Tony Rogvall) Date: Wed, 30 Jul 2014 13:41:01 +0200 Subject: [erlang-bugs] Warning shows the wrong operator when useless operator is inside a useless contruction In-Reply-To: References: Message-ID: On 30 jul 2014, at 11:38, Bj?rn Gustavsson wrote: > On Sat, Jul 19, 2014 at 6:11 PM, Jos? Valim > wrote: >> Given the following code: >> >> -module(foo). >> -compile(export_all). >> >> bar() -> >> [{foo, hello:world() == bar}], >> ok. >> >> >> When compiled, it reports: >> >> foo.erl:5: Warning: a term is constructed, but never used >> foo.erl:5: Warning: use of operator '=:=' has no effect > > Unfortunately it is not that easy to fix. > > The compiler rewrites '==' to '=:=' if > it can know that the result will be the > same ('=:=' is slightly more efficient than > '=='). It does that rewriting before it has > found out that the result of the expression > is not used. Why not just change the error message into: foo.erl:5 Warning: use of operator =:= (or ==) has no effect Or something similar. Not too complex I guess :-) /Tony > > While I can think of a few ways to fix the > problem, they are all more complex than I > would like. > > /Bjorn > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Wed Jul 30 21:37:25 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 30 Jul 2014 12:37:25 -0700 Subject: [erlang-bugs] inets stand_alone mode Message-ID: <53D94975.1020107@gmail.com> Hi, I ran into a problem that exists in 17.1.2 with inets between inets mode and stand_along mode with httpc: This works: 1> application:start(inets). ok 2> inets:start(httpc, [{profile, foobar}], inets). {ok,<0.53.0>} 3> inets:start(httpc, [{profile, foobar}], inets). {error,{already_started,<0.53.0>}} This is the problem (unable to use a try/catch to get the exit, since that is within an inets process): 1> inets:start(httpc, [{profile, foobar}], stand_alone). {ok,<0.35.0>} 2> inets:start(httpc, [{profile, foobar}], stand_alone). =ERROR REPORT==== 30-Jul-2014::12:24:22 === ** Generic server <0.35.0> terminating ** Last message in was {'EXIT',<0.33.0>, {'EXIT', {badarg, [{ets,new, [stand_alone_foobar__session_db, [public,set,named_table,{keypos,2}]], []}, {httpc_manager,do_init,2, [{file,"httpc_manager.erl"},{line,421}]}, {httpc_manager,init,1, [{file,"httpc_manager.erl"},{line,406}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,306}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}}} ** When Server state == {state,[],stand_alone_foobar__handler_db, {cookie_db,undefined,16402}, stand_alone_foobar__session_db,stand_alone_foobar, {options, {undefined,[]}, {undefined,[]}, 0,2,5,120000,2,disabled,false,inet,default, default,[]}} ** Reason for termination == ** {'EXIT',{badarg,[{ets,new, [stand_alone_foobar__session_db, [public,set,named_table,{keypos,2}]], []}, {httpc_manager,do_init,2, [{file,"httpc_manager.erl"},{line,421}]}, {httpc_manager,init,1, [{file,"httpc_manager.erl"},{line,406}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,306}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} ** exception exit: {'EXIT', {badarg, [{ets,new, [stand_alone_foobar__session_db, [public,set,named_table,{keypos,2}]], []}, {httpc_manager,do_init,2, [{file,"httpc_manager.erl"},{line,421}]}, {httpc_manager,init,1, [{file,"httpc_manager.erl"},{line,406}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,306}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} I am not sure if this was a known issue, but it should be a bug, since it seems valid that two standalone Erlang processes might use the same httpc profile data in ets. Thanks, Michael From Ingela.Anderton.Andin@REDACTED Thu Jul 31 15:03:36 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 31 Jul 2014 15:03:36 +0200 Subject: [erlang-bugs] SSL Client Certificate Request types with EC certificates In-Reply-To: References: Message-ID: <53DA3EA8.50701@ericsson.com> Hi! Thank you for reporting this. I think it is a bug, and it is a known issue that the elliptic curve contribution lacked test cases for ECC signed certificates, although it had lots of test for ECC ciphers suites with RSA signed certs. We plan of course to add such test but it has not been top priority. I think the proper fix shall look like this: diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl index b018332..25bdc5e 100644 --- a/lib/ssl/src/ssl_handshake.erl +++ b/lib/ssl/src/ssl_handshake.erl @@ -207,7 +207,7 @@ client_certificate_verify(OwnCert, MasterSecret, Version, %% Description: Creates a certificate_request message, called by the server. %%-------------------------------------------------------------------- certificate_request(CipherSuite, CertDbHandle, CertDbRef, Version) -> - Types = certificate_types(CipherSuite), + Types = certificate_types(ssl_cipher:suite_definition(CipherSuite), Version), HashSigns = advertised_hash_signs(Version), Authorities = certificate_authorities(CertDbHandle, CertDbRef), #certificate_request{ @@ -1098,19 +1098,31 @@ supported_ecc(_) -> %%-------------certificate handling -------------------------------- -certificate_types({KeyExchange, _, _, _}) - when KeyExchange == rsa; - KeyExchange == dhe_dss; - KeyExchange == dhe_rsa; - KeyExchange == ecdhe_rsa -> - <>; +certificate_types(_, {N, M}) when N >= 3 andalso M >= 3 -> + case proplists:get_bool(ecdsa, + proplists:get_value(public_keys, crypto:supports())) of + true -> + <>; + false -> + <> + end; + +certificate_types({KeyExchange, _, _, _}, _) when KeyExchange == rsa; + KeyExchange == dhe_rsa; + KeyExchange == ecdhe_rsa -> + <>; + +certificate_types({KeyExchange, _, _, _}, _) when KeyExchange == dhe_dss, + KeyExchange == srp_dss -> + <>; -certificate_types({KeyExchange, _, _, _}) - when KeyExchange == dh_ecdsa; - KeyExchange == dhe_ecdsa -> +certificate_types({KeyExchange, _, _, _}, _) when KeyExchange == dh_ecdsa; + KeyExchange == dhe_ecdsa; + KeyExchange == ecdh_ecdsa; + KeyExchange == ecdhe_ecdsa -> <>; -certificate_types(_) -> +certificate_types(_, _) -> <>. certificate_authorities(CertDbHandle, CertDbRef) -> Regards Ingela - Erlang/OTP team Ericsson AB On 07/11/2014 06:21 PM, Peter Cooper wrote: >> -----Original Message----- >> From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs- >> bounces@REDACTED] On Behalf Of Peter Cooper >> Sent: Friday, July 11, 2014 10:42 AM >> To: 'erlang-bugs@REDACTED' >> Subject: [erlang-bugs] SSL Client Certificate Request types with EC >> certificates >> >> It's entirely possible (even likely) I'm misunderstanding something >> about how these SSL ciphers are supposed to work, but the behavior I'm >> seeing looks like an Erlang issue to me. I'm trying to use RabbitMQ on >> Erlang 17.1 on 64-bit Windows 7, requiring a connection using SSL with >> a client certificate. All the certificates are using elliptic curve >> (secp256k1) keys. However, my client (in Java) isn't sending its client >> certificate because the CertificateRequest message from the >> RabbitMQ/Erlang server is saying that it's requesting an RSA >> certificate, whereas all I have is an EC certificate. I'm trying to use >> cipher suite {ecdhe_ecdsa, aes_128_cbc, sha256} which I think is the >> correct one, but the place that specifies what types of certificates to >> request (ssl_handshake's certificate_types function) at >> https://github.com/erlang/otp/blob/maint- >> 17/lib/ssl/src/ssl_handshake.erl#L1110 >> doesn't seem to handle this case correctly and always asks for just RSA >> rather than ECDSA certificate. >> >> When I connect to the server using the same keys with "openssl >> s_client", the connection is established and the certificate gets sent >> fine, which leads me to think that openssl isn't checking for the type >> in the CertificateRequest message and is just sending the certificate I >> specify. So it looks like Erlang's SSL module can handle the >> certificate just fine if the client ignores the list of requested >> types. >> >> Thanks for any help you could provide. > > My apologies for the double-post, but I thought that showing a patch of a change that made the system work as expected for me would be helpful. This clearly isn't the way one should do this in general, as it's just handling the particular cipher I've chosen, but it looks like by the time it is figuring out the certificate type the cipher suite has already been mapped to the OpenSSL-equivalent name, and that name is what it's using to match. I'm not sure which ciphers accept just ECDSA, just RSA, or both, but since at least one accepts ECDSA there needs to be some more checking here of some sort. In the meantime, I've applied this patch to my system so I can continue developing my project. Thanks! > > --- ssl-5.3.5\src\ssl_handshake.erl Mon Jun 23 17:24:48 2014 > +++ ssl-5.3.5-mod\src\ssl_handshake.erl Fri Jul 11 12:05:21 2014 > @@ -1110,6 +1110,10 @@ > KeyExchange == dhe_ecdsa -> > <>; > > +certificate_types(Cipher) > + when Cipher == ?TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 -> > + <>; > + > certificate_types(_) -> > <>. > > > > -- > Peter Cooper Jr. > Sr. Software Engineer > EFI > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Ingela.Anderton.Andin@REDACTED Thu Jul 31 16:50:58 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 31 Jul 2014 16:50:58 +0200 Subject: [erlang-bugs] x509 certificate decoded string representation is wrong In-Reply-To: References: Message-ID: <53DA57D2.2010809@ericsson.com> Hi! Sorry for the late answer. Was this pre 17.0 or 17.0 ? There was a unicode fix in 17.0 the accidentally seems to have been lost in the release notes. If you still have problems could you please send us a sample cert that fails to speed up the process. Regards Ingela Erlang/OTP team - Ericsson AB On 06/12/2014 10:57 PM, Daniel Goertzen wrote: > In the public_key application, decoding of attributes in x509 > certificates does not always decode to a string as indicated in the > documentation. The documentation says that the value of commonName (and > several other attributes) should be: > > special_string() = {teletexString, string()} | {printableString, > string()} | {universalString, string()} | {utf8String, string()} | > {bmpString, string()} > > ... however when I decode a cert I see a utf8String coming out as a > binary instead of a string().... > > [{'AttributeTypeAndValue', > {2,5,4,3}, > {utf8String,<<"Daniel Goertzen">>}}], > > ... and typer shows several other non-string representations (unicode > characters represented by 4-tuples): > > -spec dec_X520CommonName(_) -> > {'bmpString',[byte() | {byte(),byte(),byte(),byte()}] | {byte(),binary()}} | > {'printableString',[byte() | {byte(),byte(),byte(),byte()}] | > {byte(),binary()}} | > {'teletexString',[byte() | {byte(),byte(),byte(),byte()}] | > {byte(),binary()}} | > {'universalString',[byte() | {byte(),byte(),byte(),byte()}] | > {byte(),binary()}} | > {'utf8String',_}. > > > > Also, encoding does not accept unicode strings (list of chars). The > example below crashes. > > Subject = {rdnSequence, [ > [#'AttributeTypeAndValue'{ > type = ?'id-at-commonName', > value = {utf8String, [16#4e09|" string starting with a > chinese symbol"]} > }] > ]}, > > > > I assume that the documentation is right and the decoded representation > should be "list of characters". Instead internal representations are > coming through. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Ingela.Anderton.Andin@REDACTED Thu Jul 31 17:07:05 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 31 Jul 2014 17:07:05 +0200 Subject: [erlang-bugs] Erlang OTP's httpc module denial of service In-Reply-To: References: Message-ID: <53DA5B99.1020905@ericsson.com> Hi! Thank you for your report. Sorry for the late answer, I have crated a issue to look into this. Regards Ingela - Erlang/OTP team - Ericsson AB On 05/02/2014 11:31 AM, Seba wrote: > Hi list! > > I've found a vulnerability in the httpc module. I'm sorry I can't > provide a patch (I can't code much erlang yet), I'm attaching a proof of > concept though. > > Let me know if you need further details. > > Regards, > > Sebasti?n Tello > > > Summary > ======= > > Using httpc to connect to an untrusted server can cause the system to > run out of memory and crash. > > > Description > =========== > > When requesting a URL from an untrusted source using the httpc OTP > module, if the server: > - accepts the connection > - does not read from the socket > - and indefinitely writes bytes in the socket. > > Then the client will keep on allocating memory until the system crashes. > > > Proof of concept > ================ > > Server-side (attacker): > > Start the malicious server (use the attached module). > > 1> httpc_dos:server(5678). > > > Client-side (httpc), connect to the server: > > $ erl > Erlang/OTP 17 [erts-6.0] [source] [64-bit] [smp:4:4] [async-threads:10] > [hipe] [kernel-poll:false] > > Eshell V6.0 (abort with ^G) > 1> application:start(inets). > ok > 2> httpc:request("http://SERVER_IP:5678"). > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 1167696400 bytes of memory (of type "heap"). > > Tested on > ========= > OTP 17 > Ubuntu 12.04 x86_64 > > Workaround > ========== > > I haven't been able to reproduce the issue using lhttpc > (https://github.com/esl/lhttpc) as the call will crash when the response > size is too large. > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs >