From ufm@REDACTED Tue Sep 1 09:01:47 2009 From: ufm@REDACTED (Fyodor Ustinov) Date: Tue, 01 Sep 2009 10:01:47 +0300 Subject: DETS spoils DAT files In-Reply-To: <1251644590.20412.ezmlm@erlang.org> References: <1251644590.20412.ezmlm@erlang.org> Message-ID: <1251788507.3867.8.camel@imac> Hi. In excess restrictions on 2G to file DETS spoils DAT files. Here's an example: ufm@REDACTED:~/src$ erl Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> BigL = lists:seq(1,2000000). [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, 23,24,25,26,27,28,29|...] 2> dets:open_file(tab,[{type,set}]). {ok,tab} 3> dets:info(tab). [{type,set}, {keypos,1}, {size,0}, {file_size,5432}, {filename,"tab"}] 4> lists:foreach(fun(X) -> dets:insert(tab,{X,BigL}) end, lists:seq(1,50)). ok 5> dets:info(tab). [{type,set}, {keypos,1}, {size,50}, {file_size,848861394}, {filename,"tab"}] 6> dets:close(tab). ok 7> dets:open_file(tab,[{type,set}]). {ok,tab} 8> dets:info(tab). [{type,set}, {keypos,1}, {size,50}, {file_size,848861666}, {filename,"tab"}] 9> lists:foreach(fun(X) -> dets:insert(tab,{X,BigL}) end, lists:seq(50,200)). ok 10> dets:info(tab). [{type,set}, {keypos,1}, {size,126}, {file_size,2066820196}, {filename,"tab"}] 11> dets:close(tab). {error,{{bad_object,read_buckets},"tab"}} 12> dets:close(tab). {error,not_owner} 13> dets:info(tab). undefined 14> dets:open_file(tab,[{type,set}]). dets: file "tab" not properly closed, repairing ... {error,{no_more_space_on_file,"tab.TMP"}} 15> From richardc@REDACTED Tue Sep 1 10:01:39 2009 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 01 Sep 2009 10:01:39 +0200 Subject: [erlang-bugs] DETS spoils DAT files In-Reply-To: <1251788507.3867.8.camel@imac> References: <1251644590.20412.ezmlm@erlang.org> <1251788507.3867.8.camel@imac> Message-ID: <4A9CD4E3.3070307@it.uu.se> This is great! We've been hit by a spurious "bad object" error every few months, but never been able to reproduce the conditions. If this test case makes it possible to find and fix the bug in dets, you are a certified hero. /Richard Fyodor Ustinov wrote: > Hi. > > > In excess restrictions on 2G to file DETS spoils DAT files. Here's an > example: > > ufm@REDACTED:~/src$ erl > Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] > [kernel-poll:false] > > Eshell V5.7.2 (abort with ^G) > 1> BigL = lists:seq(1,2000000). > [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, > 23,24,25,26,27,28,29|...] > 2> dets:open_file(tab,[{type,set}]). > {ok,tab} > 3> dets:info(tab). > [{type,set}, > {keypos,1}, > {size,0}, > {file_size,5432}, > {filename,"tab"}] > 4> lists:foreach(fun(X) -> dets:insert(tab,{X,BigL}) end, > lists:seq(1,50)). > ok > 5> > dets:info(tab). > [{type,set}, > {keypos,1}, > {size,50}, > {file_size,848861394}, > {filename,"tab"}] > 6> dets:close(tab). > ok > 7> > dets:open_file(tab,[{type,set}]). > {ok,tab} > 8> > dets:info(tab). > [{type,set}, > {keypos,1}, > {size,50}, > {file_size,848861666}, > {filename,"tab"}] > 9> lists:foreach(fun(X) -> dets:insert(tab,{X,BigL}) end, > lists:seq(50,200)). > ok > 10> > dets:info(tab). > [{type,set}, > {keypos,1}, > {size,126}, > {file_size,2066820196}, > {filename,"tab"}] > 11> > dets:close(tab). > {error,{{bad_object,read_buckets},"tab"}} > 12> > dets:close(tab). > {error,not_owner} > 13> > dets:info(tab). > undefined > 14> > dets:open_file(tab,[{type,set}]). > dets: file "tab" not properly closed, repairing ... > {error,{no_more_space_on_file,"tab.TMP"}} > 15> > > > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From ufm@REDACTED Tue Sep 1 14:29:07 2009 From: ufm@REDACTED (Fyodor Ustinov) Date: Tue, 01 Sep 2009 15:29:07 +0300 Subject: Garbage collection. Bug or feature? In-Reply-To: <1251644590.20412.ezmlm@erlang.org> References: <1251644590.20412.ezmlm@erlang.org> Message-ID: <1251808147.8582.30.camel@imac> Hi! I thought that in the case of dynamic garbage collection, memory allocation is roughly as follows: for(int i = 0, mem=alloc(size); mem == NULL && i < MaxAttempts; garbage_colelct), i++; while MaxAttempts should be at least 1. But the following examples indicate the contrary. ufm@REDACTED:~$ erl Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> A=[255||X<-lists:seq(1,20000000)],ok. ok 2> B=list_to_binary(A). <<"????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"...>> 3> byte_size(B). 20000000 4> byte_size(B). 20000000 5> byte_size(B). 20000000 Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 912262800 bytes of memory (of type "heap"). Aborted ufm@REDACTED:~$ erl Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.2 (abort with ^G) 1> A=[255||X<-lists:seq(1,20000000)],ok. ok 2> B=list_to_binary(A). <<"????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"...>> 3> erlang:garbage_collect(),byte_size(B). 20000000 4> erlang:garbage_collect(),byte_size(B). 20000000 5> erlang:garbage_collect(),byte_size(B). 20000000 6> erlang:garbage_collect(),byte_size(B). 20000000 7> erlang:garbage_collect(),byte_size(B). 20000000 8> erlang:garbage_collect(),byte_size(B). 20000000 9> [...and so on...] Calling the garbage collector manually - not a good idea. But in real life I do not know the size of B, it can be anything, therefore, compelled to do so. So all the same, this is a bug, feature or I misunderstood something? From vinoski@REDACTED Wed Sep 2 17:10:47 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 2 Sep 2009 11:10:47 -0400 Subject: wx fails to build on Snow Leopard Message-ID: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> I'm seeing that the wx part of the Erlang/OTP build doesn't work on OS X 10.6 (Snow Leopard). I don't use wx so it's no big deal to me, but I'm seeing the g++ compiler appear to hang when compiling lib/wx/c_src/gen/wxe_funcs.cpp. I let it run quite awhile and it never got past that point, but my laptop fans were running full blast so I wonder if the compilation got stuck in an infinite loop. If I manually edit wx out of the lib/Makefile, then everything builds and seems to work as normal. There are also lots of compilation warnings in the wx area due to deprecation of some APIs being used and due to string constants being passed as char*. --steve From samb-bulk@REDACTED Fri Sep 4 07:41:51 2009 From: samb-bulk@REDACTED (Sam Bobroff) Date: Fri, 04 Sep 2009 15:41:51 +1000 Subject: Incorrect result from QLC Message-ID: <4AA0A89F.8020503@m5networks.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The following test program produces a set of results with two entries for key 1, from an ordered_set table. The result I get is: Records with val =:= 1: [{rec,1,1},{rec,2,1},{rec,1,1}] It is clearly incorrect for an 'ordered_set' table to have two entries with a key of 1 (and the duplicate entry vanishes after the transaction completes). I'm running Erlang R13B01 on Ubuntu Linux. - --- begin --- %% Bug replication code, save to "bug.erl". %% Compile with: erlc bug.erl %% Run with: erl -noshell -run bug -run init stop - -module(bug). - -export([start/0]). - -include_lib("stdlib/include/qlc.hrl"). - -record(rec, {key, val}). start() -> ok = mnesia:start(), {atomic, ok} = mnesia:create_table(rec, [{attributes, record_info(fields, rec)}, {type, ordered_set}, {index, [val]}]), {atomic, ok} = mnesia:transaction(fun() -> ok = mnesia:write({rec,1,1}), ok = mnesia:write({rec,2,1}) end), {atomic, _} = mnesia:transaction(fun() -> ok = mnesia:write(hd(mnesia:read(rec, 1))), io:fwrite("Records with val =:= 1: ~p\n", [ qlc:e(qlc:q([ R || R <- mnesia:table(rec), R#rec.val =:= 1 ])) ]) end). - --- end --- Cheers, Sam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKoKifm97/UHSa/AQRAsddAJ0UXUK+bjJ4KzbZFxTmwFsUw1mPDQCfQqq/ 0QJV2U3IipjhfkVFfTGqQIY= =lg8n -----END PGP SIGNATURE----- From hans.bolinder@REDACTED Fri Sep 4 08:56:17 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 4 Sep 2009 08:56:17 +0200 Subject: [erlang-bugs] Incorrect result from QLC In-Reply-To: <4AA0A89F.8020503@m5networks.com.au> References: <4AA0A89F.8020503@m5networks.com.au> Message-ID: <19104.47633.231013.174549@ornendil.du.uab.ericsson.se> [Sam Bobroff:] > The following test program produces a set of results with two entries > for key 1, from an ordered_set table. The result I get is: > > Records with val =:= 1: [{rec,1,1},{rec,2,1},{rec,1,1}] > > It is clearly incorrect for an 'ordered_set' table to have two entries > with a key of 1 (and the duplicate entry vanishes after the transaction > completes). Thanks for the bug report. It seems that mnesia:index_read() is buggy. I think the person working with Mnesia will correct it before R13B02. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Fri Sep 4 10:19:34 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 4 Sep 2009 10:19:34 +0200 Subject: [erlang-bugs] DETS spoils DAT files In-Reply-To: <1251788507.3867.8.camel@imac> References: <1251644590.20412.ezmlm@erlang.org> <1251788507.3867.8.camel@imac> Message-ID: <19104.52630.294077.992346@ornendil.du.uab.ericsson.se> [Fyodor Ustinov :] > In excess restrictions on 2G to file DETS spoils DAT files. Yes, you're right. It's not a bug, but a harsh way to inform the client that the table is full. Sometimes control is returned to the client before space has actually been allocated on disk (insert(), re-hashing, ...). By marking the table as corrupt subsequent calls will return the error. This simple solution was chosen because it was assumed that no one works with an almost full table anyway. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From ufm@REDACTED Fri Sep 4 13:38:48 2009 From: ufm@REDACTED (Fyodor Ustinov) Date: Fri, 04 Sep 2009 14:38:48 +0300 Subject: [erlang-bugs] DETS spoils DAT files In-Reply-To: <19104.52630.294077.992346@ornendil.du.uab.ericsson.se> References: <1251644590.20412.ezmlm@erlang.org> <1251788507.3867.8.camel@imac> <19104.52630.294077.992346@ornendil.du.uab.ericsson.se> Message-ID: <1252064328.3351.116.camel@imac> The worst thing is that such behavior takes over at DETS Mnesia. Even more dangerous form. For quite calmly returns (atomic, ok) on the crowded disc_only_copies base: (n1@REDACTED)67> mnesia:dirty_write(tab,{tab,"oo","oo"}). {error,{{bad_object,read_buckets}, "/home/ufm/src/Mnesia.n1@REDACTED/tab.DAT"}} (n1@REDACTED)68> mnesia:transaction(fun() -> mnesia:write(tab,{tab,"oo","oo"},write)end). {atomic,ok} (n1@REDACTED)69> > Yes, you're right. It's not a bug, but a harsh way to inform the > client that the table is full. > > Sometimes control is returned to the client before space has actually > been allocated on disk (insert(), re-hashing, ...). By marking the > table as corrupt subsequent calls will return the error. This simple > solution was chosen because it was assumed that no one works with an > almost full table anyway. From tuncer.ayaz@REDACTED Fri Sep 4 15:30:55 2009 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 4 Sep 2009 15:30:55 +0200 Subject: [erlang-questions] wx fails to build on Snow Leopard In-Reply-To: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> References: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> Message-ID: <4ac8254d0909040630o43cc6beo3988d9e2fc24d3bb@mail.gmail.com> On Wed, Sep 2, 2009 at 5:10 PM, Steve Vinoski wrote: > I'm seeing that the wx part of the Erlang/OTP build doesn't work on OS X > 10.6 (Snow Leopard). I don't use wx so it's no big deal to me, but I'm > seeing the g++ compiler appear to hang when compiling > lib/wx/c_src/gen/wxe_funcs.cpp. I let it run quite awhile and it never got > past that point, but my laptop fans were running full blast so I wonder if > the compilation got stuck in an infinite loop. If I manually edit wx out of > the lib/Makefile, then everything builds and seems to work as normal. There > are also lots of compilation warnings in the wx area due to deprecation of > some APIs being used and due to string constants being passed as char*. The build continues once that one long compile step has finished. What was "quite a while"? 10 minutes? 30 minutes? Can you try to build again and wait a little longer? This does not mean that the wx driver now automatically works on OSX: "WX Failed loading "wxe_driver"@[...]". Also, by default on OSX.6 it's -m64, so: wxe_driver.so: Mach-O 64-bit bundle x86_64.). The wx driver not easily working is an issue specific to Darwin, there are no problems like that on linux. For the record, Snow Leopard seems to bundle wx-2.8.8 and the on 10.5 it?also failed with 2.8.10. That's why I didn't try to use a 2.8.10 install of wxMac for the driver, yet. From cliff@REDACTED Fri Sep 4 20:52:03 2009 From: cliff@REDACTED (Cliff Moon) Date: Fri, 04 Sep 2009 11:52:03 -0700 Subject: [erlang-bugs] Segmentation Fault R13B01 Message-ID: <4AA161D3.2020905@moonpolysoft.com> What's the status on this issue? I've seen this behavior before as well. It seems to be a concurrency issue with active TCP packet delivery. You can pretty easily reproduce the issue using the janus app found here: http://github.com/cliffmoon/janus/tree/master You need to test on a linux machine with a lot of CPU's to see it happen with any frequency. I've found that 8 cores or more is enough to see it happen after a few tries. Using an EC2 high cpu XL instance seems to do the trick. Basically just start up the server in one VM like this: `make run1` and startup the workers by doing `make sh` and issuing the erlang command bot:test(flashbot, 10000). You have a pretty good chance of seeing one of the VM's segfault. If not you need to restart the VM and start from scratch. When I run this with gdb I get a similar backtrace to what was previously mentioned in this thread, in that it appears to be a problem in active tcp delivery. ------------------------------------------------------------------------------------------ Hi,I build erlang using gcc 4.1.2 (the default for centos) I started erl using -env ERL_MAX_PORTS 110000 +K true +P 110000 +S4 -smp -detached You can download 3 core dumps http://94.75.214.130/core.12514.gz http://94.75.214.130/core.939.gz http://94.75.214.130/core.28223.gz Unfortunately, i have no clue which part of the code triggers the segfault, other than it happens constantly, and i can not redistribute the whole program. The program though uses heavily tcp connections, typically i have over 10k established tcp connections. I would try to build the debug emulator tonight and let you know if i find something. Thanks, Georgos 2009/7/1 Raimo Niskanen > > On Wed, Jul 01, 2009 at 05:25:14PM +0200, Georgos Siganos wrote: > > Hi All,I am having problems with R13B01 and segmentation faults, as the > > following one (in the bottom). > > Unfortunately, i am not sure which part of the code triggers the > > segmentation fault. > > > > I am running Centos 5.3 ( 2.6.18-128.1.16.el5 #1 SMP x86_64 ) on a quad > core > > intel processor. > > The program quits with segfault both when compiled with and without hipe. > > > > Please let me know if there is anything else i can report to fix this > > problem. This > > segmentation > > fault is quite consistent and is a show stopper for my code. > > Thanks, > > Georgos > > How did you build the Erlang emulator, how did you start it > (arguments), how did you provoke the segfault? > > Can you post the code that provokes this to see > if it is reproducable on other OS:es? > > Can you post the core dump for the Erlang/OTP team to dissect? > > Can you build and run a debug emulator and see if you get an earlier > fault detection? (gmake smp TYPE=debug in the emulator directory) > > > > > > > ----------------------- gdb output -------------------------- > > Program terminated with signal 11, Segmentation fault. > > [New process 12531] > > [New process 12533] > > [New process 12532] > > [New process 12530] > > [New process 12526] > > [New process 12517] > > [New process 12516] > > [New process 12514] > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > (gdb) bt > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > #1 0x0000000000486849 in driver_deliver_term (port= out>, > > to=4816451, data=, > > len=) at beam/io.c:2994 > > #2 0x00000000005513cf in tcp_deliver (desc=0x2aab17c17548, len=3) at > > drivers/common/inet_drv.c:2980 > > #3 0x0000000000551891 in tcp_recv (desc=0x2aab17c17548, request_len=0) > at > > drivers/common/inet_drv.c:8043 > > #4 0x0000000000551afc in tcp_inet_drv_input (data=0x2aaae21a9fc4, > > event=) at drivers/common/inet_drv.c:8381 > > #5 0x00000000004a3d78 in erts_port_task_execute (runq=0x2add1fc19340, > > curr_port_pp=0x2aaaaaacb1e8) at beam/erl_port_task.c:853 > > #6 0x000000000049ebc5 in schedule (p=0x349, calls=) > at > > beam/erl_process.c:6116 > > #7 0x0000000000505afd in process_main () at beam/beam_emu.c:1126 > > #8 0x0000000000499126 in sched_thread_func (vesdp=) > at > > beam/erl_process.c:3015 > > #9 0x000000000057a0f4 in thr_wrapper (vtwd=) at > > common/ethread.c:475 > > #10 0x00002add1f31b367 in start_thread () from /lib64/libpthread.so.0 > > #11 0x00002add1f80cf7d in clone () from /lib64/libc.so.6 > > > --------------------------------------------------------------------------- > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > From nick@REDACTED Sat Sep 5 19:40:07 2009 From: nick@REDACTED (Niclas Eklund) Date: Sat, 5 Sep 2009 19:40:07 +0200 (CEST) Subject: [erlang-bugs] Erlang R13B01 ssh-1.1.3 cipher key matching bug and documentation errors In-Reply-To: <20090712025646.GA44385@k2r.org> References: <20090712025646.GA44385@k2r.org> Message-ID: Hello! Thank you for the input. At some parts will make it into R13B02. Niclas @Erlang/OTP On Sun, 12 Jul 2009, Kenji Rikitake wrote: > Here's a list of bugs/documentation errors of ssh-1.1.3 for R13B01 which > I experienced yesterday. > > * [bug] ssh:shell/3 and ssh:connect/3 do not crash immediately even if > they fail to negotiate the cipher to use, and hang forever > > How to reproduce: > set NOT to accept 3des-cbc as a cipher on the server > (in OpenSSH, set Ciphers directive at sshd_config, *excluding* 3des-cbc) > > Possible reason: failure of finding a matching cipher does not throw > an exception immediately (I haven't tested yet). > > FYI: on Portable OpenSSH 5.1 for FreeBSD slogin client, it will turn > out to be something like the following: > > -- quote -- > debug1: match: OpenSSH_5.1p1 FreeBSD-20080901 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > no matching cipher found: client 3des-cbc server aes128-ctr,blowfish-cbc,aes128-cbc,aes192-cbc,aes256-cbc > -- unquote -- > > * [documentation error] ssh manual should include that the current ssh > module only supports the following crypto parameters of SSH Version 2 > protocol: (my opinion follows later in this message) > > cipher: 3des-cbc only > MACs: hmac-sha1 only > > * [documentation error] ssh manual should include that only an > *unencrypted* private key is supported for ssh_rsa public key > authentication. > > The manual should also note that private keys for public key > authentication used for interactive logins are mostly encrypted so > cannot be used for the time being. > > * [documentation error] ssh:connect/1 and ssh:connect/2 no longer exist, > but still documented. Description for those old functions should be > eliminated, and requirement to use ssh:connect/3 instead should be > described. > > * [my opinion] I personally think only supporting 3des-cbc is *archaic* > and insufficient; implementing at least stronger ciphers such as > aes128-cbc and aes256-cbc, or even blowfish-cbc, should be considered > ASAP, regarding the strength of the ciphers. > > Regards, > Kenji Rikitake > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From nick@REDACTED Sat Sep 5 19:55:57 2009 From: nick@REDACTED (Niclas Eklund) Date: Sat, 5 Sep 2009 19:55:57 +0200 (CEST) Subject: [erlang-bugs] Erlang R13B01 ssh and crypto module patch of aes128-cbc support on ssh In-Reply-To: <20090813100926.GA12085@k2r.org> References: <20090813100926.GA12085@k2r.org> Message-ID: Hello! The crypto stuff will make into R13B02 and hopefullly also the SSH fixes as well. /Niclas @ Erlang/OTP On Thu, 13 Aug 2009, Kenji Rikitake wrote: > The following patch includes a feature enhancement of Erlang R13B01 ssh > and crypto modules to support aes128-cbc mode on SSH. > > BUG FOUND: ssh_transport:unpack/3 causes crypto:aes_cbc_ivec/1 to crash, > by passing a null binary (<<>>), which causes erlang:split_binary/2 to > crash by badarg. > > By tracing the exchange between a FreeBSD OpenSSH implementation, I > found a case where the internal variable SshLength in > ssh_transport:unpack/3 goes to zero, which leads to passing a null > binary as an argument to ssh_transport:decrypt_blocks/3 and to > aes_cbc_ivec/1. So I added a case statement to avoid calling the > decrypt_blocks/3 when SshLength = 0. > > Patches follow. > > Kenji Rikitake > > --- lib/ssh/src/ssh_transport.erl.FCS 2009-06-05 21:55:34.000000000 +0900 > +++ lib/ssh/src/ssh_transport.erl 2009-08-13 17:42:28.000000000 +0900 > @@ -228,8 +228,10 @@ > cookie = Random, > kex_algorithms = ["diffie-hellman-group1-sha1"], > server_host_key_algorithms = ["ssh-rsa", "ssh-dss"], > - encryption_algorithms_client_to_server = ["3des-cbc"], > - encryption_algorithms_server_to_client = ["3des-cbc"], > + %% encryption_algorithms_client_to_server = ["3des-cbc"], > + %% encryption_algorithms_server_to_client = ["3des-cbc"], > + encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"], > + encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"], > mac_algorithms_client_to_server = ["hmac-sha1"], > mac_algorithms_server_to_client = ["hmac-sha1"], > compression_algorithms_client_to_server = Compression, > @@ -243,8 +245,10 @@ > cookie = Random, > kex_algorithms = ["diffie-hellman-group1-sha1"], > server_host_key_algorithms = ["ssh-dss"], > - encryption_algorithms_client_to_server = ["3des-cbc"], > - encryption_algorithms_server_to_client = ["3des-cbc"], > + %% encryption_algorithms_client_to_server = ["3des-cbc"], > + %% encryption_algorithms_server_to_client = ["3des-cbc"], > + encryption_algorithms_client_to_server = ["aes128-cbc","3des-cbc"], > + encryption_algorithms_server_to_client = ["aes128-cbc","3des-cbc"], > mac_algorithms_client_to_server = ["hmac-sha1"], > mac_algorithms_server_to_client = ["hmac-sha1"], > compression_algorithms_client_to_server = Compression, > @@ -703,6 +707,9 @@ > > unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) -> > SshLength = ReminingLenght - MacSize, > + %%?dbg(?DBG_CRYPTO, > + %% "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n", > + %% [EncodedSoFar, SshLength, ReminingLenght, MacSize]), > {NoMac, Mac, Rest} = case MacSize of > 0 -> > < @@ -714,8 +721,16 @@ > Rest0/binary>> = EncodedSoFar, > {NoMac0, Mac0, Rest0} > end, > - {Ssh1, DecData, <<>>} = > - ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0), > + %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n", > + %% [NoMac, Mac, Rest]), > + {Ssh1, DecData, <<>>} = case SshLength of > + 0 -> > + {Ssh0, <<>>, <<>>}; > + _ -> > + ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0) > + end, > + %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n", > + %% [Ssh1, DecData, Rest, Mac]), > {Ssh1, DecData, Rest, Mac}. > > msg_data(PacketData) -> > @@ -800,6 +815,18 @@ > <> = hash(Ssh, "D", 192), > {ok, Ssh#ssh{encrypt_keys = {K1,K2,K3}, > encrypt_block_size = 8, > + encrypt_ctx = IV}}; > +encrypt_init(#ssh{encrypt = 'aes128-cbc', role = client} = Ssh) -> > + IV = hash(Ssh, "A", 128), > + <> = hash(Ssh, "C", 128), > + {ok, Ssh#ssh{encrypt_keys = K, > + encrypt_block_size = 16, > + encrypt_ctx = IV}}; > +encrypt_init(#ssh{encrypt = 'aes128-cbc', role = server} = Ssh) -> > + IV = hash(Ssh, "B", 128), > + <> = hash(Ssh, "D", 128), > + {ok, Ssh#ssh{encrypt_keys = K, > + encrypt_block_size = 16, > encrypt_ctx = IV}}. > > encrypt_final(Ssh) -> > @@ -815,10 +842,19 @@ > encrypt_keys = {K1,K2,K3}, > encrypt_ctx = IV0} = Ssh, Data) -> > %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K1=~p, K2=~p, K3=~p ~n", > - %% [IV0,K1,K2,K3]), > + %% [IV0,K1,K2,K3]), > Enc = crypto:des3_cbc_encrypt(K1,K2,K3,IV0,Data), > %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]), > IV = crypto:des_cbc_ivec(Enc), > + {Ssh#ssh{encrypt_ctx = IV}, Enc}; > +encrypt(#ssh{encrypt = 'aes128-cbc', > + encrypt_keys = K, > + encrypt_ctx = IV0} = Ssh, Data) -> > + %%?dbg(?DBG_CRYPTO, "encrypt: IV=~p K=~p ~n", > + %% [IV0,K]), > + Enc = crypto:aes_cbc_128_encrypt(K,IV0,Data), > + %%?dbg(?DBG_CRYPTO, "encrypt: ~p -> ~p ~n", [Data, Enc]), > + IV = crypto:aes_cbc_ivec(Enc), > {Ssh#ssh{encrypt_ctx = IV}, Enc}. > > > @@ -840,7 +876,21 @@ > hash(Ssh, "C", 192)}, > <> = KD, > {ok, Ssh#ssh{decrypt_keys = {K1, K2, K3}, decrypt_ctx = IV, > - decrypt_block_size = 8}}. > + decrypt_block_size = 8}}; > + > +decrypt_init(#ssh{decrypt = 'aes128-cbc', role = client} = Ssh) -> > + {IV, KD} = {hash(Ssh, "B", 128), > + hash(Ssh, "D", 128)}, > + <> = KD, > + {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV, > + decrypt_block_size = 16}}; > + > +decrypt_init(#ssh{decrypt = 'aes128-cbc', role = server} = Ssh) -> > + {IV, KD} = {hash(Ssh, "A", 128), > + hash(Ssh, "C", 128)}, > + <> = KD, > + {ok, Ssh#ssh{decrypt_keys = K, decrypt_ctx = IV, > + decrypt_block_size = 16}}. > > decrypt_final(Ssh) -> > {ok, Ssh#ssh {decrypt = none, > @@ -858,6 +908,14 @@ > Dec = crypto:des3_cbc_decrypt(K1,K2,K3,IV0,Data), > %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]), > IV = crypto:des_cbc_ivec(Data), > + {Ssh#ssh{decrypt_ctx = IV}, Dec}; > +decrypt(#ssh{decrypt = 'aes128-cbc', decrypt_keys = Key, > + decrypt_ctx = IV0} = Ssh, Data) -> > + %%?dbg(?DBG_CRYPTO, "decrypt: IV=~p Key=~p ~n", > + %% [IV0,Key]), > + Dec = crypto:aes_cbc_128_decrypt(Key,IV0,Data), > + %%?dbg(?DBG_CRYPTO, "decrypt: ~p -> ~p ~n", [Data, Dec]), > + IV = crypto:aes_cbc_ivec(Data), > {Ssh#ssh{decrypt_ctx = IV}, Dec}. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > --- lib/crypto/src/crypto.erl.FCS 2009-03-12 21:28:35.000000000 +0900 > +++ lib/crypto/src/crypto.erl 2009-08-13 13:27:09.000000000 +0900 > @@ -45,6 +45,7 @@ > %% -export([idea_cbc_encrypt/3, idea_cbc_decrypt/3]). > -export([aes_cbc_128_encrypt/3, aes_cbc_128_decrypt/3]). > -export([aes_cbc_256_encrypt/3, aes_cbc_256_decrypt/3]). > +-export([aes_cbc_ivec/1]). > > -export([dh_generate_parameters/2, dh_check/1]). %% Testing see below > > @@ -469,6 +470,19 @@ > control(?AES_CBC_256_DECRYPT, [Key, IVec, Data]). > > %% > +%% aes_cbc_ivec(Data) -> binary() > +%% > +%% Returns the IVec to be used in the next iteration of > +%% aes_cbc_*_[encrypt|decrypt]. > +%% IVec size: 16 bytes > +%% > +aes_cbc_ivec(Data) when is_binary(Data) -> > + {_, IVec} = split_binary(Data, size(Data) - 16), > + IVec; > +aes_cbc_ivec(Data) when is_list(Data) -> > + aes_cbc_ivec(list_to_binary(Data)). > + > +%% > %% XOR - xor to iolists and return a binary > %% NB doesn't check that they are the same size, just concatenates > %% them and sends them to the driver > From dgud@REDACTED Mon Sep 7 08:00:18 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 07 Sep 2009 08:00:18 +0200 Subject: [erlang-bugs] Re: [erlang-questions] wx fails to build on Snow Leopard In-Reply-To: <4ac8254d0909040630o43cc6beo3988d9e2fc24d3bb@mail.gmail.com> References: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> <4ac8254d0909040630o43cc6beo3988d9e2fc24d3bb@mail.gmail.com> Message-ID: <4AA4A172.1040809@erix.ericsson.se> I don't think wxWidgets 2.8.* works in 64-bit, it uses the old gui api. They are working on fixing that in wxWidgets 2.9 and 3.0. But the problem remains, for me the emulator crashes with a SIGTRAP when loading the driver. /Dan Tuncer Ayaz wrote: > On Wed, Sep 2, 2009 at 5:10 PM, Steve Vinoski wrote: >> I'm seeing that the wx part of the Erlang/OTP build doesn't work on OS X >> 10.6 (Snow Leopard). I don't use wx so it's no big deal to me, but I'm >> seeing the g++ compiler appear to hang when compiling >> lib/wx/c_src/gen/wxe_funcs.cpp. I let it run quite awhile and it never got >> past that point, but my laptop fans were running full blast so I wonder if >> the compilation got stuck in an infinite loop. If I manually edit wx out of >> the lib/Makefile, then everything builds and seems to work as normal. There >> are also lots of compilation warnings in the wx area due to deprecation of >> some APIs being used and due to string constants being passed as char*. > > The build continues once that one long compile step has finished. > What was "quite a while"? 10 minutes? 30 minutes? > > Can you try to build again and wait a little longer? > > This does not mean that the wx driver now automatically works on OSX: > "WX Failed loading "wxe_driver"@[...]". > Also, by default on OSX.6 it's -m64, so: > wxe_driver.so: Mach-O 64-bit bundle x86_64.). > > The wx driver not easily working is an issue specific to Darwin, > there are no problems like that on linux. > > For the record, Snow Leopard seems to bundle wx-2.8.8 and the > on 10.5 it also failed with 2.8.10. That's why I didn't try to use > a 2.8.10 install of wxMac for the driver, yet. > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From tuncer.ayaz@REDACTED Mon Sep 7 11:24:12 2009 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 7 Sep 2009 11:24:12 +0200 Subject: [erlang-bugs] Re: [erlang-questions] wx fails to build on Snow Leopard In-Reply-To: <4AA4A172.1040809@erix.ericsson.se> References: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> <4ac8254d0909040630o43cc6beo3988d9e2fc24d3bb@mail.gmail.com> <4AA4A172.1040809@erix.ericsson.se> Message-ID: <4ac8254d0909070224p11db54f6idaad05b6fb6ad0ab@mail.gmail.com> On Mon, Sep 7, 2009 at 8:00 AM, Dan Gudmundsson wrote: > I don't think wxWidgets 2.8.* works in 64-bit, it uses the old gui api. > They are working on fixing that in wxWidgets 2.9 and 3.0. http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard I'll try the WX_2_9_0_BRANCH branch and/or trunk. > But the problem remains, for me the emulator crashes with a SIGTRAP when > loading the driver. > > /Dan > > Tuncer Ayaz wrote: >> >> On Wed, Sep 2, 2009 at 5:10 PM, Steve Vinoski wrote: >>> >>> I'm seeing that the wx part of the Erlang/OTP build doesn't work on OS X >>> 10.6 (Snow Leopard). I don't use wx so it's no big deal to me, but I'm >>> seeing the g++ compiler appear to hang when compiling >>> lib/wx/c_src/gen/wxe_funcs.cpp. I let it run quite awhile and it never >>> got >>> past that point, but my laptop fans were running full blast so I wonder >>> if >>> the compilation got stuck in an infinite loop. If I manually edit wx out >>> of >>> the lib/Makefile, then everything builds and seems to work as normal. >>> There >>> are also lots of compilation warnings in the wx area due to deprecation >>> of >>> some APIs being used and due to string constants being passed as char*. >> >> The build continues once that one long compile step has finished. >> What was "quite a while"? 10 minutes? 30 minutes? >> >> Can you try to build again and wait a little longer? >> >> This does not mean that the wx driver now automatically works on OSX: >> ?"WX Failed loading "wxe_driver"@[...]". >> Also, by default on OSX.6 it's -m64, so: >> ?wxe_driver.so: Mach-O 64-bit bundle x86_64.). >> >> The wx driver not easily working is an issue specific to Darwin, >> there are no problems like that on linux. >> >> For the record, Snow Leopard seems to bundle wx-2.8.8 and the >> on 10.5 it also failed with 2.8.10. That's why I didn't try to use >> a 2.8.10 install of wxMac for the driver, yet. >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> > From tuncer.ayaz@REDACTED Mon Sep 7 20:01:46 2009 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 7 Sep 2009 20:01:46 +0200 Subject: [erlang-bugs] Re: [erlang-questions] wx fails to build on Snow Leopard In-Reply-To: <4ac8254d0909070224p11db54f6idaad05b6fb6ad0ab@mail.gmail.com> References: <65b2728e0909020810j19107120r40db7344b7fbc278@mail.gmail.com> <4ac8254d0909040630o43cc6beo3988d9e2fc24d3bb@mail.gmail.com> <4AA4A172.1040809@erix.ericsson.se> <4ac8254d0909070224p11db54f6idaad05b6fb6ad0ab@mail.gmail.com> Message-ID: <4ac8254d0909071101g6e4210a7g16dbeb1ef7d09107@mail.gmail.com> On Mon, Sep 7, 2009 at 11:24 AM, Tuncer Ayaz wrote: > On Mon, Sep 7, 2009 at 8:00 AM, Dan Gudmundsson wrote: >> I don't think wxWidgets 2.8.* works in 64-bit, it uses the old gui api. >> They are working on fixing that in wxWidgets 2.9 and 3.0. > > http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard > > I'll try the WX_2_9_0_BRANCH branch and/or trunk. fyi, 2.9 branch didn't build completely. trunk built but it looks like gen/wxe_funcs.cpp would need to be adapted to changes in wx trunk. >> But the problem remains, for me the emulator crashes with a SIGTRAP when >> loading the driver. >> >> /Dan >> >> Tuncer Ayaz wrote: >>> >>> On Wed, Sep 2, 2009 at 5:10 PM, Steve Vinoski wrote: >>>> >>>> I'm seeing that the wx part of the Erlang/OTP build doesn't work on OS X >>>> 10.6 (Snow Leopard). I don't use wx so it's no big deal to me, but I'm >>>> seeing the g++ compiler appear to hang when compiling >>>> lib/wx/c_src/gen/wxe_funcs.cpp. I let it run quite awhile and it never >>>> got >>>> past that point, but my laptop fans were running full blast so I wonder >>>> if >>>> the compilation got stuck in an infinite loop. If I manually edit wx out >>>> of >>>> the lib/Makefile, then everything builds and seems to work as normal. >>>> There >>>> are also lots of compilation warnings in the wx area due to deprecation >>>> of >>>> some APIs being used and due to string constants being passed as char*. >>> >>> The build continues once that one long compile step has finished. >>> What was "quite a while"? 10 minutes? 30 minutes? >>> >>> Can you try to build again and wait a little longer? >>> >>> This does not mean that the wx driver now automatically works on OSX: >>> ?"WX Failed loading "wxe_driver"@[...]". >>> Also, by default on OSX.6 it's -m64, so: >>> ?wxe_driver.so: Mach-O 64-bit bundle x86_64.). >>> >>> The wx driver not easily working is an issue specific to Darwin, >>> there are no problems like that on linux. >>> >>> For the record, Snow Leopard seems to bundle wx-2.8.8 and the >>> on 10.5 it also failed with 2.8.10. That's why I didn't try to use >>> a 2.8.10 install of wxMac for the driver, yet. >>> >>> ________________________________________________________________ >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>> erlang-bugs (at) erlang.org >>> >>> >> > From rickard.s.green@REDACTED Tue Sep 8 13:52:00 2009 From: rickard.s.green@REDACTED (Rickard Green) Date: Tue, 08 Sep 2009 13:52:00 +0200 Subject: [erlang-bugs] Segmentation Fault R13B01 In-Reply-To: <4AA161D3.2020905@moonpolysoft.com> References: <4AA161D3.2020905@moonpolysoft.com> Message-ID: <4AA64560.2030002@ericsson.com> We've not been able to reproduce this. Next time you get a core, please make the core and the beam.smp file (located in lib/erlang/erts-5.7.2/bin) available for us. Also include info about linux distribution, kernel version, hw arch, and gcc version used. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. Cliff Moon wrote: >
What's the > status on this issue? I've seen this behavior before as well. It seems > to be a concurrency issue with active TCP packet delivery. You can > pretty easily reproduce the issue using the janus app found here: > > http://github.com/cliffmoon/janus/tree/master > > You need to test on a linux machine with a lot of CPU's to see it happen > with any frequency. I've found that 8 cores or more is enough to see it > happen after a few tries. Using an EC2 high cpu XL instance seems to do > the trick. Basically just start up the server in one VM like this: > `make run1` and startup the workers by doing `make sh` and issuing the > erlang command bot:test(flashbot, 10000). > > You have a pretty good chance of seeing one of the VM's segfault. If > not you need to restart the VM and start from scratch. When I run this > with gdb I get a similar backtrace to what was previously mentioned in > this thread, in that it appears to be a problem in active tcp delivery. > > > ------------------------------------------------------------------------------------------ > > > Hi,I build erlang using gcc 4.1.2 (the default for centos) > I started erl using > -env ERL_MAX_PORTS 110000 +K true +P 110000 +S4 -smp -detached > > You can download 3 core dumps > http://94.75.214.130/core.12514.gz > http://94.75.214.130/core.939.gz > http://94.75.214.130/core.28223.gz > > Unfortunately, i have no clue which part of the code triggers the > segfault, other than it happens constantly, and i > can not redistribute the whole program. The program though uses > heavily tcp > connections, typically i have over > 10k established tcp connections. > > I would try to build the debug emulator tonight and let you know if > i find > something. > > Thanks, > Georgos > > 2009/7/1 Raimo Niskanen > > > > > > > On Wed, Jul 01, 2009 at 05:25:14PM +0200, Georgos Siganos wrote: > > > Hi All,I am having problems with R13B01 and segmentation > faults, as the > > > following one (in the bottom). > > > Unfortunately, i am not sure which part of the code triggers the > > > segmentation fault. > > > > > > I am running Centos 5.3 ( 2.6.18-128.1.16.el5 #1 SMP x86_64 ) > on a quad > > core > > > intel processor. > > > The program quits with segfault both when compiled with and > without hipe. > > > > > > Please let me know if there is anything else i can report to > fix this > > > problem. This > > > segmentation > > > fault is quite consistent and is a show stopper for my code. > > > Thanks, > > > Georgos > > > > How did you build the Erlang emulator, how did you start it > > (arguments), how did you provoke the segfault? > > > > Can you post the code that provokes this to see > > if it is reproducable on other OS:es? > > > > Can you post the core dump for the Erlang/OTP team to dissect? > > > > Can you build and run a debug emulator and see if you get an earlier > > fault detection? (gmake smp TYPE=debug in the emulator directory) > > > > > > > > > > > ----------------------- gdb output -------------------------- > > > Program terminated with signal 11, Segmentation fault. > > > [New process 12531] > > > [New process 12533] > > > [New process 12532] > > > [New process 12530] > > > [New process 12526] > > > [New process 12517] > > > [New process 12516] > > > [New process 12514] > > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > > (gdb) bt > > > #0 0x00002add1f7b570b in memcpy () from /lib64/libc.so.6 > > > #1 0x0000000000486849 in driver_deliver_term (port= optimized > > out>, > > > to=4816451, data=, > > > len=) at beam/io.c:2994 > > > #2 0x00000000005513cf in tcp_deliver (desc=0x2aab17c17548, > len=3) at > > > drivers/common/inet_drv.c:2980 > > > #3 0x0000000000551891 in tcp_recv (desc=0x2aab17c17548, > request_len=0) > > at > > > drivers/common/inet_drv.c:8043 > > > #4 0x0000000000551afc in tcp_inet_drv_input (data=0x2aaae21a9fc4, > > > event=) at drivers/common/inet_drv.c:8381 > > > #5 0x00000000004a3d78 in erts_port_task_execute > (runq=0x2add1fc19340, > > > curr_port_pp=0x2aaaaaacb1e8) at beam/erl_port_task.c:853 > > > #6 0x000000000049ebc5 in schedule (p=0x349, calls= optimized out>) > > at > > > beam/erl_process.c:6116 > > > #7 0x0000000000505afd in process_main () at beam/beam_emu.c:1126 > > > #8 0x0000000000499126 in sched_thread_func (vesdp= optimized out>) > > at > > > beam/erl_process.c:3015 > > > #9 0x000000000057a0f4 in thr_wrapper (vtwd= out>) at > > > common/ethread.c:475 > > > #10 0x00002add1f31b367 in start_thread () from > /lib64/libpthread.so.0 > > > #11 0x00002add1f80cf7d in clone () from /lib64/libc.so.6 > > > > > > > --------------------------------------------------------------------------- > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > > >
-- Rickard Green, Erlang/OTP, Ericsson AB. From john.hughes@REDACTED Tue Sep 8 15:10:14 2009 From: john.hughes@REDACTED (John Hughes) Date: Tue, 8 Sep 2009 15:10:14 +0200 Subject: try-catch doesn't work in werl In-Reply-To: <4AA64560.2030002@ericsson.com> References: <4AA161D3.2020905@moonpolysoft.com> <4AA64560.2030002@ericsson.com> Message-ID: <78A34F6D0AA048E6A00DA7D09E5FF9C2@JohnsTablet2009> Here's an example in erl: 1> try throw(foo) catch A:B -> {A,B} end. {throw,foo} Here's the same example in werl: 20> try throw(foo) catch A:B -> {A,B} end. ** exception throw: foo exits and errors behave the same way--the exception is not caught when the try...catch is evaluated in the shell. I'm running emulator version 5.7.2 (in both cases!) and OTP release R13B01, under Vista. John Hughes From kristoffer.koch@REDACTED Tue Sep 8 16:48:46 2009 From: kristoffer.koch@REDACTED (Kristoffer Ellersgaard Koch) Date: Tue, 8 Sep 2009 16:48:46 +0200 Subject: httpc crash Message-ID: <2b868f8f0909080748x36b470b1o68f2fd29fd8a17fd@mail.gmail.com> Hi I'm using http a bit, and httpc now crashes every time [1]. The state-record in httpc_handler is given below [2]. It seems that request is set to undefined, and that the function therefor never can match. Have anyone else seen this before? [1] Edited away a lot of binary and hostname. ** Reason for termination == ** {function_clause, ?????? [{httpc_handler,handle_info, ??????????? [{ssl, ???????????????? {sslsocket,10,<0.109.0>}, ???????????????? <>}, ???????????? {state,undefined, ???????????????? {tcp_session, ???????????????????? {{"www.example.com",443},<0.108.0>}, ???????????????????? false,https, ???????????????????? {sslsocket,10,<0.109.0>}, ???????????????????? 1,keep_alive}, ???????????????? undefined,undefined,undefined,undefined, ???????????????? {[],[]}, ???????????????? {[],[]}, ???????????????? keep_alive,[],nolimit,nolimit, ???????????????? {options, ???????????????????? {undefined,[]}, ???????????????????? 0,2,5,120000,2,enabled,false,inet,default,default}, ???????????????? {timers,[],#Ref<0.0.0.1975>}, ???????????????? httpc_manager_koch,undefined}]}, ??????? {gen_server,handle_msg,5}, ??????? {proc_lib,init_p_do_apply,3}]} [2] -record(state, { request, % #request{} session, % #tcp_session{} status_line, % {Version, StatusCode, ReasonPharse} headers, % #http_response_h{} body, % binary() mfa, % {Moduel, Function, Args} pipeline = queue:new(), % queue() keep_alive = queue:new(), % queue() status = new, % new | pipeline | keep_alive | close | ssl_tunnel canceled = [], % [RequestId] max_header_size = nolimit, % nolimit | integer() max_body_size = nolimit, % nolimit | integer() options, % #options{} timers = #timers{}, % #timers{} profile_name, % atom() - id of httpc_manager process. once % send | undefined }). -- Kristoffer E. Koch +47 990 26 250 From anders.nygren@REDACTED Wed Sep 9 18:12:04 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 9 Sep 2009 11:12:04 -0500 Subject: asn1ct:value/1 bug(s)? Message-ID: Hi In the past, (R12B1 or something like that), I have been able to use asn1ct:value/1 to generate random data according to an ASN.1 spec. But it seems to not work anymore in R13B02. Error 1: In MAP-MS-DataTypes.asn there is RAB-Id ::= INTEGER (1..maxNrOfRABs) maxNrOfRABs INTEGER ::= 255 50> asn1ct:value('MAP-MS-DataTypes-v6','RAB-Id'). {error, {{case_clause, {1, {'Externalvaluereference',736,'MAP-MS-DataTypes-v6', maxNrOfRABs}}}, [{asn1ct_value,c_random,2}, {asn1ct,value,2}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]}} Error 2: In some cases it returns ok, but with errors in nested elements of the result. 51> asn1ct:value('MAP-MS-DataTypes-v6','InsertSubscriberDataRes'). {ok,{'InsertSubscriberDataRes', [{asn1_error, {not_found,{'MAP-MS-DataTypes-v6','Ext-TeleserviceCode'}}}], [{asn1_error, {not_found, {'MAP-MS-DataTypes-v6','Ext-BearerServiceCode'}}}], {asn1_error,{not_found,{'MAP-MS-DataTypes-v6','SS-List'}}}, [1,0,1,1,1,0,1,1,1,0,1,1,1,0,1], asn1_EMPTY, [1], {asn1_error, {not_found,{'MAP-MS-DataTypes-v6','ExtensionContainer'}}}, undefined, [1,0,1,1,1,0,1]}} Error 3?: Also in MAP-MS-DataTypes.asn T-BcsmTriggerDetectionPoint ::= ENUMERATED { termAttemptAuthorized (12), ... , tBusy (13), tNoAnswer (14)} 52> asn1ct:value('MAP-MS-DataTypes-v6','T-BcsmTriggerDetectionPoint'). {ok,asn1_EMPTY} Is asn1_EMPTY really a valid value for this type? /Anders From paul-trapexit@REDACTED Fri Sep 11 03:15:51 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Thu, 10 Sep 2009 18:15:51 -0700 (PDT) Subject: tracing while constructing binary segfaults emulator In-Reply-To: References: Message-ID: Hi. Sorry to be a pest, but I didn't see this bug acknowledged, and I'm nervous to trace any running system given this. Can I inquire about status? -- p On Wed, 19 Aug 2009, Paul Mineiro wrote: > this is r12b5, happens on both my mac os/x and my ubuntu 32 bit hardy. > the exact number of calls to random_binaries before the problem exhibits > is variable. > > cheers, > > -- p > > ---------- > > -module (crash). > -export ([ random_binaries/1 ]). > > random_binary () -> > << <<($a + random:uniform ($z - $a)):8>> || _ <- lists:seq (1, 10) >>. > > random_binaries (N) when N > 0 -> > random_binary (), > random_binaries (N - 1); > random_binaries (_) -> > ok. > > ---------- > > % erl > Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [kernel-poll:false] > Eshell V5.6.5 (abort with ^G) > 1> c (crash), dbg:tracer (), dbg:p (all, [ call ]), dbg:tpl (crash, dbg:fun2ms (fun (_) -> return_trace () end)), crash:random_binaries (1000). > (<0.31.0>) call crash:random_binaries(1000) > (<0.31.0>) call crash:random_binary() > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([1,2,3,4,5,6,7,8,9,10],<<>> > ) > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([2,3,4,5,6,7,8,9,10],<<"d"> > >) > > ... > > (<0.31.0>) returned from crash:random_binary/0 -> <<"hulbjkedwk">> > (<0.31.0>) call crash:random_binaries(938) > (<0.31.0>) call crash:random_binary() > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([1,2,3,4,5,6,7,8,9,10],<<>>) > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([2,3,4,5,6,7,8,9,10],<<0>>) > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([3,4,5,6,7,8,9,10],<<0,0>>) > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([4,5,6,7,8,9,10],<<0,0,0>>) > (<0.31.0>) call crash:'-random_binary/0-lbc$^0/2-0-'([5,6,7,8,9,10],<<0,0,0,0>>) > zsh: segmentation fault (core dumped) erl > % gdb /usr/lib/erlang/erts-5.6.5/bin/beam core.20527 > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > > warning: Can't read pathname for load map: Input/output error. > Reading symbols from /lib/tls/i686/cmov/libutil.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/libutil.so.1 > Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 > Reading symbols from /lib/tls/i686/cmov/libm.so.6... > (no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/libm.so.6 > Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. > Loaded symbols for /lib/libncurses.so.5 > Reading symbols from /lib/tls/i686/cmov/libpthread.so.0... > (no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 > Reading symbols from /lib/tls/i686/cmov/librt.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/librt.so.1 > Reading symbols from /lib/tls/i686/cmov/libc.so.6... > (no debugging symbols found)...done. > Loaded symbols for /lib/tls/i686/cmov/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /usr/lib/libsctp.so.1... > (no debugging symbols found)...done. > Loaded symbols for /usr/lib/libsctp.so.1 > (no debugging symbols found) > Core was generated by `/usr/lib/erlang/erts-5.6.5/bin/beam -- -root /usr/lib/erlang -progname erl -- -'. > Program terminated with signal 11, Segmentation fault. > [New process 20527] > [New process 20531] > #0 0x080788e8 in ?? () > (gdb) bt > #0 0x080788e8 in ?? () > #1 0x0807230c in ?? () > #2 0x0807462b in erts_alcu_alloc_ts () > #3 0x080beb52 in new_binary () > #4 0x080bed35 in list_to_binary_1 () > #5 0x080fe13c in process_main () > #6 0x0807c504 in erl_start () > #7 0x08067492 in main () > (gdb) q > > -------------- > > From bgustavsson@REDACTED Fri Sep 11 13:58:32 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 11 Sep 2009 13:58:32 +0200 Subject: [erlang-bugs] Re: tracing while constructing binary segfaults emulator In-Reply-To: References: Message-ID: <6672d0160909110458v2d91adf4ke13c04d3b45abe63@mail.gmail.com> On Fri, Sep 11, 2009 at 3:15 AM, Paul Mineiro wrote: > Hi. > > Sorry to be a pest, but I didn't see this bug acknowledged, and I'm > nervous to trace any running system given this. > > Can I inquire about status? We'll try to fix it in R13B02. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenneth.lundin@REDACTED Tue Sep 15 15:08:09 2009 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 15 Sep 2009 15:08:09 +0200 Subject: [erlang-bugs] asn1ct:value/1 bug(s)? In-Reply-To: References: Message-ID: Hi, I can't find anything wrong with asn1ct:value/2 it works as expected for me and we use it extensively in our test suites. are you sure that you have the *.asn1db files available when you call asn1ct:value ? If you still think this is a bug please provide info for how I can reproduce it. AFAIK there are no changes to the implementation that should have impact on asn1ct:value/2. /Regards Kenneth On Wed, Sep 9, 2009 at 6:12 PM, Anders Nygren wrote: > Hi > In the past, (R12B1 or something like that), I have been able to use > asn1ct:value/1 to generate random data according to an ASN.1 spec. > > But it seems to not work anymore in R13B02. > > Error 1: > In MAP-MS-DataTypes.asn there is > > RAB-Id ::= INTEGER (1..maxNrOfRABs) > > maxNrOfRABs INTEGER ::= 255 > > 50> asn1ct:value('MAP-MS-DataTypes-v6','RAB-Id'). > {error, > {{case_clause, > {1, > {'Externalvaluereference',736,'MAP-MS-DataTypes-v6', > maxNrOfRABs}}}, > [{asn1ct_value,c_random,2}, > {asn1ct,value,2}, > {erl_eval,do_apply,5}, > {shell,exprs,6}, > {shell,eval_exprs,6}, > {shell,eval_loop,3}]}} > > Error 2: > In some cases it returns ok, but with errors in nested elements of the > result. > 51> asn1ct:value('MAP-MS-DataTypes-v6','InsertSubscriberDataRes'). > {ok,{'InsertSubscriberDataRes', > [{asn1_error, > {not_found,{'MAP-MS-DataTypes-v6','Ext-TeleserviceCode'}}}], > [{asn1_error, > {not_found, > {'MAP-MS-DataTypes-v6','Ext-BearerServiceCode'}}}], > {asn1_error,{not_found,{'MAP-MS-DataTypes-v6','SS-List'}}}, > [1,0,1,1,1,0,1,1,1,0,1,1,1,0,1], > asn1_EMPTY, > [1], > {asn1_error, > {not_found,{'MAP-MS-DataTypes-v6','ExtensionContainer'}}}, > undefined, > [1,0,1,1,1,0,1]}} > > Error 3?: > Also in MAP-MS-DataTypes.asn > > T-BcsmTriggerDetectionPoint ::= ENUMERATED { > termAttemptAuthorized (12), > ... , > tBusy (13), > tNoAnswer (14)} > > 52> asn1ct:value('MAP-MS-DataTypes-v6','T-BcsmTriggerDetectionPoint'). > {ok,asn1_EMPTY} > > Is asn1_EMPTY really a valid value for this type? > > /Anders > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From anders.nygren@REDACTED Wed Sep 16 01:14:50 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 15 Sep 2009 18:14:50 -0500 Subject: [erlang-bugs] asn1ct:value/1 bug(s)? In-Reply-To: References: Message-ID: On Tue, Sep 15, 2009 at 8:08 AM, Kenneth Lundin wrote: > Hi, > > I can't find anything wrong with asn1ct:value/2 it works as expected > for me and we use it > extensively in our test suites. > > are you sure that you have the *.asn1db files available when you call > asn1ct:value ? > > If you still think this is a bug please provide info for how I can reproduce it. > AFAIK there are no changes to the implementation that should have > impact on asn1ct:value/2. The asn1db files are there. Playing around with asn1_db, I have noticed that for some asn files the #typedef.checked=false and for some its =true. The file I mentioned in the first email has all types checked=false. I have not figured out why some are checked and some are not, but I suspect it has to do with the compilation order. We currently do not check for dependencies between asn files, since the compiler normally generates correct code anyway, so the asn files just gets compiled in alphabetical order. Can You please explain a little about checked=true/false, what it means and how to get from one to the other. I am trying to generate QuickCheck tests and data generators from ASN.1 specifications so I have been trying to use asn1_db instead of making my own asn.1 parser, but I am a little stumped now. /Anders > > /Regards Kenneth > > On Wed, Sep 9, 2009 at 6:12 PM, Anders Nygren wrote: >> Hi >> In the past, (R12B1 or something like that), I have been able to use >> asn1ct:value/1 to generate random data according to an ASN.1 spec. >> >> But it seems to not work anymore in R13B02. >> >> Error 1: >> In MAP-MS-DataTypes.asn there is >> >> RAB-Id ::= INTEGER (1..maxNrOfRABs) >> >> maxNrOfRABs INTEGER ::= 255 >> >> 50> asn1ct:value('MAP-MS-DataTypes-v6','RAB-Id'). >> {error, >> ? ?{{case_clause, >> ? ? ? ? {1, >> ? ? ? ? ?{'Externalvaluereference',736,'MAP-MS-DataTypes-v6', >> ? ? ? ? ? ? ?maxNrOfRABs}}}, >> ? ? [{asn1ct_value,c_random,2}, >> ? ? ?{asn1ct,value,2}, >> ? ? ?{erl_eval,do_apply,5}, >> ? ? ?{shell,exprs,6}, >> ? ? ?{shell,eval_exprs,6}, >> ? ? ?{shell,eval_loop,3}]}} >> >> Error 2: >> In some cases it returns ok, but with errors in nested elements of the >> result. >> 51> ?asn1ct:value('MAP-MS-DataTypes-v6','InsertSubscriberDataRes'). >> {ok,{'InsertSubscriberDataRes', >> ? ? ? ?[{asn1_error, >> ? ? ? ? ? ? {not_found,{'MAP-MS-DataTypes-v6','Ext-TeleserviceCode'}}}], >> ? ? ? ?[{asn1_error, >> ? ? ? ? ? ? {not_found, >> ? ? ? ? ? ? ? ? {'MAP-MS-DataTypes-v6','Ext-BearerServiceCode'}}}], >> ? ? ? ?{asn1_error,{not_found,{'MAP-MS-DataTypes-v6','SS-List'}}}, >> ? ? ? ?[1,0,1,1,1,0,1,1,1,0,1,1,1,0,1], >> ? ? ? ?asn1_EMPTY, >> ? ? ? ?[1], >> ? ? ? ?{asn1_error, >> ? ? ? ? ? ?{not_found,{'MAP-MS-DataTypes-v6','ExtensionContainer'}}}, >> ? ? ? ?undefined, >> ? ? ? ?[1,0,1,1,1,0,1]}} >> >> Error 3?: >> Also in MAP-MS-DataTypes.asn >> >> T-BcsmTriggerDetectionPoint ::= ENUMERATED { >> ? ? ? ?termAttemptAuthorized (12), >> ? ? ? ?... , >> ? ? ? ?tBusy (13), >> ? ? ? ?tNoAnswer (14)} >> >> 52> asn1ct:value('MAP-MS-DataTypes-v6','T-BcsmTriggerDetectionPoint'). >> {ok,asn1_EMPTY} >> >> Is asn1_EMPTY really a valid value for this type? >> >> /Anders >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> > From bgustavsson@REDACTED Wed Sep 16 11:41:06 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 16 Sep 2009 11:41:06 +0200 Subject: [erlang-bugs] tracing while constructing binary segfaults emulator In-Reply-To: References: Message-ID: <6672d0160909160241w3c0f98bdoc0af7da791e9d4e3@mail.gmail.com> On Thu, Aug 20, 2009 at 6:21 AM, Paul Mineiro wrote: > this is r12b5, happens on both my mac os/x and my ubuntu 32 bit hardy. > the exact number of calls to random_binaries before the problem exhibits > is variable. It will be corrected in R13B02. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Wed Sep 16 17:04:41 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 16 Sep 2009 17:04:41 +0200 Subject: [erlang-bugs] Re: sctp chunked messages In-Reply-To: References: Message-ID: <20090916150441.GA26190@erix.ericsson.se> On Thu, Aug 20, 2009 at 03:23:38PM -0500, Anders Nygren wrote: > After some more testing I have found that > 1, the error only happens when it is the client that is receiving chunked > messages. > 2, it works correctly on Solaris > As far as I know, SCTP shall not chunk messages, other than under the hood, so the inet_drv should not have to reassemble chunks. http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13#section-3.1.4 There are a few exceptions: if the application's receive buffer is too small, or if the protocol stack is running low on buffers, a message without the MSG_EOR bit set may arrive, indicating truncation. inet_drv is then supposed to report the error and not the message. I have problems getting my hands on more than one Ubuntu machine; which Ubuntu variant are you using, and is it sufficient if the client runs Ubuntu? I assume it has to be client and server on different machines to get chunking. I suspect it is an Ubuntu/Linux kernel bug, or an inet_drv bug that mishandles partial messages. But since it seems to be low load it is hardly the protocol stack running low on buffers... So there should not even be a partial message. Or maybe the default buffer size is small on Ubuntu, and buffer size option handling is broken in inet_drv... > /Anders > > On Wed, Aug 19, 2009 at 4:06 PM, Anders Nygren wrote: > > Hi > > I am having a problem with chunked messages. When I try to send a > > message that is ~2kByte, it gets split into two chunks. But gen_sctp > > does not reassemble the chunks and only delivers the last chunk to > > my application. > > I have attached a simple test case to demonstrate the problem. > > > > To run > > Machine A: > > sctp_err:server(IP,Port). > > > > Machine B: > > sctp_err:client(IP,Port). > > > > I dont know if this is related but sometimes I also receive a > > {sctp_error, enoent} before the the #sctp_sndrcvinfo with the second > > chunk. > > > > This is using > > OTP R13B01 > > Between two machines running Ubuntu > > > > uname -a > > Linux curso-laptop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 > > 00:28:35 UTC 2009 i686 GNU/Linux > > > > ?uname -a > > Linux glr-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 > > UTC 2009 i686 GNU/Linux > > > > /Anders > > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From anders.nygren@REDACTED Wed Sep 16 18:20:33 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 16 Sep 2009 11:20:33 -0500 Subject: [erlang-bugs] Re: sctp chunked messages In-Reply-To: <20090916150441.GA26190@erix.ericsson.se> References: <20090916150441.GA26190@erix.ericsson.se> Message-ID: On Wed, Sep 16, 2009 at 10:04 AM, Raimo Niskanen wrote: > On Thu, Aug 20, 2009 at 03:23:38PM -0500, Anders Nygren wrote: >> After some more testing I have found that >> 1, the error only happens when it is the client that is receiving chunked >> messages. >> 2, it works correctly on Solaris >> > > As far as I know, SCTP shall not chunk messages, other than > under the hood, so the inet_drv should not have to > reassemble chunks. > http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13#section-3.1.4 > > There are a few exceptions: if the application's > receive buffer is too small, or if the protocol stack > is running low on buffers, a message without the MSG_EOR > bit set may arrive, indicating truncation. > > inet_drv is then supposed to report the error and not the message. > > > > I have problems getting my hands on more than one Ubuntu machine; > which Ubuntu variant are you using, and is it sufficient > if the client runs Ubuntu? It is almost one month ago that I tested this but I am pretty sure I got the same error on OpenSuSE 11.1, is I think it is a general Linux problem. > I assume it has to be > client and server on different machines to get chunking. Yes > > I suspect it is an Ubuntu/Linux kernel bug, But then SCTP would basically not work on Linux, so I doubt it. > or an inet_drv > bug that mishandles partial messages. But since it seems > to be low load it is hardly the protocol stack running > low on buffers... So there should not even be a partial message. > > Or maybe the default buffer size is small on Ubuntu, > and buffer size option handling is broken in inet_drv... I am on vacation this week, but I can do some more tests next week if You need any more information. /Anders > > >> /Anders >> >> On Wed, Aug 19, 2009 at 4:06 PM, Anders Nygren wrote: >> > Hi >> > I am having a problem with chunked messages. When I try to send a >> > message that is ~2kByte, it gets split into two chunks. But gen_sctp >> > does not reassemble the chunks and only delivers the last chunk to >> > my application. >> > I have attached a simple test case to demonstrate the problem. >> > >> > To run >> > Machine A: >> > sctp_err:server(IP,Port). >> > >> > Machine B: >> > sctp_err:client(IP,Port). >> > >> > I dont know if this is related but sometimes I also receive a >> > {sctp_error, enoent} before the the #sctp_sndrcvinfo with the second >> > chunk. >> > >> > This is using >> > OTP R13B01 >> > Between two machines running Ubuntu >> > >> > uname -a >> > Linux curso-laptop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 >> > 00:28:35 UTC 2009 i686 GNU/Linux >> > >> > ?uname -a >> > Linux glr-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 >> > UTC 2009 i686 GNU/Linux >> > >> > /Anders >> > >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > From uclamathguy@REDACTED Fri Sep 18 19:00:48 2009 From: uclamathguy@REDACTED (Ryan Rosario) Date: Fri, 18 Sep 2009 10:00:48 -0700 Subject: wx fails to build on Snow Leopard Message-ID: <72fc09510909181000y18bb583cpdf52b0468cf49f30@mail.gmail.com> I was able to get wxWidgets 9.0 to compile and install in 64bit mode for Snow Leopard, but WX does not seem to be the problem. The problem seems to be in OTP/Erlang with files in ./lib/wx/c_src/gen/ directory, including wxe_derived_dest.h. Can a --without-wx or --disable-wx flag be added to configure to essentially prevent compilation of those files? I can build Erlang after I remove wx from lib/Makefile as the previous poster mentioned. From mjtruog@REDACTED Sat Sep 19 06:46:21 2009 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 18 Sep 2009 21:46:21 -0700 Subject: epmd port alternative specifications Message-ID: <4AB4621D.90005@gmail.com> Others may be aware of this. However, it does seem inconsistent and not very obvious, like a bug or a problem that emerged after separate development stages. Specifying a different port for epmd is a complex task, especially if it is fed to a module like slave. I am finding myself using a script like the one attached below. Basically, the epmd port needs to be specified in 3 separate ways for things to work properly. The environmental variable ERL_EPMD_PORT must be specified before erl is called to be effective. If ERL_EPMD_PORT needs to be retrieved from os:getenv/1 it needs to be in a separate -env argument to erl (not sure why). net_kernel:start/1 depends on a different argument method because it uses the -epmd_port erl argument. Perhaps this is by design, but it would be more straightforward if net_kernel took the environmental variable instead of the different command line argument (however, this could be due to the second problem). script: #!/bin/bash ERL_EPMD_PORT=$1 # os:getenv/1 requires the -env parameter # net_kernel:start/1 requires the -epmd_port exec ${*:2} -env ERL_EPMD_PORT $ERL_EPMD_PORT -epmd_port $ERL_EPMD_PORT Sorry if this has already been reported. Thanks, Michael From colm.dougan@REDACTED Sat Sep 19 22:51:34 2009 From: colm.dougan@REDACTED (Colm Dougan) Date: Sat, 19 Sep 2009 21:51:34 +0100 Subject: Potential bug in {packet, http} Message-ID: <24d4f39c0909191351w6a705b36hb8525f09d96d50dd@mail.gmail.com> HI, When I used erlang:decode_packet to parse a HTTP request with an absolute URI I get the expected outcome : 1> erlang:decode_packet(http, <<"GET http://www.foo.com/bar HTTP/1.0\r\n">>, []). {ok,{http_request,'GET', {absoluteURI,http,"www.foo.com",undefined,"/bar"}, {1,0}}, <<>>} However, when I use {packet, http} for the same thing the outcome is not what I expect : 1> my_httpd:start(). Listening on port: 8082 ok 2> my_httpd:do_client(<<"GET http://www.foo.com/bar HTTP/1.0\r\n">>). Connecting to localhost:8082 ... Connected ok Method: 'GET', Uri: {absoluteURI,http,"www.foo.com",undefined,"/bar HTTP/1"}, Version: {1, 0} The code of my_httpd is below. Is this a bug or am I missing something? Thanks, Colm -module(my_httpd). -export([ start/0, do_client/0, do_client/1 ]). -define(LPORT, 8082). -define(LOPTS, [binary, {packet, 0}, {active, false}, {packet, http}] ). start() -> spawn(fun init_server/0), ok. do_client() -> do_client(<<"GET http://www.foo.com/bar HTTP/1.0\r\n">>). do_client(Bin) -> io:format("Connecting to localhost:~p ...~n", [?LPORT]), {ok, CSock} = gen_tcp:connect("localhost", ?LPORT, [binary]), io:format("Connected~n"), ok = gen_tcp:send(CSock, Bin), gen_tcp:close(CSock), ok. init_server() -> io:format("Listening on port: ~p~n", [?LPORT]), {ok, LSock} = gen_tcp:listen(?LPORT, ?LOPTS), server_loop(LSock). server_loop(LSock) -> {ok, Sock} = gen_tcp:accept(LSock), catch(handle_client(Sock)), catch(gen_tcp:close(Sock)), server_loop(LSock). handle_client(Sock) -> case gen_tcp:recv(Sock, 0) of {ok, {http_request, Method, Uri, Version}} -> io:format("Method: ~p, Uri: ~p, Version: ~p~n", [Method, Uri, Version]); {ok, Other} -> io:format("Unexpected: ~p~n", [Other]); {error, closed} -> io:format("Closed~n") end. From vinoski@REDACTED Sat Sep 19 23:13:00 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 19 Sep 2009 17:13:00 -0400 Subject: [erlang-bugs] Potential bug in {packet, http} In-Reply-To: <24d4f39c0909191351w6a705b36hb8525f09d96d50dd@mail.gmail.com> References: <24d4f39c0909191351w6a705b36hb8525f09d96d50dd@mail.gmail.com> Message-ID: <65b2728e0909191413k365064cax76252ec2df68d988@mail.gmail.com> On Sat, Sep 19, 2009 at 4:51 PM, Colm Dougan wrote: > HI, > > When I used erlang:decode_packet to parse a HTTP request with an > absolute URI I get the expected outcome : > > 1> erlang:decode_packet(http, <<"GET http://www.foo.com/bar > HTTP/1.0\r\n">>, []). > {ok,{http_request,'GET', > {absoluteURI,http,"www.foo.com",undefined,"/bar"}, > {1,0}}, > <<>>} > > However, when I use {packet, http} for the same thing the outcome is > not what I expect : > > 1> my_httpd:start(). > Listening on port: 8082 > ok > 2> my_httpd:do_client(<<"GET http://www.foo.com/bar HTTP/1.0\r\n">>). > Connecting to localhost:8082 ... > Connected > ok > Method: 'GET', Uri: {absoluteURI,http,"www.foo.com",undefined,"/bar > HTTP/1"}, Version: {1, 0} > > The code of my_httpd is below. Is this a bug or am I missing something? > What version of Erlang are you using? I tried your code on R13B01 and it was just fine, but I see the same error you got when I use R12B-5. --steve From colm.dougan@REDACTED Sun Sep 20 00:14:06 2009 From: colm.dougan@REDACTED (Colm Dougan) Date: Sat, 19 Sep 2009 23:14:06 +0100 Subject: [erlang-bugs] Potential bug in {packet, http} In-Reply-To: <65b2728e0909191413k365064cax76252ec2df68d988@mail.gmail.com> References: <24d4f39c0909191351w6a705b36hb8525f09d96d50dd@mail.gmail.com> <65b2728e0909191413k365064cax76252ec2df68d988@mail.gmail.com> Message-ID: <24d4f39c0909191514i1f53d644ode745c9845534565@mail.gmail.com> On Sat, Sep 19, 2009 at 10:13 PM, Steve Vinoski wrote: > > > On Sat, Sep 19, 2009 at 4:51 PM, Colm Dougan wrote: >> >> HI, >> >> When I used erlang:decode_packet to parse a HTTP request with an >> absolute URI I get the expected outcome : >> >> 1> erlang:decode_packet(http, <<"GET http://www.foo.com/bar >> HTTP/1.0\r\n">>, []). >> {ok,{http_request,'GET', >> ? ? ? ? ? ? ? ? ?{absoluteURI,http,"www.foo.com",undefined,"/bar"}, >> ? ? ? ? ? ? ? ? ?{1,0}}, >> ? ?<<>>} >> >> However, when I use {packet, http} for the same thing the outcome is >> not what I expect : >> >> 1> my_httpd:start(). >> Listening on port: 8082 >> ok >> 2> my_httpd:do_client(<<"GET http://www.foo.com/bar HTTP/1.0\r\n">>). >> Connecting to localhost:8082 ... >> Connected >> ok >> Method: 'GET', Uri: {absoluteURI,http,"www.foo.com",undefined,"/bar >> HTTP/1"}, Version: {1, 0} >> >> The code of my_httpd is below. ?Is this a bug or am I missing something? > > What version of Erlang are you using? I tried your code on R13B01 and it was > just fine, but I see the same error you got when I use R12B-5. Yeah I'm using 12B-5. Before I posted I checked the 13B01 changes file for anything that sounded like this but my search came up empty However, now I've checked the 13A changes file I see this : OTP-7682 A bug fixed for TCP sockets with option {packet,http}. An HTTP request with an absolute URI was returned with a corrupt path string. This bug did only exist in R12B-4 and R12B-5. My bad (although IMO it would be nice if bugs fixed in a beta release are mentioned in the next official release changes file). Colm From i.am@REDACTED Mon Sep 21 00:33:06 2009 From: i.am@REDACTED (Alex Suraci) Date: Sun, 20 Sep 2009 18:33:06 -0400 Subject: Bug in c:nc, R13B01 Message-ID: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/ On line 7, Fname is naively assumed to be a .beam file compiled to the same directory where the source .erl file resided. However, this is often false, for example when there is an `outdir' option, or when calling `nc()' from the shell with a path to a file like "foo/bar" (in which case compile:file just plops it in the cwd of the shell). For example. when you call `make:all([netload])' and your Emakefile specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine, but the modules won't update and you'll have no idea why (until you dig a little deeper). So, really, the only way for this function to work properly is when compiling with the shell's cwd being the same directory as the .erl file. -- Alex From christophe.romain@REDACTED Mon Sep 21 14:58:47 2009 From: christophe.romain@REDACTED (Christophe Romain) Date: Mon, 21 Sep 2009 14:58:47 +0200 Subject: pg2 man link issue Message-ID: <20090921125847.GN4155@localhost> go to http://erlang.org/doc/man/pg2.html at bottom page, there are links for kernel and pg pg points to http://erlang.org/doc/man/filename.html instead of http://erlang.org/doc/man/pg.html From roberto.aloi@REDACTED Mon Sep 21 18:55:03 2009 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Mon, 21 Sep 2009 17:55:03 +0100 (BST) Subject: Missing commas in .app file Message-ID: <2339443.152031253552103731.JavaMail.root@zimbra> Hi all, Warning: Line 54 in /usr/local/lib/erlang/lib/common_test-1.4.2/ebin/common_test.app: syntax error before: '{' Warning: Line 34 in /usr/local/lib/erlang/lib/test_server-3.3.2/ebin/test_server.app: syntax error before: '{' It definitely looks like two commas are missing at the end of those lines. Best regards, Roberto Aloi roberto.aloi@REDACTED http://www.erlang-consulting.com From peppe@REDACTED Tue Sep 22 09:57:46 2009 From: peppe@REDACTED (Peter Andersson) Date: Tue, 22 Sep 2009 09:57:46 +0200 Subject: [erlang-bugs] Missing commas in .app file In-Reply-To: <2339443.152031253552103731.JavaMail.root@zimbra> References: <2339443.152031253552103731.JavaMail.root@zimbra> Message-ID: <4AB8837A.50705@erix.ericsson.se> Hi Roberto, We discovered this immediately after the R13B01 release (quite embarrasing) and it's of course been fixed for the upcoming R13B02. Sorry about this and thanks for reporting! Peter Ericsson AB, Erlang/OTP Roberto Aloi wrote: > Hi all, > > Warning: Line 54 in /usr/local/lib/erlang/lib/common_test-1.4.2/ebin/common_test.app: syntax error before: '{' > Warning: Line 34 in /usr/local/lib/erlang/lib/test_server-3.3.2/ebin/test_server.app: syntax error before: '{' > > It definitely looks like two commas are missing at the end of those lines. > > Best regards, > > Roberto Aloi > roberto.aloi@REDACTED > http://www.erlang-consulting.com > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From hans.bolinder@REDACTED Tue Sep 22 12:50:40 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 22 Sep 2009 12:50:40 +0200 Subject: [erlang-bugs] pg2 man link issue In-Reply-To: <20090921125847.GN4155@localhost> References: <20090921125847.GN4155@localhost> Message-ID: <19128.44032.480959.683096@ornendil.du.uab.ericsson.se> [Christophe Romain:] > go to http://erlang.org/doc/man/pg2.html > at bottom page, there are links for kernel and pg > pg points to http://erlang.org/doc/man/filename.html > instead of http://erlang.org/doc/man/pg.html Thanks. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From hans.bolinder@REDACTED Wed Sep 23 08:24:10 2009 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 23 Sep 2009 08:24:10 +0200 Subject: [erlang-bugs] pg2 man link issue In-Reply-To: <20090921125847.GN4155@localhost> References: <20090921125847.GN4155@localhost> Message-ID: <19129.48906.744679.405264@ornendil.du.uab.ericsson.se> [Christophe Romain:] > go to http://erlang.org/doc/man/pg2.html > at bottom page, there are links for kernel and pg > pg points to http://erlang.org/doc/man/filename.html > instead of http://erlang.org/doc/man/pg.html Thanks. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From mazen.harake@REDACTED Sun Sep 27 11:41:34 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Sun, 27 Sep 2009 11:41:34 +0200 Subject: wxNotebook and wx_object Message-ID: <4ABF334E.1070602@erlang-consulting.com> Hi, Before I post a patch to erlang-patches I was just wondering if it these two things are intended behaviour: 1) If I add a Panel to Notebook (as a page) and then destroy the Panel, I can then ask for the panel on the same index (wxNotebook:getPage/2) and get a different panel. further more, if I have added a panel and then ask for an index outside of the number of panels I get a new Panel which I never created. Also, why does the page index start at 0 when everything else in Erlang is 1 based (pretty much). E.g: Nb = wxNotebook:new(Parent, ?wxID_ANY, []), Panel = wxPanel:new(), wxNotebook:addPage(Nb, Panel, "Whatever", []), %% this is the first page added P1 = wxNotebook:getPage(Nb, 0), %% this gives the first page added (Panel), PUnknown = wxNotebook:getPage(Nb, 1), %% this gives a new page... why? shouldn't it crash or something? wxPanel:destroy(Panel), %% delete the panel P2 = wxNotebook:getPage(Nb, 0), %% P1 /= P2 /= PUnknown Is this intended behaviour? I don't have a patch for this because I don't know what is expected 2) firstly, when calling wx_object:start_link/X and returning {stop, whatever} it exits the process. Why? second, it patternmatches the return value (from the ack) to {ok, Pid}, again: Why? This causes the return value to exit with badmatch, I'm sure that is not intended? Or is it? /Mazen From dangud@REDACTED Sun Sep 27 12:08:37 2009 From: dangud@REDACTED (Dan Gudmundsson) Date: Sun, 27 Sep 2009 12:08:37 +0200 Subject: [erlang-bugs] wxNotebook and wx_object In-Reply-To: <4ABF334E.1070602@erlang-consulting.com> References: <4ABF334E.1070602@erlang-consulting.com> Message-ID: <93df43b60909270308lf083025seb06eef6661862cc@mail.gmail.com> Hi wx(Erlang) is just an erlang port of wxWidgets, it marshals the arguments and make the corresponding C++ calls and so it behaves exactly the same as the original wxWidgets. Thus since wxWidgets is coded in C++ everything in wx starts from 0 and not 1. I can't answer the first question since it's not a feature of wxErlang you have to send those kind of questions to wxWidgets list, I'm no expert of the implementation of wxWidgets. Also I don't think you can depend on that behavior (unless it's documented) for all platforms. Question 2, is should mimic the gen_server behavior, I'll have a look how it's handled there. /Dan On Sun, Sep 27, 2009 at 11:41 AM, Mazen Harake wrote: > Hi, > > Before I post a patch to erlang-patches I was just wondering if it these two > things are intended behaviour: > > 1) If I add ?a Panel to Notebook (as a page) and then destroy the Panel, I > can then ask for the panel on the same index (wxNotebook:getPage/2) and get > a different panel. further more, if I have added a panel and then ask for an > index outside of the number of panels I get a new Panel which I never > created. Also, why does the page index start at 0 when everything else in > Erlang is 1 based (pretty much). > > E.g: > Nb = wxNotebook:new(Parent, ?wxID_ANY, []), > Panel = wxPanel:new(), > wxNotebook:addPage(Nb, Panel, "Whatever", []), %% this is the first page > added > P1 = wxNotebook:getPage(Nb, 0), %% this gives the first page added (Panel), > PUnknown = wxNotebook:getPage(Nb, 1), %% this gives a new page... why? > shouldn't it crash or something? > wxPanel:destroy(Panel), %% delete the panel > P2 = wxNotebook:getPage(Nb, 0), > %% P1 /= P2 /= PUnknown > > Is this intended behaviour? I don't have a patch for this because I don't > know what is expected > > 2) firstly, when calling wx_object:start_link/X and returning {stop, > whatever} it exits the process. Why? > second, it patternmatches the return value (from the ack) to {ok, Pid}, > again: Why? This causes the return value to exit with badmatch, I'm sure > that is not intended? Or is it? > > /Mazen > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > > From mazen.harake@REDACTED Sun Sep 27 12:35:38 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Sun, 27 Sep 2009 12:35:38 +0200 Subject: [erlang-bugs] wxNotebook and wx_object In-Reply-To: <93df43b60909270308lf083025seb06eef6661862cc@mail.gmail.com> References: <4ABF334E.1070602@erlang-consulting.com> <93df43b60909270308lf083025seb06eef6661862cc@mail.gmail.com> Message-ID: <4ABF3FFA.1070208@erlang-consulting.com> Hi, Thanks for the reply, I agree that one shouldn't depend on that behaviour, that is why I don't, but now at least I know it is not an erlang "bug" per se. /Mazen Dan Gudmundsson wrote: > Hi > > wx(Erlang) is just an erlang port of wxWidgets, it marshals the arguments and > make the corresponding C++ calls and so it behaves exactly the same as the > original wxWidgets. > > Thus since wxWidgets is coded in C++ everything in wx starts from 0 and not 1. > > I can't answer the first question since it's not a feature of wxErlang > you have to > send those kind of questions to wxWidgets list, I'm no expert of the > implementation > of wxWidgets. > > Also I don't think you can depend on that behavior (unless it's > documented) for all > platforms. > > Question 2, is should mimic the gen_server behavior, I'll have a look > how it's handled > there. > > /Dan > > On Sun, Sep 27, 2009 at 11:41 AM, Mazen Harake > wrote: > >> Hi, >> >> Before I post a patch to erlang-patches I was just wondering if it these two >> things are intended behaviour: >> >> 1) If I add a Panel to Notebook (as a page) and then destroy the Panel, I >> can then ask for the panel on the same index (wxNotebook:getPage/2) and get >> a different panel. further more, if I have added a panel and then ask for an >> index outside of the number of panels I get a new Panel which I never >> created. Also, why does the page index start at 0 when everything else in >> Erlang is 1 based (pretty much). >> >> E.g: >> Nb = wxNotebook:new(Parent, ?wxID_ANY, []), >> Panel = wxPanel:new(), >> wxNotebook:addPage(Nb, Panel, "Whatever", []), %% this is the first page >> added >> P1 = wxNotebook:getPage(Nb, 0), %% this gives the first page added (Panel), >> PUnknown = wxNotebook:getPage(Nb, 1), %% this gives a new page... why? >> shouldn't it crash or something? >> wxPanel:destroy(Panel), %% delete the panel >> P2 = wxNotebook:getPage(Nb, 0), >> %% P1 /= P2 /= PUnknown >> >> Is this intended behaviour? I don't have a patch for this because I don't >> know what is expected >> >> 2) firstly, when calling wx_object:start_link/X and returning {stop, >> whatever} it exits the process. Why? >> second, it patternmatches the return value (from the ack) to {ok, Pid}, >> again: Why? This causes the return value to exit with badmatch, I'm sure >> that is not intended? Or is it? >> >> /Mazen >> >> ________________________________________________________________ >> erlang-bugs mailing list. See http://www.erlang.org/faq.html >> erlang-bugs (at) erlang.org >> >> >> From mazen.harake@REDACTED Tue Sep 29 10:46:07 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Tue, 29 Sep 2009 10:46:07 +0200 Subject: [erlang-bugs] wxNotebook and wx_object In-Reply-To: <4ABF3FFA.1070208@erlang-consulting.com> References: <4ABF334E.1070602@erlang-consulting.com> <93df43b60909270308lf083025seb06eef6661862cc@mail.gmail.com> <4ABF3FFA.1070208@erlang-consulting.com> Message-ID: <4AC1C94F.1080907@erlang-consulting.com> Any news on this? Is the pattern match going to be removed? I had a look at gen_server, and that doesn't have a pattern match. Just wanted to know because otherwise I will have to work around it because currently I'm working with a hacked wx_object :) Cheers, /Mazen Mazen Harake wrote: > Hi, > > Thanks for the reply, I agree that one shouldn't depend on that > behaviour, that is why I don't, but now at least I know it is not an > erlang "bug" per se. > > /Mazen > > > Dan Gudmundsson wrote: >> Hi >> >> wx(Erlang) is just an erlang port of wxWidgets, it marshals the >> arguments and >> make the corresponding C++ calls and so it behaves exactly the same >> as the >> original wxWidgets. >> >> Thus since wxWidgets is coded in C++ everything in wx starts from 0 >> and not 1. >> >> I can't answer the first question since it's not a feature of wxErlang >> you have to >> send those kind of questions to wxWidgets list, I'm no expert of the >> implementation >> of wxWidgets. >> >> Also I don't think you can depend on that behavior (unless it's >> documented) for all >> platforms. >> >> Question 2, is should mimic the gen_server behavior, I'll have a look >> how it's handled >> there. >> >> /Dan >> >> On Sun, Sep 27, 2009 at 11:41 AM, Mazen Harake >> wrote: >> >>> Hi, >>> >>> Before I post a patch to erlang-patches I was just wondering if it >>> these two >>> things are intended behaviour: >>> >>> 1) If I add a Panel to Notebook (as a page) and then destroy the >>> Panel, I >>> can then ask for the panel on the same index (wxNotebook:getPage/2) >>> and get >>> a different panel. further more, if I have added a panel and then >>> ask for an >>> index outside of the number of panels I get a new Panel which I never >>> created. Also, why does the page index start at 0 when everything >>> else in >>> Erlang is 1 based (pretty much). >>> >>> E.g: >>> Nb = wxNotebook:new(Parent, ?wxID_ANY, []), >>> Panel = wxPanel:new(), >>> wxNotebook:addPage(Nb, Panel, "Whatever", []), %% this is the first >>> page >>> added >>> P1 = wxNotebook:getPage(Nb, 0), %% this gives the first page added >>> (Panel), >>> PUnknown = wxNotebook:getPage(Nb, 1), %% this gives a new page... why? >>> shouldn't it crash or something? >>> wxPanel:destroy(Panel), %% delete the panel >>> P2 = wxNotebook:getPage(Nb, 0), >>> %% P1 /= P2 /= PUnknown >>> >>> Is this intended behaviour? I don't have a patch for this because I >>> don't >>> know what is expected >>> >>> 2) firstly, when calling wx_object:start_link/X and returning {stop, >>> whatever} it exits the process. Why? >>> second, it patternmatches the return value (from the ack) to {ok, Pid}, >>> again: Why? This causes the return value to exit with badmatch, I'm >>> sure >>> that is not intended? Or is it? >>> >>> /Mazen >>> >>> ________________________________________________________________ >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html >>> erlang-bugs (at) erlang.org >>> >>> >>> > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From r.m.graham@REDACTED Wed Sep 30 05:32:07 2009 From: r.m.graham@REDACTED (Ryan M. Graham) Date: Tue, 29 Sep 2009 20:32:07 -0700 Subject: 64-bit compile fails on Snow Leopard Message-ID: ./configure fails when using --enable-darwin-64bit on Snow Leopard when running a 64-bit kernel. The configure scripts check the output of uname for Darwin-i386 as a sanity check but does not accept Darwin-x86_64. For reference, Snow Leopard can be booted into a 64-bit kernel by holding down the '6' and '4' keys during boot up. ~Ryan From i.am@REDACTED Wed Sep 30 06:10:39 2009 From: i.am@REDACTED (Alex Suraci) Date: Wed, 30 Sep 2009 00:10:39 -0400 Subject: Bug in c:nc, R13B01 In-Reply-To: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> References: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> Message-ID: <1a3a73650909292110j63153b61i96173500a3cc7a42@mail.gmail.com> Potential fix?: http://paste.pocoo.org/show/142193/ I'll submit a patch but I'd prefer having some input as this is kind of a low-level part of Erlang (being in the stdlib and all). Description of changes: if an outdir is specified, Fname should be prefixed with that, otherwise it should be the cwd, as that's where compile:file will put the .beam file. - Alex On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci wrote: > Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/ > > On line 7, Fname is naively assumed to be a .beam file compiled > to the same directory where the source .erl file resided. However, this > is often false, for example when there is an `outdir' option, or when > calling `nc()' from the shell with a path to a file like "foo/bar" (in which > case compile:file just plops it in the cwd of the shell). > > For example. when you call `make:all([netload])' and your Emakefile > specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine, > but the modules won't update and you'll have no idea why (until you > dig a little deeper). > > So, really, the only way for this function to work properly is when > compiling with the shell's cwd being the same directory as the .erl file. > > -- > Alex > -- Alex From mazen.harake@REDACTED Wed Sep 30 08:43:03 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 30 Sep 2009 08:43:03 +0200 Subject: [erlang-bugs] Re: Bug in c:nc, R13B01 In-Reply-To: <1a3a73650909292110j63153b61i96173500a3cc7a42@mail.gmail.com> References: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> <1a3a73650909292110j63153b61i96173500a3cc7a42@mail.gmail.com> Message-ID: <4AC2FDF7.8010702@erlang-consulting.com> I would suggest to replace {ok, Cwd} = file:get_cwd(), Dir = case lists:keyfind(outdir, 1, Opts) of {outdir, Out} -> Out; false -> Cwd end, with: Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())), ... Easier to read imho. /Mazen Alex Suraci wrote: > Potential fix?: http://paste.pocoo.org/show/142193/ > > I'll submit a patch but I'd prefer having some input as this is kind of > a low-level part of Erlang (being in the stdlib and all). > > Description of changes: if an outdir is specified, Fname should be prefixed > with that, otherwise it should be the cwd, as that's where compile:file will > put the .beam file. > > - Alex > > On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci wrote: > >> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/ >> >> On line 7, Fname is naively assumed to be a .beam file compiled >> to the same directory where the source .erl file resided. However, this >> is often false, for example when there is an `outdir' option, or when >> calling `nc()' from the shell with a path to a file like "foo/bar" (in which >> case compile:file just plops it in the cwd of the shell). >> >> For example. when you call `make:all([netload])' and your Emakefile >> specifies `ebin' as your outdir, it will call `c:nc' and it'll compile fine, >> but the modules won't update and you'll have no idea why (until you >> dig a little deeper). >> >> So, really, the only way for this function to work properly is when >> compiling with the shell's cwd being the same directory as the .erl file. >> >> -- >> Alex >> >> > > > > From mazen.harake@REDACTED Wed Sep 30 08:45:13 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 30 Sep 2009 08:45:13 +0200 Subject: [erlang-bugs] Re: Bug in c:nc, R13B01 In-Reply-To: <4AC2FDF7.8010702@erlang-consulting.com> References: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> <1a3a73650909292110j63153b61i96173500a3cc7a42@mail.gmail.com> <4AC2FDF7.8010702@erlang-consulting.com> Message-ID: <4AC2FE79.5040102@erlang-consulting.com> EErrr... element(2, ...) I meant :D /Mazen Mazen Harake wrote: > I would suggest to replace > > {ok, Cwd} = file:get_cwd(), > Dir = case lists:keyfind(outdir, 1, Opts) of > {outdir, Out} -> Out; > false -> Cwd > end, > > with: > > Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())), > ... > > Easier to read imho. > > /Mazen > > > Alex Suraci wrote: >> Potential fix?: http://paste.pocoo.org/show/142193/ >> >> I'll submit a patch but I'd prefer having some input as this is kind of >> a low-level part of Erlang (being in the stdlib and all). >> >> Description of changes: if an outdir is specified, Fname should be >> prefixed >> with that, otherwise it should be the cwd, as that's where >> compile:file will >> put the .beam file. >> >> - Alex >> >> On Sun, Sep 20, 2009 at 6:33 PM, Alex Suraci >> wrote: >> >>> Excerpt from lib/stdlib/src/c.erl: http://paste.pocoo.org/show/140752/ >>> >>> On line 7, Fname is naively assumed to be a .beam file compiled >>> to the same directory where the source .erl file resided. However, this >>> is often false, for example when there is an `outdir' option, or when >>> calling `nc()' from the shell with a path to a file like "foo/bar" >>> (in which >>> case compile:file just plops it in the cwd of the shell). >>> >>> For example. when you call `make:all([netload])' and your Emakefile >>> specifies `ebin' as your outdir, it will call `c:nc' and it'll >>> compile fine, >>> but the modules won't update and you'll have no idea why (until you >>> dig a little deeper). >>> >>> So, really, the only way for this function to work properly is when >>> compiling with the shell's cwd being the same directory as the .erl >>> file. >>> >>> -- >>> Alex >>> >>> >> >> >> >> > > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From ulf.wiger@REDACTED Wed Sep 30 09:58:23 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 30 Sep 2009 09:58:23 +0200 Subject: [erlang-bugs] Re: Bug in c:nc, R13B01 In-Reply-To: <4AC2FE79.5040102@erlang-consulting.com> References: <1a3a73650909201533n358fa6fdv624b6eeeb4c1c909@mail.gmail.com> <1a3a73650909292110j63153b61i96173500a3cc7a42@mail.gmail.com> <4AC2FDF7.8010702@erlang-consulting.com> <4AC2FE79.5040102@erlang-consulting.com> Message-ID: <4AC30F9F.7000808@erlang-consulting.com> Mazen Harake wrote: > EErrr... element(2, ...) I meant :D > > /Mazen ...and I was just about to suggest that {ok, Cwd} = file:get_cwd(), Dir = proplists:get_value(outdir, Opts, Cwd), would be even more readable. ;-) This would also cover the case where get_cwd() returns {error,Reason} (which can happen "in rare circumstances" on Unix, according to the manual) - it covers it in the sense that it fails in an understandable way, rather than setting Dir to something unusable (a POSIX error such as 'eacces'), which would trigger a failure somewhere else. "Make things as simple as possible, but not simpler." (A Einstein) BR, Ulf W > > Mazen Harake wrote: >> I would suggest to replace >> >> {ok, Cwd} = file:get_cwd(), >> Dir = case lists:keyfind(outdir, 1, Opts) of >> {outdir, Out} -> Out; >> false -> Cwd >> end, >> >> with: >> >> Dir = proplists:get_value(outdir, Opts, element(1, file:get_cwd())), >> ... >> >> Easier to read imho. >> >> /Mazen -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From dimavs@REDACTED Wed Sep 30 10:37:37 2009 From: dimavs@REDACTED (Dmitri Sosnik) Date: Wed, 30 Sep 2009 18:37:37 +1000 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: References: Message-ID: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> 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 Cheers, D PS My old 13B01 x64 build from Leopard works fine with 64bit kernel of Snow Leopard. On 30/09/2009, at 1:32 PM, Ryan M. Graham wrote: > ./configure fails when using --enable-darwin-64bit on Snow Leopard > when running a 64-bit kernel. > > The configure scripts check the output of uname for Darwin-i386 as a > sanity check but does not accept Darwin-x86_64. > > For reference, Snow Leopard can be booted into a 64-bit kernel by > holding down the '6' and '4' keys during boot up. > > ~Ryan > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From kostis@REDACTED Wed Sep 30 10:41:02 2009 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 30 Sep 2009 11:41:02 +0300 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> Message-ID: <4AC3199E.8020804@cs.ntua.gr> 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 From dimavs@REDACTED Wed Sep 30 11:04:43 2009 From: dimavs@REDACTED (Dmitri Sosnik) Date: Wed, 30 Sep 2009 19:04:43 +1000 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <4AC3199E.8020804@cs.ntua.gr> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> Message-ID: <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> 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 > From r.m.graham@REDACTED Wed Sep 30 22:01:18 2009 From: r.m.graham@REDACTED (Ryan Graham) Date: Wed, 30 Sep 2009 13:01:18 -0700 Subject: [erlang-bugs] 64-bit compile fails on Snow Leopard In-Reply-To: <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> References: <12457ED9-4BA0-49FF-B91E-7E0BB7D89521@gmail.com> <4AC3199E.8020804@cs.ntua.gr> <27CDEC93-F671-4989-A647-7997F7971B62@gmail.com> Message-ID: <93e244cc0909301301x4171cc3bt91d7835248df9872@mail.gmail.com> 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