From bgustavsson@REDACTED Fri Oct 1 15:09:02 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 1 Oct 2010 15:09:02 +0200 Subject: [erlang-bugs] hibernate/3 and HiPE In-Reply-To: <11B31815-6B3D-44C4-819B-7E9764406984@kallisys.net> References: <509D06B0-008C-4AFE-B356-0FBBBDA71086@kallisys.net> <94679BA9-92D1-4A8E-938D-E401C918C570@kallisys.net> <19617.60761.599137.961032@pilspetsen.it.uu.se> <6C940E94-C9AD-4441-84DE-B34201F6A791@kallisys.net> <19619.9805.31482.502922@pilspetsen.it.uu.se> <11B31815-6B3D-44C4-819B-7E9764406984@kallisys.net> Message-ID: On Thu, Sep 30, 2010 at 10:28 AM, Paul Guyot wrote: > Hello, > > The following branch contains fixes for hibernate/3 and HiPE: > http://github.com/pguyot/otp/commits/fix-hibernate-with-hipe > git fetch git://github.com/pguyot/otp.git fix-hibernate-with-hipe > Thanks! pu updated. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From michael.santos@REDACTED Sat Oct 2 00:07:46 2010 From: michael.santos@REDACTED (Michael Santos) Date: Fri, 1 Oct 2010 18:07:46 -0400 Subject: cerl hanging on gdb prompt Message-ID: <20101001220746.GA30223@ecn.lan> At least for me, running cerl on Ubuntu 10.04 hangs at the gdb prompt. I've tried 2 versions of emacs with gdb: GNU Emacs 23.1.1 GNU Emacs 22.2.1 GNU gdb (GDB) 7.1-ubuntu cerl works fine on Mac OS X. The following changes fix it for me (and didn't cause any problems on Mac OS X), but I only use emacs with cerl, so I don't know if these changes are correct. diff --git a/erts/etc/unix/cerl.src b/erts/etc/unix/cerl.src index 9dab9fc..de34ffc 100644 --- a/erts/etc/unix/cerl.src +++ b/erts/etc/unix/cerl.src @@ -66,4 +66,5 @@ core= GDB= +GDBARGS= GDBBP= TYPE= @@ -278,7 +279,13 @@ else esac + gdbcmd="$gdbcmd $GDBBP \ + (insert-string \"source $ROOTDIR/erts/etc/unix/etp-commands\") \ + (comint-send-input)" + # Set annotation level for gdb in emacs 22 and higher. emacs_major=`$EMACS --version | head -1 | sed 's,^[^0-9]*\([0-9]*\).*,\1,g'` - if [ '!' -z "$emacs_major" -a $emacs_major -gt 21 ]; then + if [ '!' -z "$emacs_major" -a $emacs_major -gt 22 ]; then + GDBARGS="--annotate=3" + elif [ '!' -z "$emacs_major" -a $emacs_major -gt 21 ]; then # Hack - wait for etp-commands to be loaded and then set # annotation level, could be done more beautifully than with sit-for... @@ -288,8 +295,5 @@ else (comint-send-input)" fi - gdbcmd="$gdbcmd $GDBBP \ - (insert-string \"source $ROOTDIR/erts/etc/unix/etp-commands\") \ - (comint-send-input)" # Fire up gdb in emacs... - exec $EMACS --eval "(progn (gdb \"gdb $EMU\") $gdbcmd)" + exec $EMACS --eval "(progn (gdb \"gdb $GDBARGS $EMU\") $gdbcmd)" fi From john.hughes@REDACTED Mon Oct 4 18:34:27 2010 From: john.hughes@REDACTED (John Hughes) Date: Mon, 4 Oct 2010 18:34:27 +0200 Subject: Race condition in dets causes "bad_object" error In-Reply-To: <19616.50594.922960.87700@pilspetsen.it.uu.se> References: <557798F9-D84C-4BAD-A54B-298465058762@kallisys.net> <19616.50594.922960.87700@pilspetsen.it.uu.se> Message-ID: <7EF6CB5CBAB64D88A31D65FDF9E2B01E@JohnsTablet2009> QuickCheck appears to have turned up the infamous "bad_object" bug in dets, by testing for race conditions. This one can be reproduced using the attached code as follows: Erlang R14B (erts-5.8.1) [smp:2:2] [rq:2] [async-threads:0] Eshell V5.8.1 (abort with ^G) 1> dets_eqc:bug_bad_object(). Failed! Reason: {'EXIT',{badarg,[{erlang,length, [{error,{{bad_object,read_buckets},"dets_table"}}]}, {dets_eqc,corrupted,2}, ...lots of output... Prefix: open_file(dets_table,[{type,set}]) --> dets_table insert(dets_table,[{1,0}]) --> ok Parallel: 1. lookup(dets_table,0) --> [] delete(dets_table,1) --> ok 2. open_file(dets_table,[{type,set}]) --> dets_table Result: ok false What's happening is that we first do the prefix above, then the two parallel branches (which appear to work, in that the calls return the correct results). Finally we reopen the table and call match_object(...,'_'), which returns the bad_object error. This isn't the SAME bug as the one I reported a week ago that causes a "premature_eof" error--as well as the R14B version of dets, I've tested a fixed version that Hans Bolinder sent me in which the "premature eof" bug has been fixed--so there is something else wrong. John -------------- next part -------------- A non-text attachment was scrubbed... Name: dets_eqc.erl Type: application/octet-stream Size: 9239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pretty.erl Type: application/octet-stream Size: 759 bytes Desc: not available URL: From kostis@REDACTED Tue Oct 5 22:51:17 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 05 Oct 2010 23:51:17 +0300 Subject: Confusing error message from erlc Message-ID: <4CAB8FC5.5070705@cs.ntua.gr> This is a bit silly, but I discovered that if one forgets the list in an export declaration, the warning message that she gets presented is a bit confusing. For example: ================================ -module(bar). -export(test/0). test() -> 42. ================================ % erlc bar.erl ./bar.erl:2: bad function arity ./bar.erl:4: Warning: function test/0 is unused Not a big deal, but somebody may want to fix that. Kostis From Jim.Engquist@REDACTED Sat Oct 9 03:03:36 2010 From: Jim.Engquist@REDACTED (Engquist, Jim) Date: Fri, 8 Oct 2010 21:03:36 -0400 Subject: compiler bug in r14B Message-ID: <8B3F57999F89864D9334A94C15E1ABFE02569191@USILMS16.ca.com> Here's a compilation error encountered in R14B (download from erlang.org dated Sep 15, 2010): % erlc foo.erl foo: function test_run/4+45: Internal consistency check failed - please report this bug. Instruction: {test_heap,3,2} Error: {{x,0},not_live}: ./foo.erl:12: Warning: variable 'TestCaseList' is unused Here is the source file foo.erl (admittedly it's poorly written code, but shouldn't produce an error like this): -module(foo). -export([test_run/4]). test_run(Reference, TestCaseList, Listeners, ErrorLog) -> receive {done, Reference} -> cast(Listeners, {stop, Reference, self()}), receive {result, Reference, Result} -> Result after 30000 -> Result = {error, {noresult, check_for_timeout}} end, cast(ErrorLog, {geterrors, self()}), receive {{errors, Errors}, {tests, TestCount}} -> {Result, TestCount, [], Errors} end end. cast(_,_) -> ok. From lihaitao@REDACTED Sat Oct 9 16:46:10 2010 From: lihaitao@REDACTED (Haitao Li) Date: Sat, 9 Oct 2010 22:46:10 +0800 Subject: [HiPE] Link failed when building with TYPE=valgrind Message-ID: Hi, Building beam with valgrind failed when linking. $ cd erts/emulator $ make valgrind FLAVOR=smp obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o: In function `nbif_handle_fp_exception': (.text+0x9): undefined reference to `erts_restore_fpu' collect2: ld returned 1 exit status $ nm ./obj/x86_64-unknown-linux-gnu/valgrind/smp/sys_float.o | grep erts_restore_fpu $ nm obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o | grep erts_restore_fpu U erts_restore_fpu The problem is erts_restore_fpu is not defined when build for valgrind. In beam/sys.h: #if defined(VALGRIND) && !defined(NO_FPE_SIGNALS) # define NO_FPE_SIGNALS #endif In sys/unix/sys_float.c: #ifdef NO_FPE_SIGNALS ...... #else ...... ...... #endif /Haitao Li From mikpe@REDACTED Sat Oct 9 17:59:37 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Sat, 9 Oct 2010 17:59:37 +0200 Subject: [erlang-bugs] [HiPE] Link failed when building with TYPE=valgrind In-Reply-To: References: Message-ID: <19632.37225.127416.20927@pilspetsen.it.uu.se> Haitao Li writes: > Hi, > > Building beam with valgrind failed when linking. > > $ cd erts/emulator > $ make valgrind FLAVOR=smp > > obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o: In > function `nbif_handle_fp_exception': > (.text+0x9): undefined reference to `erts_restore_fpu' > collect2: ld returned 1 exit status > > $ nm ./obj/x86_64-unknown-linux-gnu/valgrind/smp/sys_float.o | grep > erts_restore_fpu > $ nm obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o | > grep erts_restore_fpu > U erts_restore_fpu > > The problem is erts_restore_fpu is not defined when build for valgrind. > > In beam/sys.h: > #if defined(VALGRIND) && !defined(NO_FPE_SIGNALS) > # define NO_FPE_SIGNALS > #endif > > In sys/unix/sys_float.c: > > #ifdef NO_FPE_SIGNALS > ...... > #else > ...... > > ...... > #endif You apparently have to ./configure --disable-hipe if you want to make a valgrind build. I don't know why they want to disable FP signals in valgrind builds, but FP signals are required for HiPE/AMD64. From pguyot@REDACTED Sun Oct 10 16:02:18 2010 From: pguyot@REDACTED (Paul Guyot) Date: Sun, 10 Oct 2010 16:02:18 +0200 Subject: Segfault when calling module_info/0 from HiPE after a code:delete Message-ID: Hello, There is a bug in HiPE where calling module_info/0 on a module after a code:purge and code:delete will segfault. The test case is the following (to be added in module_info_SUITE.erl): %% Test that module_info works after code:delete. code_delete(Config) when is_list(Config) -> ?line ModuleInfo = module_info_helper:module_info(), ?line false = code:purge(module_info_helper), ?line true = code:delete(module_info_helper), ?line ModuleInfo = module_info_helper:module_info(), ok. module_info_helper is just a dummy module: ---- %%% @doc Helper for module_info_SUITE test. -module(module_info_helper). %% API -export([f/0]). f() -> ok. ---- If module_info_SUITE is compiled natively, the VM segfaults. If module_info_SUITE is not compiled natively, the test passes as the code server properly reloads the module. The stacktrace is the following: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 Crashed Thread: 5 ... Thread 5 Crashed: 0 beam.smp 0x0000000010105a75 erts_module_info_1 + 917 (beam_load.c:4692) 1 beam.smp 0x0000000010105d2d erts_module_info_0 + 109 (beam_load.c:4453) 2 beam.smp 0x000000001004f109 get_module_info_1 + 9 (bif.c:4232) 3 beam.smp 0x00000000100fcba6 process_main + 16982 (beam_emu.c:2205) 4 beam.smp 0x0000000010073ff2 sched_thread_func + 706 (erl_process.c:3637) 5 beam.smp 0x000000001017f8c6 thr_wrapper + 134 6 libSystem.B.dylib 0x00007fff884a4456 _pthread_start + 331 7 libSystem.B.dylib 0x00007fff884a4309 thread_start + 13 The crash happens in compilation_info_for_module: http://github.com/erlang/otp/blob/dev/erts/emulator/beam/beam_load.c#L4692 code = modp->code; ext = (byte *) code[MI_COMPILE_PTR]; <--- here. code is NULL A similar crash can occur in attributes_for_module: code = modp->code; ext = (byte *) code[MI_ATTR_PTR]; modp->code is set to NULL when code:delete is called. Paul -- Semiocast http://semiocast.com/ +33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris From zerthurd@REDACTED Mon Oct 11 14:20:41 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Mon, 11 Oct 2010 19:20:41 +0700 Subject: [erlang-bugs] compiler bug in r14B In-Reply-To: <8B3F57999F89864D9334A94C15E1ABFE02569191@USILMS16.ca.com> References: <8B3F57999F89864D9334A94C15E1ABFE02569191@USILMS16.ca.com> Message-ID: Have the same On 9 October 2010 08:03, Engquist, Jim wrote: > Here's a compilation error encountered in R14B (download from erlang.org > dated Sep 15, 2010): > > > > % erlc foo.erl > > foo: function test_run/4+45: > > Internal consistency check failed - please report this bug. > > Instruction: {test_heap,3,2} > > Error: {{x,0},not_live}: > > > > ./foo.erl:12: Warning: variable 'TestCaseList' is unused > > > > Here is the source file foo.erl (admittedly it's poorly written code, > but shouldn't produce an error like this): > > > > -module(foo). > > -export([test_run/4]). > > > > test_run(Reference, TestCaseList, Listeners, ErrorLog) -> > > receive > > {done, Reference} -> > > cast(Listeners, {stop, Reference, self()}), > > receive > > {result, Reference, Result} -> > > Result > > after 30000 -> > > Result = {error, {noresult, check_for_timeout}} > > end, > > cast(ErrorLog, {geterrors, self()}), > > receive > > {{errors, Errors}, {tests, TestCount}} -> > > {Result, TestCount, [], Errors} > > end > > end. > > > > cast(_,_) -> > > ok. > > > > > > > > -- Maxim Treskin From bgustavsson@REDACTED Mon Oct 11 17:36:20 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 11 Oct 2010 17:36:20 +0200 Subject: [erlang-bugs] compiler bug in r14B In-Reply-To: <8B3F57999F89864D9334A94C15E1ABFE02569191@USILMS16.ca.com> References: <8B3F57999F89864D9334A94C15E1ABFE02569191@USILMS16.ca.com> Message-ID: On Sat, Oct 9, 2010 at 3:03 AM, Engquist, Jim wrote: > Here's a compilation error encountered in R14B (download from erlang.org > dated Sep 15, 2010): > > > > % erlc foo.erl > > foo: function test_run/4+45: > > Internal consistency check failed - please report this bug. > > Instruction: {test_heap,3,2} > > Error: {{x,0},not_live}: > Thanks for reporting this bug. I'll investigate it. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From avtobiff@REDACTED Mon Oct 11 18:42:55 2010 From: avtobiff@REDACTED (Per Andersson) Date: Mon, 11 Oct 2010 18:42:55 +0200 Subject: SSL client certificate verify problems (RSA) Message-ID: Hi! When setting #ssl.verify = 2 (verify = verify_peer, fail_if_no_peer_cert = true; if I understand correctly), and the client sends a certificate the SSL connection crashes. The investigation I have made indicates that this happens when ssl_handshake:certificate_verify/6 is called, because PublicKey seems to be an integer() and public_key:decrypt_public/3 assumes PublicKey is a #'RSAPublicKey'. Should public_key:decrypt_public/3 be extended to also take PublicKey formatted as an integer()? Best regards, Per From michael@REDACTED Tue Oct 12 22:41:19 2010 From: michael@REDACTED (Michael Stapelberg) Date: Tue, 12 Oct 2010 22:41:19 +0200 Subject: Connection to IPv6 link local address fails due to missing scope identifier Message-ID: <1286915681-sup-4991@midna.zekjur.net> Hi, the following proof of concept fails: -module(poc). -export([start/0]). start() -> {ok, Sock} = gen_tcp:connect("fe80::21f:16ff:fe1a:f5b8%eth0", 80, [inet6]), io:fwrite("connect said: ~p~n", [ok]). If you strace it using strace -fF -etrace=network erl -s poc, you?ll see the following: socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 7 bind(7, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 getsockname(7, {sa_family=AF_INET6, sin6_port=htons(36404), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 connect(7, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "fe80::21f:16ff:fe1a:f5b8", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument) The problem is the missing scope identifier (sin6_scope_id), which should be 2 for eth0 in my case (see /proc/net/igmp6 for easily getting the scope id for your interfaces). To reproduce this test: ? to test the client side, use nc -6 fe80::21f:16ff:fe1a:f5b8%eth0 80 ? to test the server side, use for example OpenSSH (listens on all interfaces/addresses per default) or Apache. ? to get your link local address, use ifconfig(1) or "ip a|grep fe80" Best regards, Michael From raimo+erlang-bugs@REDACTED Wed Oct 13 09:04:30 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 13 Oct 2010 09:04:30 +0200 Subject: [erlang-bugs] Connection to IPv6 link local address fails due to missing scope identifier In-Reply-To: <1286915681-sup-4991@midna.zekjur.net> References: <1286915681-sup-4991@midna.zekjur.net> Message-ID: <20101013070430.GA9640@erix.ericsson.se> On Tue, Oct 12, 2010 at 10:41:19PM +0200, Michael Stapelberg wrote: > Hi, > > the following proof of concept fails: > -module(poc). > -export([start/0]). > > start() -> > {ok, Sock} = gen_tcp:connect("fe80::21f:16ff:fe1a:f5b8%eth0", 80, [inet6]), > io:fwrite("connect said: ~p~n", [ok]). > > If you strace it using strace -fF -etrace=network erl -s poc, you???ll see the > following: > > socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 7 > bind(7, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::", > &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 > getsockname(7, {sa_family=AF_INET6, sin6_port=htons(36404), > inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, > [28]) = 0 > connect(7, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, > "fe80::21f:16ff:fe1a:f5b8", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, > 28) = -1 EINVAL (Invalid argument) > > The problem is the missing scope identifier (sin6_scope_id), which should be 2 > for eth0 in my case (see /proc/net/igmp6 for easily getting the scope id for > your interfaces). Scope identifiers are currently not implemented. They are also not quite portable, especially how you find them out and translate them into the 32-bit scope ID needed in sockaddr_in6{}. We need to support as many as possible of Linux, Solaris 8/9/10/.., Windows XP/Vista/7, MacOS X, FreeBSD, OpenBSD and NetBSD, plus some other Unix-like OS:es. Most do not have Linux /proc. We also need to solve our own backwards compatibility problem of representing IPv6 addresses as 8-tuples of 0..65535 and having _lots_ of code testing for a term being an IPv6-address simply by checking if it is an 8-tuple. Somehow we need to squeeze in a scope ID in our representation of IPv6 addresses. There are also issues to consider regarding how and to what extent the name resolving functions can/should return scope IDs with accompaning OS compatibility quirks. But it _is_ on our todo list... > > To reproduce this test: > ??? to test the client side, use nc -6 fe80::21f:16ff:fe1a:f5b8%eth0 80 > ??? to test the server side, use for example OpenSSH (listens on all > interfaces/addresses per default) or Apache. > ??? to get your link local address, use ifconfig(1) or "ip a|grep fe80" > > Best regards, > Michael > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ingela@REDACTED Wed Oct 13 10:01:56 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 13 Oct 2010 10:01:56 +0200 Subject: [erlang-bugs] SSL client certificate verify problems (RSA) In-Reply-To: References: Message-ID: <4CB56774.6050806@erix.ericsson.se> Hi! Per Andersson wrote: > Hi! > > When setting #ssl.verify = 2 (verify = verify_peer, fail_if_no_peer_cert = true; > if I understand correctly), and the client sends a certificate the SSL > connection crashes. > > The investigation I have made indicates that this happens when > ssl_handshake:certificate_verify/6 is called, because PublicKey seems to be an > integer() and public_key:decrypt_public/3 assumes PublicKey is a > #'RSAPublicKey'. > > > Should public_key:decrypt_public/3 be extended to also take PublicKey formatted > as an integer()? > > If the public key is an integer it suggests it is a dsa-key and not an rsa-key, and it should not have ended up calling public_key:decrypt_public/3 rather calling public_key:verify/ 4. Could you provides us with a way to repeat the problem? (Some dummy cert and keys perhaps?). We have some test for client certs in ssl_to_openssl_SUITE.erl using both rsa and dsa signed certs that all pass. Regards Ingela Erlang/OTP team - Ericsson AB From michael@REDACTED Wed Oct 13 10:40:59 2010 From: michael@REDACTED (Michael Stapelberg) Date: Wed, 13 Oct 2010 10:40:59 +0200 Subject: [erlang-bugs] Connection to IPv6 link local address fails due to missing scope identifier In-Reply-To: <20101013070430.GA9640@erix.ericsson.se> References: <1286915681-sup-4991@midna.zekjur.net> <20101013070430.GA9640@erix.ericsson.se> Message-ID: <1286959185-sup-2893@midna.zekjur.net> Hi, Excerpts from Raimo Niskanen's message of 2010-10-13 09:04:30 +0200: > Scope identifiers are currently not implemented. They are also not quite > portable, especially how you find them out and translate them into the 32-bit > scope ID needed in sockaddr_in6{}. The most easy way is to use getaddrinfo(3). Thanks for your detailed reply. Best regards, Michael From raimo+erlang-bugs@REDACTED Wed Oct 13 11:12:54 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 13 Oct 2010 11:12:54 +0200 Subject: [erlang-bugs] Connection to IPv6 link local address fails due to missing scope identifier In-Reply-To: <1286959185-sup-2893@midna.zekjur.net> References: <1286915681-sup-4991@midna.zekjur.net> <20101013070430.GA9640@erix.ericsson.se> <1286959185-sup-2893@midna.zekjur.net> Message-ID: <20101013091254.GB9640@erix.ericsson.se> On Wed, Oct 13, 2010 at 10:40:59AM +0200, Michael Stapelberg wrote: > Hi, > > Excerpts from Raimo Niskanen's message of 2010-10-13 09:04:30 +0200: > > Scope identifiers are currently not implemented. They are also not quite > > portable, especially how you find them out and translate them into the 32-bit > > scope ID needed in sockaddr_in6{}. > The most easy way is to use getaddrinfo(3). Yes. Good hint. That is what the 'native' resolver method prefers. Still remains Windows'es, the 8-tuple address representation problem and which string representation to choose to be compatible with other programs on each OS... > > Thanks for your detailed reply. You are welcome. This will need to be discussed so we appreciate any hints about best practices. > > Best regards, > Michael -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From avtobiff@REDACTED Wed Oct 13 15:57:19 2010 From: avtobiff@REDACTED (Per Andersson) Date: Wed, 13 Oct 2010 15:57:19 +0200 Subject: [erlang-bugs] SSL client certificate verify problems (RSA) In-Reply-To: <4CB56774.6050806@erix.ericsson.se> References: <4CB56774.6050806@erix.ericsson.se> Message-ID: Hi! Thanks for your quick response! On Wed, Oct 13, 2010 at 10:01 AM, Ingela Anderton Andin wrote: > Hi! > > Per Andersson wrote: >> >> Hi! >> >> When setting #ssl.verify = 2 (verify = verify_peer, fail_if_no_peer_cert = >> true; >> if I understand correctly), and the client sends a certificate the SSL >> connection crashes. >> >> The investigation I have made indicates that this happens when >> ssl_handshake:certificate_verify/6 is called, because PublicKey seems to >> be an >> integer() and public_key:decrypt_public/3 assumes PublicKey is a >> #'RSAPublicKey'. >> >> ?Should public_key:decrypt_public/3 be extended to also take PublicKey >> formatted >> as an integer()? >> >> > > If the public key is an integer it suggests it is a dsa-key and not an > rsa-key, and it should not > have ended up calling public_key:decrypt_public/3 rather calling > public_key:verify/ 4. I understand. >From what I can see the client cert is DSA (pubkey) and RSA (encryption). Can this be the pressing issue? > Could you provides us with a way to repeat the problem? (Some dummy cert and > keys perhaps?). I am using RBS WorldPays client certs, obviously I don't have the key for this... CA and client certs attached, they are also available online https://crm.rbsworldpay.com/cgi-bin/rbsworldpay.cfg/php/enduser/std_adp.php?p_faqid=925 Best regards, Per -------------- next part -------------- A non-text attachment was scrubbed... Name: bibit.ca.pem Type: application/octet-stream Size: 1416 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bibit.client.pem Type: application/octet-stream Size: 1774 bytes Desc: not available URL: From avtobiff@REDACTED Wed Oct 13 16:51:23 2010 From: avtobiff@REDACTED (Per Andersson) Date: Wed, 13 Oct 2010 16:51:23 +0200 Subject: [erlang-bugs] SSL client certificate verify problems (RSA) In-Reply-To: References: <4CB56774.6050806@erix.ericsson.se> Message-ID: Hi! On Wed, Oct 13, 2010 at 3:57 PM, Per Andersson wrote: >> If the public key is an integer it suggests it is a dsa-key and not an >> rsa-key, and it should not >> have ended up calling public_key:decrypt_public/3 rather calling >> public_key:verify/ 4. > > I understand. > > From what I can see the client cert is DSA (pubkey) and RSA (encryption). > Can this be the pressing issue? The client cert seems to be signed with RSA, not mixing algorithms as my comment above implies... Best, Per From kostis@REDACTED Fri Oct 15 00:08:36 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 15 Oct 2010 01:08:36 +0300 Subject: Specs of reltool Message-ID: <4CB77F64.7000507@cs.ntua.gr> A dialyzer user complained that he gets spurious warnings when using reltool functions. A quick dialyzer run revealed that reltool is full of erroneous specs which cannot possibly be right. For example, dialyzer complains that: reltool.erl:178: The specification for reltool:get_target_spec/1 states that the function might also return {'ok',[[any()] | {_,_} | {_,_,_} | {_,_,_,_}] | {'copy_file',[any()]} | {'strip_beam_file',[any()]} | {'copy_file',[any()],[any()]} | {'create_dir',[any()],[any()]} | {'write_file',[any()],maybe_improper_list(any(),binary() | [])} | {'archive',[any()],[any()],[any()]} | {'create_dir',[any()],[any()],[any()]}} but the inferred return is {'error',string()} | {'ok',pid()} and indeed: get_target_spec(PidOrOptions) when is_pid(PidOrOptions); is_list(PidOrOptions) -> eval_server(PidOrOptions, true, fun(Pid) -> reltool_server:gen_spec(Pid) end). where there is a promise that eval_server/3 will return: -spec eval_server(server(), boolean(), fun((server_pid()) -> term())) -> {ok, server_pid()} | {error, reason()}. These two together cannot be right. In fact, it's easy to see that this function returns whatever the fun in its third argument returns (which is term() in this case, if one believes the 3rd argument). In general, reltool produces many dialyzer warnings of similar kind. They should be fixed because they are not only wrong, but they affect users of this application. Kostis From sgolovan@REDACTED Sat Oct 16 16:15:47 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Sat, 16 Oct 2010 18:15:47 +0400 Subject: ODBC and net.ipv6.bindv6only Message-ID: Hi! Looks like odbc application has a bug which breaks it in case when net.ipv6.bindv6only config variable is set to 1 (so, binding to inet6 socket doesn't bind to inet one as well). In Debian GNU/Linux (using R14A, but R14B has the same odbc version 2.10.8): % cat /proc/sys/net/ipv6/bindv6only 0 % erl Erlang R14A (erts-5.8) [source] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8 (abort with ^G) 1> odbc:start(). ok 2> odbc:connect("DSN=postgres;UID=odbcuser;PWD=odbcpasswd",[]). {ok,<0.39.0>} 3> Another scenario: % cat /proc/sys/net/ipv6/bindv6only 1 % erl Erlang R14A (erts-5.8) [source] [smp:8:8] [rq:8] [async-threads:0] [kernel-poll:false] Eshell V5.8 (abort with ^G) 1> odbc:start(). ok 2> odbc:connect("DSN=postgres;UID=odbcuser;PWD=odbcpasswd",[]). {error,connection_closed} =ERROR REPORT==== 16-Oct-2010::18:11:35 === ** Generic server <0.39.0> terminating ** Last message in was {<0.32.0>, {connect,[1,1,2,1,1,2, "DSN=postgres;UID=odbcuser;PWD=odbcpasswd"], on,on}, infinity} ** When Server state == {state,#Port<0.571>, {<0.32.0>,#Ref<0.0.0.39>}, <0.32.0>,undefined,on,undefined,undefined,on, connecting,undefined,0, [#Port<0.569>,#Port<0.570>], undefined,undefined} ** Reason for termination == ** timeout 3> The latter timeout occurs even in case when "localhost" resolves to both 127.0.0.1 and ::1. Cheers! -- Sergei Golovan From sgolovan@REDACTED Sun Oct 17 10:07:23 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Sun, 17 Oct 2010 12:07:23 +0400 Subject: ODBC and net.ipv6.bindv6only In-Reply-To: References: Message-ID: Hi again! It seems I've found why odbc doesn't work in IPv6-IPv4 environment when IPv6 sockets don't bind to IPv4 also. In odbcserver.c code I've found the following: #define USE_IPV4 #ifdef UNIX #define SOCKET int #endif #if defined WIN32 || defined USE_IPV4 /* Currently only an old windows compiler is supported so we do not have ipv6 capabilities */ static SOCKET connect_to_erlang(const char *port) { So, IPv6 capable code is just switched off. Is it safe to enable it? (Only connect_to_erlang function will change.) Cheers! -- Sergei Golovan From baggett.patrick@REDACTED Wed Oct 20 13:50:55 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Wed, 20 Oct 2010 06:50:55 -0500 Subject: erl rejects FQN that begin with a digit Message-ID: This one is probably a really quick fix... Synopsis: It seems Erlang doesn't like domain names that start with digits, in my case, the domain "8fun.net" (host1@REDACTED)5> tut17:start_ping(host2@REDACTED). * 1: syntax error before: 8 (host1@REDACTED)6> tut17:start_ping(host2@REDACTED). << Notice the 8 is gone <0.53.0> (host1@REDACTED)7> tut17:start_ping(host2@REDACTED). << 8 in the middle works <0.58.0> (host1@REDACTED)8> tut17:start_ping(host2@REDACTED). << 8 in the end is fine, too <0.61.0> Expected: Domain names that begin with a digit are legal and should be accepted. Reproduce: Use any FQN that has a domain name that begins with a digit. Confirmed Version: R14B built on OpenSuSE 11.3 from source, Windows XP SP3 from R14B binaries Blind Guess: Probably some code is looking to categorize a string based upon the first character, when in reality, domain names can be represented by the RE [a-zA-Z0-9]* or the C function isalnum(). Domain names don't need alpha characters at all in the part before the TLD, e.g. 45.com Background: I created a simple internal LAN using the domain name of "8fun.net" I've got DNS and DHCP working on this and I have two hosts, "test1.8fun.net" and "test2.8fun.net" using 192.168.0.10 and .11 respectively. They can ping each other by IP or hostname, and all is good with the world. I started one with "erl -name host1" and I'm greeted with: Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.1 (abort with ^G) (host1@REDACTED)1> No problem here. Now, I want to send a message to a process, and I used the tutorial 17 to do so (http://www.erlang.org/doc/getting_started/conc_prog.html , section 3.4). This exports start_ping/1, where the first argument is the name of the node. In short name mode, this works great, but in long name mode, Erlang chokes on the FQN. From magnus@REDACTED Wed Oct 20 13:58:09 2010 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 20 Oct 2010 12:58:09 +0100 Subject: erl rejects FQN that begin with a digit In-Reply-To: (Patrick Baggett's message of "Wed, 20 Oct 2010 06:50:55 -0500") References: Message-ID: <8439s1dqjy.fsf@linux-b2a3.site> Patrick Baggett writes: > This one is probably a really quick fix... > > Synopsis: > It seems Erlang doesn't like domain names that start with digits, in my > case, the domain "8fun.net" > > (host1@REDACTED)5> tut17:start_ping(host2@REDACTED). > * 1: syntax error before: 8 Try with single quotes around the hostname: tut17:start_ping('host2@REDACTED'). By using single quotes, you force the parser to read the name as an atom. -- Magnus Henoch, magnus@REDACTED Erlang Solutions http://www.erlang-solutions.com/ From vladdu55@REDACTED Wed Oct 20 13:58:56 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Oct 2010 13:58:56 +0200 Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 13:50, Patrick Baggett wrote: > It seems Erlang doesn't like domain names that start with digits, in my > case, the domain "8fun.net" > > (host1@REDACTED)5> tut17:start_ping(host2@REDACTED). > * 1: syntax error before: 8 Hi! Try enclosing the host name in single quotes, to make it a single atom: (host1@REDACTED)5> tut17:start_ping('host2@REDACTED'). Otherwise each part delimited by a dot is scanned as an atom, and atoms can't begin with digits. best regards, Vlad From baggett.patrick@REDACTED Wed Oct 20 14:03:39 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Wed, 20 Oct 2010 07:03:39 -0500 Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: References: Message-ID: That seems like an odd deficiency of the parser, or maybe just an artifact of the language. I guess there isn't any support for treating name@REDACTED as a single unit since it is trying to convert everything into atoms rather than leaving it a string. Well, I won't say it is intuitive, but it does work. Thanks Patrick On Wed, Oct 20, 2010 at 6:58 AM, Vlad Dumitrescu wrote: > On Wed, Oct 20, 2010 at 13:50, Patrick Baggett > wrote: > > It seems Erlang doesn't like domain names that start with digits, in my > > case, the domain "8fun.net" > > > > (host1@REDACTED)5> tut17:start_ping(host2@REDACTED). > > * 1: syntax error before: 8 > > Hi! > > Try enclosing the host name in single quotes, to make it a single atom: > > (host1@REDACTED)5> tut17:start_ping('host2@REDACTED'). > > Otherwise each part delimited by a dot is scanned as an atom, and > atoms can't begin with digits. > > best regards, > Vlad > From baggett.patrick@REDACTED Wed Oct 20 14:13:23 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Wed, 20 Oct 2010 07:13:23 -0500 Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 7:03 AM, Patrick Baggett wrote: > That seems like an odd deficiency of the parser, or maybe just an artifact > of the language. I guess there isn't any support for treating name@REDACTED as > a single unit since it is trying to convert everything into atoms rather > than leaving it a string. Well, I won't say it is intuitive, but it does > work. Thanks > > Patrick > > Let me qualify that, for the record. >From http://www.erlang.org/doc/reference_manual/data_types.html -- snip -- 2.3 Atom An atom is a literal, a constant with name. An atom should be enclosed in single quotes (') if it does not begin with a lower-case letter or if it contains other characters than alphanumeric characters, underscore (_), or @. -- snip -- name@REDACTED contains a @, so one would expect if this was a single atom, that single quotes would be required, but they aren't. Erlang just magically knows, that is, unless you start it with a digit, because when it is broken into multiple atoms (I guess?) it fails the test of starting with a lower case character. But if it starts with a digit, then it needs quotes, /around the whole thing/, meaning it isn't a sequence of atom@REDACTED, but just 'atom' I would have expected to see host1@'8fun'.net, which makes '8fun' an atom, rather than the whole thing. ...which is why I think it isn't particularly intuitive. Patrick From vladdu55@REDACTED Wed Oct 20 14:37:45 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Oct 2010 14:37:45 +0200 Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 14:13, Patrick Baggett wrote: > -- snip -- > 2.3 ?Atom > An atom is a literal, a constant with name. An atom should be enclosed in > single quotes (') if it does not begin with a lower-case letter or if it > contains other characters than alphanumeric characters, underscore (_), or > @. > -- snip -- > ?name@REDACTED contains a @, so one would expect if this was a single atom, that > single quotes would be required, but they aren't. Erlang just magically > knows, that is, unless you start it with a digit, because when it is broken > into multiple atoms (I guess?) it fails the test of starting with a lower > case character. It's not the @ that separates the name in multiple atoms, but the dots. It's an artifact of the still experimental package feature that you can chain atoms together with dots, in the old times one had to use quotes for host names. > ?But if it starts with a digit, then it needs quotes, /around the whole > thing/, meaning it isn't a sequence of atom@REDACTED, but just 'atom' > I would have expected to see host1@'8fun'.net, which makes '8fun' an atom, > rather than the whole thing. No, quotes around the misbehaving atom work fine: 1> x@REDACTED x@REDACTED 2> x@REDACTED x@REDACTED 4> x@REDACTED * 1: syntax error before: 2 4> x@REDACTED'2y'. 'x@REDACTED' regards, Vlad From vances@REDACTED Thu Oct 21 00:41:57 2010 From: vances@REDACTED (Vance Shipley) Date: Wed, 20 Oct 2010 18:41:57 -0400 Subject: Change node name in mnesia In-Reply-To: <20101018172930.GE21059@h216-235-12-174.host.egate.net> References: <20100214031924.GM13976@h216-235-12-174.host.egate.net> <20100702222835.GC267@h216-235-12-169.host.egate.net> <20101018172930.GE21059@h216-235-12-174.host.egate.net> Message-ID: <20101020224157.GA3472@h216-235-12-169.host.egate.net> Dan, I am able to reproduce the problem with the attached code and the procedure detailed below. In a nutshell the process outlined in The Mnesia User's Guide for renaming a database node in a backup file results in a corrupt database. http://erlang.org/doc/apps/mnesia/Mnesia_chap7.html#id74479 I used the attached test code, derived from the above example, to create a sample database, rename the node name from long form to short and verify it's integrity. Start a node with a long node name: $ erl -name long Eshell V5.8.1 (abort with ^G) (long@REDACTED)1> rr("db_transform.erl"). [acc,bar,baz,foo] Build an example data base: (long@REDACTED)2> db_transform:install([node()], 4000, 500, 25). {ok,#acc{foo = 3994,bar = 500,baz = 25}} Back up the example database into the file "long": (long@REDACTED)3> mnesia:backup(long). ok Start a node with a short node name: $ erl -sname short Eshell V5.8.1 (abort with ^G) (short@REDACTED)1> rr("db_transform.erl"). [acc,bar,baz,foo] Change the node name in the backup file "long" and create backup "short": (short@REDACTED)2> db_transform:rename('long@REDACTED', 'short@REDACTED', long, short). {ok,#acc{foo = 3994,bar = 500,baz = 25}} Create a new database from the backup "short": (short@REDACTED)3> mnesia:create_schema([node()]). ok (short@REDACTED)4> mnesia:start(). ok (short@REDACTED)5> mnesia:restore(short, [{default_op, recreate_tables}]). {atomic,[foo,baz,bar]} Test the database integrity: (short@REDACTED)6> db_transform:verify([foo, bar, baz]). #acc{foo = 3994,bar = 500,baz = 25} The above proves the backup, transform and restore process works. So far so good. Now below is where the problem can be reproduced. (short@REDACTED)7> q(). ok $ erl -sname short (short@REDACTED)1> mnesia:start(). ok (short@REDACTED)2> db_transform:verify([foo, bar, baz]). ** exception exit: {function_clause,[{db_transform,'-verify/2-fun-0-', [{log_header,dcl_log,"1.0","4.4.15",'short@REDACTED', {1287,613266,224499}}, 1899]}, {lists,foldl,3}, {mnesia,do_foldl,8}, {mnesia,foldl,6}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {db_transform,count,2}, {db_transform,verify,2}]} in function db_transform:count/2 in call from db_transform:verify/2 Restarting the node is what triggers the problem. (short@REDACTED)3> ets:i(baz). <1 > {baz,711590, <<76,16,157,97,48,225,132,80,36,196,3,199,194,239 ... <2 > {baz,411561, <<173,175,232,135,28,118,233,210,111,49,169,19,88 ... <3 > {baz,909239, <<135,214,14,32,8,121,144,64,196,35,186,167,63,24 ... <4 > {baz,463433, <<66,156,188,32,49,157,54,160,133,241,196,78,22,2 ... <5 > {baz,997452, <<248,253,234,156,76,130,48,212,89,197,186,210,21 ... <6 > {baz,797390, <<25,1,27,228,30,234,2,147,80,80,167,58,230,54,11 ... <7 > {baz,879889, <<249,45,35,209,179,173,217,158,208,227,220,67,20 ... <8 > {baz,604804, <<120,75,101,145,118,116,39,218,204,246,198,162,3 ... <9 > {baz,807967, <<58,209,110,188,212,128,136,15,133,56,166,13,30, ... <10 > {baz,388388, <<143,53,248,42,115,146,218,222,246,67,10,173,185 ... <11 > {baz,890638, <<11,137,19,231,155,97,254,94,79,68,94,82,156,190 ... <12 > {baz,865475, <<169,173,174,222,235,89,94,90,11,192,50,72,37,43 ... <13 > {baz,595736, <<43,98,245,177,0,79,54,225,36,201,24,188,195,240 ... <14 > {log_header,dcl_log,"1.0","4.4.15",'short@REDACTED', ... <15 > {baz,771466, <<39,59,205,76,71,40,80,85,65,229,224,198,109,132 ... <16 > {baz,834821, <<76,65,143,50,217,159,155,39,129,56,67,59,73,95, ... <17 > {baz,534651, <<72,192,141,91,154,171,201,126,135,7,213,143,13, ... <18 > {baz,551117, <<85,185,77,144,114,113,203,93,206,29,122,106,52, ... <19 > {baz,224818, <<120,27,23,224,251,51,254,69,215,104,11,93,135,5 ... <20 > {baz,358442, <<255,165,10,214,6,121,98,31,231,82,52,194,27,94, ... <21 > {baz,382522, <<188,190,108,27,51,81,186,175,215,95,168,203,128 ... <22 > {baz,991628, <<232,191,166,252,143,87,251,139,145,217,227,85,5 ... <23 > {baz,748772, <<210,38,226,254,243,76,211,180,233,33,160,144,25 ... <24 > {baz,563034, <<52,120,167,54,135,139,205,40,57,250,28,86,34,10 ... <25 > {baz,765113, <<189,143,122,1,82,185,173,20,161,90,145,16,225,1 ... <26 > {baz,510427, <<193,192,140,177,72,25,44,199,190,71,144,24,242, ... EOT (q)uit (p)Digits (k)ill /Regexp --> For some reason the header of a TABLE.DCL file is getting stuck into the database in between stopping the node, restarting the node and starting mnesia again. -Vance On Mon, Oct 18, 2010 at 01:29:30PM -0400, Vance Shipley wrote: } On Sat, Jul 03, 2010 at 09:09:31AM +0200, Dan Gudmundsson wrote: } } Are you seeing those in the ets table? } } Yes I do see the headers in the ets table: } } 4> ets:i(foo). } [...] } <12 > {log_header,dcl_log,"1.0","4.4.10",'bar@REDACTED',{1287,322033,2 ... } [...] } } } They should not be in the table, they are what they say the header of } } a TABLE.DCL file. } } } } Either you or I have some improvements to do :-) } } I did another database migration today, changing long node name } to short, on R13B04 yesterday and experienced the same results. } These header records don't show up in the items passed through } mnesia:traverse_backup/6 so it doesn't appear to be something } I'm doing wrong. } } I'm going to work on demonstrating the problem as simply as possible. } } -- } -Vance } } } On Sat, Jul 3, 2010 at 12:28 AM, Vance Shipley wrote: } } > Is it valid to have records in an mnesia table of this form: } } > } } > ?{log_header,dcl_log,"1.0","4.4.10",'foo@REDACTED',{1266,113437,587068}}, } } > } } > The tables seem to be working fine even though these entries are } } > there which obviously do not have the correct OID for the table. } } > } } > What I'd like to understand is if I've broken the tables myself } } > or if this type of thing is valid and I should just deal with } } > them when traversing a table with mnesia:foldl/3. } } > } } > ? ? ? ?-Vance } } > } } > On Sat, Feb 13, 2010 at 10:19:24PM -0500, Vance Shipley wrote: } } > } ?I used the example in the Mnesia User's Guide to backup } } > } ?and transform a database from a long node name to a short } } > } ?one. ?That all seemed to go smoothly enough but now I'm } } > } ?noticing these strange records in my tables: } } > } } } > } ? ? {log_header,dcl_log,"1.0","4.4.10",'foo@REDACTED',{1266,113437,587068}}, } } > } } } > } ?I discovered this using mnesia:foldl/3. ?Is this normal } } > } ?or have I messed things up? -- -Vance -------------- next part -------------- -module(db_transform). -export([install/4, rename/4, info/1, verify/1]). -record(foo, {key, value}). -record(bar, {key, value}). -record(baz, {key, value}). -record(acc, {foo = 0, bar = 0, baz = 0}). install(Nodes, SizeFoo, SizeBar, SizeBaz) -> try case mnesia:create_schema(Nodes) of ok -> ok; {error, CReason} -> throw(CReason) end, case mnesia:start() of ok -> ok; {error, SReason} -> throw(SReason) end, case mnesia:wait_for_tables([schema], 10000) of ok -> ok; SchemaResult-> throw(SchemaResult) end, case mnesia:create_table(foo, [{disc_copies, Nodes}, {attributes, record_info(fields, foo)}]) of {atomic, ok} -> ok; T1Result -> throw(T1Result) end, case mnesia:create_table(bar, [{disc_copies, Nodes}, {attributes, record_info(fields, bar)}]) of {atomic, ok} -> ok; T2Result -> throw(T2Result) end, case mnesia:create_table(baz, [{disc_copies, Nodes}, {attributes, record_info(fields, baz)}]) of {atomic, ok} -> ok; T4Result -> throw(T4Result) end, Tables = [foo, bar, baz], case mnesia:wait_for_tables(Tables, 10000) of ok -> ok; TablesResult -> throw(TablesResult) end, crypto:start(), Threshold = mnesia:system_info(dump_log_write_threshold) - 1, initialize(Tables, Threshold, SizeFoo, SizeBar, SizeBaz), {ok, info(Tables)} of Result -> Result catch throw:Error -> mnesia:error_description(Error) end. initialize([], _Threshold, _SizeFoo, _SizeBar, _SizeBaz) -> ok; initialize([foo | Rest], Threshold, SizeFoo, SizeBar, SizeBaz) -> batch(foo, SizeFoo, Threshold), initialize(Rest, Threshold, SizeFoo, SizeBar, SizeBaz); initialize([bar | Rest], Threshold, SizeFoo, SizeBar, SizeBaz) -> batch(bar, SizeBar, Threshold), initialize(Rest, Threshold, SizeFoo, SizeBar, SizeBaz); initialize([baz | Rest], Threshold, SizeFoo, SizeBar, SizeBaz) -> batch(baz, SizeBaz, Threshold), initialize(Rest, Threshold, SizeFoo, SizeBar, SizeBaz). batch(_Table, N, _Threshold) when N =< 0 -> ok; batch(Table, N, Threshold) when N =< Threshold -> insert(Table, N), mnesia:dump_log(), ok; batch(Table, N, Threshold) when N > Threshold -> insert(Table, Threshold), mnesia:dump_log(), batch(Table, N - Threshold, Threshold). insert(_Table, 0) -> ok; insert(Table, N) -> Key = crypto:rand_uniform(0, 1000000), Value = crypto:rand_bytes(128), Rec = {Table, Key, Value}, mnesia:dirty_write(Table, Rec), insert(Table, N - 1). rename(From, To, Source, Target) -> Fswitch = fun(Node) when Node == From -> To; (Node) when Node == To -> throw({error, already_exists}); (Other) -> Other end, Fconvert = fun({schema, db_nodes, Nodes}, Acc) -> {[{schema, db_nodes, lists:map(Fswitch,Nodes)}], Acc}; ({schema, Tab, CreateList}, Acc) -> Keys = [ram_copies, disc_copies, disc_only_copies, cookie], FoptSwitch = fun({cookie, {Now, Node}}) when Node == From -> {cookie, {Now, To}}; ({Key, Val}) -> case lists:member(Key, Keys) of true -> {Key, lists:map(Fswitch, Val)}; false-> {Key, Val} end end, {[{schema, Tab, lists:map(FoptSwitch, CreateList)}], Acc}; (#foo{} = Foo, #acc{foo = Count} = Acc) -> {[Foo], Acc#acc{foo = Count + 1}}; (#bar{} = Foo, #acc{bar = Count} = Acc) -> {[Foo], Acc#acc{bar = Count + 1}}; (#baz{} = Foo, #acc{baz = Count} = Acc) -> {[Foo], Acc#acc{baz = Count + 1}} end, mnesia:traverse_backup(Source, Target, Fconvert, #acc{}). info(Tables) -> info(Tables, #acc{}). info([foo | Rest], Acc) -> Size = mnesia:table_info(foo, size), info(Rest, Acc#acc{foo = Size}); info([bar | Rest], Acc) -> Size = mnesia:table_info(bar, size), info(Rest, Acc#acc{bar = Size}); info([baz | Rest], Acc) -> Size = mnesia:table_info(baz, size), info(Rest, Acc#acc{baz = Size}); info([], Acc) -> Acc. verify(Tables) -> verify(Tables, #acc{}). verify([foo | Rest], Acc) -> Fun = fun(#foo{}, Count) -> Count + 1 end, Size = count(Fun, foo), verify(Rest, Acc#acc{foo = Size}); verify([bar | Rest], Acc) -> Fun = fun(#bar{}, Count) -> Count + 1 end, Size = count(Fun, bar), verify(Rest, Acc#acc{bar = Size}); verify([baz | Rest], Acc) -> Fun = fun(#baz{}, Count) -> Count + 1 end, Size = count(Fun, baz), verify(Rest, Acc#acc{baz = Size}); verify([], Acc) -> Acc. count(Facc, Table) -> Ftrans = fun() -> mnesia:foldl(Facc, 0, Table) end, case mnesia:transaction(Ftrans) of {atomic, Result} -> Result; {aborted, Reason} -> exit(Reason) end. From vances@REDACTED Thu Oct 21 00:45:21 2010 From: vances@REDACTED (Vance Shipley) Date: Wed, 20 Oct 2010 18:45:21 -0400 Subject: Change node name in mnesia In-Reply-To: <20101020224157.GA3472@h216-235-12-169.host.egate.net> References: <20100214031924.GM13976@h216-235-12-174.host.egate.net> <20100702222835.GC267@h216-235-12-169.host.egate.net> <20101018172930.GE21059@h216-235-12-174.host.egate.net> <20101020224157.GA3472@h216-235-12-169.host.egate.net> Message-ID: <20101020224521.GB3472@h216-235-12-169.host.egate.net> The interesting thing is that the database keeps on working. I only noticed the problem because I have code which uses mnesia:foldl/3 function to iterate over all the table entries and that ciode expects all the entries to be valid records for the table. -Vance On Wed, Oct 20, 2010 at 06:41:57PM -0400, Vance Shipley wrote: } For some reason the header of a TABLE.DCL file is getting stuck into } the database in between stopping the node, restarting the node and } starting mnesia again. From raimo+erlang-bugs@REDACTED Thu Oct 21 11:27:59 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 21 Oct 2010 11:27:59 +0200 Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: References: Message-ID: <20101021092759.GA32286@erix.ericsson.se> On Wed, Oct 20, 2010 at 02:37:45PM +0200, Vlad Dumitrescu wrote: > On Wed, Oct 20, 2010 at 14:13, Patrick Baggett > wrote: > > -- snip -- > > 2.3 ?Atom > > An atom is a literal, a constant with name. An atom should be enclosed in > > single quotes (') if it does not begin with a lower-case letter or if it > > contains other characters than alphanumeric characters, underscore (_), or > > @. > > -- snip -- > > ?name@REDACTED contains a @, so one would expect if this was a single atom, that > > single quotes would be required, but they aren't. Erlang just magically > > knows, that is, unless you start it with a digit, because when it is broken > > into multiple atoms (I guess?) it fails the test of starting with a lower > > case character. > > It's not the @ that separates the name in multiple atoms, but the > dots. It's an artifact of the still experimental package feature that > you can chain atoms together with dots, in the old times one had to > use quotes for host names. Long host names that is. foo@REDACTED has always been interpreted as an atom. That was a peculiar side effect of the package system. The traditional answer is: node names with fully qualified host names has to be quoted in whole e.g 'foo@REDACTED'. > > > ?But if it starts with a digit, then it needs quotes, /around the whole > > thing/, meaning it isn't a sequence of atom@REDACTED, but just 'atom' > > I would have expected to see host1@'8fun'.net, which makes '8fun' an atom, > > rather than the whole thing. > > No, quotes around the misbehaving atom work fine: > > 1> x@REDACTED > x@REDACTED > 2> x@REDACTED > x@REDACTED > 4> x@REDACTED > * 1: syntax error before: 2 > 4> x@REDACTED'2y'. > 'x@REDACTED' > > regards, > Vlad > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From robert.virding@REDACTED Thu Oct 21 23:49:20 2010 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 21 Oct 2010 21:49:20 +0000 (GMT) Subject: [erlang-bugs] erl rejects FQN that begin with a digit In-Reply-To: <1108216984.131231287697674534.JavaMail.root@zimbra> Message-ID: <699258831.131251287697760386.JavaMail.root@zimbra> ----- "Vlad Dumitrescu" wrote: > On Wed, Oct 20, 2010 at 14:13, Patrick Baggett > wrote: > > -- snip -- > > 2.3 ?Atom > > An atom is a literal, a constant with name. An atom should be > enclosed in > > single quotes (') if it does not begin with a lower-case letter or > if it > > contains other characters than alphanumeric characters, underscore > (_), or > > @. > > -- snip -- > > ?name@REDACTED contains a @, so one would expect if this was a single > atom, that > > single quotes would be required, but they aren't. Erlang just > magically > > knows, that is, unless you start it with a digit, because when it is > broken > > into multiple atoms (I guess?) it fails the test of starting with a > lower > > case character. > > It's not the @ that separates the name in multiple atoms, but the > dots. It's an artifact of the still experimental package feature that > you can chain atoms together with dots, in the old times one had to > use quotes for host names. Sorry, I find that a terrible hack. It is one thing allowing a dot to be an atom character so you can write a.b.c without quoting, but it is another to special case it so it is only an atom character if it is followed by a lowercase letter. And having some sort of auto-concatenate if part of the atom is quoted. I just checked and you get: 9> a.'b'.c. 'a.b.c' 10> a.'b.'c. * 1: syntax error before: c 10> a'.b'c. * 1: syntax error before: '.b' 10> a.'.b'c. * 1: syntax error before: c 10> a.'.b'.c. * 1: bad module name 'a..b.c' 11> 'a'.'b'.c. 'a.b.c' 12> 'a''b'. * 1: syntax error before: b So it can only be used to quote parts of a dot separated sequence of atoms to build one atom. That is terrible! Robert From ufm@REDACTED Fri Oct 22 17:15:22 2010 From: ufm@REDACTED (Fyodor Ustinov) Date: Fri, 22 Oct 2010 18:15:22 +0300 Subject: Strange Message-ID: <4CC1AA8A.7030609@ufm.su> Erlang R14B (erts-5.8.1.1) [source] [rq:1] [async-threads:0] [kernel-poll:false] Eshell V5.8.1.1 (abort with ^G) 1> gen_server:call({global, 'nonexistent'}, aa). ** exception exit: {noproc,{gen_server,call,[{global,nonexistent},aa]}} in function gen_server:call/2 2> gen_server:cast({global, 'nonexistent'}, aa). ok 3> Why gen_server:cast return 'ok'? From spawn.think@REDACTED Fri Oct 22 17:26:51 2010 From: spawn.think@REDACTED (Ahmed Omar) Date: Fri, 22 Oct 2010 17:26:51 +0200 Subject: [erlang-bugs] Strange In-Reply-To: <4CC1AA8A.7030609@ufm.su> References: <4CC1AA8A.7030609@ufm.su> Message-ID: http://www.erlang.org/doc/man/gen_server.html#cast-2 Sends an asynchronous request to the gen_server ServerRef and *returns ok immediately, ignoring if the destination node or gen_server does not exist*. The gen_server will call Module:handle_cast/2 to handle the request On Fri, Oct 22, 2010 at 5:15 PM, Fyodor Ustinov wrote: > Erlang R14B (erts-5.8.1.1) [source] [rq:1] [async-threads:0] > [kernel-poll:false] > > Eshell V5.8.1.1 (abort with ^G) > 1> gen_server:call({global, 'nonexistent'}, aa). > ** exception exit: {noproc,{gen_server,call,[{global,nonexistent},aa]}} > in function gen_server:call/2 > 2> gen_server:cast({global, 'nonexistent'}, aa). > ok > 3> > > Why gen_server:cast return 'ok'? > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think From vicviq@REDACTED Sun Oct 24 01:44:45 2010 From: vicviq@REDACTED (viq) Date: Sun, 24 Oct 2010 01:44:45 +0200 Subject: configure --enable-ethread-pre-pentium4-compatibility does not properly enable ETHR_PRE_PENTIUM4_COMPAT on R14B Message-ID: I tried this both on linux and OpenBSD, and running configure --enable-ethread-pre-pentium4-compatibility does give us ./erts/configure:#define ETHR_PRE_PENTIUM4_COMPAT 1 but it is not defined so in the build directory, thus producing binaries that dump core on processors older than Pentium 4 with example command erl +A1 Both when trying to compile R14B from sources, flag (and issue) as per http://www.erlang.org/download/otp_src_R14B.readme referencing OTP-8544 -- viq From eric.pailleau@REDACTED Sun Oct 24 13:02:36 2010 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 24 Oct 2010 13:02:36 +0200 Subject: bug in string:copies when copying float times character Message-ID: <4CC4124C.9010609@wanadoo.fr> Hello, I found something weird, that can be considered as a bug. Here is below the documentation for string:copies function. --------------------------------------- copies(String, Number) -> Copies Types: String = Copies = string() Number = integer() --------------------------------------- Number should obviously be an integer, but it seems there no guards on the type. I forgot do round my copy number of characters, I got crashes, and I finally found the problem : by doing : -------------------------------------------------------------------- Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8 (abort with ^G) 1> string:copies("a",2.5). Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 1140328500 bytes of memory (of type "heap"). -------------------------------------------------------------------- Erlang try to allocate the whole memory when trying to copy any float number of characters. My computer is frozen a while, and reach hopefully to garbage . I got same behaviour in R13 and I did update to R14 in order to see if a fix was done. I guess an en exception 'badarith' or something else should be raised if integer is not used on such function. Best regards. From michael.santos@REDACTED Sun Oct 24 14:26:43 2010 From: michael.santos@REDACTED (Michael Santos) Date: Sun, 24 Oct 2010 08:26:43 -0400 Subject: [erlang-bugs] bug in string:copies when copying float times character In-Reply-To: <4CC4124C.9010609@wanadoo.fr> References: <4CC4124C.9010609@wanadoo.fr> Message-ID: <20101024122643.GA863@ecn.lan> On Sun, Oct 24, 2010 at 01:02:36PM +0200, PAILLEAU Eric wrote: > Number should obviously be an integer, but it seems there no > guards on the type. > > I forgot do round my copy number of characters, I got crashes, and I > finally found the problem : > > by doing : > -------------------------------------------------------------------- > Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.8 (abort with ^G) > 1> string:copies("a",2.5). > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 1140328500 bytes of memory (of type "heap"). > -------------------------------------------------------------------- string:copies/2 decrements to 0 with each copy. With a float, 0 will never be matched and the function goes into an infinite loop. Using your suggestion of a guard fixes it: 1> string:copies("a",2.5). ** exception error: no function clause matching string:copies("a",2.5) I'll send a patch to erlang-patches. diff --git a/lib/stdlib/src/string.erl b/lib/stdlib/src/string.erl index 6636a03..c987c22 100644 --- a/lib/stdlib/src/string.erl +++ b/lib/stdlib/src/string.erl @@ -202,5 +202,5 @@ chars(C, 0, Tail) when is_integer(C) -> -spec copies(string(), non_neg_integer()) -> string(). -copies(CharList, Num) when is_list(CharList), Num >= 0 -> +copies(CharList, Num) when is_list(CharList), is_integer(Num), Num >= 0 -> copies(CharList, Num, []). From sgolovan@REDACTED Wed Oct 27 08:06:33 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Wed, 27 Oct 2010 10:06:33 +0400 Subject: [erlang-bugs] Re: ODBC and net.ipv6.bindv6only In-Reply-To: <4CBC04F7.8060003@erix.ericsson.se> References: <4CBC04F7.8060003@erix.ericsson.se> Message-ID: Hi again! After loking into this bug more closely I've found that the disabled code (only for UNIX) does the following: it resolves "localhost" for all available IP-addresses (IPv4 and IPv6) and tries to connect to all of them sequentially (to the first success). The problem is that localhost may have only IPv4 IP-address associated with. In this case enabling IPv6 code will not fix the bug (though a local admin will be able to fix it himself by adding ::1 localhost to /etc/hosts). So, I'm suggesting the following: 1) prefer IPv4 in odbc:init/1 instead of IPv6. This makes sure that in all current environments ODBC will work (I'm not aware of anyone who has IPv4 disabled other that for testing). 2) enable IPv6 capable code in odbcserver.c, which will make things working if IPv6 is the only protocol (in this case it's very likely that localhost resolves into ::1 and doesn't require special attention). I'm attaching a simple patch which does the above changes. On Mon, Oct 18, 2010 at 12:27 PM, Ingela Anderton Andin wrote: > Hi! > > I think it should be fairly safe to enable it, I am sure we had a good > reason > for doing this once upon a time but ?now it ?feels ?somewhat ?strange to > have that hardcode and it does not agree with the rest of the code. > I will try removing it and see what happens. > > Regards ?Ingela Erlang/OTP team -Ericsson AB > > Sergei Golovan wrote: >> >> Hi again! >> >> It seems I've found why odbc doesn't work in IPv6-IPv4 environment when >> IPv6 >> sockets don't bind to IPv4 also. In odbcserver.c code I've found the >> following: >> >> #define USE_IPV4 >> #ifdef UNIX >> #define SOCKET int >> #endif >> >> #if defined WIN32 || defined USE_IPV4 >> /* Currently only an old windows compiler is supported so we do not have >> ipv6 >> ?capabilities */ >> static SOCKET connect_to_erlang(const char *port) >> { >> >> So, IPv6 capable code is just switched off. Is it safe to enable it? >> (Only connect_to_erlang function will change.) >> >> Cheers! >> > > -- Sergei Golovan -------------- next part -------------- A non-text attachment was scrubbed... Name: odbc.patch Type: application/octet-stream Size: 814 bytes Desc: not available URL: From emile@REDACTED Wed Oct 27 19:08:54 2010 From: emile@REDACTED (Emile Joubert) Date: Wed, 27 Oct 2010 18:08:54 +0100 Subject: escript empty arguments on windows Message-ID: <4CC85CA6.6060205@rabbitmq.com> There is a difference in the way escripts treats empty strings in the argument list on Windows and Unix. Under cygwin and cmd any "" parameters are stripped out and don't appear in the main(Args) list. The Unix version of escript preserves these as an empty list. This looks like a bug to me. Regards Emile From ingela@REDACTED Thu Oct 28 17:23:55 2010 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 28 Oct 2010 17:23:55 +0200 Subject: [erlang-bugs] Re: ODBC and net.ipv6.bindv6only In-Reply-To: References: <4CBC04F7.8060003@erix.ericsson.se> Message-ID: <4CC9958B.6010006@erix.ericsson.se> Hi! We decided not to solve it that way, as this code was written a long time ago when things where different from now, we decided on enabling ipv6 on windows and using loopback address constants to connect avoiding localhost resolution. I think this should work, will be available at github in the begining of next week if our tests goes well on all platforms. (Only tested on linux at the moment). Regards Ingela Erlang/OTP team - Ericsson AB Sergei Golovan wrote: > Hi again! > > After loking into this bug more closely I've found that the disabled > code (only for UNIX) does the following: it resolves "localhost" for > all available IP-addresses (IPv4 and IPv6) and tries to connect to all > of them sequentially (to the first success). > > The problem is that localhost may have only IPv4 IP-address associated > with. In this case enabling IPv6 code will not fix the bug (though a > local admin will be able to fix it himself by adding ::1 localhost to > /etc/hosts). > > So, I'm suggesting the following: > > 1) prefer IPv4 in odbc:init/1 instead of IPv6. This makes sure that in > all current environments ODBC will work (I'm not aware of anyone who > has IPv4 disabled other that for testing). > > 2) enable IPv6 capable code in odbcserver.c, which will make things > working if IPv6 is the only protocol (in this case it's very likely > that localhost resolves into ::1 and doesn't require special > attention). > > I'm attaching a simple patch which does the above changes. > > On Mon, Oct 18, 2010 at 12:27 PM, Ingela Anderton Andin > wrote: > >> Hi! >> >> I think it should be fairly safe to enable it, I am sure we had a good >> reason >> for doing this once upon a time but now it feels somewhat strange to >> have that hardcode and it does not agree with the rest of the code. >> I will try removing it and see what happens. >> >> Regards Ingela Erlang/OTP team -Ericsson AB >> >> Sergei Golovan wrote: >> >>> Hi again! >>> >>> It seems I've found why odbc doesn't work in IPv6-IPv4 environment when >>> IPv6 >>> sockets don't bind to IPv4 also. In odbcserver.c code I've found the >>> following: >>> >>> #define USE_IPV4 >>> #ifdef UNIX >>> #define SOCKET int >>> #endif >>> >>> #if defined WIN32 || defined USE_IPV4 >>> /* Currently only an old windows compiler is supported so we do not have >>> ipv6 >>> capabilities */ >>> static SOCKET connect_to_erlang(const char *port) >>> { >>> >>> So, IPv6 capable code is just switched off. Is it safe to enable it? >>> (Only connect_to_erlang function will change.) >>> >>> Cheers! >>> >>> >> > > > > > ------------------------------------------------------------------------ > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED From sgolovan@REDACTED Thu Oct 28 21:09:27 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Thu, 28 Oct 2010 23:09:27 +0400 Subject: [erlang-bugs] Re: ODBC and net.ipv6.bindv6only In-Reply-To: <4CC9958B.6010006@erix.ericsson.se> References: <4CBC04F7.8060003@erix.ericsson.se> <4CC9958B.6010006@erix.ericsson.se> Message-ID: On Thu, Oct 28, 2010 at 7:23 PM, Ingela Anderton Andin wrote: > Hi! > > We decided not to solve it that way, as this code was written ?a long time > ago when > things where different from now, we decided on enabling ipv6 on windows and > using loopback address constants to connect avoiding localhost resolution. > I think this should work, will be available at github in the begining of > next week > if our tests goes well on all platforms. (Only tested on linux at the > moment). Just don't forget that for now there still are systems without IPv6 support at all (some admins disable IPv6 for security reasons). So, a solution should work on such systems too. Cheers! -- Sergei Golovan From baggett.patrick@REDACTED Fri Oct 29 13:08:56 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 29 Oct 2010 06:08:56 -0500 Subject: ethread.h return in void function Message-ID: I started compiling Erlang R14B on IRIX 6.5 with the native system compilers and it stopped on line 760 of ethread.h, which is trying to return a value in a function that is declared to return void. Simple fix is to just remove "return". It looks like a copy-paste error. Any chance this could get patched for the next release? Obviously it isn't a high priority since it is a one-liner fix for a platform without any native atomic ops (yet). Patrick Baggett From baggett.patrick@REDACTED Fri Oct 29 14:50:24 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 29 Oct 2010 07:50:24 -0500 Subject: Compile errors in beam/io.c on IRIX Message-ID: Here's another problem I found when compiling beam/io.c for IRIX. Since The OpenGroup defines the struct iovec::iov_base field to be a void*, it is illegal to perform pointer arithmetic on it. I'm really surprised this didn't show up in GCC or any other compiler. Specifically, I get these errors. cc-3316 c99: ERROR File = beam/io.c, Line = 3343 The expression must be a pointer to a complete object type. iov->iov_base += skip; ^ cc-3316 c99: ERROR File = beam/io.c, Line = 3795 The expression must be a pointer to a complete object type. iov->iov_base += skip; ^ cc-3316 c99: ERROR File = beam/io.c, Line = 3858 The expression must be a pointer to a complete object type. iov->iov_base += skip; ^ cc-3316 c99: ERROR File = beam/io.c, Line = 3918 The expression must be a pointer to a complete object type. q->v_head->iov_base += size; ----- The implied goal here is to increment an address by a certain number of bytes, so casting to a char* as follows will allow the compile to succeed: iov->iov_base = (char*)iov->iov_base + skip; [I had sent a message a long time ago not being functional, but I was mistaken. Fortunately, it looks like nobody implemented what I said, so there isn't anything to revert.] From jesper.louis.andersen@REDACTED Fri Oct 29 15:21:51 2010 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 29 Oct 2010 15:21:51 +0200 Subject: [erlang-bugs] Compile errors in beam/io.c on IRIX In-Reply-To: References: Message-ID: On Fri, Oct 29, 2010 at 2:50 PM, Patrick Baggett wrote: > Here's another problem I found when compiling beam/io.c for IRIX. > Since The OpenGroup defines the struct iovec::iov_base field to be a > void*, it is illegal to perform pointer arithmetic on it. I'm really > surprised this didn't show up in GCC or any other compiler. Good catch! > ----- > The implied goal here is to increment an address by a certain number > of bytes, so casting to a char* as follows will allow the compile to > succeed: > > ? ? ? ? ? ?iov->iov_base = (char*)iov->iov_base + skip; > This change looks reasonable to me. I might be wrong, but I think this is what GCC is doing: assuming that void* aritmetic are 1-byte increments. If not, the code would probably not have worked as expected. I like the explicit behaviour. If Tuncer Ayaz or one of the Erlang/OTP devs does not change this into a topic branch, I'd happily volunteer to make it a topic branch on github. -- J. From jesper.louis.andersen@REDACTED Fri Oct 29 15:55:26 2010 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 29 Oct 2010 15:55:26 +0200 Subject: [erlang-bugs] Compile errors in beam/io.c on IRIX In-Reply-To: References: Message-ID: On Fri, Oct 29, 2010 at 3:21 PM, Jesper Louis Andersen wrote: > > This change looks reasonable to me. I might be wrong, but I think this > is what GCC is doing: assuming that void* aritmetic are 1-byte > increments. If not, the code would probably not have worked as > expected. I like the explicit behaviour. If Tuncer Ayaz or one of the > Erlang/OTP devs does not change this into a topic branch, I'd happily > volunteer to make it a topic branch on github. > It is a GCC extension, see http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Pointer-Arith.html#Pointer-Arith which really sets the size of the pointer to 1 byte (thus also enabling the use of sizeof() in the same vein). It can be made into a warning with -Wpointer-arith if so desired. Tuncer suggested that I go ahead, so unless you want to do it, ... -- J. From baggett.patrick@REDACTED Fri Oct 29 22:47:03 2010 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Fri, 29 Oct 2010 13:47:03 -0700 Subject: More void* arith errors Message-ID: Same deal as before, SGI IRIX 6.5 + native sys compilers. Spat at a few more cases where casting to char* is necessary for the build to continue. cc-3316 c99: ERROR File = drivers/unix/unix_efile.c, Line = 1070 The expression must be a pointer to a complete object type. w = write(fd, iov[cnt].iov_base + p, iov[cnt].iov_len - p); ^ cc-3316 c99: ERROR File = drivers/unix/unix_efile.c, Line = 1076 The expression must be a pointer to a complete object type. iov[cnt].iov_base += p; ^ cc-3316 c99: ERROR File = drivers/unix/unix_efile.c, Line = 1081 The expression must be a pointer to a complete object type. iov[cnt].iov_base -= p; ^ =============================== cc-3316 c99: ERROR File = drivers/common/efile_drv.c, Line = 1157 The expression must be a pointer to a complete object type. ev->iov[1 + c->cnt].iov_base + c->size, ^ cc-3316 c99: ERROR File = drivers/common/efile_drv.c, Line = 1433 The expression must be a pointer to a complete object type. iov[iovcnt].iov_base + p, cc-3316 c99: ERROR File = drivers/common/efile_drv.c, Line = 2965 The expression must be a pointer to a complete object type. put_int32(n, res_ev->iov[0].iov_base+4); Patrick Baggett