From dimavs@REDACTED Thu Oct 1 03:33:31 2009 From: dimavs@REDACTED (Dmitri Sosnik) Date: Thu, 1 Oct 2009 11:33:31 +1000 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> Message-ID: I have no idea about autoconf, but I've checked logs and it looks like autoconf is using "uname -p" to get host architecture. Snow Leopard x64 returns i386 here. Cheers, D On 01/10/2009, at 6:01 AM, Ryan Graham wrote: > That's what I was trying to point out. It fails on the configure > because it is looking for Darwin-i386 in the output from uname. The > same check is done for each submodule as well. It should be a trivial > fix, I just didn't have the time to make a patch for it. > > ~Ryan > > On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik > wrote: >> Thanks! >> >> But I've realised that it's an another problem. Configure detects >> wrong >> architecture: >> >> checking build system type... i386-apple-darwin10.0.0 >> checking host system type... i386-apple-darwin10.0.0 >> >> $uname -a >> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 >> 22:46:25 >> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 >> >> >> Cheers, >> D >> >> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote: >> >>> Dmitri Sosnik wrote: >>>> >>>> Yep, the same for me. I think the reason is broken wxWidgets >>>> library. >>>> According to http://wiki.wxwidgets.org/Development:_wxMac >>>> wxWidgets 2.8 is >>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa >>>> based, but >>>> there is no stable release for it. >>>> Anyway, can we disable wxWidgets? I've tried with --disable- >>>> wxwidgets, >>>> but it didn't work >>> >>> After the 'configure' and before the 'make' you can avoid building >>> any >>> library directory you do not want by placing a file named SKIP in >>> it. In >>> this case, the following command will do the trick: >>> >>> touch lib/wx/SKIP >>> >>> Kostis >>> >>> ________________________________________________________________ >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>> erlang-bugs (at) erlang.org >>> >> >> > > > > -- > http://rmgraham.blogspot.com > http://twitter.com/rmgraham From r.m.graham@REDACTED Thu Oct 1 06:20:22 2009 From: r.m.graham@REDACTED (Ryan Graham) Date: Wed, 30 Sep 2009 21:20:22 -0700 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> Message-ID: Reboot and hold down the 6 and 4 keys on your keyboard. If your mac has a new enough CPU, it will boot up with the 64-bit kernel instead of the standard 32-bit kernel. The bug I'm reporting wouldn't typically be seen in normal use, but it is still wrong to assume non- i386 means ppc, which is what the check is probably there for. ~Ryan On 2009-09-30, at 6:33 PM, Dmitri Sosnik wrote: > I have no idea about autoconf, but I've checked logs and it looks > like autoconf is using "uname -p" to get host architecture. Snow > Leopard x64 returns i386 here. > > Cheers, > D > > > > On 01/10/2009, at 6:01 AM, Ryan Graham wrote: > >> That's what I was trying to point out. It fails on the configure >> because it is looking for Darwin-i386 in the output from uname. The >> same check is done for each submodule as well. It should be a trivial >> fix, I just didn't have the time to make a patch for it. >> >> ~Ryan >> >> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik >> wrote: >>> Thanks! >>> >>> But I've realised that it's an another problem. Configure detects >>> wrong >>> architecture: >>> >>> checking build system type... i386-apple-darwin10.0.0 >>> checking host system type... i386-apple-darwin10.0.0 >>> >>> $uname -a >>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 >>> 22:46:25 >>> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 >>> >>> >>> Cheers, >>> D >>> >>> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote: >>> >>>> Dmitri Sosnik wrote: >>>>> >>>>> Yep, the same for me. I think the reason is broken wxWidgets >>>>> library. >>>>> According to http://wiki.wxwidgets.org/Development:_wxMac >>>>> wxWidgets 2.8 is >>>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa >>>>> based, but >>>>> there is no stable release for it. >>>>> Anyway, can we disable wxWidgets? I've tried with --disable- >>>>> wxwidgets, >>>>> but it didn't work >>>> >>>> After the 'configure' and before the 'make' you can avoid >>>> building any >>>> library directory you do not want by placing a file named SKIP in >>>> it. In >>>> this case, the following command will do the trick: >>>> >>>> touch lib/wx/SKIP >>>> >>>> Kostis >>>> >>>> ________________________________________________________________ >>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>>> erlang-bugs (at) erlang.org >>>> >>> >>> >> >> >> >> -- >> http://rmgraham.blogspot.com >> http://twitter.com/rmgraham > From dimavs@REDACTED Thu Oct 1 07:17:45 2009 From: dimavs@REDACTED (Dmitri Sosnik) Date: Thu, 1 Oct 2009 15:17:45 +1000 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> Message-ID: I am already booted with x64 kernel and conf.log says: uname -m = x86_64 uname -r = 10.0.0 uname -s = Darwin uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = Mach kernel version: Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 configure:1358: checking build system type configure:1376: result: i386-apple-darwin10.0.0 configure:1384: checking host system type configure:1398: result: i386-apple-darwin10.0.0 Cheers, D On 01/10/2009, at 2:20 PM, Ryan Graham wrote: > Reboot and hold down the 6 and 4 keys on your keyboard. If your mac > has a new enough CPU, it will boot up with the 64-bit kernel instead > of the standard 32-bit kernel. The bug I'm reporting wouldn't > typically be seen in normal use, but it is still wrong to assume non- > i386 means ppc, which is what the check is probably there for. > > ~Ryan > > On 2009-09-30, at 6:33 PM, Dmitri Sosnik wrote: > >> I have no idea about autoconf, but I've checked logs and it looks >> like autoconf is using "uname -p" to get host architecture. Snow >> Leopard x64 returns i386 here. >> >> Cheers, >> D >> >> >> >> On 01/10/2009, at 6:01 AM, Ryan Graham wrote: >> >>> That's what I was trying to point out. It fails on the configure >>> because it is looking for Darwin-i386 in the output from uname. The >>> same check is done for each submodule as well. It should be a >>> trivial >>> fix, I just didn't have the time to make a patch for it. >>> >>> ~Ryan >>> >>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik >>> wrote: >>>> Thanks! >>>> >>>> But I've realised that it's an another problem. Configure detects >>>> wrong >>>> architecture: >>>> >>>> checking build system type... i386-apple-darwin10.0.0 >>>> checking host system type... i386-apple-darwin10.0.0 >>>> >>>> $uname -a >>>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 >>>> 22:46:25 >>>> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 >>>> >>>> >>>> Cheers, >>>> D >>>> >>>> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote: >>>> >>>>> Dmitri Sosnik wrote: >>>>>> >>>>>> Yep, the same for me. I think the reason is broken wxWidgets >>>>>> library. >>>>>> According to http://wiki.wxwidgets.org/Development:_wxMac >>>>>> wxWidgets 2.8 is >>>>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa >>>>>> based, but >>>>>> there is no stable release for it. >>>>>> Anyway, can we disable wxWidgets? I've tried with --disable- >>>>>> wxwidgets, >>>>>> but it didn't work >>>>> >>>>> After the 'configure' and before the 'make' you can avoid >>>>> building any >>>>> library directory you do not want by placing a file named SKIP >>>>> in it. In >>>>> this case, the following command will do the trick: >>>>> >>>>> touch lib/wx/SKIP >>>>> >>>>> Kostis >>>>> >>>>> ________________________________________________________________ >>>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>>>> erlang-bugs (at) erlang.org >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> http://rmgraham.blogspot.com >>> http://twitter.com/rmgraham >> From r.m.graham@REDACTED Thu Oct 1 19:53:11 2009 From: r.m.graham@REDACTED (Ryan Graham) Date: Thu, 1 Oct 2009 10:53:11 -0700 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> Message-ID: <93e244cc0910011053u4d8be5eoecd86debcc608f71@mail.gmail.com> My Mac died last night, but I downloaded the latest source (R13B02-1) onto my Linux box at work... $ grep -Inr "TMPSYS" ./ ./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m` ./erts/configure.in:290: if test X"$TMPSYS" '!=' X"Darwin-i386"; then ./erts/configure:2782:TMPSYS=`uname -s`-`uname -m` ./erts/configure:2806: if test X"$TMPSYS" '!=' X"Darwin-i386"; then ./configure.in:210:TMPSYS=`uname -s`-`uname -m` ./configure.in:222: if test X"$TMPSYS" '!=' X"Darwin-i386"; then ./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then ./configure:2691:TMPSYS=`uname -s`-`uname -m` ./configure:2705: if test X"$TMPSYS" '!=' X"Darwin-i386"; then ./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then The configure scripts only allow the --enable-darwin-64bit switch if you are running on the 32-bit kernel. As your outputs show, if you boot up into the 64-bit kernel, `uname -m` spits out x86_64 which results in the $TMPSYS being the string "Darwin-x86_64", which the script fails to match against "Darwin-i386". As a result, it prints out an error: "$as_me:$LINENO: error: --enable-darwin-64bit only supported on x86 host" ~Ryan On Wed, Sep 30, 2009 at 10:17 PM, Dmitri Sosnik wrote: > I am already booted with x64 kernel and conf.log says: > > uname -m = x86_64 > uname -r = 10.0.0 > uname -s = Darwin > uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_X86_64 > > /usr/bin/uname -p = i386 > /bin/uname -X ? ? = unknown > > /bin/arch ? ? ? ? ? ? ?= unknown > /usr/bin/arch -k ? ? ? = unknown > /usr/convex/getsysinfo = unknown > hostinfo ? ? ? ? ? ? ? = Mach kernel version: > ? ? Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; > root:xnu-1456.1.25~1/RELEASE_X86_64 > > configure:1358: checking build system type > configure:1376: result: i386-apple-darwin10.0.0 > configure:1384: checking host system type > configure:1398: result: i386-apple-darwin10.0.0 > > > > Cheers, > D > > > On 01/10/2009, at 2:20 PM, Ryan Graham wrote: > >> Reboot and hold down the 6 and 4 keys on your keyboard. If your mac has a >> new enough CPU, it will boot up with the 64-bit kernel instead of the >> standard 32-bit kernel. The bug I'm reporting wouldn't typically be seen in >> normal use, but it is still wrong to assume non-i386 means ppc, which is >> what the check is probably there for. >> >> ~Ryan >> >> On 2009-09-30, at 6:33 PM, Dmitri Sosnik wrote: >> >>> I have no idea about autoconf, but I've checked logs and it looks like >>> autoconf is using "uname -p" to get host architecture. Snow Leopard x64 >>> returns i386 here. >>> >>> Cheers, >>> D >>> >>> >>> >>> On 01/10/2009, at 6:01 AM, Ryan Graham wrote: >>> >>>> That's what I was trying to point out. It fails on the configure >>>> because it is looking for Darwin-i386 in the output from uname. The >>>> same check is done for each submodule as well. It should be a trivial >>>> fix, I just didn't have the time to make a patch for it. >>>> >>>> ~Ryan >>>> >>>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik wrote: >>>>> >>>>> Thanks! >>>>> >>>>> But I've realised that it's an another problem. Configure detects wrong >>>>> architecture: >>>>> >>>>> checking build system type... i386-apple-darwin10.0.0 >>>>> checking host system type... i386-apple-darwin10.0.0 >>>>> >>>>> $uname -a >>>>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 >>>>> 22:46:25 >>>>> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 >>>>> >>>>> >>>>> Cheers, >>>>> D >>>>> >>>>> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote: >>>>> >>>>>> Dmitri Sosnik wrote: >>>>>>> >>>>>>> Yep, the same for me. I think the reason is broken wxWidgets library. >>>>>>> According to http://wiki.wxwidgets.org/Development:_wxMac wxWidgets >>>>>>> 2.8 is >>>>>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa based, >>>>>>> but >>>>>>> there is no stable release for it. >>>>>>> Anyway, can we disable wxWidgets? I've tried with >>>>>>> --disable-wxwidgets, >>>>>>> but it didn't work >>>>>> >>>>>> After the 'configure' and before the 'make' you can avoid building any >>>>>> library directory you do not want by placing a file named SKIP in it. >>>>>> In >>>>>> this case, the following command will do the trick: >>>>>> >>>>>> ? ? touch lib/wx/SKIP >>>>>> >>>>>> Kostis >>>>>> >>>>>> ________________________________________________________________ >>>>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>>>>> erlang-bugs (at) erlang.org >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> http://rmgraham.blogspot.com >>>> http://twitter.com/rmgraham >>> > > -- http://rmgraham.blogspot.com http://twitter.com/rmgraham From dgud@REDACTED Fri Oct 2 09:52:15 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Fri, 02 Oct 2009 09:52:15 +0200 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <93e244cc0910011053u4d8be5eoecd86debcc608f71@mail.gmail.com> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> <93e244cc0910011053u4d8be5eoecd86debcc608f71@mail.gmail.com> Message-ID: <4AC5B12F.6090002@erix.ericsson.se> We are aware of the problem, but have no machines that will boot with a 64-bit kernel, and can't test it. We will try to fix it in the next release. /Dan Ryan Graham wrote: > My Mac died last night, but I downloaded the latest source (R13B02-1) > onto my Linux box at work... > > $ grep -Inr "TMPSYS" ./ > ./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m` > ./erts/configure.in:290: if test X"$TMPSYS" '!=' X"Darwin-i386"; then > ./erts/configure:2782:TMPSYS=`uname -s`-`uname -m` > ./erts/configure:2806: if test X"$TMPSYS" '!=' X"Darwin-i386"; then > ./configure.in:210:TMPSYS=`uname -s`-`uname -m` > ./configure.in:222: if test X"$TMPSYS" '!=' X"Darwin-i386"; then > ./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then > ./configure:2691:TMPSYS=`uname -s`-`uname -m` > ./configure:2705: if test X"$TMPSYS" '!=' X"Darwin-i386"; then > ./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then > > The configure scripts only allow the --enable-darwin-64bit switch if > you are running on the 32-bit kernel. > > As your outputs show, if you boot up into the 64-bit kernel, `uname > -m` spits out x86_64 which results in the $TMPSYS being the string > "Darwin-x86_64", which the script fails to match against > "Darwin-i386". As a result, it prints out an error: > > "$as_me:$LINENO: error: --enable-darwin-64bit only supported on x86 host" > > ~Ryan > > On Wed, Sep 30, 2009 at 10:17 PM, Dmitri Sosnik wrote: >> I am already booted with x64 kernel and conf.log says: >> >> uname -m = x86_64 >> uname -r = 10.0.0 >> uname -s = Darwin >> uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; >> root:xnu-1456.1.25~1/RELEASE_X86_64 >> >> /usr/bin/uname -p = i386 >> /bin/uname -X = unknown >> >> /bin/arch = unknown >> /usr/bin/arch -k = unknown >> /usr/convex/getsysinfo = unknown >> hostinfo = Mach kernel version: >> Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; >> root:xnu-1456.1.25~1/RELEASE_X86_64 >> >> configure:1358: checking build system type >> configure:1376: result: i386-apple-darwin10.0.0 >> configure:1384: checking host system type >> configure:1398: result: i386-apple-darwin10.0.0 >> >> >> >> Cheers, >> D >> >> >> On 01/10/2009, at 2:20 PM, Ryan Graham wrote: >> >>> Reboot and hold down the 6 and 4 keys on your keyboard. If your mac has a >>> new enough CPU, it will boot up with the 64-bit kernel instead of the >>> standard 32-bit kernel. The bug I'm reporting wouldn't typically be seen in >>> normal use, but it is still wrong to assume non-i386 means ppc, which is >>> what the check is probably there for. >>> >>> ~Ryan >>> >>> On 2009-09-30, at 6:33 PM, Dmitri Sosnik wrote: >>> >>>> I have no idea about autoconf, but I've checked logs and it looks like >>>> autoconf is using "uname -p" to get host architecture. Snow Leopard x64 >>>> returns i386 here. >>>> >>>> Cheers, >>>> D >>>> >>>> >>>> >>>> On 01/10/2009, at 6:01 AM, Ryan Graham wrote: >>>> >>>>> That's what I was trying to point out. It fails on the configure >>>>> because it is looking for Darwin-i386 in the output from uname. The >>>>> same check is done for each submodule as well. It should be a trivial >>>>> fix, I just didn't have the time to make a patch for it. >>>>> >>>>> ~Ryan >>>>> >>>>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik wrote: >>>>>> Thanks! >>>>>> >>>>>> But I've realised that it's an another problem. Configure detects wrong >>>>>> architecture: >>>>>> >>>>>> checking build system type... i386-apple-darwin10.0.0 >>>>>> checking host system type... i386-apple-darwin10.0.0 >>>>>> >>>>>> $uname -a >>>>>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 >>>>>> 22:46:25 >>>>>> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 >>>>>> >>>>>> >>>>>> Cheers, >>>>>> D >>>>>> >>>>>> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote: >>>>>> >>>>>>> Dmitri Sosnik wrote: >>>>>>>> Yep, the same for me. I think the reason is broken wxWidgets library. >>>>>>>> According to http://wiki.wxwidgets.org/Development:_wxMac wxWidgets >>>>>>>> 2.8 is >>>>>>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa based, >>>>>>>> but >>>>>>>> there is no stable release for it. >>>>>>>> Anyway, can we disable wxWidgets? I've tried with >>>>>>>> --disable-wxwidgets, >>>>>>>> but it didn't work >>>>>>> After the 'configure' and before the 'make' you can avoid building any >>>>>>> library directory you do not want by placing a file named SKIP in it. >>>>>>> In >>>>>>> this case, the following command will do the trick: >>>>>>> >>>>>>> touch lib/wx/SKIP >>>>>>> >>>>>>> Kostis >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>>>>>> erlang-bugs (at) erlang.org >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> http://rmgraham.blogspot.com >>>>> http://twitter.com/rmgraham >> > > > From sverker@REDACTED Fri Oct 9 10:34:46 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 09 Oct 2009 10:34:46 +0200 Subject: [erlang-questions] beam crasher: ets + write_concurrency In-Reply-To: References: Message-ID: <4ACEF5A6.8000303@erix.ericsson.se> Dave Smith wrote: > I believe that I have identified a VM crasher when using ETS with > write concurrency enabled. Sample code is as follows: > > T = ets:new(?MODULE, [{write_concurrency, true}]), > ets:insert_new(T, {foo, 1}), > ets:match(T, {nosuchvalue, '$1'}) Yes, it's repeatable on my machine as well (Linux x86_64, 64-bit VM). I will have a look at it right now. Thanks for reporting. /Sverker, Erlang/OTP From zl9d97p02@REDACTED Fri Oct 9 11:35:19 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Fri, 9 Oct 2009 11:35:19 +0200 Subject: R12B3 tracing crashes emulator Message-ID: <27779-83101@sneakemail.com> Tracing on [all], or specifically [running, scheduler_id] trashes the stack leading to some sort of SEGV or BUS fault. Seen on Solaris i386/64-bit and OS/X i386/32-bit. This doesn't seem to be related to the other thing reported/fixed recently in R13. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: R12B-3-0F-ext.patch Type: application/octet-stream Size: 827 bytes Desc: not available URL: From egil@REDACTED Sun Oct 11 18:45:00 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Sun, 11 Oct 2009 18:45:00 +0200 Subject: [erlang-bugs] R12B3 tracing crashes emulator In-Reply-To: <27779-83101@sneakemail.com> References: <27779-83101@sneakemail.com> Message-ID: <4AD20B8C.2050003@erix.ericsson.se> Hi Simon, These issues are fixed in R12B-4 and later. This section of code was completely revised in R12B-4, ticket OTP-7481. Are you seeing this on later releases as well? Regards, Bj?rn-Egil Erlang/OTP Simon Cornish wrote: > Tracing on [all], or specifically [running, scheduler_id] trashes the > stack leading to some sort of SEGV or BUS fault. Seen on Solaris > i386/64-bit and OS/X i386/32-bit. > This doesn't seem to be related to the other thing reported/fixed > recently in R13. > Patch attached. > > > ------------------------------------------------------------------------ > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org From adam@REDACTED Wed Oct 14 10:57:10 2009 From: adam@REDACTED (Adam Lindberg) Date: Wed, 14 Oct 2009 09:57:10 +0100 (BST) Subject: Edoc crash when using macro with function Message-ID: <23579439.205971255510630318.JavaMail.root@zimbra> Hi! Running edoc:file/1 on test.erl with this content will result in a crash in edoc: -module(test). -export([f/0]). -define(FUNC, f() -> ok). ?FUNC. Seems edoc in R13B02 can't handle the macro on line 7. 1> edoc:file("test.erl"). test.erl: at line 7: syntax error before: '.' ** exception exit: error in function edoc:'-check_forms/2-fun-0-'/2 in call from lists:foreach/2 in call from edoc:read_source/2 in call from edoc_extract:source/3 in call from edoc:read/2 in call from edoc:file/2 Cheers, Adam From adam@REDACTED Wed Oct 14 14:34:13 2009 From: adam@REDACTED (Adam Lindberg) Date: Wed, 14 Oct 2009 13:34:13 +0100 (BST) Subject: [erlang-bugs] Edoc crash when using macro with function In-Reply-To: <4AD5A99E.5090000@gmail.com> Message-ID: <18724023.206841255523653176.JavaMail.root@zimbra> Thanks, didn't make that connection with the documentation at all. Follow up question: Is it possible to make edoc just skip those files? Right now it says that is is skipping them, but exits with an error anyway. I'd like it to generate the documentation for the modules that do work. Is that possible? Cheers, Adam ----- "Richard Carlsson" wrote: > Adam Lindberg wrote: > > Running edoc:file/1 on test.erl with this content will result in a > crash in edoc: > > > > -module(test). > > > > -export([f/0]). > > > > -define(FUNC, f() -> ok). > > > > ?FUNC. > > > > > > Seems edoc in R13B02 can't handle the macro on line 7. > > That's not a bug, it's a feature. :-) > > If you want to run edoc on files that contain too weird macros, > you need to give it the 'preprocess' flag, and possibly specify > include paths as well; see the docs for eunit.erl for details. > > /Richard From adam@REDACTED Thu Oct 15 13:35:14 2009 From: adam@REDACTED (Adam Lindberg) Date: Thu, 15 Oct 2009 12:35:14 +0100 (BST) Subject: [erlang-bugs] Edoc crash when using macro with function In-Reply-To: <4AD5D990.2030100@gmail.com> Message-ID: <33414463.209481255606514933.JavaMail.root@zimbra> Yeah, it does. I am however running it in an eval argument to erl, so it crashes the whole node and produces a core dump. Not so nice. Cheers, Adam ----- "Richard Carlsson" wrote: > Adam Lindberg wrote: > > Thanks, didn't make that connection with the documentation at all. > > > > Follow up question: Is it possible to make edoc just skip those > > files? Right now it says that is is skipping them, but exits with > an > > error anyway. I'd like it to generate the documentation for the > > modules that do work. Is that possible? > > But it does generate them, right? Apart from the error status > at the end, I mean? > > /Richard From zerthurd@REDACTED Fri Oct 16 11:47:06 2009 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 16 Oct 2009 16:47:06 +0700 Subject: [erlang-bugs] erl -make returns ok status after compilation error Message-ID: Hello Make in erlang dose not handles errors in compilation. If some files in application broken, compilation with erlc returns 1, while erl -make returns 0 what indicates that compilation i successful. So, when we uses Makefile, where some targets should been compiled with erl -make, and when one target compilation is broken, make cannot catch this. Thank you -- Maxim Treskin From mazen.harake@REDACTED Fri Oct 16 15:34:26 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 16 Oct 2009 15:34:26 +0200 Subject: wx_object locks Message-ID: <4AD87662.3080202@erlang-consulting.com> Hi all, If I create a frame using wx_object, then using an event destroy the frame and then start a new frame (wx_object or not doesn't matter I think) then the new frame is not created before the process that runs inside my callback function (specified with connect/3) returns from the callback. I find this very odd... so I was wondering if this is intended behaviour. This code example (attached) shows what I'm trying to describe. Instructions: do dlock:start(). then click on the middle of the frame that appears. I expected this to destroy the frame that was open and then create a new one but as long as the process in the callback is alive it will not. To unlock the process and let it complete type the following in the shell: pid(0,X,0) ! {continue}. where X is the Pid. Then you should see that the first frame is removed and the second one appears. Is this intended? Best regards, /Mazen -------------- next part -------------- A non-text attachment was scrubbed... Name: dlock.erl Type: application/x-extension-erl Size: 1479 bytes Desc: not available URL: From smith.winston.101@REDACTED Sat Oct 17 04:50:58 2009 From: smith.winston.101@REDACTED (Winston Smith) Date: Fri, 16 Oct 2009 22:50:58 -0400 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <4AC5B12F.6090002@erix.ericsson.se> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> <93e244cc0910011053u4d8be5eoecd86debcc608f71@mail.gmail.com> <4AC5B12F.6090002@erix.ericsson.se> Message-ID: On Fri, Oct 2, 2009 at 3:52 AM, Dan Gudmundsson wrote: > We are aware of the problem, but have no machines that will boot with a > 64-bit kernel, > and can't test it. I just ran into this, if you are interested I have attached a patch, it was pretty simple (sorry, I don't know if it's in the right format, but you should be able to see the changes well enough). BTW: This was against R13B02-1 sources. > We will try to fix it in the next release. I'd be more than happy to test it for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: otp_R13B02-1_x86_64-patch Type: application/octet-stream Size: 1855 bytes Desc: not available URL: From smith.winston.101@REDACTED Sat Oct 17 06:14:50 2009 From: smith.winston.101@REDACTED (Winston Smith) Date: Sat, 17 Oct 2009 00:14:50 -0400 Subject: R13B02-1: badmatch in memsup:get_memory_usage Message-ID: Running R13B02-1 on Mac OS 10.6.2 (x86_64), I'm seeing the following error when I start my OTP application: =SUPERVISOR REPORT==== 17-Oct-2009::00:10:08 === Supervisor: {local,os_mon_sup} Context: child_terminated Reason: {{badmatch,{error,{fread,input}}}, [{memsup,get_memory_usage,1}, {memsup,'-handle_info/2-fun-0-',2}]} Offender: [{pid,<0.74.0>}, {name,memsup}, {mfa,{memsup,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] Not sure how to diagnose this further ... From mikage@REDACTED Sat Oct 17 08:20:57 2009 From: mikage@REDACTED (Mikage Sawatari) Date: Sat, 17 Oct 2009 15:20:57 +0900 Subject: Erlang ssl module doesn't treat self-signed certificates as an error Message-ID: <5e448700910162320s2f8dd98wdca7992b25854e9a@mail.gmail.com> Hello, The ssl module doesn't treat self-signed certificates an error, even when it is told to verify peer certificates with an option. Therefore in case of connecting to a self-signed server, client programs continue to process their jobs, which lead to a security problem. The following is esock_openssl.c at line 961 and later. Shouldn't it do MAYBE_SET_ERRSTR("eselfsignedcert") when the cert_err is X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT? switch (cert_err) { case X509_V_OK: case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: ok = 1; break; case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: MAYBE_SET_ERRSTR("enoissuercert"); break; case X509_V_ERR_CERT_HAS_EXPIRED: MAYBE_SET_ERRSTR("epeercertexpired"); break; case X509_V_ERR_CERT_NOT_YET_VALID: case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD: case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD: MAYBE_SET_ERRSTR("epeercertinvalid"); break; case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: MAYBE_SET_ERRSTR("eselfsignedcert"); break; case X509_V_ERR_CERT_CHAIN_TOO_LONG: MAYBE_SET_ERRSTR("echaintoolong"); break; default: MAYBE_SET_ERRSTR("epeercert"); break; } Thank, you. -- ----------------------------------------------------------------------- SAWATARI Mikage (SANO Taku) From smith.winston.101@REDACTED Sat Oct 17 19:13:43 2009 From: smith.winston.101@REDACTED (Winston Smith) Date: Sat, 17 Oct 2009 13:13:43 -0400 Subject: R13B02-1: badmatch in memsup:get_memory_usage (Mac OS X 10.6) Message-ID: I found the problem, the output of vm_stat has changed in Snow Leopard (10.6) and the code in memsup.erl, in get_memory_usage({unix,darwin}) fails to read the number of pages wired: get_memory_usage({unix,darwin}) -> Str = os:cmd("/usr/bin/vm_stat"), {ok, [Free],Str2} = io_lib:fread("Pages free:~d.",skip_to_eol(Str)), {ok, [Active],Str3} = io_lib:fread("Pages active:~d.", skip_to_eol(Str2)), {ok, [Inactive],Str4} = io_lib:fread("Pages inactive:~d.", skip_to_eol(Str3)), {ok, [Wired],_} = io_lib:fread("Pages wired down:~d.", skip_to_eol(Str4)), %% FAILS HERE NMemUsed = (Wired + Active + Inactive) * 4000, NMemTotal = NMemUsed + Free * 4000, {NMemUsed,NMemTotal}; Here's the new output of vm_stat (they've inserted "Pages speculative" before "Pages wired down" comparing to 10.5): winston$ /usr/bin/vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes) Pages free: 110845. Pages active: 563208. Pages inactive: 201387. Pages speculative: 8936. Pages wired down: 164629. "Translation faults": 128602101. Pages copy-on-write: 2406604. Pages zero filled: 66882837. Pages reactivated: 39662. Pageins: 232245. Pageouts: 12164. Object cache: 173 hits of 69999244 lookups (0% hit rate) Hope this helps! Thanks. On Sat, Oct 17, 2009 at 12:14 AM, Winston Smith wrote: > Running R13B02-1 on Mac OS 10.6.2 (x86_64), I'm seeing the following > error when I start my OTP application: > > =SUPERVISOR REPORT==== 17-Oct-2009::00:10:08 === > ? ? Supervisor: {local,os_mon_sup} > ? ? Context: ? ?child_terminated > ? ? Reason: ? ? {{badmatch,{error,{fread,input}}}, > ? ? ? ? ? ? ? ? ?[{memsup,get_memory_usage,1}, > ? ? ? ? ? ? ? ? ? {memsup,'-handle_info/2-fun-0-',2}]} > ? ? Offender: ? [{pid,<0.74.0>}, > ? ? ? ? ? ? ? ? ?{name,memsup}, > ? ? ? ? ? ? ? ? ?{mfa,{memsup,start_link,[]}}, > ? ? ? ? ? ? ? ? ?{restart_type,permanent}, > ? ? ? ? ? ? ? ? ?{shutdown,2000}, > ? ? ? ? ? ? ? ? ?{child_type,worker}] > > > Not sure how to diagnose this further ... > From dgud@REDACTED Mon Oct 19 08:16:28 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 19 Oct 2009 08:16:28 +0200 Subject: [erlang-bugs] wx_object locks In-Reply-To: <4AD87662.3080202@erlang-consulting.com> References: <4AD87662.3080202@erlang-consulting.com> Message-ID: <4ADC043C.3040301@erix.ericsson.se> Mazen Harake wrote: > Hi all, > > If I create a frame using wx_object, then using an event destroy the > frame and then start a new frame (wx_object or not doesn't matter I > think) then the new frame is not created before the process that runs > inside my callback function (specified with connect/3) returns from the > callback. I find this very odd... so I was wondering if this is intended > behaviour. That is intended, callbacks from C++ to erlang are very tricky to get right. wxWidgets is a single threaded application and doesn't expect a multithreaded erlang above it. Which results in several deadlock sitatutions if not callbacks are handled first. I have rewritten this part several times, this implementation is the best so far. It get's tricky when you get recursive callbacks, i.e. you call something from inside a callback which generates a new callback to erlang. So use callbacks only when you really have to, and don't call any other erlang wx process because then can get the deadlock up in erlang code, but at least that is debug-able. /Dan > > This code example (attached) shows what I'm trying to describe. > Instructions: do dlock:start(). then click on the middle of the frame > that appears. I expected this to destroy the frame that was open and > then create a new one but as long as the process in the callback is > alive it will not. To unlock the process and let it complete type the > following in the shell: pid(0,X,0) ! {continue}. where X is the Pid. > Then you should see that the first frame is removed and the second one > appears. > > Is this intended? > > Best regards, > > /Mazen > > > > ------------------------------------------------------------------------ > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org From ulf.wiger@REDACTED Tue Oct 20 17:18:20 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 20 Oct 2009 17:18:20 +0200 Subject: typos in erlang:system_profile() doc Message-ID: <4ADDD4BC.7000706@erlang-consulting.com> The following sentence in the R13B02 documentation for erlang:system_profile() could need some revising: "Running processes that is reinsertet into the runqueue after completing its reductions does not trigger this message." It would be better as "Running processes that are reinserted into the run queue after having been preemptively scheduled out will not trigger this message." ...or something like that. BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From egil@REDACTED Wed Oct 21 11:45:53 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 21 Oct 2009 11:45:53 +0200 Subject: [erlang-bugs] typos in erlang:system_profile() doc In-Reply-To: <4ADDD4BC.7000706@erlang-consulting.com> References: <4ADDD4BC.7000706@erlang-consulting.com> Message-ID: <4ADED851.10901@erix.ericsson.se> Hi Ulf, Thank you for pointing out these errors. I will review my english in the system_profile documentation. Regards, Bj?rn-Egil Erlang/OTP Ulf Wiger wrote: > > The following sentence in the R13B02 documentation for > erlang:system_profile() could need some revising: > > "Running processes that is reinsertet into the runqueue after completing > its reductions does not trigger this message." > > It would be better as > > "Running processes that are reinserted into the run queue > after having been preemptively scheduled out will not trigger > this message." > > ...or something like that. > > BR, > Ulf W From kruber@REDACTED Wed Oct 21 16:30:53 2009 From: kruber@REDACTED (Nico Kruber) Date: Wed, 21 Oct 2009 16:30:53 +0200 Subject: R13B02 builds with older versions of wxGTK, e.g. 2.8.4 Message-ID: <200910211630.57875.kruber@zib.de> attached is a patch I created so that the current release (R13B02) builds with at least wxGTK 2.8.4, used by Mandriva 2008 and openSUSE 10.3. Regards, Nico Kruber -------------- next part -------------- A non-text attachment was scrubbed... Name: otp-R13B02-wxevt.patch Type: text/x-patch Size: 1315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From roberto.aloi@REDACTED Wed Oct 21 19:05:44 2009 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Wed, 21 Oct 2009 18:05:44 +0100 Subject: About Inets and httpd_utils:ip_address/2 Message-ID: <17757A68-7C27-42EE-987C-68E2F13E377E@erlang-consulting.com> Hi all, playing a bit with Inets and Erlang Web, my attention went to the "httpd_utils" module in inets. In the ip_address/2 function (last clause), you bind the Inet variable to "inet" or "inet6", according to the result of the following piece of code: Inet = case gen_tcp:listen(0, [inet6]) of {ok, Dummyport} -> gen_tcp:close(Dummyport), inet6; _ -> inet end, Now, on my laptop (Mac OS X 10.6), the listen and the close operations both succeed, so I get: Inet = inet6. Still, inet:getaddr("0.0.0.0", inet6). will fail on my machine, returning: {error, nxdomain}. By replacing "inet6" with "inet" I get (as expected): {ok, {0,0,0,0}}. This strange (at least for me) behavior, resulted into my Erlang Web installation not understanding a: BindAddress 0.0.0.0 directive in my inets.conf file. Is this an expected behaviour? Regards, Roberto Aloi roberto.aloi@REDACTED http://www.erlang-consulting.com --- From dangud@REDACTED Fri Oct 23 11:18:03 2009 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 23 Oct 2009 11:18:03 +0200 Subject: [erlang-bugs] R13B02 builds with older versions of wxGTK, e.g. 2.8.4 In-Reply-To: <200910211630.57875.kruber@zib.de> References: <200910211630.57875.kruber@zib.de> Message-ID: <93df43b60910230218k1d855f66g83287bc5e39dea7@mail.gmail.com> Thanks for the patch, I will have a look at how to solve that. Unfortunately it isn't that easy, since that code is generated. /Dan On Wed, Oct 21, 2009 at 4:30 PM, Nico Kruber wrote: > attached is a patch I created so that the current release (R13B02) builds with > at least wxGTK 2.8.4, used by Mandriva 2008 and openSUSE 10.3. > > > Regards, > Nico Kruber > From rvirding@REDACTED Sat Oct 24 22:10:55 2009 From: rvirding@REDACTED (Robert Virding) Date: Sat, 24 Oct 2009 22:10:55 +0200 Subject: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill" In-Reply-To: <200910242342216873502@gmail.com> References: <200910241907167657586@gmail.com> <200910242342216873502@gmail.com> Message-ID: <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> I just want to clear up one little point: there is in fact only one type of process, all processes behave in the same way with respect to dying and exit signals. So what Joe calls "system processes" are just processes started by the system, nothing more. That exit(kill) and exit(Self, kill) behave differently is *exactly* as it should be, they are *defined* to behave differently. exit/2 will *always* send an exit signal to the process even if the process itself! Its behaviour is consistent. When sending to itself the process should behave as if the exit signal came from "outside" the itself. This means that if you are trapping exits you should also trap the exits from exit/2 to yourself. Oth an exit/1 works "internally". It should behave in the same way as erlang:error/1. In fact originally they were the same and there was only exit/1. Internal errors also looked the same as exit/1. Things started to drift apart when internal errors got stack traces. Now stack traces are a Good Thing but it meant that the behaviour of errors and exit/1 diverged. Unfortunately, instead of fixing exit/1, which would have been the most sensible thing to do, the split was made permanent by adding error/1. So exit/1 and error/1 should behave in the same way, which is different to exit/2. 'kill' is a little special as we felt we needed something which wasn't trappable but at the same time we realised that if it spread in the same way as other exit signals then it would be uncontrollable. This is why it was decided that when a process received an exit 'kill' signal it should always unconditionally die but only resignal 'killed' to its linked processes. Whether doing exit(kill) should send a real exit 'kill' signal or only a 'killed' signal is an interesting question which I can't remember now what we decided. If it sends an exit 'kill' signal then it should behave as a real 'kill' signal and be non-trappable. This definitely something for the Erlang Rationale! Robert 2009/10/24 Yan Yan > Thanks, Richard > > In fact, I had a very similiar thought with yours as I found b killed when > b is not a system process but b not killed when b is a system process. > > However, even if exit(kill) acts the same as exit(self(), kill) does, there > seems to be problems left. For example, if, in this setup, c does want ALL > linked processes to be killed when c itself exits abnormally, we will want a > simple code in c() just like exit(kill). In this way, we want all processes > linked to c will be killed because of c's exit, even if there were any > system processes among c's linked processes. Currently, if we write > exit(kill) or exit(self(), kill) in c(), only c and c's linked non-system > processes will be killed, but all system processed linked will survive, > which is not correct. > > So far, there seems to be no other ways to let it happen correctly except: > > Code: > > c(......) -> > blabla... > > %% P1, P2, ..., Pn are linked SYSTEM processes > exit(P1, kill), > exit(P2, kill), > ... > exit(Pn, kill), > > %%Here c is still alive, and we want c and its linked non-system processes > also killed, so... > exit(kill). %% or exit(self(), kill), or exit(anything).. > > End code. > > However, it still demands that programmers know ahead of time how many and > which system processes are linked to c, which is not a good design pattern. > > Sincerely, > > Yan Yan > > > > > Yan Yan > 2009-10-24 > > > > From: Richard Carlsson > Time: 2009-10-24 21:05:05 > To: Yan Yan > Fw: erlang-questions; erlang-bugs; Bj?n_Gustavsson > Subject: Re: [erlang-questions] Erlang's process not killed by exit > signalreasoned by "kill" > > Yan Yan wrote: > > (2)On Page 169, > (Page 161 in my copy of the book.) > > Quote: > > > > 8> edemo1:start(true, {die,kill}). Process b received > > {'EXIT',<0.73.0>,kill} process b (<0.72.0>) is alive process c > > (<0.73.0>) is dead ok > > > > End quote. > > > > Here a and b are both system processes, while c is not. When c exits > > with the reason "kill" (not "killed"), it sends exit signal to b with > > the reason "kill". Therefore b should be killed and dead, but b is > > still alive here! > > > > (I had thought it was only a small typo in the book. But then I > > tested by myself and got the same result: b received the exit signal > > with the reason "kill" and b was not killed but alive.) > > > > Why is the system process b not killed by the exit signal with the > > reason "kill"? > Interesting. There seems to be a difference in behaviour (probably > not intentional) between `exit(kill)' and `exit(self(),kill)'. > A summary of the setup: we have three processes, linked in a chain. > 'a' is always trapping, 'b' may or may not be trapping, and 'c' is > the one who dies by calling exit(Reason). > 1. When 'b' is not trapping, and 'c' does exit(kill), we see a > report from 'a' that 'b' died with reason 'killed'. > 2. When 'b' is trapping, and 'c' does exit(kill), 'b' survives > and reports that it sees the exit reason 'kill' from 'c' > (not 'killed'). > The question is: in case 2, why didn't 'b' die, when it apparently > got a 'kill' message. This should be untrappable, which is why it is > changed to 'killed' when it is propagated. But it was 'c' who died, > so why wasn't the atom changed to 'killed'? > If we change `exit(kill)' to `exit(self(),kill)' in 'c', we get the > effect we expected: 'b' survives and reports that it sees 'killed' > as the exit reason from 'c'. > Then, a new question is why 'a' saw 'killed' in case 1 when 'b' is > non-trapping. If 'c' dies in the same way in both, then doesn't > 'b' get the same signal from 'c'? Apparently, it does, but since > 'b' is not trapping, it doesn't matter what the atom is as long > as it is something else than 'normal'. So 'b' dies due to an > incoming 'kill', and this is then propagated as 'killed'. > It seems that when a process does exit(kill) on itself, it causes > a different outgoing signal than if it does exit(self(),kill). > The former is not untrappable even though it has the reason 'kill', > but if that in its turn causes another process to die, the atom > will _then_ be rewritten to 'killed'. > To me, it seems that this should be fixed so that exit(kill), even > if it's an unusual case, should be propagated as 'killed'. > /Richard > From ulf.wiger@REDACTED Wed Oct 28 09:05:45 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 28 Oct 2009 09:05:45 +0100 Subject: table_info on non-local mnesia table Message-ID: <4AE7FB59.9000500@erlang-consulting.com> I recently came across the problem that calling mnesia:table_info(Tab, size) will return 0 if the table does not reside locally. This behaviour is not obvious from the documentation, nor is the remedy: Calling mnesia:activity(Type, fun() -> mnesia:table_info(Tab,size) end, mnesia_frag), will always return the correct value, even if the table isn't fragmented. I consider this a bug. Mnesia should detect that the table is remote and act accordingly, rather than returning a bogus value. BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From matthew@REDACTED Wed Oct 28 13:30:28 2009 From: matthew@REDACTED (Matthew Sackman) Date: Wed, 28 Oct 2009 12:30:28 +0000 Subject: file:read with read_ahead and binaries broken Message-ID: <20091028123028.GA27900@mrnibble.lshift.net> dd if=/dev/urandom of=/tmp/file.rnd bs=1M count=20 test(Hdl) -> test(Hdl, []). test(Hdl, Acc) -> case file:read(Hdl, 1) of {ok, <>} -> {ok, _Pos} = file:position(Hdl, {cur, 1}), test(Hdl, [Num|Acc]); eof -> Acc end. 1> f(), {ok, Hdl} = file:open("/tmp/file.rnd", [read, read_ahead, binary, raw]), X = test:test(Hdl), ok = file:close(Hdl). Erlang will die. Badly. erlang:memory() shows that of the 4GB erlang has claimed before I kill it, 3.9GB of that is binary data. Ways to stop this going nuts: 1) Don't use read_ahead 2) Remove the position call - instead, read 2 bytes and skip the second 3) Add any random term, say 'foo' to the Acc, rather than Num. 4) Have Num as an int, not a binary. 5) Do the following: {ok, <>} -> {ok, _Pos} = file:position(Hdl, {cur, 1}), <> = <>, test(Hdl, [Num2|Acc]); My guess is that what's happening is that the read is reading in a whole disk page (as it should), Num is a pointer into the start of that page, but the rest of the page beyond the first byte, isn't reclaimed. Then the position seemingly invalidates the entire page. This is confirmed by the fact that strace -f -c -p $PID shows the same number of calls to read in both the read_ahead and non read_ahead versions. Interestingly though, there are twice as many calls to lseek in the read_ahead version. >From inspecting the size of the file itself, both the read_ahead and non versions are really issuing a read for every single byte read, and the read_ahead version also has the advantage of issuing twice as many seeks. A quick test shows this happens at least as far back as R12B5, and still happens in R13B02. Oh and if you follow suggestion (5), you'll find the read_ahead version is about 8 times slower than the non read_ahead version. Matthew From egil@REDACTED Wed Oct 28 13:50:48 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 28 Oct 2009 13:50:48 +0100 Subject: [erlang-bugs] file:read with read_ahead and binaries broken In-Reply-To: <20091028123028.GA27900@mrnibble.lshift.net> References: <20091028123028.GA27900@mrnibble.lshift.net> Message-ID: <4AE83E28.1050806@erix.ericsson.se> Hi Matthew, We are aware of this issue and a more aggressive gc-strategy is being developed. This will be in place in the next release unless something unforeseen happens. The new strategy involves virtual heaps for binaries that will also trigger gc:s when binary heap boundaries are reached instead of only procbins and binary overhead counting triggers. The new strategy will also take care of past old heap binary problems. Regards, Bj?rn-Egil Erlang/OTP Matthew Sackman wrote: > dd if=/dev/urandom of=/tmp/file.rnd bs=1M count=20 > > test(Hdl) -> > test(Hdl, []). > > test(Hdl, Acc) -> > case file:read(Hdl, 1) of > {ok, <>} -> {ok, _Pos} = file:position(Hdl, {cur, 1}), > test(Hdl, [Num|Acc]); > eof -> Acc > end. > > 1> f(), {ok, Hdl} = file:open("/tmp/file.rnd", [read, read_ahead, binary, raw]), > X = test:test(Hdl), ok = file:close(Hdl). > > Erlang will die. Badly. erlang:memory() shows that of the 4GB erlang > has claimed before I kill it, 3.9GB of that is binary data. > > Ways to stop this going nuts: > 1) Don't use read_ahead > 2) Remove the position call - instead, read 2 bytes and skip the second > 3) Add any random term, say 'foo' to the Acc, rather than Num. > 4) Have Num as an int, not a binary. > 5) Do the following: > {ok, <>} -> {ok, _Pos} = file:position(Hdl, {cur, 1}), > <> = <>, > test(Hdl, [Num2|Acc]); > > My guess is that what's happening is that the read is reading in a whole > disk page (as it should), Num is a pointer into the start of that page, > but the rest of the page beyond the first byte, isn't reclaimed. Then the > position seemingly invalidates the entire page. This is confirmed by the > fact that strace -f -c -p $PID shows the same number of calls to read in > both the read_ahead and non read_ahead versions. Interestingly though, > there are twice as many calls to lseek in the read_ahead version. > >>From inspecting the size of the file itself, both the read_ahead and non > versions are really issuing a read for every single byte read, and the > read_ahead version also has the advantage of issuing twice as many > seeks. > > A quick test shows this happens at least as far back as R12B5, and still > happens in R13B02. > > Oh and if you follow suggestion (5), you'll find the read_ahead version > is about 8 times slower than the non read_ahead version. > > Matthew > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org From matthew@REDACTED Wed Oct 28 14:04:04 2009 From: matthew@REDACTED (Matthew Sackman) Date: Wed, 28 Oct 2009 13:04:04 +0000 Subject: [erlang-bugs] file:read with read_ahead and binaries broken In-Reply-To: <4AE83E28.1050806@erix.ericsson.se> References: <20091028123028.GA27900@mrnibble.lshift.net> <4AE83E28.1050806@erix.ericsson.se> Message-ID: <20091028130404.GB27900@mrnibble.lshift.net> Hi Bj?rn-Egil, Thanks for the reply, and good to know a solution is in the pipeline. However, you're solution is only addressing one issue. The other issue is why is a read issued when the position call does not move the file handle outside of the region currently cached by the read ahead buffer? In truth, both the seek and read libc calls can be avoided, or at the least, the position can be delayed until some other non-(position or read) call - eg truncate or write. Matthew From mjtruog@REDACTED Wed Oct 28 20:05:35 2009 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 28 Oct 2009 12:05:35 -0700 Subject: {packet, http} with gen_tcp:connect/2 problem Message-ID: <4AE895FF.6010905@gmail.com> When {active, false} and {packet, http} are used with gen_tcp:connect/2 there is a difference between what dialyzer (in R13B02-1 or R13B01) expects and what happens in reality. Based on the code here: erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1 It makes sense that you can get a response {ok, {http_error, _}} when calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the result dialyzer expects. However, in reality I get {error, {http_error, _}} and need to make sure my code is {_, {http_error, _}} to avoid the problem. I am not sure what is changing the output of erlang:decode_packet/3. - Michael From zl9d97p02@REDACTED Wed Oct 28 21:07:16 2009 From: zl9d97p02@REDACTED (Simon Cornish) Date: Wed, 28 Oct 2009 13:07:16 -0700 Subject: [erlang-bugs] Re: R13B02-1: badmatch in memsup:get_memory_usage (Mac OS X 10.6) In-Reply-To: References: Message-ID: <7764-67980@sneakemail.com> Hello, Here is a patch against R12B-3 that solves your problem. Probably you can apply it without too much hassle to R13 but I haven't the time to look into that. Regards, Simon On Sat, Oct 17, 2009 at 10:13 AM, Winston Smith smith.winston.101-at-......... |erlang-mail| <...> wrote: > I found the problem, the output of vm_stat has changed in Snow Leopard > (10.6) and the code in memsup.erl, in get_memory_usage({unix,darwin}) > fails to read the number of pages wired: > > get_memory_usage({unix,darwin}) -> > ? ?Str = os:cmd("/usr/bin/vm_stat"), > ? ?{ok, [Free],Str2} = io_lib:fread("Pages free:~d.",skip_to_eol(Str)), > ? ?{ok, [Active],Str3} = > ? ? ? ?io_lib:fread("Pages active:~d.", skip_to_eol(Str2)), > ? ?{ok, [Inactive],Str4} = > ? ? ? ?io_lib:fread("Pages inactive:~d.", skip_to_eol(Str3)), > ? ?{ok, [Wired],_} = > ? ? ? ?io_lib:fread("Pages wired down:~d.", skip_to_eol(Str4)), ? ? ? ? ? ? ? ?%% FAILS HERE > ? ?NMemUsed ?= (Wired + Active + Inactive) * 4000, > ? ?NMemTotal = NMemUsed + Free * 4000, > ? ?{NMemUsed,NMemTotal}; > > > Here's the new output of vm_stat (they've inserted "Pages speculative" > before "Pages wired down" comparing to 10.5): > > winston$ /usr/bin/vm_stat > Mach Virtual Memory Statistics: (page size of 4096 bytes) > Pages free: ? ? ? ? ? ? ? ? ? ? ? ? 110845. > Pages active: ? ? ? ? ? ? ? ? ? ? ? 563208. > Pages inactive: ? ? ? ? ? ? ? ? ? ? 201387. > Pages speculative: ? ? ? ? ? ? ? ? ? ?8936. > Pages wired down: ? ? ? ? ? ? ? ? ? 164629. > "Translation faults": ? ? ? ? ? ?128602101. > Pages copy-on-write: ? ? ? ? ? ? ? 2406604. > Pages zero filled: ? ? ? ? ? ? ? ?66882837. > Pages reactivated: ? ? ? ? ? ? ? ? ? 39662. > Pageins: ? ? ? ? ? ? ? ? ? ? ? ? ? ?232245. > Pageouts: ? ? ? ? ? ? ? ? ? ? ? ? ? ?12164. > Object cache: 173 hits of 69999244 lookups (0% hit rate) > > > Hope this helps! > > Thanks. > > > On Sat, Oct 17, 2009 at 12:14 AM, Winston Smith > wrote: >> Running R13B02-1 on Mac OS 10.6.2 (x86_64), I'm seeing the following >> error when I start my OTP application: >> >> =SUPERVISOR REPORT==== 17-Oct-2009::00:10:08 === >> ? ? Supervisor: {local,os_mon_sup} >> ? ? Context: ? ?child_terminated >> ? ? Reason: ? ? {{badmatch,{error,{fread,input}}}, >> ? ? ? ? ? ? ? ? ?[{memsup,get_memory_usage,1}, >> ? ? ? ? ? ? ? ? ? {memsup,'-handle_info/2-fun-0-',2}]} >> ? ? Offender: ? [{pid,<0.74.0>}, >> ? ? ? ? ? ? ? ? ?{name,memsup}, >> ? ? ? ? ? ? ? ? ?{mfa,{memsup,start_link,[]}}, >> ? ? ? ? ? ? ? ? ?{restart_type,permanent}, >> ? ? ? ? ? ? ? ? ?{shutdown,2000}, >> ? ? ? ? ? ? ? ? ?{child_type,worker}] >> >> >> Not sure how to diagnose this further ... >> > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > -------------- next part -------------- A non-text attachment was scrubbed... Name: memsup.patch Type: application/octet-stream Size: 920 bytes Desc: not available URL: From erlang@REDACTED Wed Oct 28 22:32:03 2009 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 28 Oct 2009 22:32:03 +0100 Subject: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill" In-Reply-To: <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> References: <200910241907167657586@gmail.com> <200910242342216873502@gmail.com> <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> Message-ID: <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> On Sat, Oct 24, 2009 at 9:10 PM, Robert Virding wrote: > I just want to clear up one little point: there is in fact only one type of > process, all processes behave in the same way with respect to dying and exit > signals. So what Joe calls "system processes" are just processes started by > the system, nothing more. In this context "system process" means "a process that has evaluated process_flag(trap_exit, true)" > > That exit(kill) and exit(Self, kill) behave differently is *exactly* as it > should be, they are *defined* to behave differently. exit/2 will *always* > send an exit signal to the process even if the process itself! Its behaviour > is consistent. When sending to itself the process should behave as if the > exit signal came from "outside" the itself. This means that if you are > trapping exits you should also trap the exits from exit/2 to yourself. > Yes - in the book and elsewhere we refer to "signals" and "messages" - but they are not the same thing. Signals get converted to messages and put into the inbox of a process if you have said process_flag(tap_exit, true). But the signal generated by exit(Pid, kill) *never* gets converted to a message. When c dies by evaluating exit(X) it broadcasts a signal to it's link set If b is linked to c it will convert this to the message {'EXIT',Pid,X} this is true for all X. If c says exit(Pic, kill) a *different kind* of unstoppable signal is sent and b must die. Signals are internal things and can never be printed, we can only print the messages that result form signals being converted to messages. The origonal reason for this was to be able to kill rogue processes. If A wants to kill B it evaluates exit(B, kill) and we are guaranted that B will die. If A just says exit(kill) it says I'm dieing with reason kill. The distinction between messages and signals is subtle. If you read section 9.4 subsection "system processes" of my book you'll see this behavior is described more or less as I have described it above. Now if you didn't like the above description we can try a different approach ---- a different way of describing the same thing The VM behaves as if there were 3 type of inter-process messages: (1, Data) tuples represent regular messages (2, Data) tuples represent signals 3 is the kill signal P ! X sends a type 1 message (1,X) exit(X) sends a type 2 message (2,X) exit(P, kill) sends a type 3 message exit(P, X) sends a type 2 message (2,X) on receiving a type 2 message if X != normal a normal process dies on receiving a type 2 message a system process converts this to a (1,X) message on receiving a type 3 message the receiving process dies unconditionally --- end This is reasonably clear - the *problem* is that to describe the behavior I've had to suddenly invent an new abstract machine and you have to guess the semantics of this machine. That's why we try very hard to use terms like signals and messages to describe the behavior in an abstract way and not in terms of a VM - because the description of the VM itself would be pretty large and for most purposes is not necessary. (( and anyway if I describe the VM in language in L1, what do I describe L1 in? L2? and what do I describe L2 in .....)) To make life simple we try to use meta-circular descriptions and describe Erlang behavior in terms of Erlang. Mostly this works - but for the case of signals and messages is not easy. > Oth an exit/1 works "internally". It should behave in the same way as > erlang:error/1. In fact originally they were the same and there was only > exit/1. Internal errors also looked the same as exit/1. Things started to > drift apart when internal errors got stack traces. Now stack traces are a > Good Thing but it meant that the behaviour of errors and exit/1 diverged. > Unfortunately, instead of fixing exit/1, which would have been the most > sensible thing to do, the split was made permanent by adding error/1. > > So exit/1 and error/1 should behave in the same way, which is different to > exit/2. > > 'kill' is a little special as we felt we needed something which wasn't > trappable but at the same time we realised that if it spread in the same way > as other exit signals then it would be uncontrollable. This is why it was > decided that when a process received an exit 'kill' signal it should always > unconditionally die but only resignal 'killed' to its linked processes. > Whether doing exit(kill) should send a real exit 'kill' signal or only a > 'killed' signal is an interesting question which I can't remember now what > we decided. If it sends an exit 'kill' signal then it should behave as a > real 'kill' signal and be non-trappable. > > This definitely something for the Erlang Rationale! Yup /Joe > > Robert > > 2009/10/24 Yan Yan > >> Thanks, Richard >> >> In fact, I had a very similiar thought with yours as I found b killed when >> b is not a system process but b not killed when b is a system process. >> >> However, even if exit(kill) acts the same as exit(self(), kill) does, there >> seems to be problems left. For example, if, in this setup, c does want ALL >> linked processes to be killed when c itself exits abnormally, we will want a >> simple code in c() just like exit(kill). In this way, we want all processes >> linked to c will be killed because of c's exit, even if there were any >> system processes among c's linked processes. Currently, if we write >> exit(kill) or exit(self(), kill) in c(), only c and c's linked non-system >> processes will be killed, but all system processed linked will survive, >> which is not correct. >> >> So far, there seems to be no other ways to let it happen correctly except: >> >> Code: >> >> c(......) -> >> blabla... >> >> %% P1, P2, ..., Pn are linked SYSTEM processes >> exit(P1, kill), >> exit(P2, kill), >> ... >> exit(Pn, kill), >> >> %%Here c is still alive, and we want c and its linked non-system processes >> also killed, so... >> exit(kill). %% or exit(self(), kill), or exit(anything).. >> >> End code. >> >> However, it still demands that programmers know ahead of time how many and >> which system processes are linked to c, which is not a good design pattern. >> >> Sincerely, >> >> Yan Yan >> >> >> >> >> Yan Yan >> 2009-10-24 >> >> >> >> From: Richard Carlsson >> Time: ?2009-10-24 21:05:05 >> To: Yan Yan >> Fw: erlang-questions; erlang-bugs; Bj?n_Gustavsson >> Subject: Re: [erlang-questions] Erlang's process not killed by exit >> signalreasoned by "kill" >> >> Yan Yan wrote: >> > (2)On Page 169, >> (Page 161 in my copy of the book.) >> > Quote: >> > >> > 8> edemo1:start(true, {die,kill}). ?Process b received >> > {'EXIT',<0.73.0>,kill} process b (<0.72.0>) is alive process c >> > (<0.73.0>) is dead ok >> > >> > End quote. >> > >> > Here a and b are both system processes, while c is not. When c exits >> > with the reason "kill" (not "killed"), it sends exit signal to b with >> > the reason "kill". Therefore b should be killed and dead, but b is >> > still alive here! >> > >> > (I had thought it was only a small typo in the book. But then I >> > tested by myself and got the same result: b received the exit signal >> > with the reason "kill" and b was not killed but alive.) >> > >> > Why is the system process b not killed by the exit signal with the >> > reason "kill"? >> Interesting. There seems to be a difference in behaviour (probably >> not intentional) between `exit(kill)' and `exit(self(),kill)'. >> A summary of the setup: we have three processes, linked in a chain. >> 'a' is always trapping, 'b' may or may not be trapping, and 'c' is >> the one who dies by calling exit(Reason). >> ?1. When 'b' is not trapping, and 'c' does exit(kill), we see a >> ? ? report from 'a' that 'b' died with reason 'killed'. >> ?2. When 'b' is trapping, and 'c' does exit(kill), 'b' survives >> ? ? and reports that it sees the exit reason 'kill' from 'c' >> ? ? (not 'killed'). >> The question is: in case 2, why didn't 'b' die, when it apparently >> got a 'kill' message. This should be untrappable, which is why it is >> changed to 'killed' when it is propagated. But it was 'c' who died, >> so why wasn't the atom changed to 'killed'? >> If we change `exit(kill)' to `exit(self(),kill)' in 'c', we get the >> effect we expected: 'b' survives and reports that it sees 'killed' >> as the exit reason from 'c'. >> Then, a new question is why 'a' saw 'killed' in case 1 when 'b' is >> non-trapping. If 'c' dies in the same way in both, then doesn't >> 'b' get the same signal from 'c'? Apparently, it does, but since >> 'b' is not trapping, it doesn't matter what the atom is as long >> as it is something else than 'normal'. So 'b' dies due to an >> incoming 'kill', and this is then propagated as 'killed'. >> It seems that when a process does exit(kill) on itself, it causes >> a different outgoing signal than if it does exit(self(),kill). >> The former is not untrappable even though it has the reason 'kill', >> but if that in its turn causes another process to die, the atom >> will _then_ be rewritten to 'killed'. >> To me, it seems that this should be fixed so that exit(kill), even >> if it's an unusual case, should be propagated as 'killed'. >> ? ? /Richard >> > From ulf.wiger@REDACTED Thu Oct 29 10:57:37 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 29 Oct 2009 10:57:37 +0100 Subject: [erlang-bugs] Re: Re: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill" In-Reply-To: <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> References: <200910241907167657586@gmail.com> <200910242342216873502@gmail.com> <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> Message-ID: <4AE96711.9020303@erlang-consulting.com> Joe Armstrong wrote: > > The distinction between messages and signals is subtle. One way to verify that it is indeed as Joe says: Eshell V5.6.5 (abort with ^G) 1> P = spawn(fun() -> timer:sleep(infinity) end). <0.32.0> 2> P ! {'EXIT',self(),foo}. {'EXIT',<0.30.0>,foo} 3> is_process_alive(P). true 4> exit(P,foo). true 5> is_process_alive(P). false 6> In other words, you cannot fake an exit signal by sending an {'EXIT',P,R} message. BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From sverker@REDACTED Thu Oct 29 12:15:05 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 29 Oct 2009 12:15:05 +0100 Subject: [erlang-bugs] {packet, http} with gen_tcp:connect/2 problem In-Reply-To: <4AE895FF.6010905@gmail.com> References: <4AE895FF.6010905@gmail.com> Message-ID: <4AE97939.5070807@erix.ericsson.se> Hi, gen_tcp:recv has been returning {error,{http_error,_}} instead of {ok,{...}} since the beginning (when it was an undocumented feature used by some privileged applications), so I don't think we can change that without breaking backwards compatibility. I guess we have to introduce this "exception to the rule" in both the documentation and dialyzer. About the code: gen_tcp with {packet,http} does not use erlang:decode_packet or any of the http related code in erl_bif_port.c. The common code used by both gen_tcp and decode_packet is in beam/packet_parser.c. The terms returned from the socket are then contructed by code in emulator/drivers/common/inet_drv.c. /Sverker, Erlang/OTP Ericsson Michael Truog wrote: > When {active, false} and {packet, http} are used with gen_tcp:connect/2 > there is a difference between what dialyzer (in R13B02-1 or R13B01) > expects and what happens in reality. Based on the code here: > erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1 > > It makes sense that you can get a response {ok, {http_error, _}} when > calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the > result dialyzer expects. However, in reality I get {error, {http_error, > _}} and need to make sure my code is {_, {http_error, _}} to avoid the > problem. I am not sure what is changing the output of > erlang:decode_packet/3. > > - Michael > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From egil@REDACTED Thu Oct 29 14:25:24 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 29 Oct 2009 14:25:24 +0100 Subject: [erlang-bugs] file:read with read_ahead and binaries broken In-Reply-To: <20091028130404.GB27900@mrnibble.lshift.net> References: <20091028123028.GA27900@mrnibble.lshift.net> <4AE83E28.1050806@erix.ericsson.se> <20091028130404.GB27900@mrnibble.lshift.net> Message-ID: <4AE997C4.2080103@erix.ericsson.se> Yes, I did hit send a bit prematurely. The solution I was talking about does not solve this particular problem. What's happening here is that the driver is keeping a read_ahead buffer which is a binary of size 64 kB (if I remember the default cache size correctly). Each read will generate a subbinary of the read_ahead buffer which is kept reachable in the process by pushing the subbinary to a list in the read-loop. Each file:position will flush the read_ahead cache and a new binary will be made to take is place. *repeat until eof* Each subbinary will reference the binary and force the gc to keep those binaries since they are all live data. In this example the total memory consumption would be roughly ~20M x 64K bytes / 2 ~ 640 GB which is not the intention by the programmer I guess. =) The main problem here is that each subbinary is kept. It is aggravated by producing a new binary cache for each read. This is of course easily remedied by matching numbers instead of binaries. In this case using <> instead of <>. Also instead of seeks one could read 2 bytes instead of one. Or, as you said, skip read_ahead since it wont give any boost because of the seeks. I realize that this not the intent of the test though. Is this a bug in the handling of binaries? No, but perhaps a limitation and not the "least astonishing result". Users must be aware of the fact that subbinaries will keep the whole binary it is referencing. And keeping the subbinaries reachable will keep them from being gc:ed. In this case the user must also be aware of the fact that he is receiving subbinaries from the reads. I think that this could be clearer in the documentation. One could argue that seeks should not always flush the cache. I fully agree with you that this should be avoided. This is something we will review. One could also argue that subbinaries should be compacted. This is not wise for the most common cases. It would kill performance and actually bloat memory. A user can do this by himself by forcing a copy of the subbinary. This will generate a new separate smaller binary. Some sort of smart automatic compacting of binaries could be done in the gc but it is not easily implemented for a number of reasons. Several strategies for compacting are on the table but it wont be a realization until R14 at the earliest. I hope you find this information helpful. *hitting send* Regards, Bj?rn-Egil Erlang/OTP Matthew Sackman wrote: > Hi Bj?rn-Egil, > > Thanks for the reply, and good to know a solution is in the pipeline. > However, you're solution is only addressing one issue. The other issue > is why is a read issued when the position call does not move the file > handle outside of the region currently cached by the read ahead buffer? > In truth, both the seek and read libc calls can be avoided, or at the > least, the position can be delayed until some other non-(position or > read) call - eg truncate or write. > > Matthew > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org From rvirding@REDACTED Thu Oct 29 14:36:37 2009 From: rvirding@REDACTED (Robert Virding) Date: Thu, 29 Oct 2009 14:36:37 +0100 Subject: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill" In-Reply-To: <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> References: <200910241907167657586@gmail.com> <200910242342216873502@gmail.com> <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> Message-ID: <3dbc6d1c0910290636u557f51e2y51e067d4d7f117fe@mail.gmail.com> 2009/10/28 Joe Armstrong > > ---- a different way of describing the same thing > > The VM behaves as if there were 3 type of inter-process messages: > > (1, Data) tuples represent regular messages > (2, Data) tuples represent signals > 3 is the kill signal > > P ! X sends a type 1 message (1,X) > exit(X) sends a type 2 message (2,X) > exit(P, kill) sends a type 3 message > exit(P, X) sends a type 2 message (2,X) > > on receiving a type 2 message if X != normal a normal process dies > on receiving a type 2 message a system process converts this to a (1,X) > message > on receiving a type 3 message the receiving process dies unconditionally > > --- end > Yes, this is clear and understandable. In these terms I suppose you could describe the problem as: When I do exit(Self, kill) it sends a type 3 'kill' signal to myself and when I die I send type 2 'killed' signals to my linked processes. This is consistent irrespective to whom I send the kill signal. BUT when I do exit(kill) I send a type 2 signal with value 'kill' which doesn't behave as a type 3 'kill' signal though the name is the same. This is inconsistent, and I don't like inconsistencies. There are two different solutions: either send out real type 3 kill signals; or send out type 2 'killed' signals as if I had received a type 3 signal. Both are consistent, but which is best? This is how I have read the problem. Robert From ulf.wiger@REDACTED Thu Oct 29 15:04:24 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 29 Oct 2009 15:04:24 +0100 Subject: [erlang-bugs] Re: Re: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill" In-Reply-To: <3dbc6d1c0910290636u557f51e2y51e067d4d7f117fe@mail.gmail.com> References: <200910241907167657586@gmail.com> <200910242342216873502@gmail.com> <3dbc6d1c0910241310p53a30c23m58ba263d271f99fe@mail.gmail.com> <9b08084c0910281432m134e4f98p4154eb33ca224f52@mail.gmail.com> <3dbc6d1c0910290636u557f51e2y51e067d4d7f117fe@mail.gmail.com> Message-ID: <4AE9A0E8.7050101@erlang-consulting.com> Robert Virding wrote: > > BUT when I do exit(kill) I send a type 2 signal with value 'kill' which > doesn't behave as a type 3 'kill' signal though the name is the same. This > is inconsistent, and I don't like inconsistencies. There are two different > solutions: either send out real type 3 kill signals; or send out type 2 > 'killed' signals as if I had received a type 3 signal. Both are consistent, > but which is best? Why send out type 3 kill signals? What is that consistent with? I think the consistent behaviour would be to send out type 2 'killed' signals. BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From kostis@REDACTED Thu Oct 29 16:47:25 2009 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 29 Oct 2009 17:47:25 +0200 Subject: [erlang-bugs] {packet, http} with gen_tcp:connect/2 problem In-Reply-To: <4AE97939.5070807@erix.ericsson.se> References: <4AE895FF.6010905@gmail.com> <4AE97939.5070807@erix.ericsson.se> Message-ID: <4AE9B90D.5050803@cs.ntua.gr> Sverker Eriksson wrote: > Hi, > > gen_tcp:recv has been returning {error,{http_error,_}} instead of > {ok,{...}} since the beginning (when it was an undocumented feature used > by some privileged applications), so I don't think we can change that > without breaking backwards compatibility. I guess we have to introduce > this "exception to the rule" in both the documentation and dialyzer. I do not really see any problem as far as backwards compatibility for the masses is concerned. Even today, the documented behaviour of gen_tcp (http://www.erlang.org/doc/man/gen_tcp.html) reads: recv(Socket, Length) -> {ok, Packet} | {error, Reason} recv(Socket, Length, Timeout) -> {ok, Packet} | {error, Reason} Types: Socket = socket() Length = int() Packet = [char()] | binary() Timeout = int() | infinity Reason = closed | posix() where posix() is an atom. Programs that explicitly match on {error, {http_error, _}} rely on something undocumented and they should know better that this could change at any time. Moreover, dialyzer exists and automatically identifies all these places in the code and is there to help users in changing them. What's the problem in making the right decision here? Erlang has too many inconsistent return values in its key functions. Does it need another one? Kostis From sverker@REDACTED Thu Oct 29 17:41:46 2009 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 29 Oct 2009 17:41:46 +0100 Subject: [erlang-bugs] {packet, http} with gen_tcp:connect/2 problem In-Reply-To: <4AE9B90D.5050803@cs.ntua.gr> References: <4AE895FF.6010905@gmail.com> <4AE97939.5070807@erix.ericsson.se> <4AE9B90D.5050803@cs.ntua.gr> Message-ID: <4AE9C5CA.6000206@erix.ericsson.se> Kostis Sagonas wrote: > : > > Programs that explicitly match on {error, {http_error, _}} rely on > something undocumented and they should know better that this could > change at any time. > > Moreover, dialyzer exists and automatically identifies all these > places in the code and is there to help users in changing them. > > What's the problem in making the right decision here? > Fear of breaking "established" applications such as Yaws and Mochiweb, I guess... > Erlang has too many inconsistent return values in its key functions. > Does it need another one? > No, maybe we should muster the courage to do the right thing then... /Sverker, Erlang/OTP