From peppe@REDACTED Tue Sep 1 10:41:14 2015 From: peppe@REDACTED (Peter Andersson E) Date: Tue, 1 Sep 2015 10:41:14 +0200 Subject: [erlang-bugs] CT custom framework leads to group mess In-Reply-To: References: Message-ID: <55E564AA.8090009@erlang.org> Hi Danil, We don't recommend you use a Test Server framework module to get access to more data, but use the Common Test Hooks feature instead. You get the same (even better) support for what you want to achieve that way. Best, Peter Ericsson AB, Erlang/OTP On 08/31/2015 10:53 PM, Danil Zagoskin wrote: > Hello! > > Recently I needed a more verbose error reports in common_test log. > Reading the code I found an option to specify a TEST_SERVER_FRAMEWORK > environment variable (and it's even documented here: > http://www1.erlang.org/documentation/doc-5.8/lib/test_server-3.4/doc/html/write_framework_chapter.html > ). > I implemented a simple proxy module, and my ct_run started to fail in > a very strange way ? it looks for a group from one suite with another > suite's group/1 function. > > I created a minimal set of files to reproduce the bug: > https://github.com/stolen/ct_custom_fw_bug > > Am I doing something wrong with this custom framework? > > -- > Danil Zagoskin | z@REDACTED > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergej.jurecko@REDACTED Tue Sep 1 14:20:31 2015 From: sergej.jurecko@REDACTED (=?UTF-8?Q?Sergej_Jure=C4=8Dko?=) Date: Tue, 1 Sep 2015 14:20:31 +0200 Subject: [erlang-bugs] erlang:monotonic_time() is negative Message-ID: hello, Using 18.0.3 on OS X 10.10.5. I even tried rebooting the machine to check if the time turns negative after a while, but it seems it is always negative. erlang:monotonic_time(). -576460736152226213 Other timing calls: erlang:system_info(time_correction). true erlang:system_info(os_monotonic_time_source). [{function,clock_get_time}, {clock_id,'SYSTEM_CLOCK'}, {resolution,10000000}, {extended,no}, {parallel,yes}, {time,593734054849752}] erlang:system_time(). 1441101200986915220 erlang:unique_integer(). -576460752303423486 erlang:system_info(os_system_time_source). [{function,clock_get_time}, {clock_id,'CALENDAR_CLOCK'}, {resolution,10000000}, {parallel,yes}, {time,1441101320775081000}] Sergej -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Sep 1 15:35:01 2015 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 1 Sep 2015 15:35:01 +0200 Subject: [erlang-bugs] erlang:monotonic_time() is negative In-Reply-To: References: Message-ID: Wow - we've invented a time machine - what stocks are going up tomorrow? /Joe On Tue, Sep 1, 2015 at 2:20 PM, Sergej Jure?ko wrote: > hello, > > Using 18.0.3 on OS X 10.10.5. I even tried rebooting the machine to check if > the time turns negative after a while, but it seems it is always negative. > > erlang:monotonic_time(). > -576460736152226213 > > Other timing calls: > > erlang:system_info(time_correction). > true > > erlang:system_info(os_monotonic_time_source). > [{function,clock_get_time}, > {clock_id,'SYSTEM_CLOCK'}, > {resolution,10000000}, > {extended,no}, > {parallel,yes}, > {time,593734054849752}] > > erlang:system_time(). > 1441101200986915220 > > erlang:unique_integer(). > -576460752303423486 > > erlang:system_info(os_system_time_source). > [{function,clock_get_time}, > {clock_id,'CALENDAR_CLOCK'}, > {resolution,10000000}, > {parallel,yes}, > {time,1441101320775081000}] > > Sergej > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From essen@REDACTED Tue Sep 1 15:42:02 2015 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 1 Sep 2015 15:42:02 +0200 Subject: [erlang-bugs] erlang:monotonic_time() is negative In-Reply-To: References: Message-ID: <55E5AB2A.40806@ninenines.eu> On 09/01/2015 02:20 PM, Sergej Jure?ko wrote: > hello, > > Using 18.0.3 on OS X 10.10.5. I even tried rebooting the machine to > check if the time turns negative after a while, but it seems it is > always negative. > > erlang:monotonic_time(). > -576460736152226213 From the docs, emphasis added: Different runtime system instances will use different unspecified points in time as base for their Erlang monotonic clocks. That is, it is pointless comparing monotonic times from different runtime system instances. Different runtime system instances may also place this unspecified point in time different relative runtime system start. It may be placed in the future (time at start will be a *negative value*), the past (time at start will be a positive value), or the runtime system start (time at start will be zero). It's surprising the first time I admit. -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From jesper.louis.andersen@REDACTED Tue Sep 1 15:43:03 2015 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 1 Sep 2015 15:43:03 +0200 Subject: [erlang-bugs] erlang:monotonic_time() is negative In-Reply-To: References: Message-ID: On Tue, Sep 1, 2015 at 2:20 PM, Sergej Jure?ko wrote: > Using 18.0.3 on OS X 10.10.5. I even tried rebooting the machine to check > if the time turns negative after a while, but it seems it is always > negative. > > erlang:monotonic_time(). > -576460736152226213 > This is the normal behavior. In order to use the full 60 bit signed value, it is custom to start at a negative number when starting a new Erlang node: 1> os:type(). {unix,freebsd} 2> erlang:monotonic_time(). -576460743520961806 1> os:type(). {unix,sunos} 2> erlang:monotonic_time(). -576460744933281955 And so on. You can only use monotonic_time() for doing checks relative to itself, as in: B = erlang:monotonic_time(), do_work(), E = erlang:monotonic_time(), Elapsed = erlang:convert_time_unit(E - B, native, micro_seconds), ... As Loic writes, check the document on time and time correction. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rapsey@REDACTED Tue Sep 1 15:51:12 2015 From: rapsey@REDACTED (Rapsey) Date: Tue, 1 Sep 2015 15:51:12 +0200 Subject: [erlang-bugs] erlang:monotonic_time() is negative In-Reply-To: References: Message-ID: Oh ok. Thanks for the explanation. Sergej On Tue, Sep 1, 2015 at 3:43 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Tue, Sep 1, 2015 at 2:20 PM, Sergej Jure?ko > wrote: > >> Using 18.0.3 on OS X 10.10.5. I even tried rebooting the machine to check >> if the time turns negative after a while, but it seems it is always >> negative. >> >> erlang:monotonic_time(). >> -576460736152226213 >> > > This is the normal behavior. In order to use the full 60 bit signed value, > it is custom to start at a negative number when starting a new Erlang node: > > 1> os:type(). > {unix,freebsd} > 2> erlang:monotonic_time(). > -576460743520961806 > > 1> os:type(). > {unix,sunos} > 2> erlang:monotonic_time(). > -576460744933281955 > > And so on. You can only use monotonic_time() for doing checks relative to > itself, as in: > > B = erlang:monotonic_time(), > do_work(), > E = erlang:monotonic_time(), > Elapsed = erlang:convert_time_unit(E - B, native, micro_seconds), > ... > > As Loic writes, check the document on time and time correction. > > > > -- > J. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Wed Sep 2 16:11:02 2015 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 2 Sep 2015 14:11:02 +0000 Subject: [erlang-bugs] Dialyzer crashes with Solver v2 failed: error:function_clause In-Reply-To: References: Message-ID: <56466BD70414EA48969B4064696CF28C21EF675D@ESESSMB207.ericsson.se> Hi, [ILYA:] > Following spec causes dialyzer to crash > > -opaque att() :: #att{} | attachment(). > More info is here https://gist.github.com/iilyak/25a2534b65b6972bf251 The bug was fixed in commit d57dea02 (OTP 18.1). Best regards, Hans Bolinder, Erlang/OTP team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From benmmurphy@REDACTED Wed Sep 2 16:15:33 2015 From: benmmurphy@REDACTED (Ben Murphy) Date: Wed, 2 Sep 2015 15:15:33 +0100 Subject: [erlang-bugs] R18 Unbounded SSL Session ETS Table Growth Message-ID: I've seen in production that the ssl_session_cache ETS table can become very large which will start to cause new SSL connections to take > 5 seconds to establish. The root cause of this is that multiple SSL sessions are stored for a particular SSL connection configuration even though only 1 (the most recent) is needed. So the ETS table is keyed by {Host, Port, SessionID} but there a bunch of other parameters that need to match for a session to be resumed for example the client certificate and compression algorithm also need to match. So what the current code does is create a new entry into the table for each connection (even if session reuse is not enabled!!) and then when you create a new connection it will iterate through all the matching sessions for that {Host,Port} and check that the other parameters match. Looking at the code sessions are only removed from this table when a lifetime is reached which is configurable but defaults to 24 hours or if a FATAL error happens on a connection with that ID. In the pathological case where a server supplies a session ID but never supports resuming it this causes the session table to grow at the same rate as new connections are established. This makes establishing N connections take O(N^2) work. Also, in the case when {reuse_sessions, false} has been supplied the session should not be added to the table because a new entry will be added to the table every time and will only be removed after 24 hours. We've witnessed the catastrophic slow down occur when making a requests against a server that normally resumes sessions properly. I suspect this is because a) it started failing to resume sessions because of some failure on their side or b) it's session lifetime was considerably less than 24 hours and erlang started to try to resume failed sessions and continuously created new sessions because of this. I think it is also important to note that while the register_unique_session fix would fix the memory leak if it worked in this situation it would cause a new session to be created each time and make ssl session caching pointless until the erlang session expired. I think it would be preferable to create a new session and delete the old one to preserve the uniqueness but I'm not sure how this could be done ETS without creating a race that would generate multiple sessions. The other alternative would be to delete sessions that are known to not resume. For example if you try to resume a session and the server no longer knows about it this is known by the client because the client has to go through the whole handshake. I think this was meant to be fixed in by register_unique_session fucntion but the fix does not work because it assumes the return value of select_session is [#session{}] when it is really [ [binary(), #session{}] ]. https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L564 This is an example of the broken behaviour with reuse_sessions: false (should work on R16B02 and R18). 1> application:ensure_all_started(ssl). {ok,[crypto,asn1,public_key,ssl]} 2> ets:info(element(2, sys:get_state(whereis(ssl_manager)))). [{compressed,false}, {memory,107}, {owner,<0.45.0>}, {heir,none}, {name,ssl_otp_session_cache}, {size,0}, {node,nonode@REDACTED}, {named_table,false}, {type,ordered_set}, {keypos,1}, {protection,protected}] 3> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 4> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 5> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 6> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 7> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 8> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 9> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 10> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 11> ssl:close(element(2, ssl:connect("google.com", 443, [{reuse_sessions, false}]))). ok 12> ets:info(element(2, sys:get_state(whereis(ssl_manager)))). [{compressed,false}, {memory,881}, {owner,<0.45.0>}, {heir,none}, {name,ssl_otp_session_cache}, {size,9}, {node,nonode@REDACTED}, {named_table,false}, {type,ordered_set}, {keypos,1}, {protection,protected}] From sg2342@REDACTED Wed Sep 2 20:47:34 2015 From: sg2342@REDACTED (Stefan Grundmann) Date: Wed, 2 Sep 2015 18:47:34 +0000 Subject: [erlang-bugs] R18 Unbounded SSL Session ETS Table Growth In-Reply-To: References: Message-ID: <20150902184734.GA42575@seth> hi, i think, that the default ssl session cache callback module is unsuitable for erlang TLS servers that see connections from lots of clients. In use cases where session reuse is not needed: {session_cb,null_ssl_session_cb} in ssl app environment and -module_null_ssl_session_cb). -behaviour(ssl_session_cache_api). -export([delete/2,foldl/3,init/1,lookup/2, select_session/2,terminate/1,update/3]). init(_) -> invalid. terminate(_) -> ok. lookup(_,_) -> undefined update(_,_,_) -> ok delete(_,_) -> ok foldl(_,Acc,_) -> Acc. select_session(_,_) -> []. provides an easy workaround. best regards Stefan Grundmann On Wed, Sep 02, 2015 at 03:15:33PM +0100, Ben Murphy wrote: > I've seen in production that the ssl_session_cache ETS table can > become very large which will start to cause new SSL connections to > take > 5 seconds to establish. The root cause of this is that multiple > SSL sessions are stored for a particular SSL connection configuration > even though only 1 (the most recent) is needed. > > So the ETS table is keyed by {Host, Port, SessionID} but there a bunch > of other parameters that need to match for a session to be resumed for > example the client certificate and compression algorithm also need to > match. So what the current code does is create a new entry into the > table for each connection (even if session reuse is not enabled!!) and > then when you create a new connection it will iterate through all the > matching sessions for that {Host,Port} and check that the other > parameters match. > > Looking at the code sessions are only removed from this table when a > lifetime is reached which is configurable but defaults to 24 hours or > if a FATAL error happens on a connection with that ID. > > In the pathological case where a server supplies a session ID but > never supports resuming it this causes the session table to grow at > the same rate as new connections are established. This makes > establishing N connections take O(N^2) work. Also, in the case when > {reuse_sessions, false} has been supplied the session should not be > added to the table because a new entry will be added to the table > every time and will only be removed after 24 hours. > > We've witnessed the catastrophic slow down occur when making a > requests against a server that normally resumes sessions properly. I > suspect this is because a) it started failing to resume sessions > because of some failure on their side or b) it's session lifetime was > considerably less than 24 hours and erlang started to try to resume > failed sessions and continuously created new sessions because of this. > I think it is also important to note that while the > register_unique_session fix would fix the memory leak if it worked in > this situation it would cause a new session to be created each time > and make ssl session caching pointless until the erlang session > expired. I think it would be preferable to create a new session and > delete the old one to preserve the uniqueness but I'm not sure how > this could be done ETS without creating a race that would generate > multiple sessions. The other alternative would be to delete sessions > that are known to not resume. For example if you try to resume a > session and the server no longer knows about it this is known by the > client because the client has to go through the whole handshake. > > I think this was meant to be fixed in by register_unique_session > fucntion but the fix does not work because it assumes the return value > of select_session is [#session{}] when it is really [ [binary(), > #session{}] ]. > > https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L564 > > This is an example of the broken behaviour with reuse_sessions: false > (should work on R16B02 and R18). > > 1> application:ensure_all_started(ssl). > {ok,[crypto,asn1,public_key,ssl]} > 2> ets:info(element(2, sys:get_state(whereis(ssl_manager)))). > [{compressed,false}, > {memory,107}, > {owner,<0.45.0>}, > {heir,none}, > {name,ssl_otp_session_cache}, > {size,0}, > {node,nonode@REDACTED}, > {named_table,false}, > {type,ordered_set}, > {keypos,1}, > {protection,protected}] > 3> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 4> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 5> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 6> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 7> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 8> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 9> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 10> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 11> ssl:close(element(2, ssl:connect("google.com", 443, > [{reuse_sessions, false}]))). > ok > 12> ets:info(element(2, sys:get_state(whereis(ssl_manager)))). > [{compressed,false}, > {memory,881}, > {owner,<0.45.0>}, > {heir,none}, > {name,ssl_otp_session_cache}, > {size,9}, > {node,nonode@REDACTED}, > {named_table,false}, > {type,ordered_set}, > {keypos,1}, > {protection,protected}] > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Ingela.Anderton.Andin@REDACTED Thu Sep 3 16:00:49 2015 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 3 Sep 2015 16:00:49 +0200 Subject: [erlang-bugs] R18 Unbounded SSL Session ETS Table Growth In-Reply-To: References: Message-ID: <55E85291.4030409@ericsson.com> Hi! See in line comments below: On 09/02/2015 04:15 PM, Ben Murphy wrote: > I've seen in production that the ssl_session_cache ETS table can > become very large which will start to cause new SSL connections to > take > 5 seconds to establish. The root cause of this is that multiple > SSL sessions are stored for a particular SSL connection configuration > even though only 1 (the most recent) is needed. > > So the ETS table is keyed by {Host, Port, SessionID} but there a bunch > of other parameters that need to match for a session to be resumed for > example the client certificate and compression algorithm also need to > match. So what the current code does is create a new entry into the > table for each connection (even if session reuse is not enabled!!) and > then when you create a new connection it will iterate through all the > matching sessions for that {Host,Port} and check that the other > parameters match. > > Looking at the code sessions are only removed from this table when a > lifetime is reached which is configurable but defaults to 24 hours or > if a FATAL error happens on a connection with that ID. > > In the pathological case where a server supplies a session ID but > never supports resuming it this causes the session table to grow at > the same rate as new connections are established. This makes > establishing N connections take O(N^2) work. Also, in the case when > {reuse_sessions, false} has been supplied the session should not be > added to the table because a new entry will be added to the table > every time and will only be removed after 24 hours. > > We've witnessed the catastrophic slow down occur when making a > requests against a server that normally resumes sessions properly. I > suspect this is because a) it started failing to resume sessions > because of some failure on their side or b) it's session lifetime was > considerably less than 24 hours and erlang started to try to resume > failed sessions and continuously created new sessions because of this. > I think it is also important to note that while the > register_unique_session fix would fix the memory leak if it worked in > this situation it would cause a new session to be created each time > and make ssl session caching pointless until the erlang session > expired. I think it would be preferable to create a new session and > delete the old one to preserve the uniqueness but I'm not sure how > this could be done ETS without creating a race that would generate > multiple sessions. The other alternative would be to delete sessions > that are known to not resume. For example if you try to resume a > session and the server no longer knows about it this is known by the > client because the client has to go through the whole handshake. > > I think this was meant to be fixed in by register_unique_session > fucntion but the fix does not work because it assumes the return value > of select_session is [#session{}] when it is really [ [binary(), > #session{}] ]. Thank you for the detailed explanations and suggestions. Well yes there is definitely a bug here. I am analyzing the best way to fix it now. I think in the short run we will fix so that register_unique_session works as intended. And we will analyze if there are further improvements that can be done to keep the session table "fresh" and small. > https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl_manager.erl#L564 Regards Ingela Erlang/OTP team - Ericsson AB From mattevans123@REDACTED Thu Sep 3 20:52:37 2015 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 3 Sep 2015 14:52:37 -0400 Subject: [erlang-bugs] Erlang (beam.smp) corefile R17 Message-ID: Our regressions hit a core-file for beam.smp running version 17 (erts-6.2): [New LWP 2106] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/lib/erlang/erts-6.2/bin/beam.smp -K true -A 24 -P 350000 -- -root /usr/lib'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004b26cf in export_list () (gdb) bt #0 0x00000000004b26cf in export_list () #1 0x00000000004efa67 in delete_code () #2 0x00000000004efb47 in beam_make_current_old () #3 0x00000000004e76e6 in insert_new_code () #4 0x00000000004e8f97 in erts_finish_loading () #5 0x00000000004f100c in finish_loading_1 () #6 0x00000000004e2133 in process_main () #7 0x000000000048071d in sched_thread_func () #8 0x0000000000549f89 in thr_wrapper () #9 0x00007f8464eb4a30 in start_thread () from /lib/libpthread.so.0 #10 0x00007f8464a1353d in clone () from /lib/libc.so.6 (gdb) 14:51:07:# erlErlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.2 (abort with ^G) 1> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Fri Sep 4 02:05:16 2015 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 3 Sep 2015 20:05:16 -0400 Subject: [erlang-bugs] Erlang (beam.smp) corefile R17 In-Reply-To: References: Message-ID: I should add that it's likely that erl_parse:parse_form/1, compile:forms/2 and/or parse code:load_binary/3 was been called at this time. The CPU is 4 core Intel Atom processor. Thanks From: mattevans123@REDACTED To: erlang-bugs@REDACTED Date: Thu, 3 Sep 2015 14:52:37 -0400 Subject: [erlang-bugs] Erlang (beam.smp) corefile R17 Our regressions hit a core-file for beam.smp running version 17 (erts-6.2): [New LWP 2106] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/lib/erlang/erts-6.2/bin/beam.smp -K true -A 24 -P 350000 -- -root /usr/lib'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004b26cf in export_list () (gdb) bt #0 0x00000000004b26cf in export_list () #1 0x00000000004efa67 in delete_code () #2 0x00000000004efb47 in beam_make_current_old () #3 0x00000000004e76e6 in insert_new_code () #4 0x00000000004e8f97 in erts_finish_loading () #5 0x00000000004f100c in finish_loading_1 () #6 0x00000000004e2133 in process_main () #7 0x000000000048071d in sched_thread_func () #8 0x0000000000549f89 in thr_wrapper () #9 0x00007f8464eb4a30 in start_thread () from /lib/libpthread.so.0 #10 0x00007f8464a1353d in clone () from /lib/libc.so.6 (gdb) 14:51:07:# erlErlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.2 (abort with ^G) 1> _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Mon Sep 7 17:18:43 2015 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 7 Sep 2015 17:18:43 +0200 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message In-Reply-To: <21945.8617.922895.528392@gargle.gargle.HOWL> References: <21945.8617.922895.528392@gargle.gargle.HOWL> Message-ID: <55EDAAD3.5090303@ericsson.com> On 07/29/2015 08:55 PM, Mikael Pettersson wrote: > James Fish writes: > > When using {message, {process_dump}} in a trace the VM can abort on OTP > > R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic > > x86_64: > > > > TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: > > 0x7f9c183ee6d2 > > Aborted (core dumped) > > > > #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at > > ../sysdeps/unix/sysv/linux/raise.c:55 > > #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 > > #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: > > 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at > > beam/erl_term.c:48 > > #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 > > #4 0x00000000004cf12e in print_term (obj_base=, > > dcount=, obj=140308398401234, arg=0x7f9c1d780078, > > fn=0x630a10 ) at beam/erl_printf_term.c:352 > > #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, > > term=, precision=99999, term_base=) at > > beam/erl_printf_term.c:657 > > #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 > > , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b "%T\n", > > ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 > > #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED=0x7f9c1d780078, > > format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED=0x7f9c198fc640) > > at common/erl_printf.c:459 > > #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, > > arg=arg@REDACTED=0x7f9c1d780078, > > format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 > > #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, > > to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 > > #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED=0x7f9c1d780078, > > p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 > > #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, > > to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at > > beam/break.c:339 > > #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, > > bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, > > base=base@REDACTED=0x0, > > termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, > > in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at > > beam/erl_db_util.c:2404 > > #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, > > mpsp=, args=args@REDACTED=0x7f9c198fca70, > > num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, > > return_flags=return_flags@REDACTED=0x7f9c198fca14) at > > beam/erl_db_util.c:1243 > > #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, > > mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, > > args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, > > tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at > > beam/erl_trace.c:1873 > > #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, ms= > out>, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 > > #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 > > #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 > > #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at > > beam/erl_process.c:8021 > > #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at > > pthread/ethread.c:114 > > #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at > > pthread_create.c:333 > > #21 0x00007f9c1c640eed in clone () at > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > > > A minimal example: > > > > c("test.erl"), > > dbg:tracer(), > > dbg:p(self(), [call]), > > dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), > > test:sum(<<0>>, 0). > > > > test.erl: > > > > -module(test). > > > > -export([sum/2]). > > > > sum(<>, Acc) -> > > sum(Rest, Acc + identity(Int)); > > sum(<<>>, Acc) -> Acc. > > > > identity(Int) -> > > Int. > > I can reproduce, with otp 18.0.2 on Linux x86_64 w/ gcc-4.9.3. > > Inspecting the term at the final et_abort() in tag_val_def() gave me nonsense data > (it looked like a perfectly fine 2-tuple), but adding an et_abort() at the end of the > TAG_PRIMARY_BOXED case showed me a boxed term with header 0x144, a BIN_MATCHSTATE_SUBTAG, > which isn't allowed here (it's not a user-visible term type). > > Running with erl -smp disable didn't prevent the error, so it's hopefully > not a concurrency problem. > This bug will be fixed in OTP 18.1 planned for 23 September. The fix based on 17.5.6.1 can be found here: https://github.com/sverker/otp/commit/a22b5ba19193e3f39129fadd20d375f6cc3f8529 /Sverker, Erlang/OTP Ericsson From jens@REDACTED Tue Sep 8 23:09:19 2015 From: jens@REDACTED (=?UTF-8?Q?Jens_P=C3=A1ll?=) Date: Tue, 08 Sep 2015 21:09:19 +0000 Subject: [erlang-bugs] =?utf-8?q?file=3Asendfile_broken_on_FreeBSD=3F?= Message-ID: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> Hi I've been doing some tests using file:sendfile on FreeBSD 10 and it seems to be broken. It's unable to send files that are larger than the OS send buffer. For example, if the buffer is 32KB, then only 48.996 bytes are sent to the client but from time to time it sends 130.708 bytes. It's always those numbers of bytes sent, 48.996 being the more popular one. I discovered this when using Cowboy. I contacted Luic and we have been discussing some options, like the server could be closing the socket too soon. I created a simple test server to try things out where I for example delayed the closing of the socket well beyond the time it took the client to receive a full buffer. It had no effect, that is, the client just received its one and a half buffer and then waited until the server got to closing the socket. I tried both versions of sendfile. If I use gen_tcp:send instead, the data is sent without any problems so I know the server works correctly. Luic is planning on testing this in a few days but since I'm pretty sure (I can't rule out the possibility that I could be doing something wrong) the problem lies with Erlang itself I decided to post this here to get some further feedback. I have a test server and client on github if someone cares to take a look: https://github.com/theom/eclm Thanks, Jens P?ll -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Wed Sep 9 09:33:45 2015 From: garazdawi@REDACTED (Lukas Larsson) Date: Wed, 9 Sep 2015 09:33:45 +0200 Subject: [erlang-bugs] file:sendfile broken on FreeBSD? In-Reply-To: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> References: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> Message-ID: Hello Jens, Thanks for the bug report. I cannot find any information about which versions of Erlang/OTP you have tried this on. Lukas On Tue, Sep 8, 2015 at 11:09 PM, Jens P?ll wrote: > Hi > > I've been doing some tests using file:sendfile on FreeBSD 10 and it seems > to be broken. It's unable to send files that are larger than the OS send > buffer. > > For example, if the buffer is 32KB, then only 48.996 bytes are sent to the > client but from time to time it sends 130.708 bytes. It's always those > numbers of bytes sent, 48.996 being the more popular one. > > I discovered this when using Cowboy. I contacted Luic and we have been > discussing some options, like the server could be closing the socket too > soon. I created a simple test server to try things out where I for example > delayed the closing of the socket well beyond the time it took the client > to receive a full buffer. It had no effect, that is, the client just > received its one and a half buffer and then waited until the server got to > closing the socket. I tried both versions of sendfile. > > If I use gen_tcp:send instead, the data is sent without any problems so I > know the server works correctly. > > Luic is planning on testing this in a few days but since I'm pretty sure > (I can't rule out the possibility that I could be doing something wrong) > the problem lies with Erlang itself I decided to post this here to get some > further feedback. > > I have a test server and client on github if someone cares to take a look: > https://github.com/theom/eclm > > Thanks, > > Jens P?ll > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Sep 9 10:25:33 2015 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 9 Sep 2015 10:25:33 +0200 Subject: [erlang-bugs] file:sendfile broken on FreeBSD? In-Reply-To: References: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> Message-ID: <55EFECFD.9010206@ninenines.eu> For reference: https://github.com/ninenines/cowboy/issues/889#issuecomment-138704428 Says OTP 18. On 09/09/2015 09:33 AM, Lukas Larsson wrote: > Hello Jens, > > Thanks for the bug report. > > I cannot find any information about which versions of Erlang/OTP you > have tried this on. > > Lukas > > On Tue, Sep 8, 2015 at 11:09 PM, Jens P?ll > wrote: > > __ > > Hi > > I've been doing some tests using file:sendfile on FreeBSD 10 and it > seems to be broken. It's unable to send files that are larger than > the OS send buffer. > > For example, if the buffer is 32KB, then only 48.996 bytes are sent > to the client but from time to time it sends 130.708 bytes. It's > always those numbers of bytes sent, 48.996 being the more popular one. > > I discovered this when using Cowboy. I contacted Luic and we have > been discussing some options, like the server could be closing the > socket too soon. I created a simple test server to try things out > where I for example delayed the closing of the socket well beyond > the time it took the client to receive a full buffer. It had no > effect, that is, the client just received its one and a half buffer > and then waited until the server got to closing the socket. I tried > both versions of sendfile. > > If I use gen_tcp:send instead, the data is sent without any problems > so I know the server works correctly. > > Luic is planning on testing this in a few days but since I'm pretty > sure (I can't rule out the possibility that I could be doing > something wrong) the problem lies with Erlang itself I decided to > post this here to get some further feedback. > > I have a test server and client on github if someone cares to take a > look: https://github.com/theom/eclm > > Thanks, > > Jens P?ll > > > _______________________________________________ > 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 > -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From erlangsiri@REDACTED Wed Sep 9 10:31:22 2015 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 9 Sep 2015 10:31:22 +0200 Subject: [erlang-bugs] supervisor transient child error? In-Reply-To: <559F2597.7030909@gmail.com> References: <559F2597.7030909@gmail.com> Message-ID: Hi Michael, I think that the child spec is kept in the supervisor so that one is allowed to do supervisor:restart_child/2. This has been the behavior at least as far back as the git repository goes. And given that the text was changed as far back as OTP-R8B, I don't think that the old documentation is a reason for changing this behavior. Regards /siri 2015-07-10 3:53 GMT+02:00 Michael Truog : > Hi, > > I have noticed that when the supervisor has a child process with the > childspec restart set to transient, and the process terminates in a way > that is not abnormal, the childspec remains within the supervisor. This > appears to be an error based on old documentation: "When a temporary > child dies for any reason or a transient child dies normally, the child > is removed from the supervisor." ( > http://www.erlang.org/documentation/doc-4.8.2/lib/stdlib-1.6.1/doc/html/supervisor.html). > The new documentation states: "a transient child process will be > restarted only if it terminates abnormally, i.e. with another exit reason > than normal, shutdown or {shutdown,Term}" ( > http://www.erlang.org/doc/man/supervisor.html), and this statement is > true with the current supervisor code. > > Is it an error that transient processes that terminate in a way that is > not abnormal do not get removed from the supervisor? I think it is, but I > am not sure if this was accepted legacy behavior that the documentation > didn't want to contradict. I have an example below with output: > > -module(test). > -behaviour(supervisor). > -export([start_link/0, test_child/0, test/0, init/1]). > start_link() -> > supervisor:start_link({local, ?MODULE}, ?MODULE, []). > test_child() -> > {ok, erlang:spawn_link(fun() -> erlang:exit(normal) end)}. > test() -> > ChildSpec = {test, {test, test_child, []}, transient, 2000, worker, > []}, > supervisor:start_child(?MODULE, ChildSpec). > init([]) -> > {ok, {{one_for_one, 5, 300}, []}}. > > > Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:2:2] [ds:2:2:10] > [async-threads:10] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1> {ok, Sup} = test:start_link(). > {ok,<0.35.0>} > 2> erlang:unlink(Sup). > true > 3> {ok, P} = test:test(). > {ok,<0.38.0>} > 4> erlang:is_process_alive(P). > false > 5> supervisor:which_children(test). > [{test,undefined,worker,[]}] > 6> test:test(). > {error,already_present} > > Isn't keeping the entry in the supervisor, after a termination that is not > abnormal, an error? > > Thanks, > Michael > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Wed Sep 9 11:06:27 2015 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 09 Sep 2015 02:06:27 -0700 Subject: [erlang-bugs] supervisor transient child error? In-Reply-To: References: <559F2597.7030909@gmail.com> Message-ID: <55EFF693.7040506@gmail.com> On 09/09/2015 01:31 AM, Siri Hansen wrote: > Hi Michael, > > I think that the child spec is kept in the supervisor so that one is allowed to do supervisor:restart_child/2. This has been the behavior at least as far back as the git repository goes. And given that the text was changed as far back as OTP-R8B, I don't think that the old documentation is a reason for changing this behavior. That is fine, but documentation could be added to make sure this behavior is clear, since it is contrary to the definition of "transient": 1a passing especially quickly into and out of existence (http://www.merriam-webster.com/dictionary/transient) I assume temporary has a similar problem. > > Regards > /siri > > > 2015-07-10 3:53 GMT+02:00 Michael Truog >: > > Hi, > > I have noticed that when the supervisor has a child process with the childspec restart set to transient, and the process terminates in a way that is not abnormal, the childspec remains within the supervisor. This appears to be an error based on old documentation: "When a |temporary|child dies for any reason or a |transient|child dies normally, the child is removed from the supervisor." (http://www.erlang.org/documentation/doc-4.8.2/lib/stdlib-1.6.1/doc/html/supervisor.html). The new documentation states: "a transientchild process will be restarted only if it terminates abnormally, i.e. with another exit reason than normal, shutdownor {shutdown,Term}" (http://www.erlang.org/doc/man/supervisor.html), and this statement is true with the current supervisor code. > > Is it an error that transient processes that terminate in a way that is not abnormal do not get removed from the supervisor? I think it is, but I am not sure if this was accepted legacy behavior that the documentation didn't want to contradict. I have an example below with output: > > -module(test). > -behaviour(supervisor). > -export([start_link/0, test_child/0, test/0, init/1]). > start_link() -> > supervisor:start_link({local, ?MODULE}, ?MODULE, []). > test_child() -> > {ok, erlang:spawn_link(fun() -> erlang:exit(normal) end)}. > test() -> > ChildSpec = {test, {test, test_child, []}, transient, 2000, worker, []}, > supervisor:start_child(?MODULE, ChildSpec). > init([]) -> > {ok, {{one_for_one, 5, 300}, []}}. > > > Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:10] [kernel-poll:false] > > Eshell V7.0 (abort with ^G) > 1> {ok, Sup} = test:start_link(). > {ok,<0.35.0>} > 2> erlang:unlink(Sup). > true > 3> {ok, P} = test:test(). > {ok,<0.38.0>} > 4> erlang:is_process_alive(P). > false > 5> supervisor:which_children(test). > [{test,undefined,worker,[]}] > 6> test:test(). > {error,already_present} > > Isn't keeping the entry in the supervisor, after a termination that is not abnormal, an error? > > Thanks, > Michael > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens@REDACTED Wed Sep 9 11:13:17 2015 From: jens@REDACTED (=?UTF-8?Q?Jens_P=C3=A1ll?=) Date: Wed, 09 Sep 2015 09:13:17 +0000 Subject: [erlang-bugs] =?utf-8?q?file=3Asendfile_broken_on_FreeBSD=3F?= In-Reply-To: References: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> Message-ID: <24c322d23c0bf42bcce6034b2a36a65c@axonehf.com> Ah, sorry about that. I'm using version 18 (erts-7.0). Luic suggested I'd try disabling the async threads (+A 0) but I got the same results. JP On 09.09.2015 07:33, Lukas Larsson wrote: > Hello Jens, > > Thanks for the bug report. > > I cannot find any information about which versions of Erlang/OTP you have tried this on. > > Lukas > > On Tue, Sep 8, 2015 at 11:09 PM, Jens P?ll wrote: > >> Hi >> >> I've been doing some tests using file:sendfile on FreeBSD 10 and it seems to be broken. It's unable to send files that are larger than the OS send buffer. >> >> For example, if the buffer is 32KB, then only 48.996 bytes are sent to the client but from time to time it sends 130.708 bytes. It's always those numbers of bytes sent, 48.996 being the more popular one. >> >> I discovered this when using Cowboy. I contacted Luic and we have been discussing some options, like the server could be closing the socket too soon. I created a simple test server to try things out where I for example delayed the closing of the socket well beyond the time it took the client to receive a full buffer. It had no effect, that is, the client just received its one and a half buffer and then waited until the server got to closing the socket. I tried both versions of sendfile. >> >> If I use gen_tcp:send instead, the data is sent without any problems so I know the server works correctly. >> >> Luic is planning on testing this in a few days but since I'm pretty sure (I can't rule out the possibility that I could be doing something wrong) the problem lies with Erlang itself I decided to post this here to get some further feedback. >> >> I have a test server and client on github if someone cares to take a look: https://github.com/theom/eclm [1] >> >> Thanks, >> >> Jens P?ll >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs [2] Links: ------ [1] https://github.com/theom/eclm [2] http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Sep 10 11:08:40 2015 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 10 Sep 2015 11:08:40 +0200 Subject: [erlang-bugs] gen_fsm:reply returns wrong value In-Reply-To: <55D2DE27.30308@comarch.pl> References: <559FD23E.4080708@comarch.pl> <55D2DE27.30308@comarch.pl> Message-ID: Hi Aleksander! Thank you for the report! The documentation will be corrected in OTP-18.1. Regards /siri 2015-08-18 9:26 GMT+02:00 Aleksander Nycz : > Hello, > > Manual claims that gen_fsm:reply returns value 'true': > > http://www.erlang.org/doc/man/gen_fsm.html#reply-2 > > reply(Caller, Reply) -> true > > but code shows that different value is returned: > > %% Send a reply to the client.reply({To, Tag}, Reply) -> > catch To ! {Tag, Reply}. > > > Regards > Aleksander Nycz > > > -- > Aleksander Nycz > Chief Designer > Telco_021 BSS R&D > Comarch SA > Phone: +48 17 785 5909 > Mobile: +48 691 464 275 > website: www.comarch.pl > > > _______________________________________________ > 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 Thu Sep 10 11:23:25 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 10 Sep 2015 11:23:25 +0200 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message In-Reply-To: References: Message-ID: <22001.19469.244196.903279@gargle.gargle.HOWL> James Fish writes: > When using {message, {process_dump}} in a trace the VM can abort on OTP > R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic > x86_64: > > TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: > 0x7f9c183ee6d2 > Aborted (core dumped) > > #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at > ../sysdeps/unix/sysv/linux/raise.c:55 > #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 > #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: > 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at > beam/erl_term.c:48 > #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 > #4 0x00000000004cf12e in print_term (obj_base=, > dcount=, obj=140308398401234, arg=0x7f9c1d780078, > fn=0x630a10 ) at beam/erl_printf_term.c:352 > #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, > term=, precision=99999, term_base=) at > beam/erl_printf_term.c:657 > #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 > , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b "%T\n", > ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 > #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED=0x7f9c1d780078, > format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED=0x7f9c198fc640) > at common/erl_printf.c:459 > #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, > arg=arg@REDACTED=0x7f9c1d780078, > format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 > #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, > to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 > #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED=0x7f9c1d780078, > p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 > #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, > to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at > beam/break.c:339 > #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, > bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, > base=base@REDACTED=0x0, > termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, > in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at > beam/erl_db_util.c:2404 > #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, > mpsp=, args=args@REDACTED=0x7f9c198fca70, > num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, > return_flags=return_flags@REDACTED=0x7f9c198fca14) at > beam/erl_db_util.c:1243 > #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, > mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, > args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, > tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at > beam/erl_trace.c:1873 > #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, > I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, ms= out>, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 > #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, > I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 > #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 > #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at > beam/erl_process.c:8021 > #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at > pthread/ethread.c:114 > #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at > pthread_create.c:333 > #21 0x00007f9c1c640eed in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > A minimal example: > > c("test.erl"), > dbg:tracer(), > dbg:p(self(), [call]), > dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), > test:sum(<<0>>, 0). > > test.erl: > > -module(test). > > -export([sum/2]). > > sum(<>, Acc) -> > sum(Rest, Acc + identity(Int)); > sum(<<>>, Acc) -> Acc. > > identity(Int) -> > Int. I can't reproduce the issue in a vanilla OTP R16B03-1. Are you sure R16B03-1 is affected? I'm asking because I started backporting the fix to R16, but noticed that the R16 code shouldn't abort() in this case, and indeed your recipe doesn't fail for me. From james@REDACTED Thu Sep 10 11:41:34 2015 From: james@REDACTED (James Fish) Date: Thu, 10 Sep 2015 10:41:34 +0100 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message In-Reply-To: <22001.19469.244196.903279@gargle.gargle.HOWL> References: <22001.19469.244196.903279@gargle.gargle.HOWL> Message-ID: On 10 September 2015 at 10:23, Mikael Pettersson wrote: > James Fish writes: > > When using {message, {process_dump}} in a trace the VM can abort on OTP > > R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic > > x86_64: > > > > TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: > > 0x7f9c183ee6d2 > > Aborted (core dumped) > > > > #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at > > ../sysdeps/unix/sysv/linux/raise.c:55 > > #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 > > #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: > > 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at > > beam/erl_term.c:48 > > #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 > > #4 0x00000000004cf12e in print_term (obj_base=, > > dcount=, obj=140308398401234, arg=0x7f9c1d780078, > > fn=0x630a10 ) at beam/erl_printf_term.c:352 > > #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, > > term=, precision=99999, term_base=) at > > beam/erl_printf_term.c:657 > > #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 > > , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b > "%T\n", > > ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 > > #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED > =0x7f9c1d780078, > > format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED > =0x7f9c198fc640) > > at common/erl_printf.c:459 > > #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, > > arg=arg@REDACTED=0x7f9c1d780078, > > format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 > > #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, > > to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 > > #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED > =0x7f9c1d780078, > > p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 > > #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, > > to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at > > beam/break.c:339 > > #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, > > bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, > > base=base@REDACTED=0x0, > > termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, > > in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at > > beam/erl_db_util.c:2404 > > #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, > > mpsp=, args=args@REDACTED=0x7f9c198fca70, > > num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, > > return_flags=return_flags@REDACTED=0x7f9c198fca14) at > > beam/erl_db_util.c:1243 > > #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, > > mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, > > args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, > > tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at > > beam/erl_trace.c:1873 > > #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, > ms= > out>, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 > > #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 > > #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 > > #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at > > beam/erl_process.c:8021 > > #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at > > pthread/ethread.c:114 > > #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at > > pthread_create.c:333 > > #21 0x00007f9c1c640eed in clone () at > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > > > A minimal example: > > > > c("test.erl"), > > dbg:tracer(), > > dbg:p(self(), [call]), > > dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), > > test:sum(<<0>>, 0). > > > > test.erl: > > > > -module(test). > > > > -export([sum/2]). > > > > sum(<>, Acc) -> > > sum(Rest, Acc + identity(Int)); > > sum(<<>>, Acc) -> Acc. > > > > identity(Int) -> > > Int. > > I can't reproduce the issue in a vanilla OTP R16B03-1. Are you sure > R16B03-1 is affected? > > I'm asking because I started backporting the fix to R16, but noticed that > the R16 code shouldn't abort() in this case, and indeed your recipe doesn't > fail for me. > I just tried again and I can't reproduce with R16B03-1 either. The earliest version I can reproduce on is actually 17.0-rc1. Sorry for the mix up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Sep 10 12:10:00 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 10 Sep 2015 12:10:00 +0200 Subject: [erlang-bugs] Type assertion failure when tracing with process_dump message In-Reply-To: References: <22001.19469.244196.903279@gargle.gargle.HOWL> Message-ID: <22001.22264.465977.959019@gargle.gargle.HOWL> James Fish writes: > On 10 September 2015 at 10:23, Mikael Pettersson > wrote: > > > James Fish writes: > > > When using {message, {process_dump}} in a trace the VM can abort on OTP > > > R16B03 to 18.0.2 (not R16B02 and earlier) on a linux 3.19.0-21-generic > > > x86_64: > > > > > > TYPE ASSERTION FAILED, file beam/erl_term.c, line 115: tag_val_def: > > > 0x7f9c183ee6d2 > > > Aborted (core dumped) > > > > > > #0 0x00007f9c1c56f267 in __GI_raise (sig=sig@REDACTED=6) at > > > ../sysdeps/unix/sysv/linux/raise.c:55 > > > #1 0x00007f9c1c570eca in __GI_abort () at abort.c:89 > > > #2 0x000000000056dfd1 in et_abort (expr=0x9081e0 "tag_val_def: > > > 0x7f9c183ee6d2", file=0x64fe45 "beam/erl_term.c", line=115) at > > > beam/erl_term.c:48 > > > #3 tag_val_def (x=x@REDACTED=140308398401234) at beam/erl_term.c:115 > > > #4 0x00000000004cf12e in print_term (obj_base=, > > > dcount=, obj=140308398401234, arg=0x7f9c1d780078, > > > fn=0x630a10 ) at beam/erl_printf_term.c:352 > > > #5 erts_printf_term (fn=0x630a10 , arg=0x7f9c1d780078, > > > term=, precision=99999, term_base=) at > > > beam/erl_printf_term.c:657 > > > #6 0x000000000062ed17 in erts_printf_format (fn=fn@REDACTED=0x630a10 > > > , arg=arg@REDACTED=0x7f9c1d780078, fmt=fmt@REDACTED=0x64830b > > "%T\n", > > > ap=ap@REDACTED=0x7f9c198fc640) at common/erl_printf_format.c:847 > > > #7 0x0000000000631750 in erts_vdsprintf (dsbufp=dsbufp@REDACTED > > =0x7f9c1d780078, > > > format=format@REDACTED=0x64830b "%T\n", arglist=arglist@REDACTED > > =0x7f9c198fc640) > > > at common/erl_printf.c:459 > > > #8 0x00000000004a9696 in erts_print (to=to@REDACTED=-4, > > > arg=arg@REDACTED=0x7f9c1d780078, > > > format=format@REDACTED=0x64830b "%T\n") at beam/utils.c:400 > > > #9 0x00000000004ea8cf in stack_element_dump (yreg=2, sp=0x7f9c183ef258, > > > to_arg=0x7f9c1d780078, to=-4) at beam/erl_process.c:12546 > > > #10 erts_stack_dump (to=to@REDACTED=-4, to_arg=to_arg@REDACTED > > =0x7f9c1d780078, > > > p=p@REDACTED=0x7f9c1bb003d8) at beam/erl_process.c:12466 > > > #11 0x000000000055b56d in print_process_info (to=to@REDACTED=-4, > > > to_arg=to_arg@REDACTED=0x7f9c1d780078, p=p@REDACTED=0x7f9c1bb003d8) at > > > beam/break.c:339 > > > #12 0x000000000052cc20 in db_prog_match (c_p=c_p@REDACTED=0x7f9c1bb003d8, > > > bprog=0x7f9c1bdc0b78, term=term@REDACTED=18446744073709551611, > > > base=base@REDACTED=0x0, > > > termp=termp@REDACTED=0x7f9c198fca70, arity=arity@REDACTED=1, > > > in_flags=ERTS_PAM_TMP_RESULT, return_flags=0x7f9c198fca14) at > > > beam/erl_db_util.c:2404 > > > #13 0x000000000052e5ec in erts_match_set_run (p=p@REDACTED=0x7f9c1bb003d8, > > > mpsp=, args=args@REDACTED=0x7f9c198fca70, > > > num_args=num_args@REDACTED=1, in_flags=in_flags@REDACTED=ERTS_PAM_TMP_RESULT, > > > return_flags=return_flags@REDACTED=0x7f9c198fca14) at > > > beam/erl_db_util.c:1243 > > > #14 0x00000000004a0c55 in erts_call_trace (p=p@REDACTED=0x7f9c1bb003d8, > > > mfa=mfa@REDACTED=0x7f9c1822f058, match_spec=, > > > args=0x7f9c198fca70, args@REDACTED=0x7f9c1bfc4180, local=local@REDACTED=1, > > > tracer_pid=0x7f9c1bb003e8, tracer_pid@REDACTED=0x7f9c198fdcc8) at > > > beam/erl_trace.c:1873 > > > #15 0x0000000000455654 in do_call_trace (c_p=0x7f9c1bb003d8, > > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180, local=local@REDACTED=1, > > ms= > > out>, tracer_pid=tracer_pid@REDACTED=75) at beam/beam_bp.c:900 > > > #16 0x0000000000459524 in erts_generic_breakpoint (c_p=0x7f9c1bb003d8, > > > I=0x7f9c1822f070, reg=0x7f9c1bfc4180) at beam/beam_bp.c:626 > > > #17 0x0000000000443f23 in process_main () at beam/beam_emu.c:4921 > > > #18 0x00000000004d6415 in sched_thread_func (vesdp=0x7f9c1ae4bc40) at > > > beam/erl_process.c:8021 > > > #19 0x000000000062d0e3 in thr_wrapper (vtwd=0x7fff8a43d010) at > > > pthread/ethread.c:114 > > > #20 0x00007f9c1cb136aa in start_thread (arg=0x7f9c198fe700) at > > > pthread_create.c:333 > > > #21 0x00007f9c1c640eed in clone () at > > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > > > > > A minimal example: > > > > > > c("test.erl"), > > > dbg:tracer(), > > > dbg:p(self(), [call]), > > > dbg:tpl(test, identity, [{'_',[],[{message,{process_dump}}]}]), > > > test:sum(<<0>>, 0). > > > > > > test.erl: > > > > > > -module(test). > > > > > > -export([sum/2]). > > > > > > sum(<>, Acc) -> > > > sum(Rest, Acc + identity(Int)); > > > sum(<<>>, Acc) -> Acc. > > > > > > identity(Int) -> > > > Int. > > > > I can't reproduce the issue in a vanilla OTP R16B03-1. Are you sure > > R16B03-1 is affected? > > > > I'm asking because I started backporting the fix to R16, but noticed that > > the R16 code shouldn't abort() in this case, and indeed your recipe doesn't > > fail for me. > > > > I just tried again and I can't reproduce with R16B03-1 either. The earliest > version I can reproduce on is actually 17.0-rc1. Sorry for the mix up. No problem. One less issue/backport for me to handle in our R16 :-) From jens@REDACTED Sat Sep 12 20:04:30 2015 From: jens@REDACTED (jens@REDACTED) Date: Sat, 12 Sep 2015 18:04:30 +0000 Subject: [erlang-bugs] file:sendfile broken on FreeBSD? In-Reply-To: <24c322d23c0bf42bcce6034b2a36a65c@axonehf.com> References: <1aa617b3e1575115593949fde5b0a66b@axonehf.com> <24c322d23c0bf42bcce6034b2a36a65c@axonehf.com> Message-ID: <81b8bb46512257c99e31ea2c574f9a75@axonehf.com> Hi I've created a pull request with a patch for this bug. It can be found here: https://github.com/erlang/otp/pull/831 JP On 2015-09-09 09:13, Jens P?ll wrote: > Ah, sorry about that. > > I'm using version 18 (erts-7.0). > > Luic suggested I'd try disabling the async threads (+A 0) but I got > the same results. > > JP > > On 09.09.2015 07:33, Lukas Larsson wrote: > >> Hello Jens, >> >> Thanks for the bug report. >> >> I cannot find any information about which versions of Erlang/OTP you >> have tried this on. >> >> Lukas >> >> On Tue, Sep 8, 2015 at 11:09 PM, Jens P?ll >> wrote: >> >>> Hi >>> >>> I've been doing some tests using file:sendfile on FreeBSD 10 and >>> it seems to be broken. It's unable to send files that are larger >>> than the OS send buffer. >>> >>> For example, if the buffer is 32KB, then only 48.996 bytes are >>> sent to the client but from time to time it sends 130.708 bytes. >>> It's always those numbers of bytes sent, 48.996 being the more >>> popular one. >>> >>> I discovered this when using Cowboy. I contacted Luic and we have >>> been discussing some options, like the server could be closing the >>> socket too soon. I created a simple test server to try things out >>> where I for example delayed the closing of the socket well beyond >>> the time it took the client to receive a full buffer. It had no >>> effect, that is, the client just received its one and a half >>> buffer and then waited until the server got to closing the socket. >>> I tried both versions of sendfile. >>> >>> If I use gen_tcp:send instead, the data is sent without any >>> problems so I know the server works correctly. >>> >>> Luic is planning on testing this in a few days but since I'm >>> pretty sure (I can't rule out the possibility that I could be >>> doing something wrong) the problem lies with Erlang itself I >>> decided to post this here to get some further feedback. >>> >>> I have a test server and client on github if someone cares to take >>> a look: https://github.com/theom/eclm [1] >>> >>> Thanks, >>> >>> Jens P?ll >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs [2] > > > > Links: > ------ > [1] https://github.com/theom/eclm > [2] http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From nico.kruber@REDACTED Wed Sep 16 17:11:38 2015 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 16 Sep 2015 17:11:38 +0200 Subject: [erlang-bugs] the error_logger does not clean up its file_io_server instances anymore (gen_event related?) Message-ID: <3104538.27grqWmXyf@csr-pc40> In the current master (ddd1acec5100f5bcc96b29f09b80edd717746edf) the following code does not seem to properly remove the file_io_server processes. In error_logger_file_h [1] however, the terminate/2 function seems to clean up by closing the file. So I guess, either file:close/1 does not clean up or gen_event:delete_handler/3 (called by error_logger:logfile(close)[2]) does not call Module:terminate/2 anymore(?) error_logger:logfile({open, "test1"}). error_logger:logfile(close). error_logger:logfile({open, "test2"}). error_logger:logfile(close). [{X, file:pid2name(X)} || X <- processes(), Data <- [process_info(X, [current_function, initial_call, registered_name])], Data =/= undefined, element(1, element(2, lists:keyfind(current_function, 1, Data))) =:= file_io_server]. [1] https://github.com/erlang/otp/blob/ddd1acec5100f5bcc96b29f09b80edd717746edf/lib/stdlib/src/error_logger_file_h.erl#L97 [2] https://github.com/erlang/otp/blob/ddd1acec5100f5bcc96b29f09b80edd717746edf/lib/kernel/src/error_logger.erl#L316 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From dangud@REDACTED Thu Sep 17 09:50:15 2015 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 17 Sep 2015 07:50:15 +0000 Subject: [erlang-bugs] the error_logger does not clean up its file_io_server instances anymore (gen_event related?) In-Reply-To: <3104538.27grqWmXyf@csr-pc40> References: <3104538.27grqWmXyf@csr-pc40> Message-ID: Thanks will fix asap. On Wed, Sep 16, 2015 at 5:11 PM Nico Kruber wrote: > In the current master (ddd1acec5100f5bcc96b29f09b80edd717746edf) the > following > code does not seem to properly remove the file_io_server processes. In > error_logger_file_h [1] however, the terminate/2 function seems to clean > up by > closing the file. > > So I guess, either file:close/1 does not clean up or > gen_event:delete_handler/3 (called by error_logger:logfile(close)[2]) does > not > call Module:terminate/2 anymore(?) > > > error_logger:logfile({open, "test1"}). > error_logger:logfile(close). > error_logger:logfile({open, "test2"}). > error_logger:logfile(close). > [{X, file:pid2name(X)} || X <- processes(), > Data <- [process_info(X, [current_function, initial_call, > registered_name])], > Data =/= undefined, > element(1, element(2, lists:keyfind(current_function, 1, Data))) =:= > file_io_server]. > > > [1] > > https://github.com/erlang/otp/blob/ddd1acec5100f5bcc96b29f09b80edd717746edf/lib/stdlib/src/error_logger_file_h.erl#L97 > [2] > > https://github.com/erlang/otp/blob/ddd1acec5100f5bcc96b29f09b80edd717746edf/lib/kernel/src/error_logger.erl#L316 > _______________________________________________ > 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 Thu Sep 17 15:32:56 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 17 Sep 2015 15:32:56 +0200 Subject: [erlang-bugs] [erlang-questions] Erlang on Xeon Phi In-Reply-To: <1359497020063649511@toto.iv> References: <55f87a4e1cc5a0.36625851@wp.pl> Message-ID: <22010.49416.354556.247569@gargle.gargle.HOWL> Jasiek Stypka writes: > Hello everyone, > > Does anybody have any experience with running Erlang programs on Intel > Xeon Phi coprocessor? I would like to carry out some experiments on this > platform concerning multicore computing, however I am struggling to run > Erlang VM on that architecture. > > It seems to be binary incompatible with x86_64 architectures. When I try > to run the normal Erlang VM v17.3 on it, I get: > /home/me/lib/erlang/bin/erl: line 28: /home/me/lib/erlang/erts-6.1/bin/erlexec: cannot execute binary file > /home/me/lib/erlang/bin/erl: line 28: /home/me/lib/erlang/erts-6.1/bin/erlexec: Success > > So I figured out that I need to use cross compilation to compile the VM > specially for this architecture. After some reading and numerous trials > and errors, I ended up compiling the EVM with these commands: > > $ ./configure --host=k1om-unknown-linux-gnu --build=x86_64-pc-linux-gnu --without-termcap --prefix=$HOME/lib/my_erlang_compilation-17.3 CC=icc CFLAGS=-mmic > $ make > > The first command somehow finishes without any errors, but when running > `make` I finally get: > > /tmp/iccvaLP3vas_.s: Assembler messages: > /tmp/iccvaLP3vas_.s:25794: Error: `mfence' is not supported on `k1om' > /tmp/iccvaLP3vas_.s:25800: Error: `mfence' is not supported on `k1om' > /tmp/iccvaLP3vas_.s:26388: Error: `mfence' is not supported on `k1om' > /tmp/iccvaLP3vas_.s:26394: Error: `mfence' is not supported on `k1om' > make[3]: *** [obj/k1om-unknown-linux-gnu/opt/smp/erl_alloc_util.o] Error 1 > > This seem to be connected with memory barrier instructions and looks like > it's incompatible. Does this mean that the Erlang VM cannot be run on > this architecture? > > Thanks in advance for any suggestions, I ported Erlang/OTP R15B02 to the Xeon Phi in 2012, using Intel's port of gcc-4.7.0 for the Xeon Phi. As you've noticed, the Xeon Phi is not a "normal" x86_64: in fact it's a P5-era core upgraded with basic 64-bit support and a new vector unit, but it lacks SSE2 and related features that the rest of the world consider part of "x86_64". Anyway, the only patch I had to apply is the following: --- otp_src_R15B02/erts/include/internal/i386/ethr_membar.h.~1~ 2012-09-03 11:58:05.000000000 +0200 +++ otp_src_R15B02/erts/include/internal/i386/ethr_membar.h 2012-10-22 13:56:54.000000000 +0200 @@ -48,12 +48,12 @@ ethr_cfence__(void) static __inline__ void ethr_mfence__(void) { -#if ETHR_SIZEOF_PTR == 4 +#if ETHR_SIZEOF_PTR == 4 || !defined(__SSE2__) if (ETHR_X86_RUNTIME_CONF_HAVE_NO_SSE2__) ETHR_NO_SSE2_MEMORY_BARRIER__; else #endif - __asm__ __volatile__ ("mfence\n\t" : : : "memory"); + __asm__ __volatile__ (".byte 0x0f,0xae,0xf0 #mfence\n\t" : : : "memory"); } static __inline__ void The port was just an experiment as I was working a lot with Xeon Phi during 2012/2013. 61 cores / 244 threads, lots of memory and cache bandwidth, Linux kernel, lame userspace, small RAM (4 or 8 GB I think), very slow sequential integer performance. Hopefully newer models are better.