From heinz@REDACTED Sun Mar 1 11:03:22 2015 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Sun, 1 Mar 2015 11:03:22 +0100 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' Message-ID: When enif_make_double gets a nan value passed as the double argument it returns a invalid term, this term can neither be printed (via the fmt*) functions nor can it be deserialized by binary_to_term when serializing it the following binary is generated: 6> io:format("~p~n", [term_to_binary(V)]). <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> V is the double returned by enif_make_double --- Cheers, Heinz Nikolaus Gies heinz@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mikpelinux@REDACTED Sun Mar 1 13:02:37 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 1 Mar 2015 13:02:37 +0100 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' In-Reply-To: References: Message-ID: <21746.65501.231478.752377@gargle.gargle.HOWL> Heinz Nikolaus Gies writes: > When enif_make_double gets a nan value passed as the double argument it returns a invalid term, this term can neither be printed (via the fmt*) functions nor can it be deserialized by binary_to_term when serializing it the following binary is generated: > > 6> io:format("~p~n", [term_to_binary(V)]). > <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> > > V is the double returned by enif_make_double There are two issues here: 1. the VM disallows INFs and NANs, but NIF authors may not be aware of that 2. enif_make_double() SHOULD reject non-finite doubles but it doesn't, and its documentation doesn't mention any failure modes; returning THE_NON_VALUE may not be detected as a failure by the NIF and so this non-value may leak into aggregates (lists or tuples) where it will totally break things When looking at this I noticed that enif_make_atom() also has problems: it may fail and return THE_NON_VALUE if the resulting atom would be too long, but the documentation doesn't mention this possibility so the NIF might continue and store this non-value in aggregates before returning. The OTP folks need to straighten up error handling in the enif_make_*() functions. From heinz@REDACTED Sun Mar 1 15:14:03 2015 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Sun, 1 Mar 2015 15:14:03 +0100 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' In-Reply-To: <21746.65501.231478.752377@gargle.gargle.HOWL> References: <21746.65501.231478.752377@gargle.gargle.HOWL> Message-ID: <2FAED6E0-58AB-462B-9BD0-CECC5D2E41B4@licenser.net> Hi Mikael, thank for the clarification. That makes sense, I find 2) actually more troublesome since I went to consult the documents to be sure it?s not a defined behavior. What was a bit more concerning was that that it returned a value that breaks transparently breaks other erlang functions. Perhaps simply returning a bad_arg would make a lot more sense? --- Cheers, Heinz Nikolaus Gies heinz@REDACTED > On Mar 1, 2015, at 13:02, Mikael Pettersson wrote: > > Heinz Nikolaus Gies writes: >> When enif_make_double gets a nan value passed as the double argument it returns a invalid term, this term can neither be printed (via the fmt*) functions nor can it be deserialized by binary_to_term when serializing it the following binary is generated: >> >> 6> io:format("~p~n", [term_to_binary(V)]). >> <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> >> >> V is the double returned by enif_make_double > > There are two issues here: > 1. the VM disallows INFs and NANs, but NIF authors may not be aware of that > 2. enif_make_double() SHOULD reject non-finite doubles but it doesn't, and > its documentation doesn't mention any failure modes; returning THE_NON_VALUE > may not be detected as a failure by the NIF and so this non-value may leak > into aggregates (lists or tuples) where it will totally break things > > When looking at this I noticed that enif_make_atom() also has problems: it > may fail and return THE_NON_VALUE if the resulting atom would be too long, > but the documentation doesn't mention this possibility so the NIF might > continue and store this non-value in aggregates before returning. > > The OTP folks need to straighten up error handling in the enif_make_*() > functions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mikpelinux@REDACTED Sun Mar 1 18:34:13 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 1 Mar 2015 18:34:13 +0100 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' In-Reply-To: <2FAED6E0-58AB-462B-9BD0-CECC5D2E41B4@licenser.net> References: <21746.65501.231478.752377@gargle.gargle.HOWL> <2FAED6E0-58AB-462B-9BD0-CECC5D2E41B4@licenser.net> Message-ID: <21747.19861.246829.251429@gargle.gargle.HOWL> Heinz Nikolaus Gies writes: > Hi Mikael, > thank for the clarification. That makes sense, I find 2) actually more troublesome since I went to consult the documents to be sure it?s not a defined behavior. What was a bit more concerning was that that it returned a value that breaks transparently breaks other erlang functions. > > Perhaps simply returning a bad_arg would make a lot more sense? Erlang-level exceptions don't exist at this level of the VM. They have to be synthesized explicitly, and doing that requires documented protocols for signalling errors, and code to follow them. E.g., the interface to BIFs is such that to signal badarg, the BIF: 1. stores a special flag in the current process struct, and 2. returns THE_NON_VALUE. The caller, beam_emu.c or native code wrappers in hipe_${arch}_bifs, checks for THE_NON_VALUE returns and branches to the exception-raising code. The problem here is that we're in even lower-level code, and there is no documentation that enif_make_*() can fail, how to detect such failures, or what to do in response. Once this is in place, the next problem is to ensure that NIFs are properly updated and not just recompiled. > --- > Cheers, > Heinz Nikolaus Gies > heinz@REDACTED > > > > > On Mar 1, 2015, at 13:02, Mikael Pettersson wrote: > > > > Heinz Nikolaus Gies writes: > >> When enif_make_double gets a nan value passed as the double argument it returns a invalid term, this term can neither be printed (via the fmt*) functions nor can it be deserialized by binary_to_term when serializing it the following binary is generated: > >> > >> 6> io:format("~p~n", [term_to_binary(V)]). > >> <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> > >> > >> V is the double returned by enif_make_double > > > > There are two issues here: > > 1. the VM disallows INFs and NANs, but NIF authors may not be aware of that > > 2. enif_make_double() SHOULD reject non-finite doubles but it doesn't, and > > its documentation doesn't mention any failure modes; returning THE_NON_VALUE > > may not be detected as a failure by the NIF and so this non-value may leak > > into aggregates (lists or tuples) where it will totally break things > > > > When looking at this I noticed that enif_make_atom() also has problems: it > > may fail and return THE_NON_VALUE if the resulting atom would be too long, > > but the documentation doesn't mention this possibility so the NIF might > > continue and store this non-value in aggregates before returning. > > > > The OTP folks need to straighten up error handling in the enif_make_*() > > functions. > > xapplication/pgp-signature [Click mouse-2 to save to a file] -- From vinoski@REDACTED Sun Mar 1 19:38:19 2015 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 1 Mar 2015 13:38:19 -0500 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' In-Reply-To: <21747.19861.246829.251429@gargle.gargle.HOWL> References: <21746.65501.231478.752377@gargle.gargle.HOWL> <2FAED6E0-58AB-462B-9BD0-CECC5D2E41B4@licenser.net> <21747.19861.246829.251429@gargle.gargle.HOWL> Message-ID: Hi Mikael, I don't understand your message, so perhaps I'm missing something -- the erl_nif functions have had the ability to throw badarg for quite some time now. Here's a PR that I think addresses the issues raised in this thread: https://github.com/erlang/otp/pull/632 --steve On Sun, Mar 1, 2015 at 12:34 PM, Mikael Pettersson wrote: > Heinz Nikolaus Gies writes: > > Hi Mikael, > > thank for the clarification. That makes sense, I find 2) actually more > troublesome since I went to consult the documents to be sure it?s not a > defined behavior. What was a bit more concerning was that that it returned > a value that breaks transparently breaks other erlang functions. > > > > Perhaps simply returning a bad_arg would make a lot more sense? > > Erlang-level exceptions don't exist at this level of the VM. They have to > be synthesized explicitly, and doing that requires documented protocols > for signalling errors, and code to follow them. > > E.g., the interface to BIFs is such that to signal badarg, the BIF: > 1. stores a special flag in the current process struct, and > 2. returns THE_NON_VALUE. > > The caller, beam_emu.c or native code wrappers in hipe_${arch}_bifs, checks > for THE_NON_VALUE returns and branches to the exception-raising code. > > The problem here is that we're in even lower-level code, and there is no > documentation that enif_make_*() can fail, how to detect such failures, > or what to do in response. Once this is in place, the next problem is > to ensure that NIFs are properly updated and not just recompiled. > > > --- > > Cheers, > > Heinz Nikolaus Gies > > heinz@REDACTED > > > > > > > > > On Mar 1, 2015, at 13:02, Mikael Pettersson > wrote: > > > > > > Heinz Nikolaus Gies writes: > > >> When enif_make_double gets a nan value passed as the double argument > it returns a invalid term, this term can neither be printed (via the fmt*) > functions nor can it be deserialized by binary_to_term when serializing it > the following binary is generated: > > >> > > >> 6> io:format("~p~n", [term_to_binary(V)]). > > >> > <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> > > >> > > >> V is the double returned by enif_make_double > > > > > > There are two issues here: > > > 1. the VM disallows INFs and NANs, but NIF authors may not be aware > of that > > > 2. enif_make_double() SHOULD reject non-finite doubles but it > doesn't, and > > > its documentation doesn't mention any failure modes; returning > THE_NON_VALUE > > > may not be detected as a failure by the NIF and so this non-value > may leak > > > into aggregates (lists or tuples) where it will totally break things > > > > > > When looking at this I noticed that enif_make_atom() also has > problems: it > > > may fail and return THE_NON_VALUE if the resulting atom would be too > long, > > > but the documentation doesn't mention this possibility so the NIF > might > > > continue and store this non-value in aggregates before returning. > > > > > > The OTP folks need to straighten up error handling in the > enif_make_*() > > > functions. > > > > xapplication/pgp-signature [Click mouse-2 to save to a file] > > -- > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Sun Mar 1 21:00:22 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 1 Mar 2015 21:00:22 +0100 Subject: [erlang-bugs] enif_make_double returns invalid term for 'nan' In-Reply-To: References: <21746.65501.231478.752377@gargle.gargle.HOWL> <2FAED6E0-58AB-462B-9BD0-CECC5D2E41B4@licenser.net> <21747.19861.246829.251429@gargle.gargle.HOWL> Message-ID: <21747.28630.302292.340027@gargle.gargle.HOWL> Steve Vinoski writes: > Hi Mikael, > > I don't understand your message, so perhaps I'm missing something -- the > erl_nif functions have had the ability to throw badarg for quite some time > now. Yes, at the top-level of a NIF you can indicate that the call to that NIF should fail with an Erlang-level exception, and the underlying mechanism is the same as the one for BIF calls. What I was talking about are the even lower-level enif_make_*() functions that, if you look at the current documentation, have no defined way of signalling errors. > Here's a PR that I think addresses the issues raised in this thread: > > https://github.com/erlang/otp/pull/632 Yes, well here you do introduce that possibility. Good. /Mikael > > --steve > > > On Sun, Mar 1, 2015 at 12:34 PM, Mikael Pettersson > wrote: > > > Heinz Nikolaus Gies writes: > > > Hi Mikael, > > > thank for the clarification. That makes sense, I find 2) actually more > > troublesome since I went to consult the documents to be sure it?s not a > > defined behavior. What was a bit more concerning was that that it returned > > a value that breaks transparently breaks other erlang functions. > > > > > > Perhaps simply returning a bad_arg would make a lot more sense? > > > > Erlang-level exceptions don't exist at this level of the VM. They have to > > be synthesized explicitly, and doing that requires documented protocols > > for signalling errors, and code to follow them. > > > > E.g., the interface to BIFs is such that to signal badarg, the BIF: > > 1. stores a special flag in the current process struct, and > > 2. returns THE_NON_VALUE. > > > > The caller, beam_emu.c or native code wrappers in hipe_${arch}_bifs, checks > > for THE_NON_VALUE returns and branches to the exception-raising code. > > > > The problem here is that we're in even lower-level code, and there is no > > documentation that enif_make_*() can fail, how to detect such failures, > > or what to do in response. Once this is in place, the next problem is > > to ensure that NIFs are properly updated and not just recompiled. > > > > > --- > > > Cheers, > > > Heinz Nikolaus Gies > > > heinz@REDACTED > > > > > > > > > > > > > On Mar 1, 2015, at 13:02, Mikael Pettersson > > wrote: > > > > > > > > Heinz Nikolaus Gies writes: > > > >> When enif_make_double gets a nan value passed as the double argument > > it returns a invalid term, this term can neither be printed (via the fmt*) > > functions nor can it be deserialized by binary_to_term when serializing it > > the following binary is generated: > > > >> > > > >> 6> io:format("~p~n", [term_to_binary(V)]). > > > >> > > <<131,99,110,97,110,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>> > > > >> > > > >> V is the double returned by enif_make_double > > > > > > > > There are two issues here: > > > > 1. the VM disallows INFs and NANs, but NIF authors may not be aware > > of that > > > > 2. enif_make_double() SHOULD reject non-finite doubles but it > > doesn't, and > > > > its documentation doesn't mention any failure modes; returning > > THE_NON_VALUE > > > > may not be detected as a failure by the NIF and so this non-value > > may leak > > > > into aggregates (lists or tuples) where it will totally break things > > > > > > > > When looking at this I noticed that enif_make_atom() also has > > problems: it > > > > may fail and return THE_NON_VALUE if the resulting atom would be too > > long, > > > > but the documentation doesn't mention this possibility so the NIF > > might > > > > continue and store this non-value in aggregates before returning. > > > > > > > > The OTP folks need to straighten up error handling in the > > enif_make_*() > > > > functions. > > > > > > xapplication/pgp-signature [Click mouse-2 to save to a file] > > > > -- > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- From dgud@REDACTED Tue Mar 3 17:15:03 2015 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 3 Mar 2015 17:15:03 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: I took at file:read_line issue, and thought about it :-) IMHO it should behave as file:read/2 does and how it is documented. i.e. return {error, {no_translation, unicode, latin1}} for both binary and list mode when encoding is set to unicode and reading non latin1 code points. (Which is confusing but that is how it is intended/documented, use io module for translating non latin1 codepoints). Also file:pread/[2,3], shouldn't they also behave the same as file:read/2 or am I missing something? /Dan On Thu, Jan 29, 2015 at 11:04 AM, Vlad Dumitrescu wrote: > Hi, > > I agree that it is difficult to know which functions in 'file' or 'io' to > use and if the file should be opened as unicode or not. Without reading the > docs in all detail, it's easy to assume that since file:open takes an > encoding option, the rest of the functions in the module can handle all > encodings. > > The docs say > > The rule of thumb is that the file module should be used for files opened > for bytewise access ({encoding,latin1}) and the io module should be used > when accessing files with any other encoding (e.g. {encoding,uf8}). > > > and using io:get_line/2 works, but maybe the very first step could be to > make the note above stand out more proeminently in the docs? > > Also, a simple step that can be done right away is to let file:read_line > return the same error message as firle: read: > {error,{no_translation,unicode,latin1}} which describes exactly what the > problem is. {error, collect_line} isn't even a documented error message. > > best regards, > Vlad > > > On Thu, Jan 29, 2015 at 9:14 AM, Jos? Valim < > jose.valim@REDACTED> wrote: > >> Pinging this thread for feedback. >> >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> On Fri, Jul 4, 2014 at 5:10 PM, Jos? Valim < >> jose.valim@REDACTED> 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. >>> >>> 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 >>> >> >> >> _______________________________________________ >> 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 prof3ta@REDACTED Fri Mar 6 11:51:09 2015 From: prof3ta@REDACTED (Roberto Aloi) Date: Fri, 6 Mar 2015 11:51:09 +0100 Subject: [erlang-bugs] Doc inconsistency for public_key:pem_entry_decode/2 Message-ID: Hi, according to the doc, the function expects Password::string() as the second argument: http://www.erlang.org/documentation/doc-5.9.3/lib/public_key-0.17/doc/html/public_key.html#pem_entry_decode-2 The spec for the function expects a list of strings: https://github.com/erlang/otp/blob/801b09af301a872170e44c215e274425c46f8d24/lib/public_key/src/public_key.erl#L113 This makes dialyzer sad. Incidentallly, the code seems to work ok both if you pass a string or a string wrapped into a list. -- Roberto Aloi --- Website: http://roberto-aloi.com Twitter: @robertoaloi -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ottenklinger@REDACTED Fri Mar 6 11:58:14 2015 From: magnus.ottenklinger@REDACTED (Magnus Ottenklinger) Date: Fri, 6 Mar 2015 10:58:14 +0000 Subject: [erlang-bugs] Deadlocking application_controller using init:stop/1, 2 In-Reply-To: References: <71607aa8a2fd48eb95938c1db5552c4a@DBXPR03MB511.eurprd03.prod.outlook.com> Message-ID: Hey Siri, Were you able to find a solution to the deadlocking problem? Regards, Magnus Von: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] Im Auftrag von Magnus Ottenklinger Gesendet: Freitag, 10. Oktober 2014 09:38 An: Siri Hansen Cc: erlang-bugs@REDACTED Betreff: Re: [erlang-bugs] Deadlocking application_controller using init:stop/1, 2 Hey Siri, any update on this? Regards, Magnus Von: Siri Hansen [mailto:erlangsiri@REDACTED] Gesendet: Mittwoch, 10. September 2014 16:32 An: Magnus Ottenklinger Cc: erlang-bugs@REDACTED Betreff: Re: [erlang-bugs] Deadlocking application_controller using init:stop/1, 2 Thanks for the additional information, Magnus! We will discuss this a bit more in the team before proceeding. Regards /siri 2014-09-09 11:38 GMT+02:00 Magnus Ottenklinger >: Hey Siri, sorry for taking so long to reply. Our system takes quite some time starting up (around one minute). While this is being done, multiple applications are started, each with a supervisor tree. Within those supervisor trees, processes might start other OTP applications, such as ssl. The init:stop() is sent to the VM by our /etc/init.d script. If e.g. an error is detected during the startup phase, and we want to stop the node, the described deadlock appears, rendering the system unstoppable (in a clean way). Regards, Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.dephily@REDACTED Fri Mar 6 16:23:11 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Fri, 06 Mar 2015 16:23:11 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value Message-ID: <4001292.JipqhWAsvW@moltowork> Hi, I just noticed that fail_if_no_peer_cert defaults to false. This is dangerous, as it means that just setting {verify,verify_peer} leaves you open to unauthentified connections. The current default unexpected and undocumented. It is a security hole waiting to happen (indeed, it has been present in my software for years). Thinking about it further, {fail_if_no_peer_cert,false} can only serve some very niche unusual usecases ? The docs say that it only has an impact if verify_peer is set. It could be that you want to accept (and treat differently) both authenticated and non-authenticated connections, but most users will either not need authentication (and set verify_none) or will want to authenticate every connection. The absence of a peer cert seems like a poor heuristic for deciding to accept unauthentificated connection. What if the peer has a cert you don't know about ? A better interface would be one that always lets the connection succeed, but includes authentication status in its success return. I'd argue that even explicitly setting {fail_if_no_peer_cert,false} is likely to lead to surprises and that people should instead put the logic in verify_fun or in post-handshake checks, but that's probably out of scope for a bug report. -- Vincent de Phily From huaqiao.long@REDACTED Fri Mar 6 14:19:42 2015 From: huaqiao.long@REDACTED (=?utf-8?B?SHVhcWlhbyBMb25n?=) Date: Fri, 6 Mar 2015 21:19:42 +0800 Subject: [erlang-bugs] Unknown message in httpc_manager:handle_info Message-ID: Sometimes getting this error report with httpc?: =ERROR REPORT==== 6-Mar-2015::18:26:56 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:06 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} =ERROR REPORT==== 6-Mar-2015::18:27:11 === Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? I haven't been able to figure out why it happens or who sends the erroneous message. Has anyone seen this before or know what may be causing it?? Maybe is httpc_manager have bug? Best, Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ingela.Anderton.Andin@REDACTED Tue Mar 10 14:44:26 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 10 Mar 2015 14:44:26 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value In-Reply-To: <4001292.JipqhWAsvW@moltowork> References: <4001292.JipqhWAsvW@moltowork> Message-ID: <54FEF53A.3070006@ericsson.com> Hi! On 03/06/2015 04:23 PM, Vincent de Phily wrote: > Hi, > > I just noticed that fail_if_no_peer_cert defaults to false. This is dangerous, > as it means that just setting {verify,verify_peer} leaves you open to > unauthentified connections. > > The current default unexpected and undocumented. It is a security hole waiting > to happen (indeed, it has been present in my software for years). From the documentation: "{fail_if_no_peer_cert, boolean()} Used together with {verify, verify_peer} by an ssl server. If set to true, the server will fail if the client does not have a certificate to send, i.e. sends a empty certificate, if set to false it will only fail if the client sends an invalid certificate (an empty certificate is considered valid)." > Thinking about it further, {fail_if_no_peer_cert,false} can only serve some > very niche unusual usecases ? The docs say that it only has an impact if > verify_peer is set. It could be that you want to accept (and treat > differently) both authenticated and non-authenticated connections, but most > users will either not need authentication (and set verify_none) or will want > to authenticate every connection. The behavior of fail_if_no_peer_cert is the same as in openSSL, as once up on a time the erlang ssl application was a wrapper for openSSL (which is no longer the case) but we like our backwards compatibility! > The absence of a peer cert seems like a poor heuristic for deciding to accept > unauthentificated connection. What if the peer has a cert you don't know about > ? A better interface would be one that always lets the connection succeed, but > includes authentication status in its success return. > > I'd argue that even explicitly setting {fail_if_no_peer_cert,false} is likely > to lead to surprises and that people should instead put the logic in > verify_fun or in post-handshake checks, but that's probably out of scope for a > bug report. There will always be a trade off between security and interoperability, and the application will always have to care about its configuration. Personally I am not very fond of the {fail_if_no_peer_cert, false} option. Regards Ingela From Ingela.Anderton.Andin@REDACTED Tue Mar 10 15:02:38 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 10 Mar 2015 15:02:38 +0100 Subject: [erlang-bugs] Unknown message in httpc_manager:handle_info In-Reply-To: References: Message-ID: <54FEF97E.2070906@ericsson.com> Hi! Thank you for reporting this. I have seen some strange behavior like this too while testing some other OTP applications. We will fix it for 18 if we have time otherwise it will be in the pipe to fix. Regards Ingela Erlang/OTP team - Ericsson AB On 03/06/2015 02:19 PM, Huaqiao Long wrote: > Sometimes getting this error report with httpc?: > > =ERROR REPORT==== 6-Mar-2015::18:26:56 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48384>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:06 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48409>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:06 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48433>,ok} > > > > =ERROR REPORT==== 6-Mar-2015::18:27:11 === > > Unknown message in httpc_manager:handle_info {#Ref<0.0.0.48470>,ok}? > > > I haven't been able to figure out why it happens or who sends the > erroneous message. > Has anyone seen this before or know what may be causing it?? > Maybe is httpc_manager have bug? > > Best, > Thanks > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Ingela.Anderton.Andin@REDACTED Tue Mar 10 17:20:57 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 10 Mar 2015 17:20:57 +0100 Subject: [erlang-bugs] Doc inconsistency for public_key:pem_entry_decode/2 In-Reply-To: References: Message-ID: <54FF19E9.9020106@ericsson.com> Hi! I changed the spec, it should be a string. Regards Ingela Erlang/OTP team - Ericsson AB On 03/06/2015 11:51 AM, Roberto Aloi wrote: > Hi, > > according to the doc, the function expects Password::string() as the > second argument: > > http://www.erlang.org/documentation/doc-5.9.3/lib/public_key-0.17/doc/html/public_key.html#pem_entry_decode-2 > > The spec for the function expects a list of strings: > > https://github.com/erlang/otp/blob/801b09af301a872170e44c215e274425c46f8d24/lib/public_key/src/public_key.erl#L113 > > This makes dialyzer sad. Incidentallly, the code seems to work ok both > if you pass a string or a string wrapped into a list. > > -- > Roberto Aloi > --- > Website: http://roberto-aloi.com > Twitter: @robertoaloi > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From vincent.dephily@REDACTED Tue Mar 10 18:15:08 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Tue, 10 Mar 2015 18:15:08 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value In-Reply-To: <54FEF53A.3070006@ericsson.com> References: <4001292.JipqhWAsvW@moltowork> <54FEF53A.3070006@ericsson.com> Message-ID: <1984418.mQH2RTTGKb@moltowork> Hi Ingela, On Tuesday 10 March 2015 14:44:26 Ingela Anderton Andin wrote: > From the documentation: > > "{fail_if_no_peer_cert, boolean()} > Used together with {verify, verify_peer} by an ssl server. If set to > true, the server will fail if the client does not have a certificate to > send, i.e. sends a empty certificate, if set to false it will only fail > if the client sends an invalid certificate (an empty certificate is > considered valid)." Yes, but it doesn't say what the default is. Not documenting the default values is bad enough in general, but if that default is the wrong value for 99% of usecases, the documentation should warn loudly about it. > The behavior of fail_if_no_peer_cert is the same as in openSSL, as once > up on a time the erlang ssl application was a wrapper for openSSL > (which is no longer the case) but we like our backwards compatibility! OpenSSL is notorious for its bad API design. I know that Erlang ssl used to be a wrapper around openssl, but that doesn't mean that it can't evolve towards something saner. In f_i_n_p_c's case, changing the default would probably close more bugs than it'd open. Importantly, the new bugs would cause a visible failure, rather than the invisible security hole caused by the current bugs. It'll be an annoyance for the minority of people who actually need f_i_n_p_c=false, but it's a clear win overall. I even think that f_i_n_p_c should be completely deprecated, since it's niche behavior can be obtained with a custom verify_fun. But it seems like I'd have a hard time convincing you about that :p Speaking of liking backward compatibility, I'm still hoping for a reply by the OTP team to my last two emails (2015-02-19, 2015-02-20) about the 17.3 partial_chain breakage ;) > There will always be a trade off between security and interoperability, > and the application will always have to care about its configuration. > Personally I am not very fond of the {fail_if_no_peer_cert, false} option. Glad we agree on that. If you do nothing else, please at least document f_i_n_p_c's default value. -- Vincent de Phily From kostis@REDACTED Tue Mar 10 18:50:29 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 10 Mar 2015 18:50:29 +0100 Subject: [erlang-bugs] Doc inconsistency for public_key:pem_entry_decode/2 In-Reply-To: References: Message-ID: <54FF2EE5.5030306@cs.ntua.gr> On 03/06/2015 11:51 AM, Roberto Aloi wrote: > Hi, > > according to the doc, the function expects Password::string() as the > second argument: > > http://www.erlang.org/documentation/doc-5.9.3/lib/public_key-0.17/doc/html/public_key.html#pem_entry_decode-2 > > The spec for the function expects a list of strings: > > https://github.com/erlang/otp/blob/801b09af301a872170e44c215e274425c46f8d24/lib/public_key/src/public_key.erl#L113 > > This makes dialyzer sad. ... and specs like the one in the link make me even sadder. The spec there reads: -spec pem_entry_decode(pem_entry(), [string()]) -> term(). This spec also has the problem that this function clearly does not return any term(), but something more specific than that. Why not document that in the spec so that the callers of this function know what to expect? (If hiding this information is intentional, simply declare this data type as opaque.) More importantly, is there (still) any good reason why discrepancies between the specs and the published documentation differ, instead of having the documentation generated directly from the specs? Kostis From Ingela.Anderton.Andin@REDACTED Tue Mar 10 19:35:28 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Tue, 10 Mar 2015 19:35:28 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value In-Reply-To: <1984418.mQH2RTTGKb@moltowork> References: <4001292.JipqhWAsvW@moltowork> <54FEF53A.3070006@ericsson.com> <1984418.mQH2RTTGKb@moltowork> Message-ID: <54FF3970.6030607@ericsson.com> Hi! On 03/10/2015 06:15 PM, Vincent de Phily wrote: > Hi Ingela, > > On Tuesday 10 March 2015 14:44:26 Ingela Anderton Andin wrote: >> From the documentation: >> >> "{fail_if_no_peer_cert, boolean()} >> Used together with {verify, verify_peer} by an ssl server. If set to >> true, the server will fail if the client does not have a certificate to >> send, i.e. sends a empty certificate, if set to false it will only fail >> if the client sends an invalid certificate (an empty certificate is >> considered valid)." > > Yes, but it doesn't say what the default is. Not documenting the default > values is bad enough in general, but if that default is the wrong value for > 99% of usecases, the documentation should warn loudly about it. You have a point there. >> The behavior of fail_if_no_peer_cert is the same as in openSSL, as once >> up on a time the erlang ssl application was a wrapper for openSSL >> (which is no longer the case) but we like our backwards compatibility! > > OpenSSL is notorious for its bad API design. I know that Erlang ssl used to be > a wrapper around openssl, but that doesn't mean that it can't evolve towards > something saner. Sure, I am not disagreeing we have already made other such changes. Just saying we need good reasons to. > In f_i_n_p_c's case, changing the default would probably close more bugs than > it'd open. Importantly, the new bugs would cause a visible failure, rather > than the invisible security hole caused by the current bugs. It'll be an > annoyance for the minority of people who actually need f_i_n_p_c=false, but > it's a clear win overall. > > I even think that f_i_n_p_c should be completely deprecated, since it's niche > behavior can be obtained with a custom verify_fun. But it seems like I'd have > a hard time convincing you about that :p We will think about it. It is not entirely up to me, but my opinion will count. > Speaking of liking backward compatibility, I'm still hoping for a reply by the > OTP team to my last two emails (2015-02-19, 2015-02-20) about the 17.3 > partial_chain breakage ;) I am not quite sure I agree that it is a breakage! We do not like to be bug compatible! It is on my todo list! >> There will always be a trade off between security and interoperability, >> and the application will always have to care about its configuration. >> Personally I am not very fond of the {fail_if_no_peer_cert, false} option. > > Glad we agree on that. If you do nothing else, please at least document > f_i_n_p_c's default value. > If nothing else is done, I promise to do that. Regards Ingela Erlang/OTP team - Ericsson AB From vincent.dephily@REDACTED Wed Mar 11 12:15:51 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Wed, 11 Mar 2015 12:15:51 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value In-Reply-To: <54FF3970.6030607@ericsson.com> References: <4001292.JipqhWAsvW@moltowork> <1984418.mQH2RTTGKb@moltowork> <54FF3970.6030607@ericsson.com> Message-ID: <1469496.YeGSKO4vTO@moltowork> On Tuesday 10 March 2015 19:35:28 Ingela Anderton Andin wrote: > > In f_i_n_p_c's case, changing the default would probably close more bugs > > than it'd open. Importantly, the new bugs would cause a visible failure, > > rather than the invisible security hole caused by the current bugs. It'll > > be an annoyance for the minority of people who actually need > > f_i_n_p_c=false, but it's a clear win overall. > > > > I even think that f_i_n_p_c should be completely deprecated, since it's > > niche behavior can be obtained with a custom verify_fun. But it seems > > like I'd have a hard time convincing you about that :p > > We will think about it. It is not entirely up to me, but my opinion will > count. Thanks, I hope I provided a good enough argument that the change is worth the potential incompatibility. > > Speaking of liking backward compatibility, I'm still hoping for a reply by > > the OTP team to my last two emails (2015-02-19, 2015-02-20) about the > > 17.3 partial_chain breakage ;) > > I am not quite sure I agree that it is a breakage! We do not like to be > bug compatible! It is on my todo list! Well my usecase was broken by it. I'm still open to an explanation that my usecase was broken to begin with, but I think that it is very reasonable. On the plus side, it got me to do a thorough code review and improve our unit testing :) Note that I'm not against changes, introcucing partial_chain is certainly usefull. But beyond the docs that could be improved, something still doesn't feel quite right. Maybe it's again a matter of default setting, we should have a require_full_cert_chain option ? IMHO the ssl options need a good bit of disentangleing, but it's hard to do without bringing incompatibilities. -- Vincent de Phily From vincent.dephily@REDACTED Wed Mar 11 13:31:34 2015 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Wed, 11 Mar 2015 13:31:34 +0100 Subject: [erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value In-Reply-To: <1469496.YeGSKO4vTO@moltowork> References: <4001292.JipqhWAsvW@moltowork> <54FF3970.6030607@ericsson.com> <1469496.YeGSKO4vTO@moltowork> Message-ID: <2669416.bbodvexb5K@moltowork> On Wednesday 11 March 2015 12:15:51 Vincent de Phily wrote: > On Tuesday 10 March 2015 19:35:28 Ingela Anderton Andin wrote: > > > In f_i_n_p_c's case, changing the default would probably close more bugs > > > than it'd open. Importantly, the new bugs would cause a visible failure, > > > rather than the invisible security hole caused by the current bugs. > > > It'll > > > be an annoyance for the minority of people who actually need > > > f_i_n_p_c=false, but it's a clear win overall. > > > > > > I even think that f_i_n_p_c should be completely deprecated, since it's > > > niche behavior can be obtained with a custom verify_fun. But it seems > > > like I'd have a hard time convincing you about that :p > > > > We will think about it. It is not entirely up to me, but my opinion will > > count. > > Thanks, I hope I provided a good enough argument that the change is worth > the potential incompatibility. I did a web search on explicit use of f_i_n_p_c in other projects and was surprised at how often it was set to false instead of true, to the point that I wonder wether I don't understand the option correctly, or wether users don't understand the implications. My understanding is this: * If you want to authenticate the peer (as opposed to just encrypting the communication), you set verify_peer. Connection to a peer that fails authentification will be refused. * You then have the option, using f_i_n_p_c=false, to nevertheless accept the connection for a specific case of auth failure (peer didn't send a cert). * This only makes sense if you have a fallback method to authenticate the peer. Authenticate using ssl certs orelse authenticate using account passwords, for example. An authentication that can be trivially bypassed (by not sending a cert) might as well not be done at all. Is that understanding correct, or is there a usecase of f_i_n_p_c=false where you don't require an alternate authentication method once the ssl authentication has failed ? Can you point at projects that use f_i_n_p_c=false properly ? -- Vincent de Phily From heinz@REDACTED Wed Mar 11 16:53:00 2015 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Wed, 11 Mar 2015 16:53:00 +0100 Subject: [erlang-bugs] port_info crashes when called concurrently by two processes Message-ID: <47020409-74B5-497A-B699-373E1DB7813F@licenser.net> Hi there is a problem with port_info it segfaults the erlang VM when two processes are executing it in parallel. We?ve been tracking this for the last two days and condensed the a crashing test down to this: https://gist.github.com/Licenser/41a7ffe5ca52f57a169c Ryan has some crash dumps: fffffd7ff6406670 collect_heap_frags.isra.7+0x90() fffffd7ff6406ba0 erts_garbage_collect+0x28f() fffffd7ff6406bd0 erts_gc_after_bif_call+0xa4() fffffd7ff6406f10 process_main+0x45da() fffffd7ff6406f70 sched_thread_func+0xef() fffffd7ff6406fb0 thr_wrapper+0x73() fffffd7ff6406fe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a5a40) fffffd7ff6406ff0 libc.so.1`_lwp_start() fffffd7ff6207af0 copy_struct+0xb5() fffffd7ff6207ba0 erts_port_info+0x292() fffffd7ff6207bd0 erts_internal_port_info_1+0xeb() fffffd7ff6207f10 process_main+0x45a9() fffffd7ff6207f70 sched_thread_func+0xef() fffffd7ff6207fb0 thr_wrapper+0x73() fffffd7ff6207fe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a6240) fffffd7ff6207ff0 libc.so.1`_lwp_start() fffffd7ff73fe670 sweep_one_area+0x58() fffffd7ff73feba0 erts_garbage_collect+0x985() fffffd7ff73febd0 erts_gc_after_bif_call+0xa4() fffffd7ff73fef10 process_main+0x45da() fffffd7ff73fef70 sched_thread_func+0xef() fffffd7ff73fefb0 thr_wrapper+0x73() fffffd7ff73fefe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a1a40) fffffd7ff73feff0 libc.so.1`_lwp_start() ``` rzezeski [14:46] this produces a segfault instantly after running arg:run(2) tested with: R16B02 (SmartOS) R16B03 (OS X) R17B03 (by Darach) --- Cheers, Heinz Nikolaus Gies heinz@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From heinz@REDACTED Wed Mar 11 19:12:28 2015 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Wed, 11 Mar 2015 19:12:28 +0100 Subject: [erlang-bugs] port_info crashes when called concurrently by two processes In-Reply-To: References: <47020409-74B5-497A-B699-373E1DB7813F@licenser.net> Message-ID: Adding more information, this is related to SMP, if starting the erlang VM with -smp disable it does not crash. --- Cheers, Heinz Nikolaus Gies heinz@REDACTED > On Mar 11, 2015, at 17:15, Ryan Zezeski wrote: > > > > On Wed, Mar 11, 2015 at 11:53 AM, Heinz Nikolaus Gies > wrote: > Hi there is a problem with port_info it segfaults the erlang VM when two processes are executing it in parallel. We?ve been tracking this for the last two days and condensed the a crashing test down to this: > > https://gist.github.com/Licenser/41a7ffe5ca52f57a169c > > Ryan has some crash dumps: > > fffffd7ff6406670 collect_heap_frags.isra.7+0x90() > fffffd7ff6406ba0 erts_garbage_collect+0x28f() > fffffd7ff6406bd0 erts_gc_after_bif_call+0xa4() > fffffd7ff6406f10 process_main+0x45da() > fffffd7ff6406f70 sched_thread_func+0xef() > fffffd7ff6406fb0 thr_wrapper+0x73() > fffffd7ff6406fe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a5a40) > fffffd7ff6406ff0 libc.so.1`_lwp_start() > fffffd7ff6207af0 copy_struct+0xb5() > fffffd7ff6207ba0 erts_port_info+0x292() > fffffd7ff6207bd0 erts_internal_port_info_1+0xeb() > fffffd7ff6207f10 process_main+0x45a9() > fffffd7ff6207f70 sched_thread_func+0xef() > fffffd7ff6207fb0 thr_wrapper+0x73() > fffffd7ff6207fe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a6240) > fffffd7ff6207ff0 libc.so.1`_lwp_start() > fffffd7ff73fe670 sweep_one_area+0x58() > fffffd7ff73feba0 erts_garbage_collect+0x985() > fffffd7ff73febd0 erts_gc_after_bif_call+0xa4() > fffffd7ff73fef10 process_main+0x45da() > fffffd7ff73fef70 sched_thread_func+0xef() > fffffd7ff73fefb0 thr_wrapper+0x73() > fffffd7ff73fefe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffd2a1a40) > fffffd7ff73feff0 libc.so.1`_lwp_start() > ``` > > zezeski [14:4 > ? > > > > ?Just to give more information: here's some info from a crash dump of the simple reproducer Heinz linked above. I simply used the chunter erl (16B02) to run this program, the chunter application is not actually running. > > This is the situation we see most often but occasionally I've seen the copy.c `copy_struct` function try to reference an address that is _above_ the stack, i.e. not even legal. > > > ::status > debugging core file of beam.smp (64-bit) from sys76 > file: /opt/chunter/erts-5.10.3/bin/beam.smp > initial argv: /opt/chunter/erts-5.10.3/bin/beam.smp -- -root /opt/chunter -progname erl -- -h > threading model: native threads > status: process terminated by SIGSEGV (Segmentation Fault), addr=fffffd7ffc540000 > > > $C > fffffd7ff8805670 collect_heap_frags.isra.7+0x95() > fffffd7ff8805ba0 erts_garbage_collect+0x115c() > fffffd7ff8805bd0 erts_gc_after_bif_call+0xa4() > fffffd7ff8805f10 process_main+0x45da() > fffffd7ff8805f70 sched_thread_func+0xef() > fffffd7ff8805fb0 thr_wrapper+0x73() > fffffd7ff8805fe0 libc.so.1`_thrp_setup+0x8a(fffffd7ffee6a240) > fffffd7ff8805ff0 libc.so.1`_lwp_start() > > > ::stacks > THREAD STATE SOBJ COUNT > 4 PARKED CV 10 > libc.so.1`cond_wait_queue+0x5b > libc.so.1`__cond_wait+0xb3 > libc.so.1`cond_wait+0x2a > libc.so.1`pthread_cond_wait+0x15 > ethr_event_wait+0x63 > async_main+0x275 > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > f PARKED CV 9 > libc.so.1`cond_wait_queue+0x5b > libc.so.1`__cond_wait+0xb3 > libc.so.1`cond_wait+0x2a > libc.so.1`pthread_cond_wait+0x15 > ethr_event_wait+0x63 > schedule+0x220d > process_main+0x143 > sched_thread_func+0xef > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 16 UNPARKED 1 > erts_garbage_collect+0x115c > erts_gc_after_bif_call+0xa4 > process_main+0x45da > sched_thread_func+0xef > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 17 UNPARKED 1 > libc.so.1`mutex_lock_impl+0x189 > libc.so.1`mutex_lock+0x13 > spawn_start+0x46c > erts_open_driver+0x21e > open_port+0xa52 > open_port_2+0x2d > process_main+0x45a9 > sched_thread_func+0xef > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 1 UNPARKED 1 > libc.so.1`pselect+0x1cb > libc.so.1`select+0x5a > erts_sys_main_thread+0x20 > erl_start+0xcfe > main+9 > _start+0x6c > > e UNPARKED 1 > libc.so.1`waitpid+0x3b > child_waiter+0x30 > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 2 UNPARKED 1 > signal_dispatcher_thread_func+0x29 > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 15 UNPARKED 1 > spawn_start+0x60b > erts_open_driver+0x21e > open_port+0xa52 > open_port_2+0x2d > process_main+0x45a9 > sched_thread_func+0xef > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 3 PARKED CV 1 > libc.so.1`cond_wait_queue+0x5b > libc.so.1`__cond_wait+0xb3 > libc.so.1`cond_wait+0x2a > libc.so.1`pthread_cond_wait+0x15 > ethr_cond_wait+9 > sys_msg_dispatcher_func+0xdf > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start > > 1b PARKED CV 1 > libc.so.1`cond_wait_queue+0x5b > libc.so.1`__cond_wait+0xb3 > libc.so.1`cond_wait+0x2a > libc.so.1`pthread_cond_wait+0x15 > ethr_event_wait+0x63 > aux_thread+0x1cd > thr_wrapper+0x73 > libc.so.1`_thrp_setup+0x8a > libc.so.1`_lwp_start? > > > ?And finally here's the VA space mapping: > > # pmap /cores/core.beam.smp.92077 > core '/cores/core.beam.smp.92077' of 92077: /opt/chunter/erts-5.10.3/bin/beam.smp -- -root /opt/chunter -progname > 0000000000400000 2652K r-x-- /opt/chunter/erts-5.10.3/bin/beam.smp > 00000000006A6000 296K rw--- /opt/chunter/erts-5.10.3/bin/beam.smp > 00000000006F0000 1276K rw--- [ heap ] > FFFFFD7FF6000000 2560K rw--- [ anon ] > FFFFFD7FF6A00000 8192K rw--- [ anon ] > FFFFFD7FF72C0000 1024K rw--- [ anon ] > FFFFFD7FF7A00000 1024K rw--- [ anon ] > FFFFFD7FF7E0A000 4K rw--- [ stack tid=27 ] > FFFFFD7FF8009000 4K rw--- [ stack tid=26 ] > FFFFFD7FF8208000 4K rw--- [ stack tid=25 ] > FFFFFD7FF8407000 4K rw--- [ stack tid=24 ] > FFFFFD7FF85FB000 8K rw--- [ anon ] > FFFFFD7FF8604000 12K rw--- [ stack tid=23 ] > FFFFFD7FF8804000 8K rw--- [ stack tid=22 ] > FFFFFD7FF8A03000 8K rw--- [ stack tid=21 ] > FFFFFD7FF8C02000 8K rw--- [ stack tid=20 ] > FFFFFD7FF8E02000 4K rw--- [ stack tid=19 ] > FFFFFD7FF9001000 4K rw--- [ stack tid=18 ] > FFFFFD7FF9200000 4K rw--- [ stack tid=17 ] > FFFFFD7FF93FF000 4K rw--- [ stack tid=16 ] > FFFFFD7FF95FE000 4K rw--- [ stack tid=15 ] > FFFFFD7FF9600000 4096K rw--- [ anon ] > FFFFFD7FF9AC0000 256K rw--- [ anon ] > FFFFFD7FF9C00000 4096K rw--- [ anon ] > FFFFFD7FFA1FE000 4K rw--- [ stack tid=3 ] > FFFFFD7FFA200000 2048K rw--- [ anon ] > FFFFFD7FFA4C0000 256K rw--- [ anon ] > FFFFFD7FFA540000 1024K rw--- [ anon ] > FFFFFD7FFA83E000 4K rw--- [ stack tid=2 ] > FFFFFD7FFA840000 512K rw--- [ anon ] > FFFFFD7FFA900000 256K rw--- [ anon ] > FFFFFD7FFA980000 256K rw--- [ anon ] > FFFFFD7FFAA00000 256K rw--- [ anon ] > FFFFFD7FFAA80000 256K rw--- [ anon ] > FFFFFD7FFAB00000 256K rw--- [ anon ] > FFFFFD7FFAB80000 256K rw--- [ anon ] > FFFFFD7FFAC00000 256K rw--- [ anon ] > FFFFFD7FFAC80000 256K rw--- [ anon ] > FFFFFD7FFAD00000 256K rw--- [ anon ] > FFFFFD7FFAD80000 256K rw--- [ anon ] > FFFFFD7FFAE00000 256K rw--- [ anon ] > FFFFFD7FFAE80000 256K rw--- [ anon ] > FFFFFD7FFAF00000 256K rw--- [ anon ] > FFFFFD7FFAF80000 256K rw--- [ anon ] > FFFFFD7FFB000000 256K rw--- [ anon ] > FFFFFD7FFB080000 256K rw--- [ anon ] > FFFFFD7FFB100000 256K rw--- [ anon ] > FFFFFD7FFB180000 256K rw--- [ anon ] > FFFFFD7FFB200000 256K rw--- [ anon ] > FFFFFD7FFB280000 256K rw--- [ anon ] > FFFFFD7FFB300000 256K rw--- [ anon ] > FFFFFD7FFB380000 256K rw--- [ anon ] > FFFFFD7FFB400000 256K rw--- [ anon ] > FFFFFD7FFB480000 256K rw--- [ anon ] > FFFFFD7FFB500000 256K rw--- [ anon ] > FFFFFD7FFB580000 256K rw--- [ anon ] > FFFFFD7FFB600000 256K rw--- [ anon ] > FFFFFD7FFB680000 256K rw--- [ anon ] > FFFFFD7FFB700000 256K rw--- [ anon ] > FFFFFD7FFB780000 256K rw--- [ anon ] > FFFFFD7FFB800000 256K rw--- [ anon ] > FFFFFD7FFB880000 256K rw--- [ anon ] > FFFFFD7FFB900000 256K rw--- [ anon ] > FFFFFD7FFB980000 256K rw--- [ anon ] > FFFFFD7FFBA00000 256K rw--- [ anon ] > FFFFFD7FFBA80000 256K rw--- [ anon ] > FFFFFD7FFBB00000 256K rw--- [ anon ] > FFFFFD7FFBB80000 256K rw--- [ anon ] > FFFFFD7FFBC00000 256K rw--- [ anon ] > FFFFFD7FFBC80000 256K rw--- [ anon ] > FFFFFD7FFBD00000 256K rw--- [ anon ] > FFFFFD7FFBD80000 256K rw--- [ anon ] > FFFFFD7FFBE00000 256K rw--- [ anon ] > FFFFFD7FFBE80000 256K rw--- [ anon ] > FFFFFD7FFBF00000 256K rw--- [ anon ] > FFFFFD7FFBF80000 256K rw--- [ anon ] > FFFFFD7FFC000000 256K rw--- [ anon ] > FFFFFD7FFC080000 256K rw--- [ anon ] > FFFFFD7FFC100000 256K rw--- [ anon ] > FFFFFD7FFC180000 256K rw--- [ anon ] > FFFFFD7FFC200000 256K rw--- [ anon ] > FFFFFD7FFC280000 256K rw--- [ anon ] > FFFFFD7FFC300000 256K rw--- [ anon ] > FFFFFD7FFC380000 256K rw--- [ anon ] > FFFFFD7FFC400000 256K rw--- [ anon ] > FFFFFD7FFC480000 256K rw--- [ anon ] > FFFFFD7FFC500000 256K rw--- [ anon ] > FFFFFD7FFC580000 256K rw--- [ anon ] > FFFFFD7FFC600000 256K rw--- [ anon ] > FFFFFD7FFC680000 256K rw--- [ anon ] > FFFFFD7FFC700000 256K rw--- [ anon ] > FFFFFD7FFC780000 256K rw--- [ anon ] > FFFFFD7FFC800000 4096K rw--- [ anon ] > FFFFFD7FFCC40000 256K rw--- [ anon ] > FFFFFD7FFCCC0000 256K rw--- [ anon ] > FFFFFD7FFCD40000 256K rw--- [ anon ] > FFFFFD7FFCDC0000 256K rw--- [ anon ] > FFFFFD7FFCE40000 256K rw--- [ anon ] > FFFFFD7FFCEC0000 256K rw--- [ anon ] > FFFFFD7FFCF40000 256K rw--- [ anon ] > FFFFFD7FFCFC0000 256K rw--- [ anon ] > FFFFFD7FFD040000 256K rw--- [ anon ] > FFFFFD7FFD0C0000 256K rw--- [ anon ] > FFFFFD7FFD140000 256K rw--- [ anon ] > FFFFFD7FFD1C0000 256K rw--- [ anon ] > FFFFFD7FFD240000 256K rw--- [ anon ] > FFFFFD7FFD2C0000 256K rw--- [ anon ] > FFFFFD7FFD340000 256K rw--- [ anon ] > FFFFFD7FFD3C0000 256K rw--- [ anon ] > FFFFFD7FFD440000 256K rw--- [ anon ] > FFFFFD7FFD4C0000 256K rw--- [ anon ] > FFFFFD7FFD540000 256K rw--- [ anon ] > FFFFFD7FFD5C0000 256K rw--- [ anon ] > FFFFFD7FFD640000 256K rw--- [ anon ] > FFFFFD7FFD6C0000 256K rw--- [ anon ] > FFFFFD7FFD740000 256K rw--- [ anon ] > FFFFFD7FFD7C0000 1024K rw--- [ anon ] > FFFFFD7FFD900000 1024K rw--- [ anon ] > FFFFFD7FFDA40000 1024K rw--- [ anon ] > FFFFFD7FFDB80000 1024K rw--- [ anon ] > FFFFFD7FFDCC0000 1024K rw--- [ anon ] > FFFFFD7FFDE00000 1024K rw--- [ anon ] > FFFFFD7FFDF40000 1024K rw--- [ anon ] > FFFFFD7FFE080000 1024K rw--- [ anon ] > FFFFFD7FFE1C0000 1024K rw--- [ anon ] > FFFFFD7FFE2D0000 352K r-x-- /usr/gnu/lib/amd64/libncurses.so.5.7 > FFFFFD7FFE337000 20K rw--- /usr/gnu/lib/amd64/libncurses.so.5.7 > FFFFFD7FFE340000 32K r-x-- /lib/amd64/librtld_db.so.1 > FFFFFD7FFE358000 4K rw--- /lib/amd64/librtld_db.so.1 > FFFFFD7FFE380000 580K r-x-- /usr/lib/amd64/libdtrace.so.1 > FFFFFD7FFE421000 84K rw--- /usr/lib/amd64/libdtrace.so.1 > FFFFFD7FFE436000 12K rw--- /usr/lib/amd64/libdtrace.so.1 > FFFFFD7FFE440000 4K r-x-- /lib/amd64/libsendfile.so.1 > FFFFFD7FFE451000 4K rw--- /lib/amd64/libsendfile.so.1 > FFFFFD7FFE480000 256K rw--- [ anon ] > FFFFFD7FFE500000 1024K rw--- [ anon ] > FFFFFD7FFE630000 8K r-x-- /lib/amd64/libkstat.so.1 > FFFFFD7FFE642000 4K rw--- /lib/amd64/libkstat.so.1 > FFFFFD7FFE680000 256K rw--- [ anon ] > FFFFFD7FFE6E0000 20K r-x-- /lib/amd64/libmp.so.2 > FFFFFD7FFE6F5000 4K rw--- /lib/amd64/libmp.so.2 > FFFFFD7FFE700000 60K r-x-- /usr/lib/amd64/libgcc_s.so.1 > FFFFFD7FFE71E000 4K rw--- /usr/lib/amd64/libgcc_s.so.1 > FFFFFD7FFE71F000 4K r-x-- /lib/amd64/libdl.so.1 > FFFFFD7FFE730000 4K rwx-- [ anon ] > FFFFFD7FFE740000 32K r-x-- /lib/amd64/libmd.so.1 > FFFFFD7FFE758000 4K rw--- /lib/amd64/libmd.so.1 > FFFFFD7FFE760000 8K r-x-- /usr/lib/amd64/libsctp.so.1 > FFFFFD7FFE772000 4K rw--- /usr/lib/amd64/libsctp.so.1 > FFFFFD7FFE780000 1024K rw--- [ anon ] > FFFFFD7FFE8BE000 4K rw--- [ stack tid=13 ] > FFFFFD7FFE8C0000 1024K rw--- [ anon ] > FFFFFD7FFE9EB000 4K rw--- [ stack tid=12 ] > FFFFFD7FFE9ED000 12K r-x-- /lib/amd64/libpthread.so.1 > FFFFFD7FFEA1B000 4K rw--- [ stack tid=11 ] > FFFFFD7FFEA3E000 4K rw--- [ stack tid=10 ] > FFFFFD7FFEA40000 28K r-x-- /lib/amd64/libdlpi.so.1 > FFFFFD7FFEA57000 4K rw--- /lib/amd64/libdlpi.so.1 > FFFFFD7FFEA60000 68K r-x-- /lib/amd64/libsocket.so.1 > FFFFFD7FFEA81000 4K rw--- /lib/amd64/libsocket.so.1 > FFFFFD7FFEABE000 4K rw--- [ stack tid=9 ] > FFFFFD7FFEAC0000 1024K rw--- [ anon ] > FFFFFD7FFEBE0000 476K r-x-- /lib/amd64/libumem.so.1 > FFFFFD7FFEC66000 4K rwx-- /lib/amd64/libumem.so.1 > FFFFFD7FFEC77000 144K rw--- /lib/amd64/libumem.so.1 > FFFFFD7FFEC9B000 44K rw--- /lib/amd64/libumem.so.1 > FFFFFD7FFECC0000 4K rwx-- [ anon ] > FFFFFD7FFECEB000 4K rw--- [ stack tid=8 ] > FFFFFD7FFED0E000 4K rw--- [ stack tid=7 ] > FFFFFD7FFED10000 532K r-x-- /lib/amd64/libnsl.so.1 > FFFFFD7FFEDA5000 12K rw--- /lib/amd64/libnsl.so.1 > FFFFFD7FFEDA8000 32K rw--- /lib/amd64/libnsl.so.1 > FFFFFD7FFEDDB000 4K rw--- [ stack tid=6 ] > FFFFFD7FFEDFE000 4K rw--- [ stack tid=5 ] > FFFFFD7FFEE00000 256K rw--- [ anon ] > FFFFFD7FFEE50000 4K rwx-- [ anon ] > FFFFFD7FFEE60000 64K rwx-- [ anon ] > FFFFFD7FFEE80000 256K rw--- [ anon ] > FFFFFD7FFEED5000 4K rw--- [ stack tid=14 ] > FFFFFD7FFEEE0000 396K r-x-- /lib/amd64/libm.so.2 > FFFFFD7FFEF53000 8K rw--- /lib/amd64/libm.so.2 > FFFFFD7FFEF7E000 4K rw--- [ stack tid=4 ] > FFFFFD7FFEF80000 256K rw--- [ anon ] > FFFFFD7FFEFD0000 4K r----* [ anon ] > FFFFFD7FFEFE0000 64K rw--- [ anon ] > FFFFFD7FFF000000 256K rw--- [ anon ] > FFFFFD7FFF052000 128K rw--- [ anon ] > FFFFFD7FFF073000 4K rwx-- [ anon ] > FFFFFD7FFF080000 64K rwx-- [ anon ] > FFFFFD7FFF0A0000 4K rwx-- [ anon ] > FFFFFD7FFF0B0000 24K rwx-- [ anon ] > FFFFFD7FFF0C0000 4K rwx-- [ anon ] > FFFFFD7FFF0D0000 4K rwx-- [ anon ] > FFFFFD7FFF0E0000 1516K r-x-- /lib/amd64/libc.so.1 > FFFFFD7FFF26B000 44K rw--- /lib/amd64/libc.so.1 > FFFFFD7FFF276000 16K rw--- /lib/amd64/libc.so.1 > FFFFFD7FFF280000 4K rw--- [ anon ] > FFFFFD7FFF290000 4K rwx-- [ anon ] > FFFFFD7FFF2A0000 4K rwx-- [ anon ] > FFFFFD7FFF2B0000 4K rw--- [ anon ] > FFFFFD7FFF2C0000 4K rwx-- [ anon ] > FFFFFD7FFF2D0000 4K rwx-- [ anon ] > FFFFFD7FFF2E0000 4K rwx-- [ anon ] > FFFFFD7FFF2F0000 4K rwx-- [ anon ] > FFFFFD7FFF300000 4K rwx-- [ anon ] > FFFFFD7FFF310000 4K rwx-- [ anon ] > FFFFFD7FFF320000 4K rwx-- [ anon ] > FFFFFD7FFF330000 4K rwx-- [ anon ] > FFFFFD7FFF340000 4K rwx-- [ anon ] > FFFFFD7FFF350000 4K rwx-- [ anon ] > FFFFFD7FFF360000 4K rw--- [ anon ] > FFFFFD7FFF370000 4K rw--- [ anon ] > FFFFFD7FFF380000 4K rwx-- [ anon ] > FFFFFD7FFF390000 4K rwx-- [ anon ] > FFFFFD7FFF398000 332K r-x-- /lib/amd64/ld.so.1 > FFFFFD7FFF3FB000 8K rwx-- /lib/amd64/ld.so.1 > FFFFFD7FFF3FD000 8K rwx-- /lib/amd64/ld.so.1 > FFFFFD7FFFDFD000 12K rw--- [ stack ] > total 75540K > > ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From n.oxyde@REDACTED Thu Mar 12 16:00:15 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 16:00:15 +0100 Subject: [erlang-bugs] port_info crashes when called concurrently by two processes In-Reply-To: References: <47020409-74B5-497A-B699-373E1DB7813F@licenser.net> Message-ID: Le 11 mars 2015 ? 19:12, Heinz Nikolaus Gies a ?crit : > Adding more information, > this is related to SMP, if starting the erlang VM with -smp disable it does not crash. Looked at it, the code uses static variables and that looks quite wrong. https://github.com/erlang/otp/blob/36576d7de20e4e8cb7b3943cfe1b7e272b5e3971/erts/emulator/beam/io.c#L4484-4485 From n.oxyde@REDACTED Thu Mar 12 16:05:20 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 16:05:20 +0100 Subject: [erlang-bugs] port_info crashes when called concurrently by two processes In-Reply-To: References: <47020409-74B5-497A-B699-373E1DB7813F@licenser.net> Message-ID: <6C7A921E-9973-405B-85A7-71E9647CC2AE@gmail.com> Le 12 mars 2015 ? 16:00, Anthony Ramine a ?crit : > Le 11 mars 2015 ? 19:12, Heinz Nikolaus Gies a ?crit : > >> Adding more information, >> this is related to SMP, if starting the erlang VM with -smp disable it does not crash. > > Looked at it, the code uses static variables and that looks quite wrong. > > https://github.com/erlang/otp/blob/36576d7de20e4e8cb7b3943cfe1b7e272b5e3971/erts/emulator/beam/io.c#L4484-4485 Removing static makes your test case not crash. I made a pull request: https://github.com/erlang/otp/pull/643 From n.oxyde@REDACTED Thu Mar 12 23:33:25 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Mar 2015 23:33:25 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: Le 3 mars 2015 ? 17:15, Dan Gudmundsson a ?crit : > I took at file:read_line issue, and thought about it :-) > > IMHO it should behave as file:read/2 does and how it is documented. > i.e. return {error, {no_translation, unicode, latin1}} for both binary and list mode > when encoding is set to unicode and reading non latin1 code points. > (Which is confusing but that is how it is intended/documented, > use io module for translating non latin1 codepoints). The problem is that file uses io in read/2 itself, calling io:request/2, which ultimately invariably converts the response to Unicode. From dgud@REDACTED Fri Mar 13 06:51:35 2015 From: dgud@REDACTED (Dan Gudmundsson) Date: Fri, 13 Mar 2015 06:51:35 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: This should be fixed on master now. /Dan On Thu, Mar 12, 2015 at 11:33 PM, Anthony Ramine wrote: > Le 3 mars 2015 ? 17:15, Dan Gudmundsson a ?crit : > > > I took at file:read_line issue, and thought about it :-) > > > > IMHO it should behave as file:read/2 does and how it is documented. > > i.e. return {error, {no_translation, unicode, latin1}} for both binary > and list mode > > when encoding is set to unicode and reading non latin1 code points. > > (Which is confusing but that is how it is intended/documented, > > use io module for translating non latin1 codepoints). > > The problem is that file uses io in read/2 itself, calling io:request/2, > which ultimately invariably converts the response to Unicode. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ottenklinger@REDACTED Fri Mar 13 10:54:37 2015 From: magnus.ottenklinger@REDACTED (Magnus Ottenklinger) Date: Fri, 13 Mar 2015 09:54:37 +0000 Subject: [erlang-bugs] Invalid section on test suite line numbers in test_server reference manual Message-ID: Hey List, The parse_transform and macro for adding line numbers has been removed in 2011 [1]. Should the section 'TEST SUITE LINE NUMBERS' [1] on using the parse_transform be removed from be removed? Also, the reference to the line macro in 'TEST SUITE SUPPORT MACROS' should be invalid by now as well. Regards, Magnus [1] https://github.com/erlang/otp/commit/f43c0a51cd15b2b0f8adba4bb9ec5531dd9d8820 [2] http://www.erlang.org/doc/man/test_server.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Fri Mar 13 00:56:06 2015 From: james@REDACTED (James Fish) Date: Thu, 12 Mar 2015 23:56:06 +0000 Subject: [erlang-bugs] Dialyzer can yield false positives and false negatives after checking PLT Message-ID: Hi, If a function is removed from a module and the module has previously been added to a PLT, the function will not be removed from PLT when the PLT is checked. This results in dialyzer failing to produce a callgraph warning when doing success typings analysis if the remove function is still called in another module As the function is not removed from the PLT a prior warning, such as a contract types warning, might be emitted when the removed function nolonger exists. I have attached an archive with a minimal example, which prints a contract types warning instead of a callgraph warning. This example has been tested on OTP R15B03 and 17.4. Regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plt_gc.tar.gz Type: application/x-gzip Size: 756 bytes Desc: not available URL: From n.oxyde@REDACTED Sun Mar 15 15:30:01 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 15 Mar 2015 15:30:01 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: Message-ID: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> Le 13 mars 2015 ? 06:51, Dan Gudmundsson a ?crit : > This should be fixed on master now. Fixed how? In which commit? From dgud@REDACTED Mon Mar 16 08:22:08 2015 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 16 Mar 2015 08:22:08 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> References: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> Message-ID: On Sun, Mar 15, 2015 at 3:30 PM, Anthony Ramine wrote: > Le 13 mars 2015 ? 06:51, Dan Gudmundsson a ?crit : > > > This should be fixed on master now. > > Fixed how? In which commit? https://github.com/erlang/otp/commit/7efa93c9dd4ce25c5754c1b72ec804e8172c0099 -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Mar 16 14:17:21 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Mar 2015 14:17:21 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> Message-ID: Le 16 mars 2015 ? 08:22, Dan Gudmundsson a ?crit : > > On Sun, Mar 15, 2015 at 3:30 PM, Anthony Ramine wrote: > Le 13 mars 2015 ? 06:51, Dan Gudmundsson a ?crit : > > > This should be fixed on master now. > > Fixed how? In which commit? > > https://github.com/erlang/otp/commit/7efa93c9dd4ce25c5754c1b72ec804e8172c0099 Tack! From anton.ryabkov@REDACTED Tue Mar 17 09:12:26 2015 From: anton.ryabkov@REDACTED (Anton Ryabkov) Date: Tue, 17 Mar 2015 14:12:26 +0600 Subject: [erlang-bugs] xmerl trouble with validation anyURI type Message-ID: Hello, I have a trouble with validating xml document by xsd schema with attribute's type anyURI and value = "alerting.wav". According to RFC 3986 (Uniform Resource Identifier) "alerting.wav" is valid value for anyURI type. I've tried on Erlang R16B03, 17.4. I attached simple sample, where you can see this problem. To run it, compile xml_test and invoke "test" method. I've analyzed xmerl source code, and have found that in xmerl_xsd_type.erl file make validation anyURI type. According source code anyURI must contains SCHEME section, but by RFC 3986 this section is optional. I've made fix, that validate anyURI type according regular expression from RFC 3986, Appendix B. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xmerl_anyURI_bug.tar.gz Type: application/x-gzip Size: 2641 bytes Desc: not available URL: From Ingela.Anderton.Andin@REDACTED Fri Mar 20 12:05:24 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 20 Mar 2015 12:05:24 +0100 Subject: [erlang-bugs] SSL suite test failure In-Reply-To: <54ECA987.2000703@ninenines.eu> References: <54E88B28.5020203@ninenines.eu> <54EB0311.1070707@ericsson.com> <54ECA987.2000703@ninenines.eu> Message-ID: <550BFEF4.3080002@ericsson.com> Hi! On 02/24/2015 05:40 PM, Lo?c Hoguin wrote: > Hello, > > On 02/23/2015 11:38 AM, Ingela Anderton Andin wrote: >> Hi! >> >> It might be a timing issue in the test suite. As the test suite always >> spawns the openssl server and waits for it to come up, but we have not >> found a perfect way of telling that it is up. > > Are you sure about that? This is the > "basic_erlang_server_openssl_client" test, sounds like the server is > Erlang and the client OpenSSL and not the other way around. Well in this case I agree that the possible timing issue, is not the problem. It is probably the OpenSSL version that is the problem. I discovered yesterday that we got this error with the OpenSSL version 1.0.1l. Only this test case runs with only defaults to s_client and all other configured test cases run well. Using a non RSA cipher suite seemed to fix the problem. Regards Ingela Erlang/OTP Team - Ericsson AB From n.oxyde@REDACTED Sat Mar 21 13:38:02 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 21 Mar 2015 13:38:02 +0100 Subject: [erlang-bugs] Invalid section on test suite line numbers in test_server reference manual In-Reply-To: References: Message-ID: <6B03483F-36AF-42BD-9D20-6519EDD84EEE@gmail.com> Le 13 mars 2015 ? 10:54, Magnus Ottenklinger a ?crit : > The parse_transform and macro for adding line numbers has been removed in 2011 [1]. Should the section ?TEST SUITE LINE NUMBERS? [1] on using the parse_transform be removed from be removed? Also, the reference to the line macro in ?TEST SUITE SUPPORT MACROS? should be invalid by now as well. https://github.com/erlang/otp/pull/655 From n.oxyde@REDACTED Sat Mar 21 13:38:54 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 21 Mar 2015 13:38:54 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> Message-ID: Le 16 mars 2015 ? 08:22, Dan Gudmundsson a ?crit : > https://github.com/erlang/otp/commit/7efa93c9dd4ce25c5754c1b72ec804e8172c0099 So in the end, the file module too supports unicode reading? From dgud@REDACTED Sat Mar 21 15:25:23 2015 From: dgud@REDACTED (Dan Gudmundsson) Date: Sat, 21 Mar 2015 15:25:23 +0100 Subject: [erlang-bugs] Misleading docs or implementation of file:read/2 and friends In-Reply-To: References: <7BD8B7AF-007F-486A-9F5F-F59C5D6BF17D@gmail.com> Message-ID: It does for latin1, i.e. it can convert latin1 chars to utf8|utf16|utf32 encoding on file and vice verse. That is no change from what file:read and write do. And the doc is the same for read_line as for read. Anything above 256 gives badarg no_translation. I left 'pread' as it is, it doesn't do any conversion today, i.e. ignores encoding. I don't know if it is a bug or intentionally ignored since it is strange to jump around at byte lengths when content is not byte oriented? On Sat, Mar 21, 2015 at 1:38 PM, Anthony Ramine wrote: > Le 16 mars 2015 ? 08:22, Dan Gudmundsson a ?crit : > > > > https://github.com/erlang/otp/commit/7efa93c9dd4ce25c5754c1b72ec804e8172c0099 > > So in the end, the file module too supports unicode reading? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From videlalvaro@REDACTED Mon Mar 23 10:22:00 2015 From: videlalvaro@REDACTED (Alvaro Videla) Date: Mon, 23 Mar 2015 09:22:00 +0000 Subject: [erlang-bugs] TLS Distribution doesn't honour distribution arguments Message-ID: Hi, It seems distribution over TLS doesn't honour the inet_dist_listen_* parameters. See: https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_tls_dist_proxy.erl#L62 More details on this RabbitMQ thread: https://groups.google.com/forum/#!searchin/rabbitmq-users/tls$20clustering/rabbitmq-users/OrvlCIrTpFY/CAUksHqQ9m4J Regards, Alvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello@REDACTED Mon Mar 23 12:58:43 2015 From: hello@REDACTED (Adam Lindberg) Date: Mon, 23 Mar 2015 12:58:43 +0100 Subject: [erlang-bugs] Segfault when using Observer Message-ID: When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it segfaults when inspecting a process from the Applications tab. This does not happen when inspecting a process from the Processes tab. $ erl Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.3 (abort with ^G) 1> observer:start(). ok 2> [1] 52545 segmentation fault erl $ Full stack trace from OS X can be found here: https://gist.github.com/eproxus/3d517e895c3e05f93bcb Cheers, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From prof3ta@REDACTED Mon Mar 23 15:32:45 2015 From: prof3ta@REDACTED (Roberto Aloi) Date: Mon, 23 Mar 2015 15:32:45 +0100 Subject: [erlang-bugs] Compile attribute and module_info Message-ID: Hi, given the following module test.erl: -module(test). -export([test/0]). test() -> ok. if I compile it with the 'native' option, I can see the option in the list of compile options returned by test:module_info/0: 1> c(test, [native]). {ok,test} 2> test:module_info(). [{exports,[{test,0},{module_info,0},{module_info,1}]}, {imports,[]}, {attributes,[{vsn,[...]}]}, {compile,[{options,[native]}, {version,"4.9.4"}, {time,{2015,3,23,14,26,9}}, {source,"/tmp/test.erl"}]}] But if I use the 'native compile attribute, instead: -module(test). -compile([native]). -export([test/0]). test() -> ok. If I compile the module, the option is not returned by test:module_info/0, either as a compile option or as an attribute: 3> c(test). {ok,test} 4> test:module_info(). [{exports,[{test,0},{module_info,0},{module_info,1}]}, {imports,[]}, {attributes,[{vsn,[...]}]}, {compile,[{options,[]}, {version,"4.9.4"}, {time,{2015,3,23,14,28,28}}, {source,"/tmp/test.erl"}]}] Is this the intended behaviour? R -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronisstav@REDACTED Mon Mar 23 17:25:54 2015 From: aronisstav@REDACTED (Stavros Aronis) Date: Mon, 23 Mar 2015 17:25:54 +0100 Subject: [erlang-bugs] Dialyzer can yield false positives and false negatives after checking PLT In-Reply-To: References: Message-ID: Hi James, it seems that the fix for this is quite trivial and requires modified modules to also be purged from an old PLT. The real issue is to create a test for this in Dialyzer's test suites. I have cc'd Hans Bolinder (Dialyzer's expert from the OTP team) and will probably take this offline. https://github.com/aronisstav/otp/commit/7df1d8fbe66c12539e3d36c0bb74b61e846815a3 Thanks for the report! Stavros On Fri, Mar 13, 2015 at 12:56 AM, James Fish wrote: > Hi, > > If a function is removed from a module and the module has previously been > added to a PLT, the function will not be removed from PLT when the PLT is > checked. This results in dialyzer failing to produce a callgraph warning > when doing success typings analysis if the remove function is still called > in another module > > As the function is not removed from the PLT a prior warning, such as a > contract types warning, might be emitted when the removed function nolonger > exists. > > I have attached an archive with a minimal example, which prints a contract > types warning instead of a callgraph warning. This example has been tested > on OTP R15B03 and 17.4. > > Regards, > > James > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Mar 24 15:16:27 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 Mar 2015 15:16:27 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure Message-ID: Hi OTP team (and other readers), Over the weekend, I've been building up a QuickCheck model of Erlang/OTP maps(). This is to be able to properly test the HAMT maps of the up-and-coming 18.0 release for correctness, but I'm testing on 17.4.1 as well. The following problem occurs for release 17.4.1. (for the curious, 18.0 currently segfaults on these tests): Erlang/OTP 17 [erts-6.3.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false] Eshell V6.3.1 (abort with ^G) 1> Map = #{0 => 0,2147483648 => 0}. #{0 => 0,2147483648 => 0} 2> Bin = term_to_binary(M). * 1: variable 'M' is unbound 3> Bin = term_to_binary(Map). <<131,116,0,0,0,2,97,0,97,0,110,4,0,0,0,0,128,97,0>> 4> Map2 = binary_to_term(Bin). #{2147483648 => 0,0 => 0} 5> Map =:= Map2. false (copied verbatim, including my error in 2>) The problem is that if I convert the map to a binary and then back again, the two maps are not equal. Furthermore, they print differently: 6> Map. #{0 => 0,2147483648 => 0} 7> Map2. #{2147483648 => 0,0 => 0} 8> The value 2147483648 seems important and it is 2^31. However, the problem also occurs at 2^31 + 1. Only testing with "small" integers poses no problem at all. I have yet to test against floating point numbers and this requires some additional attention to detail as they have fun equality rules :) A second problem occurs in merges, which may be related or may not be related. In the second problem, we are merging maps [#{-2147483649 => 0, 0 => 0, 97 => 0, false => 0, flower => 0, #Fun => 0, #Fun => 0, <<>> => 0}, #{0 => 1}] where the #Fun's are generated functions of 0 and 2 parameters respectively. Lets see how to create such a map (one might note that direct creation through #{ ... } syntax would make the keys which are functions illegal, but I am an experiened Erlang programmer and have a way around such petty limitations :P) 9> F1 = fun(_, _) -> 0 end, 9> F2 = fun(_, _) -> 1 end. This defines two functions: 11> maps:from_list( 11> [{-2147483649, 0}, 11> {0,0}, {97, 0}, {false, 0}, {flower, 0}, {F1, 0}, {F2, 0}, {<<>>, 0}]). #{-2147483649 => 0, 0 => 0, 97 => 0, false => 0, flower => 0, #Fun => 0, #Fun => 0, <<>> => 0} Remarkably, this is well-defined, now lets merge: 12> maps:merge(v(11), #{0 => 1}). #{0 => 1, -2147483649 => 0, 0 => 0, 97 => 0, false => 0, flower => 0, #Fun => 0, #Fun => 0, <<>> => 0} 13> The resulting map now has to '0' keys! Rejoice! The model I am using is the following: https://github.com/jlouis/maps_eqc/tree/ac7748ce81781ae6c1ad7b4ed07ca5cd935c125d (maps_iso_eqc are simple stateless tests, whereas maps_eqc is a more complicated stateful test which also verifies properties about copying maps between processes and that maps are persistent data structures). To run: make:all([load]). eqc:module({testing_budget, 20}, maps_iso_eqc). Two test runs of mine: https://gist.github.com/jlouis/39de114e0a447af983a5 Note the latter merge test which managed to shrink over 1200 times! -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Mar 24 15:28:05 2015 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 24 Mar 2015 15:28:05 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: References: Message-ID: <55117475.1020908@erlang.org> On 2015-03-24 15:16, Jesper Louis Andersen wrote: > Hi OTP team (and other readers), Hi Jesper! Awesome! Thank you for reporting this and thank you for your quickcheck model. =D term_to_binary binary_to_term problem has already been spotted and a fix is on it's way. We will look into the others now. // Bj?rn-Egil > > Over the weekend, I've been building up a QuickCheck model of > Erlang/OTP maps(). This is to be able to properly test the HAMT maps > of the up-and-coming 18.0 release for correctness, but I'm testing on > 17.4.1 as well. The following problem occurs for release 17.4.1. (for > the curious, 18.0 currently segfaults on these tests): > > Erlang/OTP 17 [erts-6.3.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] > [async-threads:10] [kernel-poll:false] > > Eshell V6.3.1 (abort with ^G) > 1> Map = #{0 => 0,2147483648 => 0}. > #{0 => 0,2147483648 => 0} > 2> Bin = term_to_binary(M). > * 1: variable 'M' is unbound > 3> Bin = term_to_binary(Map). > <<131,116,0,0,0,2,97,0,97,0,110,4,0,0,0,0,128,97,0>> > 4> Map2 = binary_to_term(Bin). > #{2147483648 => 0,0 => 0} > 5> Map =:= Map2. > false > > (copied verbatim, including my error in 2>) > > The problem is that if I convert the map to a binary and then back > again, the two maps are not equal. Furthermore, they print differently: > > 6> Map. > #{0 => 0,2147483648 => 0} > 7> Map2. > #{2147483648 => 0,0 => 0} > 8> > > The value 2147483648 seems important and it is 2^31. However, the > problem also occurs at 2^31 + 1. Only testing with "small" integers > poses no problem at all. I have yet to test against floating point > numbers and this requires some additional attention to detail as they > have fun equality rules :) > > A second problem occurs in merges, which may be related or may not be > related. In the second problem, we are merging maps > > [#{-2147483649 => 0, > 0 => 0, > 97 => 0, > false => 0, > flower => 0, > #Fun => 0, > #Fun => 0, > <<>> => 0}, > #{0 => 1}] > > where the #Fun's are generated functions of 0 and 2 parameters > respectively. Lets see how to create such a map (one might note that > direct creation through #{ ... } syntax would make the keys which are > functions illegal, but I am an experiened Erlang programmer and have a > way around such petty limitations :P) > > 9> F1 = fun(_, _) -> 0 end, > 9> F2 = fun(_, _) -> 1 end. > > This defines two functions: > > 11> maps:from_list( > 11> [{-2147483649, 0}, > 11> {0,0}, {97, 0}, {false, 0}, {flower, 0}, {F1, 0}, {F2, 0}, > {<<>>, 0}]). > #{-2147483649 => 0, > 0 => 0, > 97 => 0, > false => 0, > flower => 0, > #Fun => 0, > #Fun => 0, > <<>> => 0} > > Remarkably, this is well-defined, now lets merge: > > 12> maps:merge(v(11), #{0 => 1}). > #{0 => 1, > -2147483649 => 0, > 0 => 0, > 97 => 0, > false => 0, > flower => 0, > #Fun => 0, > #Fun => 0, > <<>> => 0} > 13> > > The resulting map now has to '0' keys! Rejoice! > > The model I am using is the following: > > https://github.com/jlouis/maps_eqc/tree/ac7748ce81781ae6c1ad7b4ed07ca5cd935c125d > > (maps_iso_eqc are simple stateless tests, whereas maps_eqc is a more > complicated stateful test which also verifies properties about copying > maps between processes and that maps are persistent data structures). > > To run: > > make:all([load]). > eqc:module({testing_budget, 20}, maps_iso_eqc). > > Two test runs of mine: > > https://gist.github.com/jlouis/39de114e0a447af983a5 > > Note the latter merge test which managed to shrink over 1200 times! > > > -- > J. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Mar 24 23:00:02 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 24 Mar 2015 23:00:02 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: <55117475.1020908@erlang.org> References: <55117475.1020908@erlang.org> Message-ID: On Tue, Mar 24, 2015 at 3:28 PM, Bj?rn-Egil Dahlberg wrote: > We will look into the others now. I extended the tests for the branch egil/fix-term-cmp/OTP-12623 (commit-ID: a1520d8) which fixes the binary_to_term/term_to_binary conversions. I had some model errors with maps:map/2, which I fixed. Then I added generators for floating point values. Look at this little gem: Erlang/OTP 17 [erts-6.3.1] [source-a1520d8] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.3.1 (abort with ^G) 1> L = [{-1,0},{0.0,0},{0,0},{1,0}]. [{-1,0},{0.0,0},{0,0},{1,0}] 2> lists:sort(L). [{-1,0},{0.0,0},{0,0},{1,0}] 3> lists:sort(maps:to_list(maps:from_list(L))). [{-1,0},{0,0},{0.0,0},{1,0}] 4> v(2) =:= v(3). false 5> maps:to_list(maps:from_list(L)). [{-1,0},{0,0},{1,0},{0.0,0}] In other words, factoring L through a map makes the comparison and the sort go wrong. I would expect the factoring to be the identity such that v(4) would be true in the above. But it looks like something happens to the value so 0 and 0.0 swaps place in the ordering. There *has* to be a floating point 0.0 in there. So it has something to do with this, but I can't be more specific :) Note that this bug may be related to the merge bug I reported earlier today, but the merge tests succeed on this branch. Also, another peculiar thing: 7> maps:put(-1, 3, #{}). #{-1 => 3} 8> #{ -1 => 3 }. * 1: illegal map key Negative integers are not valid map keys, but I don't know exactly why that is the case. This is compiler-land however, and I have not yet a QuickCheck model for that :) Here is the QuickCheck run, including shrinking: https://gist.github.com/jlouis/5b4311f40675b1693c84 -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Wed Mar 25 00:04:01 2015 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Wed, 25 Mar 2015 00:04:01 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: References: <55117475.1020908@erlang.org> Message-ID: Answers inline .. 2015-03-24 23:00 GMT+01:00 Jesper Louis Andersen < jesper.louis.andersen@REDACTED>: > > On Tue, Mar 24, 2015 at 3:28 PM, Bj?rn-Egil Dahlberg > wrote: > >> We will look into the others now. > > > I extended the tests for the branch egil/fix-term-cmp/OTP-12623 > (commit-ID: a1520d8) which fixes the binary_to_term/term_to_binary > conversions. I had some model errors with maps:map/2, which I fixed. Then I > added generators for floating point values. Look at this little gem: > > Erlang/OTP 17 [erts-6.3.1] [source-a1520d8] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.3.1 (abort with ^G) > 1> L = [{-1,0},{0.0,0},{0,0},{1,0}]. > [{-1,0},{0.0,0},{0,0},{1,0}] > 2> lists:sort(L). > [{-1,0},{0.0,0},{0,0},{1,0}] > 3> lists:sort(maps:to_list(maps:from_list(L))). > [{-1,0},{0,0},{0.0,0},{1,0}] > 4> v(2) =:= v(3). > false > 5> maps:to_list(maps:from_list(L)). > [{-1,0},{0,0},{1,0},{0.0,0}] > > In other words, factoring L through a map makes the comparison and the > sort go wrong. I would expect the factoring to be the identity such that > v(4) would be true in the above. But it looks like something happens to the > value so 0 and 0.0 swaps place in the ordering. There *has* to be a > floating point 0.0 in there. So it has something to do with this, but I > can't be more specific :) Note that this bug may be related to the merge > bug I reported earlier today, but the merge tests succeed on this branch. > I don't think anything is wrong here. Maps (small maps) store keys in "term order" not "arithmetic order". Where "term order" is defined as erlangs arithmetic order but integers types are less than float types. This gives us a total order of all erlang terms. Furthermore, maps:to_list/1 is defined to return pairs in arbitrary order. =) v(2) =:= v(3) returns false because lists:sort/1 is stable, 0.0 and 0 compares equal and those keys started in different positions before the sort. However, we will change map comparison between maps to 18. Two maps will compare keys by term order and not by arithmetic order as it is today. Values will still use arithmetic order. > > Also, another peculiar thing: > > 7> maps:put(-1, 3, #{}). > #{-1 => 3} > 8> #{ -1 => 3 }. > * 1: illegal map key > > Negative integers are not valid map keys, but I don't know exactly why > that is the case. This is compiler-land however, and I have not yet a > QuickCheck model for that :) > This is a (not so) known fact. It has to do with the fact that we only handle literal keys with maps syntax in 17 and negative integers are not literals. They are unary expressions on positive integers and thusly not handled by the compiler. This is not the case in 18 (current master) where we can handle map keys with variables. // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 25 00:08:49 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 25 Mar 2015 00:08:49 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: References: <55117475.1020908@erlang.org> Message-ID: On Wed, Mar 25, 2015 at 12:04 AM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > v(2) =:= v(3) returns false because lists:sort/1 is stable, 0.0 and 0 > compares equal and those keys started in different positions before the > sort. Aha! This means I need to adapt the model because obviously lists:sort/1 is now unusable for this. I'll do that tomorrow at some point :) -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed Mar 25 00:16:08 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 25 Mar 2015 00:16:08 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: References: <55117475.1020908@erlang.org> Message-ID: <5511F038.2030206@cs.ntua.gr> On 03/24/2015 11:00 PM, Jesper Louis Andersen wrote: > Erlang/OTP 17 [erts-6.3.1] [source-a1520d8] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.3.1 (abort with ^G) > 1> L = [{-1,0},{0.0,0},{0,0},{1,0}]. > [{-1,0},{0.0,0},{0,0},{1,0}] > 2> lists:sort(L). > [{-1,0},{0.0,0},{0,0},{1,0}] > 3> lists:sort(maps:to_list(maps:from_list(L))). > [{-1,0},{0,0},{0.0,0},{1,0}] > 4> v(2) =:= v(3). > false > 5> maps:to_list(maps:from_list(L)). > [{-1,0},{0,0},{1,0},{0.0,0}] > > In other words, factoring L through a map makes the comparison and the > sort go wrong. The above may seem a bit weird at first but is not at all strange given that lists:sort/1 does not sort according to the (total) term order: Eshell V6.3.1 (abort with ^G) 1> lists:sort([0, 0.0]). [0,0.0] 2> lists:sort([0.0, 0]). [0.0,0] and maps:to_list/1's manual page reads: to_list(Map) -> [{Key, Value}] Types: Map = #{} Key = Value = term() The fuction returns a list of pairs representing the key-value associations of Map, where the pairs, [{K1,V1}, ..., {Kn,Vn}], are returned in arbitrary order. Kostis PS. However, the manual has a typo: "fuction" should read "function" :) From ulf@REDACTED Wed Mar 25 16:17:04 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 25 Mar 2015 16:17:04 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: <5511F038.2030206@cs.ntua.gr> References: <55117475.1020908@erlang.org> <5511F038.2030206@cs.ntua.gr> Message-ID: <1E39161D-E222-44AA-AE69-2CB687300732@feuerlabs.com> > On 25 Mar 2015, at 00:16, Kostis Sagonas wrote: > > The above may seem a bit weird at first but is not at all strange given that lists:sort/1 does not sort according to the (total) term order: > > Eshell V6.3.1 (abort with ^G) > 1> lists:sort([0, 0.0]). > [0,0.0] > 2> lists:sort([0.0, 0]). > [0.0,0] But this is according to the documented comparison semantics, surely. From the Reference Manual: "When comparing an integer to a float, the term with the lesser precision will be converted into the other term's type, unless the operator is one of =:= or =/=.? It?s unfortunate though, and I ran into this issue when writing QuickCheck properties for the ?sext? encode/decode. prop_sort() -> ?FORALL({T1,T2}, {term_(), term_()}, begin {X1,X2} = {sext:encode(T1), sext:encode(T2)}, comp(X1,X2) == comp_i(T1,T2) end). ?where comp_i/2 takes care of the case where X1 == X2, X1 =/= X2. That is, the intuitive property could not be used, given that this also had to be satisfied: prop_encode() -> ?FORALL(T, term_(), sext:decode(sext:encode(T)) == T). BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From kostis@REDACTED Wed Mar 25 16:55:45 2015 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 25 Mar 2015 16:55:45 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: <1E39161D-E222-44AA-AE69-2CB687300732@feuerlabs.com> References: <55117475.1020908@erlang.org> <5511F038.2030206@cs.ntua.gr> <1E39161D-E222-44AA-AE69-2CB687300732@feuerlabs.com> Message-ID: <5512DA81.9090603@cs.ntua.gr> On 03/25/2015 04:17 PM, Ulf Wiger wrote: >> >On 25 Mar 2015, at 00:16, Kostis Sagonas wrote: >> > >> >The above may seem a bit weird at first but is not at all strange given that lists:sort/1 does not sort according to the (total) term order: >> > >> > Eshell V6.3.1 (abort with ^G) >> > 1> lists:sort([0, 0.0]). >> > [0,0.0] >> > 2> lists:sort([0.0, 0]). >> > [0.0,0] > But this is according to the documented comparison semantics, surely. > > From the Reference Manual: > "When comparing an integer to a float, the term with the lesser precision will be converted into the other term's type, unless the operator is one of =:= or =/=.? > > It?s unfortunate though, and I ran into this issue when writing QuickCheck properties for the ?sext? encode/decode. > > prop_sort() -> > ?FORALL({T1,T2}, {term_(), term_()}, > begin > {X1,X2} = {sext:encode(T1), sext:encode(T2)}, > comp(X1,X2) == comp_i(T1,T2) > end). > > ?where comp_i/2 takes care of the case where X1 == X2, X1 =/= X2. > > That is, the intuitive property could not be used, given that this also had to be satisfied: > > prop_encode() -> > ?FORALL(T, term_(), > sext:decode(sext:encode(T)) == T). > Not familiar with 'sext' encoding, but I am not sure I get the details in the problem you run into... For once, I do not see any use of lists:sort/1 here. Is it buried in the comp*/2 functions somehow? Does comp/2 use arithmetic rather than term comparison ? Or can it simply be that the reason the "intuitive" property cannot be used is because you have used ==/2 instead of =:=/2 there? Cheers, Kostis From ulf@REDACTED Wed Mar 25 18:20:30 2015 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 25 Mar 2015 18:20:30 +0100 Subject: [erlang-bugs] Maps equality failure / Maps merge failure In-Reply-To: <5512DA81.9090603@cs.ntua.gr> References: <55117475.1020908@erlang.org> <5511F038.2030206@cs.ntua.gr> <1E39161D-E222-44AA-AE69-2CB687300732@feuerlabs.com> <5512DA81.9090603@cs.ntua.gr> Message-ID: <67A06C93-C957-4CC9-A3D7-396B035C45CC@feuerlabs.com> > On 25 Mar 2015, at 16:55, Kostis Sagonas wrote: > > Not familiar with 'sext' encoding, but I am not sure I get the details in the problem you run into... For once, I do not see any use of lists:sort/1 here. Is it buried in the comp*/2 functions somehow? Does comp/2 use arithmetic rather than term comparison ? Ah, forgive me for being so terse. Sext is short for Sortable External Term format (a name picked before I heard of sexting). The library serializes Erlang terms in a way that preserves the original sort order. https://github.com/uwiger/sext > Or can it simply be that the reason the "intuitive" property cannot be used is because you have used ==/2 instead of =:=/2 there? The intuitive property is that encoding and then decoding any Erlang term should give the same term back*. It?s obviously difficult to support this and still preserve the notion that e.g. 1.0 and 1 are indistinguishable when sorting, so in the sext properties, I have to distinguish between floats and ints in the comparison and basically make them compare in a way that makes sense for my particular problem. An intuitive sort property could have been that for any list L, if L1 = [{X, sext:encode(X)} || X <- L], then lists:keysort(1, L1) =:= lists:keysort(2, L1). The lists:sort/1 function suffers form using the standard comparison operators, <, >, =<, >= and ==. OTOH, there are no strict comparison operators for anything but equality. BR, Ulf W * Yes, floats are problematic in themselves here. In the test suite, I ?normalize? the floats using the bit syntax, which seems to work for now. But that property of floats is undocumented, possibly even unintentional. Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From n.oxyde@REDACTED Thu Mar 26 12:15:17 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 26 Mar 2015 12:15:17 +0100 Subject: [erlang-bugs] `undefined parse transform' parse transforms which call non-existing modules In-Reply-To: References: Message-ID: <09E6E249-A6AC-484F-8450-4114C67A58F5@gmail.com> Le 17 f?vr. 2015 ? 20:23, Klas Johansson a ?crit : > If an existing parse transform calls a non-existing module, the check will misinterpret this and print the `undefined parse transform' error. https://github.com/erlang/otp/pull/660 From alexander.pozdneev@REDACTED Thu Mar 26 09:52:09 2015 From: alexander.pozdneev@REDACTED (Alexander Pozdneev) Date: Thu, 26 Mar 2015 11:52:09 +0300 Subject: [erlang-bugs] Building on IBM POWER8 running in little endian Message-ID: Hello, When I try to configure Erlang 17.4 on IBM POWER8 running RHEL 7.1 little endian, I get the following message This script, last modified 2013-02-12, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD ... I confirm that with the latest versions of config.guess and config.sub I was able to build the code successfully. Best regards, Alexander Pozdneev From tuncer.ayaz@REDACTED Thu Mar 26 21:11:02 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 26 Mar 2015 21:11:02 +0100 Subject: [erlang-bugs] Building on IBM POWER8 running in little endian In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 9:52 AM, Alexander Pozdneev wrote: > Hello, > > When I try to configure Erlang 17.4 on IBM POWER8 running RHEL 7.1 little > endian, I get the following message > > This script, last modified 2013-02-12, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > ... > > I confirm that with the latest versions of config.guess and config.sub I > was able to build the code successfully. Related: https://github.com/erlang/otp/pull/640 Can and, if so, should './otp_build autoconf' take care of this as well? From matwey.kornilov@REDACTED Thu Mar 26 20:41:52 2015 From: matwey.kornilov@REDACTED (Matwey V. Kornilov) Date: Thu, 26 Mar 2015 22:41:52 +0300 Subject: [erlang-bugs] 18.0-rc1 HIPE build failed at ARM Message-ID: Hi, I am facing the following issue when trying to build 18.0-rc1 on armv6 and armv7 respectively. ARMv6: [ 1934s] make[5]: Entering directory '/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/lib_src' [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/r/ethr_aux.o [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler messages: [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569: Error: bad instruction `standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)' [ 1935s] armv6hl-suse-linux-gnueabi/Makefile:949: recipe for target 'obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed [ 1935s] make[3]: *** [obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1 [ 1935s] make[3]: *** Waiting for unfinished jobs.... Configure was: ./configure --host=armv6hl-suse-linux-gnueabi --build=armv6hl-suse-linux-gnueabi --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-systemd --with-ssl=/usr --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib ARMv7: [ 761s] M4 armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S [ 761s] CC obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o [ 761s] armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler messages: [ 761s] armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569: Error: bad instruction `standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)' [ 761s] armv7hl-suse-linux-gnueabi/Makefile:949: recipe for target 'obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed [ 761s] make[3]: *** [obj/armv7hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1 [ 761s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/emulator' [ 761s] /home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/make/run_make.mk:34: recipe for target 'opt' failed Configure was: ./configure --host=armv7hl-suse-linux-gnueabi --build=armv7hl-suse-linux-gnueabi --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-systemd --with-ssl=/usr --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib From klas.johansson@REDACTED Thu Mar 26 22:00:26 2015 From: klas.johansson@REDACTED (Klas Johansson) Date: Thu, 26 Mar 2015 22:00:26 +0100 Subject: [erlang-bugs] `undefined parse transform' parse transforms which call non-existing modules In-Reply-To: <09E6E249-A6AC-484F-8450-4114C67A58F5@gmail.com> References: <09E6E249-A6AC-484F-8450-4114C67A58F5@gmail.com> Message-ID: Hi, Looks better, thanks. /Klas On Thu, Mar 26, 2015 at 12:15 PM, Anthony Ramine wrote: > Le 17 f?vr. 2015 ? 20:23, Klas Johansson a > ?crit : > > > If an existing parse transform calls a non-existing module, the check > will misinterpret this and print the `undefined parse transform' error. > > https://github.com/erlang/otp/pull/660 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Fri Mar 27 09:37:25 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 27 Mar 2015 09:37:25 +0100 Subject: [erlang-bugs] 18.0-rc1 HIPE build failed at ARM In-Reply-To: References: Message-ID: <21781.5829.520436.505117@gargle.gargle.HOWL> Matwey V. Kornilov writes: > > Hi, > > I am facing the following issue when trying to build 18.0-rc1 on armv6 > and armv7 respectively. > > ARMv6: > > [ 1934s] make[5]: Entering directory > '/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/lib_src' > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/r/ethr_aux.o > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler > messages: > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569: > Error: bad instruction > `standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)' > [ 1935s] armv6hl-suse-linux-gnueabi/Makefile:949: recipe for target > 'obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed > [ 1935s] make[3]: *** > [obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1 > [ 1935s] make[3]: *** Waiting for unfinished jobs.... Confirmed. The recent merge of nox/ets-update_counter-4 is the culprit: that failed to update ARM correctly, and I think I also saw a typo in the other bits. I'll put together a correction today. From mikpelinux@REDACTED Fri Mar 27 09:58:03 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 27 Mar 2015 09:58:03 +0100 Subject: [erlang-bugs] 18.0-rc1 HIPE build failed at ARM In-Reply-To: <21781.5829.520436.505117@gargle.gargle.HOWL> References: <21781.5829.520436.505117@gargle.gargle.HOWL> Message-ID: <21781.7067.740668.336283@gargle.gargle.HOWL> Mikael Pettersson writes: > Matwey V. Kornilov writes: > > > > Hi, > > > > I am facing the following issue when trying to build 18.0-rc1 on armv6 > > and armv7 respectively. > > > > ARMv6: > > > > [ 1934s] make[5]: Entering directory > > '/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/lib_src' > > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o > > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/r/ethr_aux.o > > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler > > messages: > > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569: > > Error: bad instruction > > `standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)' > > [ 1935s] armv6hl-suse-linux-gnueabi/Makefile:949: recipe for target > > 'obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed > > [ 1935s] make[3]: *** > > [obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1 > > [ 1935s] make[3]: *** Waiting for unfinished jobs.... > > Confirmed. The recent merge of nox/ets-update_counter-4 is the culprit: > that failed to update ARM correctly, and I think I also saw a typo in the > other bits. > > I'll put together a correction today. There's also a serious error in the AMD64 code changes... I'll have to do a very careful review of this stuff. From n.oxyde@REDACTED Fri Mar 27 10:10:05 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 27 Mar 2015 10:10:05 +0100 Subject: [erlang-bugs] 18.0-rc1 HIPE build failed at ARM In-Reply-To: <21781.7067.740668.336283@gargle.gargle.HOWL> References: <21781.5829.520436.505117@gargle.gargle.HOWL> <21781.7067.740668.336283@gargle.gargle.HOWL> Message-ID: <5F633DE9-FF9C-4F8A-A6AD-B4B8C4747BEA@gmail.com> Le 27 mars 2015 ? 09:58, Mikael Pettersson a ?crit : >> Confirmed. The recent merge of nox/ets-update_counter-4 is the culprit: >> that failed to update ARM correctly, and I think I also saw a typo in the >> other bits. >> >> I'll put together a correction today. > > There's also a serious error in the AMD64 code changes... I'll have to do > a very careful review of this stuff. It's not like this PR had been opened since May 2014... Oh wait, it is. :( From mikpelinux@REDACTED Fri Mar 27 13:42:30 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 27 Mar 2015 13:42:30 +0100 Subject: [erlang-bugs] 18.0-rc1 HIPE build failed at ARM In-Reply-To: <21781.7067.740668.336283@gargle.gargle.HOWL> References: <21781.5829.520436.505117@gargle.gargle.HOWL> <21781.7067.740668.336283@gargle.gargle.HOWL> Message-ID: <21781.20534.542240.555931@gargle.gargle.HOWL> Mikael Pettersson writes: > Mikael Pettersson writes: > > Matwey V. Kornilov writes: > > > > > > Hi, > > > > > > I am facing the following issue when trying to build 18.0-rc1 on armv6 > > > and armv7 respectively. > > > > > > ARMv6: > > > > > > [ 1934s] make[5]: Entering directory > > > '/home/abuild/rpmbuild/BUILD/otp-OTP-18.0-rc1/erts/lib_src' > > > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o > > > [ 1934s] CC obj/armv6hl-suse-linux-gnueabi/opt/r/ethr_aux.o > > > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S: Assembler > > > messages: > > > [ 1935s] armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.S:13569: > > > Error: bad instruction > > > `standard_bif_interface_4(nbif_ets_update_counter_4, ets_update_counter_4)' > > > [ 1935s] armv6hl-suse-linux-gnueabi/Makefile:949: recipe for target > > > 'obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o' failed > > > [ 1935s] make[3]: *** > > > [obj/armv6hl-suse-linux-gnueabi/opt/smp/hipe_arm_bifs.o] Error 1 > > > [ 1935s] make[3]: *** Waiting for unfinished jobs.... > > > > Confirmed. The recent merge of nox/ets-update_counter-4 is the culprit: > > that failed to update ARM correctly, and I think I also saw a typo in the > > other bits. > > > > I'll put together a correction today. > > There's also a serious error in the AMD64 code changes... I'll have to do > a very careful review of this stuff. https://github.com/erlang/otp/pull/663 From dangud@REDACTED Fri Mar 27 14:48:23 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 27 Mar 2015 14:48:23 +0100 Subject: [erlang-bugs] Segfault when using Observer In-Reply-To: References: Message-ID: Hi Adam I tested and could of course not replicate the issue here with wxWidgets-3.0.2. It is a bit weird that it happens, since it its the same code that is used to open a process info window. Also the stacktrace seems to indicate that it is inside wxWidgets event handling and not in wx driver code. So that gives me no clues either. On Mon, Mar 23, 2015 at 12:58 PM, Adam Lindberg wrote: > When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it > segfaults when inspecting a process from the Applications tab. This does > not happen when inspecting a process from the Processes tab. > > $ erl > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.3 (abort with ^G) > 1> observer:start(). > ok > 2> [1] 52545 segmentation fault erl > $ > > Full stack trace from OS X can be found here: > https://gist.github.com/eproxus/3d517e895c3e05f93bcb > > Cheers, > Adam > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Fri Mar 27 16:10:39 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 27 Mar 2015 16:10:39 +0100 Subject: [erlang-bugs] Segfault when using Observer In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 3:55 PM, Adam Krupicka wrote: > Hi, I think I have discovered a very similar (if not the same) issue. The > difference is that on my linux machine, only the observer app crashes and > gives a bit more useful stacktrace. I posted this on erlang-bugs about 25 > hours ago, but I still can't see the mail being published, so I will quote > it in its entirety here. Here goes: > > Seems unrelated to the original report, since erlang crashes shouldn't cause a seq fault. But thanks for the bugreport I will take a look. /Dan > Hi, > > I have discovered a bug that seems to sometimes occur when > opening a process status window. It looks like the observer expects > a string but, for some reason, gets an atom. Same thing was > happening on all nodes in the cluster, however, when I restarted > the cluster the problem disappeared. Probably just some random > glitch, but for the sake of completeness I thought I'd post here. > > Here's the crash: > > Child (unknown) crashed exiting: <0.51.0> {function_clause, > [{wxTextCtrl,appendText, > [{wx_ref,1083,wxTextCtrl,[]}, > > 'ebalancer@REDACTED'], > [{file,"gen/wxTextCtrl.erl"}, > {line,126}]}, > {observer_lib,link_entry2,3, > [{file,"observer_lib.erl"}, > {line,487}]}, > {observer_lib, > '-add_entries/6-fun-0-',5, > [{file,"observer_lib.erl"}, > {line,383}]}, > {observer_lib, > > '-add_entries/6-lc$^0/1-0-',2, > [{file,"observer_lib.erl"}, > {line,387}]}, > {observer_lib,add_box,6, > [{file,"observer_lib.erl"}, > {line,376}]}, > {observer_lib, > '-create_box/2-lc$^0/1-1-',2, > [{file,"observer_lib.erl"}, > {line,410}]}, > {observer_lib, > '-create_box/2-lc$^0/1-1-',2, > [{file,"observer_lib.erl"}, > {line,410}]}, > {observer_lib,create_box,2, > [{file,"observer_lib.erl"}, > {line,410}]}]} > > > If I find some extra time I'll have a look at the code and see if I can > submit a pull request. > > > Wx version I'm using is 3.0.2-2 (arch). > > Hope this helps, > AK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krupicka.adam@REDACTED Fri Mar 27 15:55:44 2015 From: krupicka.adam@REDACTED (Adam Krupicka) Date: Fri, 27 Mar 2015 15:55:44 +0100 Subject: [erlang-bugs] Segfault when using Observer Message-ID: Hi, I think I have discovered a very similar (if not the same) issue. The difference is that on my linux machine, only the observer app crashes and gives a bit more useful stacktrace. I posted this on erlang-bugs about 25 hours ago, but I still can't see the mail being published, so I will quote it in its entirety here. Here goes: Hi, I have discovered a bug that seems to sometimes occur when opening a process status window. It looks like the observer expects a string but, for some reason, gets an atom. Same thing was happening on all nodes in the cluster, however, when I restarted the cluster the problem disappeared. Probably just some random glitch, but for the sake of completeness I thought I'd post here. Here's the crash: Child (unknown) crashed exiting: <0.51.0> {function_clause, [{wxTextCtrl,appendText, [{wx_ref,1083,wxTextCtrl,[]}, 'ebalancer@REDACTED'], [{file,"gen/wxTextCtrl.erl"}, {line,126}]}, {observer_lib,link_entry2,3, [{file,"observer_lib.erl"}, {line,487}]}, {observer_lib, '-add_entries/6-fun-0-',5, [{file,"observer_lib.erl"}, {line,383}]}, {observer_lib, '-add_entries/6-lc$^0/1-0-',2, [{file,"observer_lib.erl"}, {line,387}]}, {observer_lib,add_box,6, [{file,"observer_lib.erl"}, {line,376}]}, {observer_lib, '-create_box/2-lc$^0/1-1-',2, [{file,"observer_lib.erl"}, {line,410}]}, {observer_lib, '-create_box/2-lc$^0/1-1-',2, [{file,"observer_lib.erl"}, {line,410}]}, {observer_lib,create_box,2, [{file,"observer_lib.erl"}, {line,410}]}]} If I find some extra time I'll have a look at the code and see if I can submit a pull request. Wx version I'm using is 3.0.2-2 (arch). Hope this helps, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Fri Mar 27 16:09:19 2015 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 27 Mar 2015 23:09:19 +0800 Subject: [erlang-bugs] observer crash in ERLANG/OTP 18.0rc1 Message-ID: I just built erlang/otp from git repo and could crash observer by: 1. Fire up erl 2. Eval observer:start(). in the REPL 3. Click `Trace Overview' in the observer window. I am on Darwin iMac 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 =ERROR REPORT==== 27-Mar-2015::17:29:42 === ** wx object server <0.43.0> terminating ** Last message in was {create_menus, [{"File", [{create_menu,306,"Load settings",[],append, false}, {create_menu,305,"Save settings",[],append, false}]}, {"Options", [{create_menu,310,"Output",[],append,false}, {create_menu,311,"Match Specifications",[], append,false}, {create_menu,312,"Default Process Options",[], append,false}]}]} ** When Server state == {state, {wx_ref,35,wxFrame,[]}, {wx_ref,37,wxMenuBar,[]}, [{"View", [{create_menu,101,"Refresh\tCtrl-R",[],append, false}, {create_menu,102,"Refresh interval",[],append, false}]}], {wx_ref,266,wxStatusBar,[]}, {wx_ref,47,wxNotebook,[]}, {wx_ref,46,wxPanel,[]}, {wx_ref,331,wxPanel,<0.55.0>}, {wx_ref,341,wxPanel,<0.59.0>}, {wx_ref,48,wxPanel,<0.47.0>}, {wx_ref,350,wxPanel,<0.60.0>}, {wx_ref,301,wxPanel,<0.53.0>}, {wx_ref,270,wxPanel,<0.49.0>}, <0.60.0>,nonode@REDACTED,[],[],false} ** Reason for termination == ** {{{badarg,0},{wxMenu,insert_3,3}}, [{wxe_util,rec,1,[{file,"wxe_util.erl"},{line,83}]}, {observer_lib,create_menu_item,3,[{file,"observer_lib.erl"},{line,324}]}, {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, {observer_lib,create_menu,5,[{file,"observer_lib.erl"},{line,293}]}, {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, {wx,foldl,3,[{file,"wx.erl"},{line,218}]}, {observer_lib,create_menus,3,[{file,"observer_lib.erl"},{line,285}]}, {wx,batch,1,[{file,"wx.erl"},{line,179}]}]} From jim.rosenblum@REDACTED Fri Mar 27 16:32:31 2015 From: jim.rosenblum@REDACTED (jim rosenblum) Date: Fri, 27 Mar 2015 11:32:31 -0400 Subject: [erlang-bugs] httpc / http 1.1. closes socket Message-ID: In http://erlang.org/pipermail/erlang-questions/2014-February/077788.html and elsewhere, users observed that httpc would occasionally encounter `{error,socket_closed_remotely}` when querying a web service of some sort. The workaround was to use http 1.0, as opposed to 1.1, which is somewhat of an unsatisfying resolution. I have encountered this same problem and have tried to create a minimal example that reproduces the issue using a public url to post a simple JSON body. I am hoping that the following provides enough information to constitute a useful bug report. The following code will quickly cause the problem to appear; however, the problem *disappears* when {"connection", "close"} is added to the header. In fact I cannot reproduce the problem ever when this header is used. My code is as follows: -module(httpc_bug). -export([test/0]). test()-> httpc:set_options([{max_keep_alive_length, 0}, {max_pipeline_length, 0}, {max_sessions, 0}]), test_put(0). test_put(N) -> Url = "https://posttestserver.com/post.php", ContentType= "application/json", Body = <<"{\"type\":\"body type\",\"value\":2}">>, Header = [], HttpOptions = [], Options = [], case httpc:request(post, {Url, Header, ContentType, Body}, HttpOptions, Options) of {ok, {{_V, _Cd, _R}, _RespHeader, B }} -> io:format("~p[~p]:~p~n?, [self(), N, B]), test_put(N+1); {error, Reason} -> io:format("~p: died after ~p iterations with: ~p. ~n.", [self(), N, Reason]) end. A typical run looks like this: Erlang/OTP 17 [erts-6.2] [source-aaaefb3] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.2 (abort with ^G) 1> inets:start(). ok 2> ssl:start(). ok 3> code:load_file(httpc_bug). {module,httpc_bug} 4> httpc_bug:test(1). [<0.15201.0>] <0.15201.0>[0]:"Successfully dumped 0 post variables.\nView it at http://www.posttestserver.com/data/2015/03/13/19.21.45157935823\nPost body was 30 chars long." <0.15201.0>[1]:"Successfully dumped 0 post variables.\nView it at http://www.posttestserver.com/data/2015/03/13/19.21.451784952425\nPost body was 30 chars long." . . SNIP . <0.15201.0>: died after 102 iterations with: socket_closed_remotely. I just did five runs, four died in under 410 iterations, and the fifth took 809 iterations. Again, adding {"connection", "close"} to the header causes the problem to disappear. By examining the contents of the http_manager__session_db before each call to the httpc:request, I am pretty sure that the flow goes: httpc_manager.erl line 759 ? within a handle_request clause handle_request(Request, State = #state{options = Options}) -> NewRequest = handle_cookies(generate_request_id(Request), State), SessionType = session_type(Options), case select_session(Request#request.method, Request#request.address, Request#request.scheme, SessionType, State) of {ok, HandlerPid} -> -> pipeline_or_keep_alive(NewRequest, HandlerPid, State); <- . . SNIP . To httpc_handler.erl line 323 ? within a handle_call where keep_alive requests are handled. Hope this is useful. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Fri Mar 27 17:22:12 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 27 Mar 2015 17:22:12 +0100 Subject: [erlang-bugs] observer crash in ERLANG/OTP 18.0rc1 In-Reply-To: References: Message-ID: Hi Today feels like "Have a nice Friday afternoon here comes observer crashes" :-) This one is already fixed and I have merged this today to master, will probably be pushed next week. On Fri, Mar 27, 2015 at 4:09 PM, Leo Liu wrote: > I just built erlang/otp from git repo and could crash observer by: > > 1. Fire up erl > 2. Eval observer:start(). in the REPL > 3. Click `Trace Overview' in the observer window. > > I am on Darwin iMac 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 > 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 > > =ERROR REPORT==== 27-Mar-2015::17:29:42 === > ** wx object server <0.43.0> terminating > ** Last message in was {create_menus, > [{"File", > [{create_menu,306,"Load settings",[],append, > false}, > {create_menu,305,"Save settings",[],append, > false}]}, > {"Options", > [{create_menu,310,"Output",[],append,false}, > {create_menu,311,"Match Specifications",[], > append,false}, > {create_menu,312,"Default Process > Options",[], > append,false}]}]} > ** When Server state == {state, > {wx_ref,35,wxFrame,[]}, > {wx_ref,37,wxMenuBar,[]}, > [{"View", > > [{create_menu,101,"Refresh\tCtrl-R",[],append, > false}, > {create_menu,102,"Refresh > interval",[],append, > false}]}], > {wx_ref,266,wxStatusBar,[]}, > {wx_ref,47,wxNotebook,[]}, > {wx_ref,46,wxPanel,[]}, > {wx_ref,331,wxPanel,<0.55.0>}, > {wx_ref,341,wxPanel,<0.59.0>}, > {wx_ref,48,wxPanel,<0.47.0>}, > {wx_ref,350,wxPanel,<0.60.0>}, > {wx_ref,301,wxPanel,<0.53.0>}, > {wx_ref,270,wxPanel,<0.49.0>}, > <0.60.0>,nonode@REDACTED,[],[],false} > ** Reason for termination == > ** {{{badarg,0},{wxMenu,insert_3,3}}, > [{wxe_util,rec,1,[{file,"wxe_util.erl"},{line,83}]}, > > {observer_lib,create_menu_item,3,[{file,"observer_lib.erl"},{line,324}]}, > {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, > {observer_lib,create_menu,5,[{file,"observer_lib.erl"},{line,293}]}, > {lists,foldl,3,[{file,"lists.erl"},{line,1261}]}, > {wx,foldl,3,[{file,"wx.erl"},{line,218}]}, > {observer_lib,create_menus,3,[{file,"observer_lib.erl"},{line,285}]}, > {wx,batch,1,[{file,"wx.erl"},{line,179}]}]} > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Sat Mar 28 00:09:21 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 28 Mar 2015 00:09:21 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> <5475E034.3030100@erlang.org> Message-ID: On Tue, Feb 3, 2015 at 11:25 PM, Tuncer Ayaz wrote: > On Wed, Nov 26, 2014 at 3:14 PM, Lukas Larsson wrote: >> >> On 26/11/14 12:29, Tuncer Ayaz wrote: >>> >>> On Tue, Sep 23, 2014 at 11:05 AM, Tuncer Ayaz wrote: >>>> >>>> On Mon, Sep 22, 2014 at 12:02 PM, Lukas Larsson wrote: >>>>> >>>>> On 17/09/14 19:23, Tuncer Ayaz wrote: >>>>>> >>>>>> On Wed, Sep 17, 2014 at 2:33 PM, Tuncer Ayaz wrote: >>>>>>> >>>>>>> Building OTP-17.3 with --enable-sanitizers=undefined, you can see >>>>>>> the following during the build of lib/wx/examples/demo: >>>>>>> ERLC ex_aui.beam >>>>>>> beam/bif.c:2828:5: runtime error: signed integer overflow: >>>>>>> 426141286 * 10 cannot be represented in type 'int' >>>>>>> >>>>>>> I thought this was also fixed. >>>>> >>>>> As did I. I wonder where that fix went... I've created a new fix >>>>> for it. >>>>> >>>>>> More during dialyzer --build_plt: >>>>>> beam/erl_process.c:9024:2: runtime error: signed integer overflow: >>>>>> 2147482509 + 2001 cannot be represented in type 'int' >>>>>> beam/erl_process.c:4908:35: runtime error: signed integer overflow: >>>>>> 3984 * 625175 cannot be represented in type 'int' >>>>>> >>>>> I've noticed these as well and a couple of other ones in >>>>> erl_process.c. I've added them to our backlog to fix. >>>> >>>> Thanks, and please keep us posted. >>> >>> What's the status? >> >> >> bif.c has been fixed, erl_process.c has not been fixed yet. > > Any status update? Still present in 18.0-rc1. From n.oxyde@REDACTED Sat Mar 28 15:05:53 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 28 Mar 2015 15:05:53 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> <5475E034.3030100@erlang.org> Message-ID: Le 28 mars 2015 ? 00:09, Tuncer Ayaz a ?crit : > Still present in 18.0-rc1. Which line? From tuncer.ayaz@REDACTED Sat Mar 28 22:49:27 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 28 Mar 2015 22:49:27 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> <5475E034.3030100@erlang.org> Message-ID: On Sat, Mar 28, 2015 at 3:05 PM, Anthony Ramine wrote: > Le 28 mars 2015 a 00:09, Tuncer Ayaz a ecrit: > > > Still present in 18.0-rc1. > > Which line? The issue(s) in erl_process.c. Lukas was working on it, and he wasn't quite finished yet. Building a comprehensive PLT (all OTP apps) triggers it consistently for me, but I'm sure there's a much simpler recipe for reproduction. From tuncer.ayaz@REDACTED Sat Mar 28 23:09:44 2015 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 28 Mar 2015 23:09:44 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> <5475E034.3030100@erlang.org> Message-ID: On Sat, Mar 28, 2015 at 10:49 PM, Tuncer Ayaz wrote: > On Sat, Mar 28, 2015 at 3:05 PM, Anthony Ramine wrote: > > Le 28 mars 2015 a 00:09, Tuncer Ayaz a ecrit: > > > > > Still present in 18.0-rc1. > > > > Which line? > > The issue(s) in erl_process.c. Lukas was working on it, and he > wasn't quite finished yet. Building a comprehensive PLT (all OTP > apps) triggers it consistently for me, but I'm sure there's a much > simpler recipe for reproduction. beam/erl_process.c:9114:2: runtime error: signed integer overflow: 2147482115 + 2001 cannot be represented in type 'int' From hufeng1987@REDACTED Sun Mar 29 08:53:11 2015 From: hufeng1987@REDACTED (Netroby) Date: Sun, 29 Mar 2015 14:53:11 +0800 Subject: [erlang-bugs] Want improve document about Getting Started Message-ID: By read the manual , we know how to compile and run module for example 3> c(helloworld). {ok,helloworld} 4> helloworld:start(). Hello world ok, this work as normal. But we can put two step into one, compile and execute 9> c(helloworld),helloworld:start(). if you want put more step in one single line input, you can split them with comma , Appreciate your time. ---------------------------- Netroby From erlang-bugs-mailing-list@REDACTED Sun Mar 29 17:47:37 2015 From: erlang-bugs-mailing-list@REDACTED (Luis Gerhorst) Date: Sun, 29 Mar 2015 17:47:37 +0200 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions Message-ID: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> Hi, Screenshot: http://f.cl.ly/items/0O0W0X0K1m390x3N1j1j/erlang-get.png I'm using solarized-theme (https://github.com/bbatsov/solarized-emacs ) and as you can see in the screenshot the local function "get" is highlighted the same way built in functions from the "erlang" module are highlighted. I use the melpa package, version 20150319.456 Best, Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Mar 29 20:02:53 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 29 Mar 2015 20:02:53 +0200 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions In-Reply-To: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> References: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> Message-ID: On Sun, Mar 29, 2015 at 5:47 PM, Luis Gerhorst < erlang-bugs-mailing-list@REDACTED> wrote: > I'm using solarized-theme (https://github.com/bbatsov/solarized-emacs > ) and as you can see in the > screenshot the local function "get" is highlighted the same way built in > functions from the "erlang" module are highlighted. > I have a guess as to why this happens. The get/1 function is defined in erlang:get/1. It is used to look up values in the process dictionary. The syntax highlighter doesn't understand that get/2 is defined locally in the current module, so it thinks your call to get is to the underlying 'erlang:get/1', not to ?MODULE:get/2. And all problems stems from there. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sun Mar 29 21:06:39 2015 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 29 Mar 2015 15:06:39 -0400 Subject: [erlang-bugs] Emacs package: Local function named "get" highlighted like built-in functions In-Reply-To: References: <196D0071-B16E-45BB-BDA8-7949699D5E84@luisgerhorst.de> Message-ID: On Sun, Mar 29, 2015 at 2:02 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Sun, Mar 29, 2015 at 5:47 PM, Luis Gerhorst < > erlang-bugs-mailing-list@REDACTED> wrote: > >> I'm using solarized-theme (https://github.com/bbatsov/solarized-emacs >> ) and as you can see in the >> screenshot the local function "get" is highlighted the same way built in >> functions from the "erlang" module are highlighted. >> > > I have a guess as to why this happens. The get/1 function is defined in > erlang:get/1. It is used to look up values in the process dictionary. The > syntax highlighter doesn't understand that get/2 is defined locally in the > current module, so it thinks your call to get is to the underlying > 'erlang:get/1', not to ?MODULE:get/2. And all problems stems from there. > Correct -- see lib/tools/emacs/erlang.el on the maint branch, line 759 (I would link to github but it's being ddos'ed right now so I can't get to it), where "get" is specified as part of an elisp variable holding erlang bif names. Erlang-mode highlights those names as symbols. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello@REDACTED Mon Mar 30 14:27:37 2015 From: hello@REDACTED (Adam Lindberg) Date: Mon, 30 Mar 2015 14:27:37 +0200 Subject: [erlang-bugs] Segfault when using Observer In-Reply-To: References: Message-ID: After some more investigation, it happens with ?any? erlang version 17.0, 17.3, 17.4 (haven?t tested older ones). I re-installed wxMac via Hombrew and compiled it myself (instead of installing the bottle) with the same results, but this still has the issue. Most likely it is something with my OS installation + wxMac version that doesn?t play well together, especially if it looks to you like the crash is inside wxWidgets code. Cheers, Adam > On 27 Mar 2015, at 14:48 , Dan Gudmundsson wrote: > > Hi Adam > > I tested and could of course not replicate the issue here with wxWidgets-3.0.2. > > It is a bit weird that it happens, since it its the same code that is used > to open a process info window. > > Also the stacktrace seems to indicate that it is inside wxWidgets event handling and not > in wx driver code. So that gives me no clues either. > > > On Mon, Mar 23, 2015 at 12:58 PM, Adam Lindberg > wrote: > When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it segfaults when inspecting a process from the Applications tab. This does not happen when inspecting a process from the Processes tab. > > $ erl > Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V6.3 (abort with ^G) > 1> observer:start(). > ok > 2> [1] 52545 segmentation fault erl > $ > > Full stack trace from OS X can be found here: https://gist.github.com/eproxus/3d517e895c3e05f93bcb > > Cheers, > Adam > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dangud@REDACTED Mon Mar 30 15:24:25 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 30 Mar 2015 15:24:25 +0200 Subject: [erlang-bugs] Segfault when using Observer In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 2:27 PM, Adam Lindberg wrote: > After some more investigation, it happens with ?any? erlang version 17.0, > 17.3, 17.4 (haven?t tested older ones). I re-installed wxMac via Hombrew > and compiled it myself (instead of installing the bottle) with the same > results, but this still has the issue. Most likely it is something with my > OS installation + wxMac version that doesn?t play well together, especially > if it looks to you like the crash is inside wxWidgets code. > > Which OS version? It might still be something observer or wx does wrong, but it is really hard to debug when I can't reproduce it or guess where something goes wrong since the stack is clean of any wx code except the call to the wxWidgets loop. Cheers /Dan Cheers, > Adam > > On 27 Mar 2015, at 14:48 , Dan Gudmundsson wrote: > > Hi Adam > > I tested and could of course not replicate the issue here with > wxWidgets-3.0.2. > > It is a bit weird that it happens, since it its the same code that is used > to open a process info window. > > Also the stacktrace seems to indicate that it is inside wxWidgets event > handling and not > in wx driver code. So that gives me no clues either. > > > On Mon, Mar 23, 2015 at 12:58 PM, Adam Lindberg wrote: > >> When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it >> segfaults when inspecting a process from the Applications tab. This does >> not happen when inspecting a process from the Processes tab. >> >> $ erl >> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] >> [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V6.3 (abort with ^G) >> 1> observer:start(). >> ok >> 2> [1] 52545 segmentation fault erl >> $ >> >> Full stack trace from OS X can be found here: >> https://gist.github.com/eproxus/3d517e895c3e05f93bcb >> >> Cheers, >> Adam >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello@REDACTED Mon Mar 30 15:45:20 2015 From: hello@REDACTED (Adam Lindberg) Date: Mon, 30 Mar 2015 15:45:20 +0200 Subject: [erlang-bugs] Segfault when using Observer In-Reply-To: References: Message-ID: OS X 10.10.2 (14C1514) with wxMac 3.0.2 (both bottled and non-bottled) installed via Homebrew. Cheers, Adam > On 30 Mar 2015, at 15:24 , Dan Gudmundsson wrote: > > On Mon, Mar 30, 2015 at 2:27 PM, Adam Lindberg > wrote: > After some more investigation, it happens with ?any? erlang version 17.0, 17.3, 17.4 (haven?t tested older ones). I re-installed wxMac via Hombrew and compiled it myself (instead of installing the bottle) with the same results, but this still has the issue. Most likely it is something with my OS installation + wxMac version that doesn?t play well together, especially if it looks to you like the crash is inside wxWidgets code. > > > Which OS version? > > It might still be something observer or wx does wrong, but it is really hard to debug when I > can't reproduce it or guess where something goes wrong since the stack is clean of any wx code except the call to the wxWidgets loop. > > Cheers > /Dan > > Cheers, > Adam > >> On 27 Mar 2015, at 14:48 , Dan Gudmundsson > wrote: >> >> Hi Adam >> >> I tested and could of course not replicate the issue here with wxWidgets-3.0.2. >> >> It is a bit weird that it happens, since it its the same code that is used >> to open a process info window. >> >> Also the stacktrace seems to indicate that it is inside wxWidgets event handling and not >> in wx driver code. So that gives me no clues either. >> >> >> On Mon, Mar 23, 2015 at 12:58 PM, Adam Lindberg > wrote: >> When using observer from 17.4 built with wxMac 3.0.2 on OS X 10.10.2, it segfaults when inspecting a process from the Applications tab. This does not happen when inspecting a process from the Processes tab. >> >> $ erl >> Erlang/OTP 17 [erts-6.3] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V6.3 (abort with ^G) >> 1> observer:start(). >> ok >> 2> [1] 52545 segmentation fault erl >> $ >> >> Full stack trace from OS X can be found here: https://gist.github.com/eproxus/3d517e895c3e05f93bcb >> >> Cheers, >> Adam >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From se-sss@REDACTED Mon Mar 30 14:30:14 2015 From: se-sss@REDACTED (=?koi8-r?B?88XSx8XKIOXSz8jJzg==?=) Date: Mon, 30 Mar 2015 15:30:14 +0300 Subject: [erlang-bugs] ^G does not work in erl.exe (Windows, x64, OTP 17.4) Message-ID: <6004051427718614@web17m.yandex.ru> Hello! I has just started reading tutorial and see that doing Ctrl-G in erl.exe has no effect: C:\>erl Eshell V6.3 (abort with ^G) 1> ^G Eshell V6.3 (abort with ^G) 1> ^G Eshell V6.3 (abort with ^G) 1> But it works in werl.exe: Erlang/OTP 17 [erts-6.3] [64-bit] [smp:8:8] [async-threads:10] Eshell V6.3 (abort with ^G) 1> User switch command --> Also Ctrl-Break just closes erl.exe while in werl.exe it gives (like it is written in manuals) following: Eshell V6.3 (abort with ^G) 1> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution Regards, Sergey