From peerst@REDACTED Sun May 1 13:22:50 2011 From: peerst@REDACTED (Peer Stritzinger) Date: Sun, 1 May 2011 13:22:50 +0200 Subject: [erlang-bugs] Dialyzer v2.2.0 crash Message-ID: When running dialyzer like: $ dialyzer --src -c codec_can.erl on the file codec_can.erl with the following contents (minimal code snippet that shows the error): -module(codec_can). -compile(export_all). -record(can_pkt, {id, data, timestamp}). -spec recv(<<_:64,_:_*8>>,fun((_) -> any()),atom() | pid() | {atom(),_}) -> any(). recv(Packet, Recv_fun, Chan) -> P = decode(Packet), #can_pkt{id=Can_id, data=Can_data}=P, Recv_fun(P). -spec decode(<<_:64,_:_*8>>) -> #can_pkt{id::<<_:11>>,data::binary(),timestamp::char()}. decode(<<_:12, Len:4, Timestamp:16, 0:3, Id:11/bitstring, 0:18, Data:Len/binary, _/binary>>) -> #can_pkt{id=Id, data=Data, timestamp=Timestamp}. I get the following error: $ dialyzer --src -c codec_can.erl Checking whether the PLT /home/peer/.dialyzer_plt is up-to-date... yes Proceeding with analysis... =ERROR REPORT==== 1-May-2011::13:08:13 === Error in process <0.30.0> with exit value: {{case_clause,8},[{erl_types,t_form_to_string,1},{erl_types,t_form_to_string,1},{dialyzer_contracts,contract_to_string_1,1},{dialyzer_contracts,extra_contract_warning,6},{dialyzer_contracts,picky_contract_check... dialyzer: Analysis failed with error: {{case_clause,8}, [{erl_types,t_form_to_string,1}, {erl_types,t_form_to_string,1}, {dialyzer_contracts,contract_to_string_1,1}, {dialyzer_contracts,extra_contract_warning,6}, {dialyzer_contracts,picky_contract_check,7}, {dialyzer_contracts,get_invalid_contract_warnings_funs,4}, {dialyzer_contracts,get_invalid_contract_warnings_modules,...}, {dialyzer_succ_typings,...}]} Last messages in the log cache: Reading files and computing callgraph... done in 0.27 secs Removing edges... done in 0.01 secs Typesig analysis for SCC: [{codec_can,module_info,1}] Typesig analysis for SCC: [{codec_can,decode,1}] Typesig analysis for SCC: [{codec_can,module_info,0}] Typesig analysis for SCC: [{codec_can,recv,3}] Dataflow of one SCC: [codec_can] I'm using dialyzer v2.2.0 from Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] I get a similar error in another file, I can try to reduce this file also and post it if it helps. Regards, Peer Stritzinger From kostis@REDACTED Sun May 1 16:49:07 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 01 May 2011 17:49:07 +0300 Subject: [erlang-bugs] Dialyzer v2.2.0 crash In-Reply-To: References: Message-ID: <4DBD72E3.1030307@cs.ntua.gr> Peer Stritzinger wrote: > When running dialyzer like: > > $ dialyzer --src -c codec_can.erl > > on the file codec_can.erl with the following contents (minimal code > snippet that shows the error): > > -module(codec_can). > -compile(export_all). > > -record(can_pkt, {id, data, timestamp}). > > -spec recv(<<_:64,_:_*8>>,fun((_) -> any()),atom() | pid() | > {atom(),_}) -> any(). > recv(Packet, Recv_fun, Chan) -> > P = decode(Packet), > #can_pkt{id=Can_id, data=Can_data}=P, > Recv_fun(P). > > -spec decode(<<_:64,_:_*8>>) -> > #can_pkt{id::<<_:11>>,data::binary(),timestamp::char()}. > decode(<<_:12, Len:4, Timestamp:16, > 0:3, Id:11/bitstring, 0:18, > Data:Len/binary, _/binary>>) -> > #can_pkt{id=Id, data=Data, timestamp=Timestamp}. > > I get the following error: > ... SNIP Thanks for your bug report! It's indeed an error in the processing of binary types generated by typer which are then fed back to dialyzer. I already have a patch ready that fixes this and will hopefully appear in OTP's dev branch pretty soon. If the other crash you get is in a function with a spec containing a type of the form <<_:N,_:_*M>>, don't bother minimizing the test case and sending a report. Otherwise, please do -- perhaps just to me. Kostis From peerst@REDACTED Sun May 1 17:38:43 2011 From: peerst@REDACTED (Peer Stritzinger) Date: Sun, 1 May 2011 17:38:43 +0200 Subject: [erlang-bugs] Dialyzer v2.2.0 crash In-Reply-To: <4DBD72E3.1030307@cs.ntua.gr> References: <4DBD72E3.1030307@cs.ntua.gr> Message-ID: On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas wrote: > Peer Stritzinger wrote: > Thanks for your bug report! ?It's indeed an error in the processing of > binary types generated by typer which are then fed back to dialyzer. ?I > already have a patch ready that fixes this and will hopefully appear in > OTP's dev branch pretty soon. Great! > If the other crash you get is in a function with a spec containing a type of > the form <<_:N,_:_*M>>, don't bother minimizing the test case and sending a > report. ?Otherwise, please do -- perhaps just to me. The other specs also contained this form, so its the same issue. BTW: is it normal not to get any warnings when just doing --annotate in typer and then dialyzer with no manually tweaked spec's (for details see http://stackoverflow.com/questions/5849335/run-of-dialyzer-after-annotation-with-typer-did-not-show-any-warnings)? From kostis@REDACTED Sun May 1 17:53:51 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 01 May 2011 18:53:51 +0300 Subject: [erlang-bugs] Dialyzer v2.2.0 crash In-Reply-To: References: <4DBD72E3.1030307@cs.ntua.gr> Message-ID: <4DBD820F.3070800@cs.ntua.gr> Peer Stritzinger wrote: > On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas wrote: >> Peer Stritzinger wrote: > > BTW: is it normal not to get any warnings when just doing --annotate > in typer and then dialyzer with no manually tweaked spec's Yes. In fact, typer is just a front end for dialyzer's basic type inference (i.e. without the warning identification component). IMO, there is very little point in doing this if you do not intend to manually "massage" the specs that you get and provide more info for some of them. Take a look at your previous program. The fact that the two <<_:64,_:_*8>> types were referring to the same quantity could be expressed better if you introduced a type as in: -type packet() :: <<_:64,_:_*8>>, Similarly for channel: -type channel() :: atom() | pid() |{atom(),_}. and then the spec would already look better. Also, dialyzer/typer has no info on what type of fun you intend to use in the second argument of function recv/3 but you do! From the code it is clear that it takes #can_pkt{} record, so why don't you add appropriate types to its fields and introduce a type for it? -record(can_pkt, {id :: id(), data :: binary(), timestamp :: ts()}). -type can_pkt() :: #can_pkt{}. then the specs can look much better: -spec recv(packet(), fun((can_pkt()) -> R), channel()) -> R. -spec decode(packet()) -> can_pkt(). and note that I've used a placeholder type variable R to denote the fact that function recv/2 returns whatever type the fun in its second argument returns. You probably know what this type is so you should also introduce a type for it and use its proper name. Hope this helps, Kostis PS. It's a pity you posted this in erlang-bugs as the information contained in the above is IMO more interesting than the actual bug. From kostis@REDACTED Mon May 2 09:21:42 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 02 May 2011 10:21:42 +0300 Subject: [erlang-bugs] Dialyzer v2.2.0 crash In-Reply-To: <4DBD72E3.1030307@cs.ntua.gr> References: <4DBD72E3.1030307@cs.ntua.gr> Message-ID: <4DBE5B86.4020403@cs.ntua.gr> Kostis Sagonas wrote: > Peer Stritzinger wrote: >> When running dialyzer like: >> >> ... >> >> I get the following error: >> ... SNIP > > Thanks for your bug report! It's indeed an error in the processing of > binary types generated by typer which are then fed back to dialyzer. I > already have a patch ready that fixes this and will hopefully appear in > OTP's dev branch pretty soon. Since I had already a branch open which was fixing some other issue in erl_types.erl, I've decided to use that branch for including those fixes too. I know it's not the proper way of doing things, but it's extremely cumbersome to maintain different versions of erl_types... The changes that fix these are here: git fetch git://github.com/kostis/otp.git list_to_bitstring The last commit fixes the issue reported by Peer. The previous commits refer to erlang:list_to_bitstring/1. Kostis From henrik@REDACTED Mon May 2 11:34:40 2011 From: henrik@REDACTED (Henrik Nord) Date: Mon, 2 May 2011 11:34:40 +0200 Subject: [erlang-bugs] [erlang-patches] Dialyzer v2.2.0 crash In-Reply-To: <4DBE5B86.4020403@cs.ntua.gr> References: <4DBD72E3.1030307@cs.ntua.gr> <4DBE5B86.4020403@cs.ntua.gr> Message-ID: <4DBE7AB0.1080307@erlang.org> On 05/02/2011 09:21 AM, Kostis Sagonas wrote: > Kostis Sagonas wrote: >> Peer Stritzinger wrote: >>> When running dialyzer like: >>> >>> ... >>> >>> I get the following error: >>> ... SNIP >> >> Thanks for your bug report! It's indeed an error in the processing >> of binary types generated by typer which are then fed back to >> dialyzer. I already have a patch ready that fixes this and will >> hopefully appear in OTP's dev branch pretty soon. > > Since I had already a branch open which was fixing some other issue in > erl_types.erl, I've decided to use that branch for including those > fixes too. I know it's not the proper way of doing things, but it's > extremely cumbersome to maintain different versions of erl_types... > > The changes that fix these are here: > > git fetch git://github.com/kostis/otp.git list_to_bitstring > > The last commit fixes the issue reported by Peer. > The previous commits refer to erlang:list_to_bitstring/1. > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hi I have included this branch into 'pu' If nothing breaks I aim for a swift graduation to 'dev' Thank you for the contribution -- /Henrik Nord Erlang/OTP From bob@REDACTED Tue May 3 02:20:46 2011 From: bob@REDACTED (Bob Ippolito) Date: Mon, 2 May 2011 17:20:46 -0700 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] Message-ID: I only see this error on Mac OS X. I have not been able to reproduce in Linux. Here's an example, any number larger than 16#7ffffffffffffe00 will cause this error. Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:4] [hipe] [kernel-poll:true] Eshell V5.8.3 (abort with ^G) 1> trunc(16#7ffffffffffffdff * 1.0). 9223372036854774784 2> trunc(16#7ffffffffffffdff * 1.0). 9223372036854774784 3> trunc(16#7ffffffffffffe00 * 1.0). 9223372036854775808 4> trunc(16#7ffffffffffffe00 * 1.0). ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at 0x19223372036854775808 5> trunc(16#7ffffffffffffe00 * 1.0). ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at 0x19223372036854775808 6> io:format("~s~n", [os:cmd("uname -a")]). Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Here's another example: Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:4] [hipe] [kernel-poll:true] Eshell V5.8.3 (abort with ^G) 1> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). 9223372036854775808 2> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at 0x19223372036854775808 3> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at 0x19223372036854775808 -bob From mikpe@REDACTED Tue May 3 10:04:57 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 3 May 2011 10:04:57 +0200 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: References: Message-ID: <19903.46889.761570.628729@pilspetsen.it.uu.se> Bob Ippolito writes: > I only see this error on Mac OS X. I have not been able to reproduce in Linux. > > Here's an example, any number larger than 16#7ffffffffffffe00 will > cause this error. > > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:4] [hipe] [kernel-poll:true] > > Eshell V5.8.3 (abort with ^G) > 1> trunc(16#7ffffffffffffdff * 1.0). > 9223372036854774784 > 2> trunc(16#7ffffffffffffdff * 1.0). > 9223372036854774784 > 3> trunc(16#7ffffffffffffe00 * 1.0). > 9223372036854775808 > 4> trunc(16#7ffffffffffffe00 * 1.0). > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > 0x19223372036854775808 > 5> trunc(16#7ffffffffffffe00 * 1.0). > ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > 0x19223372036854775808 > 6> io:format("~s~n", [os:cmd("uname -a")]). > Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 > 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 > > Here's another example: > > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:4] [hipe] [kernel-poll:true] > > Eshell V5.8.3 (abort with ^G) > 1> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > 9223372036854775808 > 2> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > 0x19223372036854775808 > 3> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > 0x19223372036854775808 It means that the code at 0x19223372036854775808 in the Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. Please attach gdb (or whatever debugger Darwin uses) to a running Erlang VM and disassemble the code at 0x19223372036854775808. We need to know the name of the enclosing function, and preferably also the actual instruction sequence that throws the FPE. If gdb can show the exact original source code line then that's even better. If this is in libc rather than the Erlang VM itself, then we need a call trace to identify which code in the VM called out to this FP-throwing code. For that you should probably plant a breakpoint at 0x19223372036854775808 and then evaluate one of those Erlang expressions above to trigger the FPE. From essen@REDACTED Tue May 3 15:40:50 2011 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 03 May 2011 15:40:50 +0200 Subject: [erlang-bugs] Specs missing or wrong in ssl, inet and gen_tcp Message-ID: <4DC005E2.8000501@dev-extend.eu> Hello, Just forwarding a few issues I've encountered with type specs in ssl, inet and gen_tcp. Hope you don't mind me sending all of them in a single email. I will try to send patches when I get some free time and would probably benefit from any comment you might make here. * https://github.com/erlang/otp/blob/dev/lib/ssl/src/ssl.erl * socketoption() is incomplete: it can also accept atoms like binary, list, inet6 or inet and also other kinds of tuples * socketoption() should probably depend on types defined in gen_tcp and inet * option() is defined as socketoption()|ssloption()|transportoption(), problem is socketoption() is defined as a list of options while others are tuples; socketoption() should be tuples too * https://github.com/erlang/otp/blob/dev/lib/kernel/src/gen_tcp.erl * no specs at all, any plans on writing them? if not, any advice? * https://github.com/erlang/otp/blob/dev/lib/kernel/src/inet.erl#L109 * I'm assuming 'mode' is 'list' | 'binary' and not list() | binary() Thanks. -- Lo?c Hoguin Dev:Extend From bob@REDACTED Tue May 3 16:18:34 2011 From: bob@REDACTED (Bob Ippolito) Date: Tue, 3 May 2011 07:18:34 -0700 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: <19903.46889.761570.628729@pilspetsen.it.uu.se> References: <19903.46889.761570.628729@pilspetsen.it.uu.se> Message-ID: On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson wrote: > Bob Ippolito writes: > ?> I only see this error on Mac OS X. I have not been able to reproduce in Linux. > ?> > ?> Here's an example, any number larger than 16#7ffffffffffffe00 will > ?> cause this error. > ?> > ?> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > ?> [async-threads:4] [hipe] [kernel-poll:true] > ?> > ?> Eshell V5.8.3 ?(abort with ^G) > ?> 1> trunc(16#7ffffffffffffdff * 1.0). > ?> 9223372036854774784 > ?> 2> trunc(16#7ffffffffffffdff * 1.0). > ?> 9223372036854774784 > ?> 3> trunc(16#7ffffffffffffe00 * 1.0). > ?> 9223372036854775808 > ?> 4> trunc(16#7ffffffffffffe00 * 1.0). > ?> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > ?> 0x19223372036854775808 > ?> 5> trunc(16#7ffffffffffffe00 * 1.0). > ?> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > ?> 0x19223372036854775808 > ?> 6> io:format("~s~n", [os:cmd("uname -a")]). > ?> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 > ?> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 > ?> > ?> Here's another example: > ?> > ?> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > ?> [async-threads:4] [hipe] [kernel-poll:true] > ?> > ?> Eshell V5.8.3 ?(abort with ^G) > ?> 1> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > ?> 9223372036854775808 > ?> 2> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > ?> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > ?> 0x19223372036854775808 > ?> 3> <> = <<67,224,0,0,0,0,0,0>>, trunc(F). > ?> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > ?> 0x19223372036854775808 > > It means that the code at 0x19223372036854775808 in the > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. > > Please attach gdb (or whatever debugger Darwin uses) to a running > Erlang VM and disassemble the code at 0x19223372036854775808. > We need to know the name of the enclosing function, and preferably > also the actual instruction sequence that throws the FPE. If gdb > can show the exact original source code line then that's even better. > > If this is in libc rather than the Erlang VM itself, then we need > a call trace to identify which code in the VM called out to this > FP-throwing code. ?For that you should probably plant a breakpoint > at 0x19223372036854775808 and then evaluate one of those Erlang > expressions above to trigger the FPE. > Well, it's actually saying 0x1, the result of the trunc is 9223372036854775808 and the message string is truncated to 64 characters which is not enough to show it all. Perhaps the buffer size in erts_fp_check_init_error should be adjusted. My gdb skills are very rusty, let me know if you need anything else (and how to get it). (gdb) attach 36833 Attaching to process 36833. Reading symbols for shared libraries . done Reading symbols for shared libraries ...... done 0x00007fff87605e52 in select$DARWIN_EXTSN () (gdb) b erts_fp_check_init_error Breakpoint 1 at 0x101209f7: file sys/unix/sys_float.c, line 87. (gdb) c Continuing. [Switching to process 36833] Breakpoint 1, erts_fp_check_init_error (fpexnp=0x110f2528) at sys/unix/sys_float.c:87 87 { (gdb) p (void*)*fpexnp $1 = (void *) 0x10025433 And in another attach (I don't know how to get gdb out of the state where it's telling me there's an EXC_ARITHMETIC which I guess is SIGFPE): (gdb) break *0x10025433 Breakpoint 1 at 0x10025433: file beam/erl_bif_guard.c, line 301. (gdb) c Continuing. [Switching to process 36833] Breakpoint 1, double_to_integer [inlined] () at /Users/bob/src/otp_src_R14B02/erts/emulator/beam/erl_bif_guard.c:301 301 d = x; /* trunc */ (gdb) list 296 297 for (i = ds-1; i >= 0; i--) { 298 ErtsDigit d; 299 300 x *= dbase; /* "shift" left */ 301 d = x; /* trunc */ 302 xp[i] = d; /* store digit */ 303 x -= d; /* remove integer part */ 304 } 305 while ((ds & (BIG_DIGITS_PER_WORD-1)) != 0) { (gdb) disassemble Dump of assembler code for function trunc_1: 0x00000000100252c0 : mov %rbx,-0x20(%rsp) 0x00000000100252c5 : mov %rbp,-0x18(%rsp) 0x00000000100252ca : mov %r12,-0x10(%rsp) 0x00000000100252cf : mov %r13,-0x8(%rsp) 0x00000000100252d4 : sub $0x38,%rsp 0x00000000100252d8 : mov %rdi,%rbx 0x00000000100252db : mov %esi,%edx 0x00000000100252dd : and $0x1,%edx 0x00000000100252e0 : jne 0x100252e9 0x00000000100252e2 : cmpq $0x58,-0x2(%rsi) 0x00000000100252e7 : je 0x10025340 0x00000000100252e9 : mov %rsi,%rax 0x00000000100252ec : and $0xf,%eax 0x00000000100252ef : cmp $0xf,%rax 0x00000000100252f3 : je 0x10025306 0x00000000100252f5 : test %edx,%edx 0x00000000100252f7 : je 0x10025330 0x00000000100252f9 : movq $0x350,0x148(%rbx) 0x0000000010025304 : xor %esi,%esi 0x0000000010025306 : mov %rsi,%rax 0x0000000010025309 : mov 0x18(%rsp),%rbx 0x000000001002530e : mov 0x20(%rsp),%rbp 0x0000000010025313 : mov 0x28(%rsp),%r12 0x0000000010025318 : mov 0x30(%rsp),%r13 0x000000001002531d : add $0x38,%rsp 0x0000000010025321 : retq 0x0000000010025322 : nopl 0x0(%rax) 0x0000000010025329 : nopl 0x0(%rax) 0x0000000010025330 : mov -0x2(%rsi),%rax 0x0000000010025334 : and $0x3b,%eax 0x0000000010025337 : cmp $0x8,%rax 0x000000001002533b : jne 0x100252f9 0x000000001002533d : jmp 0x10025306 0x000000001002533f : nop 0x0000000010025340 : movq 0x6(%rsi),%xmm0 0x0000000010025345 : xorpd %xmm1,%xmm1 0x0000000010025349 : ucomisd %xmm1,%xmm0 0x000000001002534d : jb 0x100254cb 0x0000000010025353 : callq 0x1018777a 0x0000000010025358 : movapd %xmm0,%xmm1 0x000000001002535c : ucomisd 0x172d6c(%rip),%xmm1 # 0x101980d0 0x0000000010025364 : jae 0x10025376 0x0000000010025366 : jp 0x10025376 0x0000000010025368 : ucomisd 0x172d68(%rip),%xmm1 # 0x101980d8 0x0000000010025370 : ja 0x1002549a 0x0000000010025376 : xor %r13d,%r13d 0x0000000010025379 : xorpd %xmm0,%xmm0 0x000000001002537d : ucomisd %xmm0,%xmm1 0x0000000010025381 : jb 0x100254d9 0x0000000010025387 : movsd 0x172d51(%rip),%xmm2 # 0x101980e0 0x000000001002538f : mov $0x1,%r12d 0x0000000010025395 : mov $0xffffffff,%ebp 0x000000001002539a : ucomisd %xmm2,%xmm1 0x000000001002539e : jb 0x100253c5 0x00000000100253a0 : xor %ecx,%ecx 0x00000000100253a2 : movsd 0x172d3e(%rip),%xmm0 # 0x101980e8 0x00000000100253aa : nopw 0x0(%rax,%rax,1) 0x00000000100253b0 : mulsd %xmm0,%xmm1 0x00000000100253b4 : inc %ecx 0x00000000100253b6 : ucomisd %xmm2,%xmm1 0x00000000100253ba : jae 0x100253b0 0x00000000100253bc : lea 0x1(%rcx),%eax 0x00000000100253bf : movslq %eax,%r12 0x00000000100253c2 : lea -0x1(%rcx),%ebp 0x00000000100253c5 : mov (%rbx),%rcx 0x00000000100253c8 : mov 0x8(%rbx),%rax 0x00000000100253cc : sub %rcx,%rax 0x00000000100253cf : sar $0x3,%rax 0x00000000100253d3 : cmp %r12,%rax 0x00000000100253d6 : jb 0x100254ac 0x00000000100253dc : lea 0x0(,%r12,8),%rdx 0x00000000100253e4 : lea (%rcx,%rdx,1),%rax 0x00000000100253e8 : mov %rax,(%rbx) 0x00000000100253eb : mov %rax,%rdi 0x00000000100253ee : sub %rdx,%rdi 0x00000000100253f1 : lea 0x2(%rdi),%rsi 0x00000000100253f5 : test %ebp,%ebp 0x00000000100253f7 : js 0x10025473 0x00000000100253f9 : movslq %ebp,%rax 0x00000000100253fc : lea (%rdi,%rax,8),%rcx 0x0000000010025400 : movsd 0x172ce8(%rip),%xmm3 # 0x101980f0 0x0000000010025408 : movsd 0x172ce8(%rip),%xmm2 # 0x101980f8 0x0000000010025410 : mov $0x8000000000000000,%r8 0x000000001002541a : jmp 0x1002542f 0x000000001002541c : nopl 0x0(%rax) 0x0000000010025420 : subsd %xmm0,%xmm1 0x0000000010025424 : dec %ebp 0x0000000010025426 : sub $0x8,%rcx 0x000000001002542a : cmp $0xffffffffffffffff,%ebp 0x000000001002542d : je 0x10025473 0x000000001002542f : mulsd %xmm3,%xmm1 0x0000000010025433 : cvttsd2siq %xmm1,%rdx 0x0000000010025438 : ucomisd %xmm2,%xmm1 0x000000001002543c : jb 0x1002544e 0x000000001002543e : movapd %xmm1,%xmm0 0x0000000010025442 : subsd %xmm2,%xmm0 0x0000000010025446 : cvttsd2siq %xmm0,%rdx 0x000000001002544b : xor %r8,%rdx 0x000000001002544e : mov %rdx,0x8(%rcx) 0x0000000010025452 : cvtsi2sdq %rdx,%xmm0 0x0000000010025457 : test %rdx,%rdx 0x000000001002545a : jns 0x10025420 0x000000001002545c : mov %rdx,%rax 0x000000001002545f : shr %rax 0x0000000010025462 : and $0x1,%edx 0x0000000010025465 : or %rdx,%rax 0x0000000010025468 : cvtsi2sdq %rax,%xmm0 0x000000001002546d : addsd %xmm0,%xmm0 0x0000000010025471 : jmp 0x10025420 0x0000000010025473 : test %r13d,%r13d 0x0000000010025476 : je 0x10025489 0x0000000010025478 : shl $0x6,%r12 0x000000001002547c : lea -0x34(%r12),%rax 0x0000000010025481 : mov %rax,(%rdi) 0x0000000010025484 : jmpq 0x10025306 0x0000000010025489 : shl $0x6,%r12 0x000000001002548d : lea -0x38(%r12),%rax 0x0000000010025492 : mov %rax,(%rdi) 0x0000000010025495 : jmpq 0x10025306 0x000000001002549a : cvttsd2siq %xmm1,%rax 0x000000001002549f : shl $0x4,%rax 0x00000000100254a3 : lea 0xf(%rax),%rsi 0x00000000100254a7 : jmpq 0x10025306 0x00000000100254ac : xor %edx,%edx 0x00000000100254ae : mov %r12,%rsi 0x00000000100254b1 : mov %rbx,%rdi 0x00000000100254b4 : movsd %xmm1,(%rsp) 0x00000000100254b9 : callq 0x1004cc40 0x00000000100254be : mov %rax,%rdi 0x00000000100254c1 : movsd (%rsp),%xmm1 0x00000000100254c6 : jmpq 0x100253f1 0x00000000100254cb : callq 0x101876f0 0x00000000100254d0 : movapd %xmm0,%xmm1 0x00000000100254d4 : jmpq 0x1002535c 0x00000000100254d9 : xorpd 0x172c2f(%rip),%xmm1 # 0x10198110 0x00000000100254e1 : mov $0x1,%r13b 0x00000000100254e4 : jmpq 0x10025387 End of assembler dump. -bob From jay@REDACTED Tue May 3 17:07:55 2011 From: jay@REDACTED (Jay Nelson) Date: Tue, 3 May 2011 08:07:55 -0700 Subject: [erlang-bugs] Reltool and code clash Message-ID: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> I may have more info on this. It seems to be a reltool bug. I don't have a simple case, but I discovered the problem using rebar in conjunction with a tsung installation (which doesn't use rebar and instead installs itself into the erlang lib directory). We customized tsung by adding protobuffs and a new module as dependencies of the .app file. When we use rebar to generate the app (which relies on reltool to do the work), reltool crashes because some dependencies in tsung are in the wrong directory (tsung, rather than in tsung_controller) in the /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to generate the app. To avoid this problem, we instruct reltool to ignore the apps in the erlang directory: {app, tsung, [{incl_cond, exclude}]}, {app, tsung_recorder, [{incl_cond, exclude}]}, {app, tsung_controller, [{incl_cond, exclude}]} And the dependency that we created by customizing tsung gets excluded even though it is included explicitly as a separate app: {app, my_shared_lib, [{incl_cond, include}]}, There are two issues: 1) tsung is releasing 3 applications and I believe the module dependencies are incomplete or incorrect. [Not an erlang issue, the tsung guys need to fix this one] 2) reltool does not handle include + exclude of an app dependency [This is the simple case you need to create] To recreate the problem simply, you need 3 apps (in this case, C is an included application that is just a standalone library of a single module, whereas A and B are executable apps): A => relies on C B => relies on C Create a reltool spec that excludes A but includes B. You will find the release area contains C.app but no C.beam files. It doesn't matter which of A or B is excluded as long as the other one is included, you should see the same results. I am not sure, but I don't think it matters if C is listed as an application or as an included_application. Hope this helps! Feel free to ask more questions. We are working around it by just copying the beams into place as a separate step in the Makefile. Everything else seems to work. jay From jay@REDACTED Tue May 3 17:08:39 2011 From: jay@REDACTED (Jay Nelson) Date: Tue, 3 May 2011 08:08:39 -0700 Subject: [erlang-bugs] Dialyzer bug with binary:compile_pattern/1 Message-ID: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> The following snippet of code gives a dialyzer error: NL = list_to_binary(io_lib:nl()), LinesPattern = binary:compile_pattern(NL), Lines = [Line || Line <- binary:split(Bin, LinesPattern, [global, trim]), size(Line) > 0], The call binary:split(Bin::binary(),LinesPattern::{'bm',binary()},['global' | 'trim',...]) will never return since it differs in the 2nd argument from the success typing arguments: (binary(),binary() | [binary()] | {'cp',binary()},['global' | 'trim' | {'scope',{_,_}}]) If the LinesPattern in the list comprehension is changed to NL, then there is no error. It seems the return value of binary:compile_pattern/1 is not compatible with the call to binary:split/3. jay From spawn.think@REDACTED Tue May 3 17:38:55 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 3 May 2011 17:38:55 +0200 Subject: [erlang-bugs] Dialyzer bug with binary:compile_pattern/1 In-Reply-To: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> References: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> Message-ID: I don't think this is a bug in dialyzer. binary:compile_patter returns cp() not binary() so the warning is correct On Tue, May 3, 2011 at 5:08 PM, Jay Nelson wrote: > The following snippet of code gives a dialyzer error: > > NL = list_to_binary(io_lib:nl()), > LinesPattern = binary:compile_pattern(NL), > Lines = [Line || Line <- binary:split(Bin, LinesPattern, [global, trim]), > size(Line) > 0], > > The call binary:split(Bin::binary(),LinesPattern::{'bm',binary()},['global' > | 'trim',...]) will never return since it differs in the 2nd argument from > the success typing arguments: (binary(),binary() | [binary()] | > {'cp',binary()},['global' | 'trim' | {'scope',{_,_}}]) > > If the LinesPattern in the list comprehension is changed to NL, then there > is no error. > > It seems the return value of binary:compile_pattern/1 is not compatible > with the call to binary:split/3. > > jay > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue May 3 17:45:27 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 3 May 2011 17:45:27 +0200 Subject: [erlang-bugs] Dialyzer bug with binary:compile_pattern/1 In-Reply-To: References: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> Message-ID: the return from binary:compile_pattern is {'bm',binary()} , while split is expecting either binary() or {'cp', binary()} I think the function compile_patters is the one to blame here cause in the documentation it's said to return cp(), but i didn't digg into the module On Tue, May 3, 2011 at 5:38 PM, Ahmed Omar wrote: > I don't think this is a bug in dialyzer. binary:compile_patter returns cp() > not binary() > so the warning is correct > > > On Tue, May 3, 2011 at 5:08 PM, Jay Nelson wrote: > >> The following snippet of code gives a dialyzer error: >> >> NL = list_to_binary(io_lib:nl()), >> LinesPattern = binary:compile_pattern(NL), >> Lines = [Line || Line <- binary:split(Bin, LinesPattern, [global, >> trim]), >> size(Line) > 0], >> >> The call >> binary:split(Bin::binary(),LinesPattern::{'bm',binary()},['global' | >> 'trim',...]) will never return since it differs in the 2nd argument from the >> success typing arguments: (binary(),binary() | [binary()] | >> {'cp',binary()},['global' | 'trim' | {'scope',{_,_}}]) >> >> If the LinesPattern in the list comprehension is changed to NL, then there >> is no error. >> >> It seems the return value of binary:compile_pattern/1 is not compatible >> with the call to binary:split/3. >> >> jay >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Tue May 3 18:09:47 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 03 May 2011 19:09:47 +0300 Subject: [erlang-bugs] Dialyzer bug with binary:compile_pattern/1 In-Reply-To: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> References: <0A70E6C9-B3D6-45DD-9456-DB3E05333F63@duomark.com> Message-ID: <4DC028CB.7040200@cs.ntua.gr> Jay Nelson wrote: > The following snippet of code gives a dialyzer error: > > NL = list_to_binary(io_lib:nl()), > LinesPattern = binary:compile_pattern(NL), > Lines = [Line || Line <- binary:split(Bin, LinesPattern, [global, trim]), > size(Line) > 0], > > The call binary:split(Bin::binary(),LinesPattern::{'bm',binary()},['global' | 'trim',...]) will never return since it differs in the 2nd argument from the success typing arguments: (binary(),binary() | [binary()] | {'cp',binary()},['global' | 'trim' | {'scope',{_,_}}]) > > If the LinesPattern in the list comprehension is changed to NL, then there is no error. > > It seems the return value of binary:compile_pattern/1 is not compatible with the call to binary:split/3. Well, It's definitely not a dialyzer bug, meaning it has nothing to do with dialyzer's analysis, but something indeed seems wrong there... The published Erlang/OTP documentation mentions that the second argument of binary:split/3 is: Pattern = binary() | [ binary() ] | cp() where cp(): Opaque data-type representing a compiled search-pattern. Guaranteed to be a tuple() ... The developer who wrote the 'binary' module added the following as the hard-coded type information for the above in erl_bif_types.erl: t_binary_pattern() -> t_sup([t_binary(), t_list(t_binary()), t_binary_compiled_pattern()]). t_binary_compiled_pattern() -> t_tuple([t_atom('cp'), t_binary()]). On the other hand, strangely the return of binary:compile_pattern/1 does not use this type but instead specifies that the return is: type(binary, compile_pattern, 1, Xs) -> strict(arg_types(binary, compile_pattern, 1), Xs, fun(_) -> t_tuple([t_atom(bm),t_binary()]) end); i.e. a pair tagged with the atom 'bm' (as it actually is). I have no idea whether the 'cp' atom there in the definition of t_binary_compiled_pattern() should read 'bm', whether a 'bm' tagged pair should be added to the list of binary_compiled_patterns or whether this is intentional... The responsible person at OTP who added this type information should answer this (and possibly fix). But I suspect that the proper fix here is to change: t_binary_compiled_pattern() -> t_tuple([t_atom('bm'), t_binary()]). and then use this type in: type(binary, compile_pattern, 1, Xs) -> strict(arg_types(binary, compile_pattern, 1), Xs, fun(_) -> t_binary_compiled_pattern() end); Oh, probably this should also be declared as opaque. Right? Kostis From mikpe@REDACTED Wed May 4 00:35:32 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 4 May 2011 00:35:32 +0200 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: References: <19903.46889.761570.628729@pilspetsen.it.uu.se> Message-ID: <19904.33588.924591.882382@pilspetsen.it.uu.se> On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito wrote: > On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson wrote: > > Bob Ippolito writes: > > =C2=A0> I only see this error on Mac OS X. I have not been able to reprod= > uce in Linux. > > =C2=A0> > > =C2=A0> Here's an example, any number larger than 16#7ffffffffffffe00 wil= > l > > =C2=A0> cause this error. > > =C2=A0> > > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true] > > =C2=A0> > > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G) > > =C2=A0> 1> trunc(16#7ffffffffffffdff * 1.0). > > =C2=A0> 9223372036854774784 > > =C2=A0> 2> trunc(16#7ffffffffffffdff * 1.0). > > =C2=A0> 9223372036854774784 > > =C2=A0> 3> trunc(16#7ffffffffffffe00 * 1.0). > > =C2=A0> 9223372036854775808 > > =C2=A0> 4> trunc(16#7ffffffffffffe00 * 1.0). > > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > > =C2=A0> 0x19223372036854775808 > > =C2=A0> 5> trunc(16#7ffffffffffffe00 * 1.0). > > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at > > =C2=A0> 0x19223372036854775808 > > =C2=A0> 6> io:format("~s~n", [os:cmd("uname -a")]). > > =C2=A0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 > > =C2=A0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 > > =C2=A0> > > =C2=A0> Here's another example: > > =C2=A0> > > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] > > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true] > > =C2=A0> > > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G) > > =C2=A0> 1> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). > > =C2=A0> 9223372036854775808 > > =C2=A0> 2> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). > > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > > =C2=A0> 0x19223372036854775808 > > =C2=A0> 3> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). > > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at > > =C2=A0> 0x19223372036854775808 > > > > It means that the code at 0x19223372036854775808 in the > > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. > > > > Please attach gdb (or whatever debugger Darwin uses) to a running > > Erlang VM and disassemble the code at 0x19223372036854775808. > > We need to know the name of the enclosing function, and preferably > > also the actual instruction sequence that throws the FPE. If gdb > > can show the exact original source code line then that's even better. > > > > If this is in libc rather than the Erlang VM itself, then we need > > a call trace to identify which code in the VM called out to this > > FP-throwing code. =C2=A0For that you should probably plant a breakpoint > > at 0x19223372036854775808 and then evaluate one of those Erlang > > expressions above to trigger the FPE. > > > > Well, it's actually saying 0x1, the result of the trunc is > 9223372036854775808 and the message string is truncated to 64 > characters which is not enough to show it all. Perhaps the buffer size > in erts_fp_check_init_error should be adjusted. Something in your terminal or email client ate a \r\n sequence after the 0x1 from erts_fp_check_init_error() making it appear glued together with the 9223372036854775808 that the erlang prompt printed. That 0x1 means that the #ifdef tests in erts/emulator/sys/unix/sys_float.c failed to enable the proper sigaction-style SIGFPE handler in your Erlang VM build, and instead fell back to a very primitive plain SIGFPE handler. If you run gdb or objdump on your Erlang VM (the beam.smp executable not the erl frontend) I bet you won't find an fpe_sig_action() function but a smallish fpe_sig_handler() one instead. The machine-specific fpe_sig_action() handler is absolutely mandatory for reliable FP exceptions. The bug then is that the C compiler on your Mac OS X didn't set up the proper preprocessor symbols so that the sigaction-style handler could be enabled. What does `gcc -E -dM -xc /dev/null | sort' say? (For 'gcc' substitute whatever compiler and extra compiler options you used to build Erlang.) /Mikael From bob@REDACTED Wed May 4 01:48:20 2011 From: bob@REDACTED (Bob Ippolito) Date: Tue, 3 May 2011 16:48:20 -0700 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: <19904.33588.924591.882382@pilspetsen.it.uu.se> References: <19903.46889.761570.628729@pilspetsen.it.uu.se> <19904.33588.924591.882382@pilspetsen.it.uu.se> Message-ID: On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson wrote: > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito wrote: >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson wrote: >> > Bob Ippolito writes: >> > =C2=A0> I only see this error on Mac OS X. I have not been able to reprod= >> uce in Linux. >> > =C2=A0> >> > =C2=A0> Here's an example, any number larger than 16#7ffffffffffffe00 wil= >> l >> > =C2=A0> cause this error. >> > =C2=A0> >> > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] >> > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true] >> > =C2=A0> >> > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G) >> > =C2=A0> 1> trunc(16#7ffffffffffffdff * 1.0). >> > =C2=A0> 9223372036854774784 >> > =C2=A0> 2> trunc(16#7ffffffffffffdff * 1.0). >> > =C2=A0> 9223372036854774784 >> > =C2=A0> 3> trunc(16#7ffffffffffffe00 * 1.0). >> > =C2=A0> 9223372036854775808 >> > =C2=A0> 4> trunc(16#7ffffffffffffe00 * 1.0). >> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at >> > =C2=A0> 0x19223372036854775808 >> > =C2=A0> 5> trunc(16#7ffffffffffffe00 * 1.0). >> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE at >> > =C2=A0> 0x19223372036854775808 >> > =C2=A0> 6> io:format("~s~n", [os:cmd("uname -a")]). >> > =C2=A0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 >> > =C2=A0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 >> > =C2=A0> >> > =C2=A0> Here's another example: >> > =C2=A0> >> > =C2=A0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq:4] >> > =C2=A0> [async-threads:4] [hipe] [kernel-poll:true] >> > =C2=A0> >> > =C2=A0> Eshell V5.8.3 =C2=A0(abort with ^G) >> > =C2=A0> 1> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> > =C2=A0> 9223372036854775808 >> > =C2=A0> 2> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at >> > =C2=A0> 0x19223372036854775808 >> > =C2=A0> 3> <> =3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> > =C2=A0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE at >> > =C2=A0> 0x19223372036854775808 >> > >> > It means that the code at 0x19223372036854775808 in the >> > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. >> > >> > Please attach gdb (or whatever debugger Darwin uses) to a running >> > Erlang VM and disassemble the code at 0x19223372036854775808. >> > We need to know the name of the enclosing function, and preferably >> > also the actual instruction sequence that throws the FPE. If gdb >> > can show the exact original source code line then that's even better. >> > >> > If this is in libc rather than the Erlang VM itself, then we need >> > a call trace to identify which code in the VM called out to this >> > FP-throwing code. =C2=A0For that you should probably plant a breakpoint >> > at 0x19223372036854775808 and then evaluate one of those Erlang >> > expressions above to trigger the FPE. >> > >> >> Well, it's actually saying 0x1, the result of the trunc is >> 9223372036854775808 ?and the message string is truncated to 64 >> characters which is not enough to show it all. Perhaps the buffer size >> in erts_fp_check_init_error should be adjusted. > > Something in your terminal or email client ate a \r\n sequence after the > 0x1 from erts_fp_check_init_error() making it appear glued together with > the 9223372036854775808 that the erlang prompt printed. Not my terminal or email client, this is a bug in erts_fp_check_init_error. It only allocates a 64 byte buffer for the error message. The pointer address and the \r\n are eaten because the buffer is too small to fit the whole error message. buf[64] is too small... the format string itself is already 57 chars (including the NULL). void erts_fp_check_init_error(volatile unsigned long *fpexnp) { char buf[64]; snprintf(buf, sizeof buf, "ERTS_FP_CHECK_INIT at %p: detected unhandled FPE at %p\r\n", __builtin_return_address(0), (void*)*fpexnp); > That 0x1 means that the #ifdef tests in erts/emulator/sys/unix/sys_float.c > failed to enable the proper sigaction-style SIGFPE handler in your Erlang > VM build, and instead fell back to a very primitive plain SIGFPE handler. > If you run gdb or objdump on your Erlang VM (the beam.smp executable not > the erl frontend) I bet you won't find an fpe_sig_action() function but > a smallish fpe_sig_handler() one instead. > > The machine-specific fpe_sig_action() handler is absolutely mandatory for > reliable FP exceptions. Maybe you missed it in my previous email, it's not 0x1, it is 0x10025433. I showed that by breaking at the function that prints the error. Breakpoint 1, erts_fp_check_init_error (fpexnp=0x110f2528) at sys/unix/sys_float.c:87 87 { (gdb) p (void*)*fpexnp $1 = (void *) 0x10025433 There is a fpe_sig_action, and no fpe_sig_handler. $ gdb beam.smp GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done (gdb) list fpe_sig_action 523 #elif defined(__sun__) && defined(__x86_64__) 524 #define mc_pc(mc) ((mc)->gregs[REG_RIP]) 525 #endif 526 527 static void fpe_sig_action(int sig, siginfo_t *si, void *puc) 528 { 529 ucontext_t *uc = puc; 530 unsigned long pc; 531 532 #if defined(__linux__) (gdb) list fpe_sig_handler Function "fpe_sig_handler" not defined. > The bug then is that the C compiler on your Mac OS X didn't set up the > proper preprocessor symbols so that the sigaction-style handler could > be enabled. > > What does `gcc -E -dM -xc /dev/null | sort' say? (For 'gcc' substitute > whatever compiler and extra compiler options you used to build Erlang.) #define OBJC_NEW_PROPERTIES 1 #define _LP64 1 #define __APPLE_CC__ 5664 #define __APPLE__ 1 #define __BLOCKS__ 1 #define __CHAR_BIT__ 8 #define __CONSTANT_CFSTRINGS__ 1 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __DBL_DIG__ 15 #define __DBL_EPSILON__ 2.2204460492503131e-16 #define __DBL_HAS_DENORM__ 1 #define __DBL_HAS_INFINITY__ 1 #define __DBL_HAS_QUIET_NAN__ 1 #define __DBL_MANT_DIG__ 53 #define __DBL_MAX_10_EXP__ 308 #define __DBL_MAX_EXP__ 1024 #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_MIN_10_EXP__ (-307) #define __DBL_MIN_EXP__ (-1021) #define __DBL_MIN__ 2.2250738585072014e-308 #define __DEC128_DEN__ 0.000000000000000000000000000000001E-6143DL #define __DEC128_EPSILON__ 1E-33DL #define __DEC128_MANT_DIG__ 34 #define __DEC128_MAX_EXP__ 6144 #define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL #define __DEC128_MIN_EXP__ (-6143) #define __DEC128_MIN__ 1E-6143DL #define __DEC32_DEN__ 0.000001E-95DF #define __DEC32_EPSILON__ 1E-6DF #define __DEC32_MANT_DIG__ 7 #define __DEC32_MAX_EXP__ 96 #define __DEC32_MAX__ 9.999999E96DF #define __DEC32_MIN_EXP__ (-95) #define __DEC32_MIN__ 1E-95DF #define __DEC64_DEN__ 0.000000000000001E-383DD #define __DEC64_EPSILON__ 1E-15DD #define __DEC64_MANT_DIG__ 16 #define __DEC64_MAX_EXP__ 384 #define __DEC64_MAX__ 9.999999999999999E384DD #define __DEC64_MIN_EXP__ (-383) #define __DEC64_MIN__ 1E-383DD #define __DECIMAL_DIG__ 21 #define __DEC_EVAL_METHOD__ 2 #define __DYNAMIC__ 1 #define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1067 #define __FINITE_MATH_ONLY__ 0 #define __FLT_DENORM_MIN__ 1.40129846e-45F #define __FLT_DIG__ 6 #define __FLT_EPSILON__ 1.19209290e-7F #define __FLT_EVAL_METHOD__ 0 #define __FLT_HAS_DENORM__ 1 #define __FLT_HAS_INFINITY__ 1 #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MANT_DIG__ 24 #define __FLT_MAX_10_EXP__ 38 #define __FLT_MAX_EXP__ 128 #define __FLT_MAX__ 3.40282347e+38F #define __FLT_MIN_10_EXP__ (-37) #define __FLT_MIN_EXP__ (-125) #define __FLT_MIN__ 1.17549435e-38F #define __FLT_RADIX__ 2 #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 #define __GXX_ABI_VERSION 1002 #define __INTMAX_MAX__ 9223372036854775807L #define __INTMAX_TYPE__ long int #define __INT_MAX__ 2147483647 #define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L #define __LDBL_DIG__ 18 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L #define __LDBL_HAS_DENORM__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __LDBL_MANT_DIG__ 64 #define __LDBL_MAX_10_EXP__ 4932 #define __LDBL_MAX_EXP__ 16384 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_MIN_EXP__ (-16381) #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __LITTLE_ENDIAN__ 1 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __LONG_MAX__ 9223372036854775807L #define __LP64__ 1 #define __MACH__ 1 #define __MMX__ 1 #define __NO_INLINE__ 1 #define __PIC__ 2 #define __PTRDIFF_TYPE__ long int #define __REGISTER_PREFIX__ #define __SCHAR_MAX__ 127 #define __SHRT_MAX__ 32767 #define __SIZE_TYPE__ long unsigned int #define __SSE2_MATH__ 1 #define __SSE2__ 1 #define __SSE3__ 1 #define __SSE_MATH__ 1 #define __SSE__ 1 #define __SSP__ 1 #define __STDC_HOSTED__ 1 #define __STDC__ 1 #define __UINTMAX_TYPE__ long unsigned int #define __USER_LABEL_PREFIX__ _ #define __VERSION__ "4.2.1 (Apple Inc. build 5664)" #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WINT_TYPE__ int #define __amd64 1 #define __amd64__ 1 #define __block __attribute__((__blocks__(byref))) #define __k8 1 #define __k8__ 1 #define __pic__ 2 #define __strong #define __tune_core2__ 1 #define __weak __attribute__((objc_gc(weak))) #define __x86_64 1 #define __x86_64__ 1 -bob From mikpe@REDACTED Wed May 4 10:14:33 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 4 May 2011 10:14:33 +0200 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: References: <19903.46889.761570.628729@pilspetsen.it.uu.se> <19904.33588.924591.882382@pilspetsen.it.uu.se> Message-ID: <19905.2793.962779.656652@pilspetsen.it.uu.se> On Tue, 3 May 2011 16:48:20 -0700, Bob Ippolito wrote: > On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson wrote: > > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito wrote: > >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson wrote= > : > >> > Bob Ippolito writes: > >> > =3DC2=3DA0> I only see this error on Mac OS X. I have not been able to= > reprod=3D > >> uce in Linux. > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Here's an example, any number larger than 16#7ffffffffffff= > e00 wil=3D > >> l > >> > =3DC2=3DA0> cause this error. > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq= > :4] > >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) > >> > =3DC2=3DA0> 1> trunc(16#7ffffffffffffdff * 1.0). > >> > =3DC2=3DA0> 9223372036854774784 > >> > =3DC2=3DA0> 2> trunc(16#7ffffffffffffdff * 1.0). > >> > =3DC2=3DA0> 9223372036854774784 > >> > =3DC2=3DA0> 3> trunc(16#7ffffffffffffe00 * 1.0). > >> > =3DC2=3DA0> 9223372036854775808 > >> > =3DC2=3DA0> 4> trunc(16#7ffffffffffffe00 * 1.0). > >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a= > t > >> > =3DC2=3DA0> 0x19223372036854775808 > >> > =3DC2=3DA0> 5> trunc(16#7ffffffffffffe00 * 1.0). > >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a= > t > >> > =3DC2=3DA0> 0x19223372036854775808 > >> > =3DC2=3DA0> 6> io:format("~s~n", [os:cmd("uname -a")]). > >> > =3DC2=3DA0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat J= > an 29 > >> > =3DC2=3DA0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Here's another example: > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq= > :4] > >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] > >> > =3DC2=3DA0> > >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) > >> > =3DC2=3DA0> 1> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> > =3DC2=3DA0> 9223372036854775808 > >> > =3DC2=3DA0> 2> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a= > t > >> > =3DC2=3DA0> 0x19223372036854775808 > >> > =3DC2=3DA0> 3> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). > >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a= > t > >> > =3DC2=3DA0> 0x19223372036854775808 > >> > > >> > It means that the code at 0x19223372036854775808 in the > >> > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. > >> > > >> > Please attach gdb (or whatever debugger Darwin uses) to a running > >> > Erlang VM and disassemble the code at 0x19223372036854775808. > >> > We need to know the name of the enclosing function, and preferably > >> > also the actual instruction sequence that throws the FPE. If gdb > >> > can show the exact original source code line then that's even better. > >> > > >> > If this is in libc rather than the Erlang VM itself, then we need > >> > a call trace to identify which code in the VM called out to this > >> > FP-throwing code. =3DC2=3DA0For that you should probably plant a break= > point > >> > at 0x19223372036854775808 and then evaluate one of those Erlang > >> > expressions above to trigger the FPE. > >> > > >> > >> Well, it's actually saying 0x1, the result of the trunc is > >> 9223372036854775808 =C2=A0and the message string is truncated to 64 > >> characters which is not enough to show it all. Perhaps the buffer size > >> in erts_fp_check_init_error should be adjusted. > > > > Something in your terminal or email client ate a \r\n sequence after the > > 0x1 from erts_fp_check_init_error() making it appear glued together with > > the 9223372036854775808 that the erlang prompt printed. > > Not my terminal or email client, this is a bug in > erts_fp_check_init_error. It only allocates a 64 byte buffer for the > error message. The pointer address and the \r\n are eaten because the > buffer is too small to fit the whole error message. buf[64] is too > small... the format string itself is already 57 chars (including the > NULL). Ah yes. I did see your comment about the short buffer but failed to connect that with the strange message. The buffer needs to be at least (calculating..) 89 bytes, making it 96 bytes should suffice. This means that my comment about 0x1 and the wrong type SIGFPE handler was invalid. (0x1 is used as a fake PC value in that case.) > Maybe you missed it in my previous email, it's not 0x1, it is > 0x10025433. I showed that by breaking at the function that prints the > error. > Breakpoint 1, erts_fp_check_init_error (fpexnp=3D0x110f2528) at > sys/unix/sys_float.c:87 > 87 { > (gdb) p (void*)*fpexnp > $1 =3D (void *) 0x10025433 In your previous disassembly that pointed to a cvttsd2siq instruction. That can probably throw a SIGFPE, but I see similar code in a build on Linux, and there SIGFPE isn't thrown. If you attach gdb to a freshly started beam instance, let the process continue, and evaluate one of those expressions at the Erlang prompt, then gdb should wake up with a SIGFPE at that location. At that point dump parts of the SSE2 state with: print $mxcsr (SSE control and status flags) print $xmm1 (the source operand in the failing SSE instruction) (If the first SIGFPE occurs elsewhere, disassemble that code first, then adjust the print $xmm1 to match that instruction's source operand.) /Mikael From ingela@REDACTED Wed May 4 10:54:37 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 4 May 2011 10:54:37 +0200 Subject: [erlang-bugs] Specs missing or wrong in ssl, inet and gen_tcp In-Reply-To: <4DC005E2.8000501@dev-extend.eu> References: <4DC005E2.8000501@dev-extend.eu> Message-ID: <4DC1144D.10205@erix.ericsson.se> Hi! Answer to the ssl-related parts of your mail. Lo?c Hoguin wrote: > Hello, > > Just forwarding a few issues I've encountered with type specs in ssl, > inet and gen_tcp. Hope you don't mind me sending all of them in a single > email. > > I will try to send patches when I get some free time and would probably > benefit from any comment you might make here. > > * https://github.com/erlang/otp/blob/dev/lib/ssl/src/ssl.erl > > * socketoption() is incomplete: it can also accept atoms like binary, > list, inet6 or inet and also other kinds of tuples > > We will change it to term() for now, until there exists a exported type that we can use. > * socketoption() should probably depend on types defined > in gen_tcp and inet > > * option() is defined as socketoption()|ssloption()|transportoption(), > problem is socketoption() is defined as a list of options while > others are tuples; socketoption() should be tuples too > I agree there is a list too much. > * https://github.com/erlang/otp/blob/dev/lib/kernel/src/gen_tcp.erl > > * no specs at all, any plans on writing them? if not, any advice? > > * https://github.com/erlang/otp/blob/dev/lib/kernel/src/inet.erl#L109 > > * I'm assuming 'mode' is 'list' | 'binary' and not list() | binary() > > Thanks. > > Regards Ingela Erlang/OTP team - Ericsson AB From erlangsiri@REDACTED Wed May 4 11:03:52 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 4 May 2011 11:03:52 +0200 Subject: [erlang-bugs] Reltool and code clash In-Reply-To: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> References: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> Message-ID: Thanks Jay - this is very helpful! /siri@REDACTED 2011/5/3 Jay Nelson > I may have more info on this. It seems to be a reltool bug. I don't have a > simple case, but I discovered the problem using rebar in conjunction with a > tsung installation (which doesn't use rebar and instead installs itself into > the erlang lib directory). > > We customized tsung by adding protobuffs and a new module as dependencies > of the .app file. When we use rebar to generate the app (which relies on > reltool to do the work), reltool crashes because some dependencies in tsung > are in the wrong directory (tsung, rather than in tsung_controller) in the > /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to > generate the app. > > To avoid this problem, we instruct reltool to ignore the apps in the erlang > directory: > > {app, tsung, [{incl_cond, exclude}]}, > {app, tsung_recorder, [{incl_cond, exclude}]}, > {app, tsung_controller, [{incl_cond, exclude}]} > > And the dependency that we created by customizing tsung gets excluded even > though it is included explicitly as a separate app: > > {app, my_shared_lib, [{incl_cond, include}]}, > > There are two issues: > > 1) tsung is releasing 3 applications and I believe the module dependencies > are incomplete or incorrect. > [Not an erlang issue, the tsung guys need to fix this one] > > 2) reltool does not handle include + exclude of an app dependency > [This is the simple case you need to create] > > To recreate the problem simply, you need 3 apps (in this case, C is an > included application that is just a standalone library of a single module, > whereas A and B are executable apps): > > A => relies on C > B => relies on C > > Create a reltool spec that excludes A but includes B. You will find the > release area contains C.app but no C.beam files. It doesn't matter which of > A or B is excluded as long as the other one is included, you should see the > same results. I am not sure, but I don't think it matters if C is listed as > an application or as an included_application. > > Hope this helps! Feel free to ask more questions. We are working around it > by just copying the beams into place as a separate step in the Makefile. > Everything else seems to work. > > jay > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Wed May 4 16:03:59 2011 From: bob@REDACTED (Bob Ippolito) Date: Wed, 4 May 2011 07:03:59 -0700 Subject: [erlang-bugs] Mac OS X - trunc for large float causes ERTS_FP_CHECK_INIT at [...]: detected unhandled FPE at [...] In-Reply-To: <19905.2793.962779.656652@pilspetsen.it.uu.se> References: <19903.46889.761570.628729@pilspetsen.it.uu.se> <19904.33588.924591.882382@pilspetsen.it.uu.se> <19905.2793.962779.656652@pilspetsen.it.uu.se> Message-ID: On Wed, May 4, 2011 at 1:14 AM, Mikael Pettersson wrote: > On Tue, 3 May 2011 16:48:20 -0700, Bob Ippolito wrote: >> On Tue, May 3, 2011 at 3:35 PM, Mikael Pettersson wrote: >> > On Tue, 3 May 2011 07:18:34 -0700, Bob Ippolito wrote: >> >> On Tue, May 3, 2011 at 1:04 AM, Mikael Pettersson wrote= >> : >> >> > Bob Ippolito writes: >> >> > =3DC2=3DA0> I only see this error on Mac OS X. I have not been able to= >> ?reprod=3D >> >> uce in Linux. >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Here's an example, any number larger than 16#7ffffffffffff= >> e00 wil=3D >> >> l >> >> > =3DC2=3DA0> cause this error. >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq= >> :4] >> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) >> >> > =3DC2=3DA0> 1> trunc(16#7ffffffffffffdff * 1.0). >> >> > =3DC2=3DA0> 9223372036854774784 >> >> > =3DC2=3DA0> 2> trunc(16#7ffffffffffffdff * 1.0). >> >> > =3DC2=3DA0> 9223372036854774784 >> >> > =3DC2=3DA0> 3> trunc(16#7ffffffffffffe00 * 1.0). >> >> > =3DC2=3DA0> 9223372036854775808 >> >> > =3DC2=3DA0> 4> trunc(16#7ffffffffffffe00 * 1.0). >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a= >> t >> >> > =3DC2=3DA0> 0x19223372036854775808 >> >> > =3DC2=3DA0> 5> trunc(16#7ffffffffffffe00 * 1.0). >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10086210: detected unhandled FPE a= >> t >> >> > =3DC2=3DA0> 0x19223372036854775808 >> >> > =3DC2=3DA0> 6> io:format("~s~n", [os:cmd("uname -a")]). >> >> > =3DC2=3DA0> Darwin ba.local 10.7.0 Darwin Kernel Version 10.7.0: Sat J= >> an 29 >> >> > =3DC2=3DA0> 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Here's another example: >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:4:4] [rq= >> :4] >> >> > =3DC2=3DA0> [async-threads:4] [hipe] [kernel-poll:true] >> >> > =3DC2=3DA0> >> >> > =3DC2=3DA0> Eshell V5.8.3 =3DC2=3DA0(abort with ^G) >> >> > =3DC2=3DA0> 1> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> >> > =3DC2=3DA0> 9223372036854775808 >> >> > =3DC2=3DA0> 2> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a= >> t >> >> > =3DC2=3DA0> 0x19223372036854775808 >> >> > =3DC2=3DA0> 3> <> =3D3D <<67,224,0,0,0,0,0,0>>, trunc(F). >> >> > =3DC2=3DA0> ERTS_FP_CHECK_INIT at 0x10083e24: detected unhandled FPE a= >> t >> >> > =3DC2=3DA0> 0x19223372036854775808 >> >> > >> >> > It means that the code at 0x19223372036854775808 in the >> >> > Erlang VM needs to use the proper ERTS_FP_CHECK_ macros. >> >> > >> >> > Please attach gdb (or whatever debugger Darwin uses) to a running >> >> > Erlang VM and disassemble the code at 0x19223372036854775808. >> >> > We need to know the name of the enclosing function, and preferably >> >> > also the actual instruction sequence that throws the FPE. If gdb >> >> > can show the exact original source code line then that's even better. >> >> > >> >> > If this is in libc rather than the Erlang VM itself, then we need >> >> > a call trace to identify which code in the VM called out to this >> >> > FP-throwing code. =3DC2=3DA0For that you should probably plant a break= >> point >> >> > at 0x19223372036854775808 and then evaluate one of those Erlang >> >> > expressions above to trigger the FPE. >> >> > >> >> >> >> Well, it's actually saying 0x1, the result of the trunc is >> >> 9223372036854775808 =C2=A0and the message string is truncated to 64 >> >> characters which is not enough to show it all. Perhaps the buffer size >> >> in erts_fp_check_init_error should be adjusted. >> > >> > Something in your terminal or email client ate a \r\n sequence after the >> > 0x1 from erts_fp_check_init_error() making it appear glued together with >> > the 9223372036854775808 that the erlang prompt printed. >> >> Not my terminal or email client, this is a bug in >> erts_fp_check_init_error. It only allocates a 64 byte buffer for the >> error message. The pointer address and the \r\n are eaten because the >> buffer is too small to fit the whole error message. buf[64] is too >> small... the format string itself is already 57 chars (including the >> NULL). > > Ah yes. I did see your comment about the short buffer but failed > to connect that with the strange message. The buffer needs to be at > least (calculating..) 89 bytes, making it 96 bytes should suffice. > > This means that my comment about 0x1 and the wrong type SIGFPE > handler was invalid. (0x1 is used as a fake PC value in that case.) > >> Maybe you missed it in my previous email, it's not 0x1, it is >> 0x10025433. I showed that by breaking at the function that prints the >> error. >> Breakpoint 1, erts_fp_check_init_error (fpexnp=3D0x110f2528) at >> sys/unix/sys_float.c:87 >> 87 ? ? ?{ >> (gdb) p (void*)*fpexnp >> $1 =3D (void *) 0x10025433 > > In your previous disassembly that pointed to a cvttsd2siq instruction. > That can probably throw a SIGFPE, but I see similar code in a build on > Linux, and there SIGFPE isn't thrown. > > If you attach gdb to a freshly started beam instance, let the process > continue, and evaluate one of those expressions at the Erlang prompt, > then gdb should wake up with a SIGFPE at that location. ?At that point > dump parts of the SSE2 state with: > > print $mxcsr (SSE control and status flags) > print $xmm1 (the source operand in the failing SSE instruction) > > (If the first SIGFPE occurs elsewhere, disassemble that code first, then > adjust the print $xmm1 to match that instruction's source operand.) Program received signal EXC_ARITHMETIC, Arithmetic exception. [Switching to process 14985] double_to_integer [inlined] () at /Users/bob/src/otp_src_R14B02/erts/emulator/beam/erl_bif_guard.c:301 301 d = x; /* trunc */ (gdb) info frame Stack level 0, frame at 0x10: rip = 0x10025433 in trunc_1 (beam/erl_bif_guard.c:301); saved rip 0x10025433 called by frame at 0x0 source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp (gdb) disassemble 0x0000000010025433 [...] 0x0000000010025433 : cvttsd2siq %xmm1,%rdx [...] (gdb) print $mxcsr $1 = 6433 (gdb) print $xmm1 $2 = { v4_float = {0, 0, 448, 0}, v2_double = {0, 9.2233720368547758e+18}, v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, 67, -32, 0, 0, 0, 0, 0, 0}, v8_int16 = {0, 0, 0, 0, 17376, 0, 0, 0}, v4_int32 = {0, 0, 1138753536, 0}, v2_int64 = {0, 4890909195324358656}, uint128 = 57411 } (gdb) print $rdx $3 = 16 -bob From erlangsiri@REDACTED Thu May 5 11:16:39 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 5 May 2011 11:16:39 +0200 Subject: [erlang-bugs] Reltool and code clash In-Reply-To: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> References: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> Message-ID: Hi Jay - I'm trying to re-create this, but so far I haven't succeeded. Could you please help me getting on?? What I have so far is: Application c, which only has one module, c_lib. Application a, which uses the c_lib. Application b, which is a copy of application a, only with different names. And the following reltool config: {sys,[{lib_dirs,["/my/lib/dir"]}, {app,a,[{incl_cond,exclude}]}, {app,b,[{incl_cond,include}]}, {app,kernel,[{incl_cond,include}]}, {app,sasl,[{incl_cond,include}]}, {app,stdlib,[{incl_cond,include}]}]}. I have tried with c listed as 'applications' and as 'included_applications' in a.app and b.app. I have also tried without mentioning c in a.app and b.app. In all cases, I get c_lib.beam in the target system. I have tried with a, b and c all in the same lib dir, and I have tried to move c to a different lib dir - no difference. Any ideas?? Thanks /siri 2011/5/3 Jay Nelson > I may have more info on this. It seems to be a reltool bug. I don't have a > simple case, but I discovered the problem using rebar in conjunction with a > tsung installation (which doesn't use rebar and instead installs itself into > the erlang lib directory). > > We customized tsung by adding protobuffs and a new module as dependencies > of the .app file. When we use rebar to generate the app (which relies on > reltool to do the work), reltool crashes because some dependencies in tsung > are in the wrong directory (tsung, rather than in tsung_controller) in the > /usr/local/lib/erlang/lib/ directory. Uninstalling tsung allows reltool to > generate the app. > > To avoid this problem, we instruct reltool to ignore the apps in the erlang > directory: > > {app, tsung, [{incl_cond, exclude}]}, > {app, tsung_recorder, [{incl_cond, exclude}]}, > {app, tsung_controller, [{incl_cond, exclude}]} > > And the dependency that we created by customizing tsung gets excluded even > though it is included explicitly as a separate app: > > {app, my_shared_lib, [{incl_cond, include}]}, > > There are two issues: > > 1) tsung is releasing 3 applications and I believe the module dependencies > are incomplete or incorrect. > [Not an erlang issue, the tsung guys need to fix this one] > > 2) reltool does not handle include + exclude of an app dependency > [This is the simple case you need to create] > > To recreate the problem simply, you need 3 apps (in this case, C is an > included application that is just a standalone library of a single module, > whereas A and B are executable apps): > > A => relies on C > B => relies on C > > Create a reltool spec that excludes A but includes B. You will find the > release area contains C.app but no C.beam files. It doesn't matter which of > A or B is excluded as long as the other one is included, you should see the > same results. I am not sure, but I don't think it matters if C is listed as > an application or as an included_application. > > Hope this helps! Feel free to ask more questions. We are working around it > by just copying the beams into place as a separate step in the Makefile. > Everything else seems to work. > > jay > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kruber@REDACTED Thu May 5 11:39:29 2011 From: kruber@REDACTED (Nico Kruber) Date: Thu, 5 May 2011 11:39:29 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <19897.5974.659362.789149@pilspetsen.it.uu.se> References: <20110427194556.GA3947@corelatus.se> <20110428054348.GA2303@corelatus.se> <19897.5974.659362.789149@pilspetsen.it.uu.se> Message-ID: <201105051139.29873.kruber@zib.de> On Thursday 28 April 2011 09:29:26 Mikael Pettersson wrote: > Matthias Lang writes: > > Hi, > > > > > I'm unable to reproduce this with either gcc-4.5.2 or > > > gcc-4.5-20110421, both vanilla unpatched FSF sources, on an x86-64 > > > box running Fedora 13. Looks like a Debian bug to me. > > > > Thanks, agree. > > > > I glanced at Debian's patches, but they're 200k lines long. Did not > > feel like digging through that to try and understand what they've > > done. Feels like "report and forget" time. > > > > Anything more than the rest of this mail I should send to Debian? > > > > -------------------- > > > > gcc -v: gcc version 4.5.2 (Debian 4.5.2-11) > > This bit looks incomplete. 'gcc -v' normally includes a list of > configuration options, that sometimes do matter. Of course, Debian > should know what "4.5.2-11" means exactly, so it may not matter. > It would matter for bug reports to FSF GCC. > > Apart from that, the bug report looks complete. > > > uname -a: Linux contorpis.corelatus.se 2.6.38-2-amd64 #1 SMP Thu Apr 7 > > 04:28:07 UTC 2011 x86_64 GNU/Linux > > > > how to reproduce: > > cd /tmp > > wget www.corelatus.se/~matthias/preprocessed.i > > gcc -O3 -c preprocessed.i > > > > here's what it looks like on my machine: > > > gcc -O3 -c preprocessed.i > > > > beam/dist.c: In function ???erts_do_net_exits???: > > beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, at > > cfganal.c:1207 Please submit a full bug report, > > with preprocessed source if appropriate. > > See for instructions. > > > > MD5: 616c74a08f57cb9263a9af62d845fb19 preprocessed.i > > > > Problem does not occur with "gcc version 4.4.5 (Debian 4.4.5-15)" > > > > Can't find a similar problem at bugs.debian.org. > > Similar problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 > > > > Matt This is not only a Debian problem. Happens on openSUSE Factory, too - but only on x86_64 - see https://build.opensuse.org/package/rawlog?arch=x86_64&package=erlang&project=home%3Atschuett&repository=openSUSE_Factory This error did not occur with R14B01 - but the GCC packages might have been different back then. Does the error still occur with the GCC patch from the bug report you mentioned? Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kruber@REDACTED Thu May 5 11:52:13 2011 From: kruber@REDACTED (Nico Kruber) Date: Thu, 5 May 2011 11:52:13 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <201105051139.29873.kruber@zib.de> References: <20110427194556.GA3947@corelatus.se> <19897.5974.659362.789149@pilspetsen.it.uu.se> <201105051139.29873.kruber@zib.de> Message-ID: <201105051152.17685.kruber@zib.de> On Thursday 05 May 2011 11:39:29 Nico Kruber wrote: > On Thursday 28 April 2011 09:29:26 Mikael Pettersson wrote: > > Matthias Lang writes: > > > Hi, > > > > > > > I'm unable to reproduce this with either gcc-4.5.2 or > > > > gcc-4.5-20110421, both vanilla unpatched FSF sources, on an x86-64 > > > > box running Fedora 13. Looks like a Debian bug to me. > > > > > > Thanks, agree. > > > > > > I glanced at Debian's patches, but they're 200k lines long. Did not > > > feel like digging through that to try and understand what they've > > > done. Feels like "report and forget" time. > > > > > > Anything more than the rest of this mail I should send to Debian? > > > > > > -------------------- > > > > > > gcc -v: gcc version 4.5.2 (Debian 4.5.2-11) > > > > This bit looks incomplete. 'gcc -v' normally includes a list of > > configuration options, that sometimes do matter. Of course, Debian > > should know what "4.5.2-11" means exactly, so it may not matter. > > It would matter for bug reports to FSF GCC. > > > > Apart from that, the bug report looks complete. > > > > > uname -a: Linux contorpis.corelatus.se 2.6.38-2-amd64 #1 SMP Thu Apr 7 > > > 04:28:07 UTC 2011 x86_64 GNU/Linux > > > > > > how to reproduce: > > > cd /tmp > > > wget www.corelatus.se/~matthias/preprocessed.i > > > gcc -O3 -c preprocessed.i > > > > > > here's what it looks like on my machine: > > > > gcc -O3 -c preprocessed.i > > > > > > beam/dist.c: In function ???erts_do_net_exits???: > > > beam/dist.c:501:1: internal compiler error: in dfs_enumerate_from, > > > at cfganal.c:1207 Please submit a full bug report, > > > with preprocessed source if appropriate. > > > See for instructions. > > > > > > MD5: 616c74a08f57cb9263a9af62d845fb19 preprocessed.i > > > > > > Problem does not occur with "gcc version 4.4.5 (Debian 4.4.5-15)" > > > > > > Can't find a similar problem at bugs.debian.org. > > > Similar problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 > > > > > > Matt > > This is not only a Debian problem. Happens on openSUSE Factory, too - but > only on x86_64 - see > https://build.opensuse.org/package/rawlog?arch=x86_64&package=erlang&proje > ct=home%3Atschuett&repository=openSUSE_Factory > > This error did not occur with R14B01 I need to correct this - apparently, the same error occurs in R14B but there, it happens on both, i586 and x86_64! see: https://build.opensuse.org/package/rawlog?arch=i586&package=erlang&project=devel%3Alanguages%3Aerlang&repository=openSUSE_Factory https://build.opensuse.org/package/rawlog?arch=x86_64&package=erlang&project=devel%3Alanguages%3Aerlang&repository=openSUSE_Factory > Does the error still occur with the GCC patch from > the bug report you mentioned? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jesper.louis.andersen@REDACTED Thu May 5 12:11:33 2011 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 5 May 2011 12:11:33 +0200 Subject: [erlang-bugs] A small bug I ran into with ct_run on FreeBSD 8.2 Message-ID: Here is a problem I ran into. The machine is: FreeBSD shadow 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@REDACTED:/usr/obj/usr/src/sys/GENERIC amd64 Sympton: I try to execute ct_run on my etorrent project: ./rel/etorrent/erts-*/bin/ct_run -spec etorrent_test.spec | tee test.log ct_run: Error 2 executing './rel/etorrent/erts-5.8.4/bin/erl'. which is odd, because I *just* created a release with an Erl in it. Oh well, ktrace(1) to the rescue. From the kdump(1) we see the following: 1744 ct_run NAMI "./rel/etorrent/erts-5.8.4/bin/erl" 1744 ct_run NAMI "/bin/bash" 1744 ct_run RET execve -1 errno 2 No such file or directory which shows: a) There is an assumption bash is at /bin/bash. This is almost always not the case, unless the system is Linux. b) The error message is wrong. The error is due to the missing /bin/bash, not the missing file. Temporary workaround: sudo ln -s /usr/local/bin/bash /bin/bash this fixes the problem so I am sure this is what happens. -- J. From andrew@REDACTED Thu May 5 20:20:51 2011 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 5 May 2011 14:20:51 -0400 Subject: [erlang-bugs] A small bug I ran into with ct_run on FreeBSD 8.2 In-Reply-To: References: Message-ID: <20110505182051.GC29934@hijacked.us> I believe I've also seen this on some of the other BSDs where stuff like run_erl was trying to call /bin/bash instead of /bin/sh. I didn't see this on FreeBSD, however. Andrew From matthias@REDACTED Fri May 6 08:02:44 2011 From: matthias@REDACTED (Matthias Lang) Date: Fri, 6 May 2011 08:02:44 +0200 Subject: [erlang-bugs] gcc bug triggered by compiling R14B02 (not an erlang bug per se) In-Reply-To: <201105051139.29873.kruber@zib.de> References: <20110427194556.GA3947@corelatus.se> <20110428054348.GA2303@corelatus.se> <19897.5974.659362.789149@pilspetsen.it.uu.se> <201105051139.29873.kruber@zib.de> Message-ID: <20110506060244.GA2698@corelatus.se> On Thursday, May 05, Nico Kruber wrote: > This error did not occur with R14B01 - but the GCC packages might > have been different back then. > Does the error still occur with the GCC patch from the bug report you mentioned? I didn't try. I solved my immediate problem by going back to gcc-4.4. I just checked the thread on the debian gcc bugs list where I reported the problem along with the example to reproduce it. Crickets there. Matt From dangud@REDACTED Fri May 6 13:30:26 2011 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 6 May 2011 13:30:26 +0200 Subject: [erlang-bugs] Segmentation fault in R14B02/wxErlang/amd64/debian-sid In-Reply-To: References: Message-ID: Hi Olivier It works here, does other opengl programs work for you? Or is it a driver install issue? Otherwise you can try to check that the functions are loaded correctly in load_gl_functions (in egl_impl.cpp). /Dan On Sat, Apr 30, 2011 at 4:01 AM, Olivier Girondel wrote: > Hello, > > I have an application that works just fine with R14B02 on i386 / debian sid, > but segfaults on amd64 (same configuration, nothing special in the > erlang build): > > ================================ > olivier@REDACTED:~$ cat /etc/debian_version > wheezy/sid > olivier@REDACTED:~$ uname -a > Linux yoda 2.6.38-2-amd64 #1 SMP Sat Apr 23 18:47:49 UTC 2011 x86_64 GNU/Linux > olivier@REDACTED:~$ erl > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.8.3 ?(abort with ^G) > ================================ > > Way to reproduce the bug -alas, not related to my application- > > 1> wx:demo(). > > Then click on the "gl" example. Segfaults without a core (even with > ulimit -c unlimited > and write permissions to the cwd) > > 1> wx:demo(). > {wx_ref,35,wxFrame,<0.34.0>} > 2> Segmentation fault > > Backtrace with gdb (erlang was compiled with -g): > ================================ > olivier@REDACTED:~$ ./erldbg.sh > GNU gdb (GDB) 7.2-debian > Copyright (C) 2010 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 "x86_64-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/local/lib/erlang/erts-5.8.3/bin/erlexec...done. > (gdb) run > Starting program: /usr/local/lib/erlang/erts-5.8.3/bin/erlexec > process 4030 is executing new program: > /usr/local/lib/erlang/erts-5.8.3/bin/beam.smp > [Thread debugging using libthread_db enabled] > [New Thread 0x7ffff6b87700 (LWP 4033)] > [New Thread 0x7ffff7ff8700 (LWP 4034)] > [New Thread 0x7ffff6386700 (LWP 4035)] > [New Thread 0x7ffff7fe6700 (LWP 4036)] > [New Thread 0x7ffff5a84700 (LWP 4037)] > [New Thread 0x7ffff5283700 (LWP 4038)] > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.8.3 ?(abort with ^G) > 1> wx:demo(). > [New Thread 0x7fffe560e700 (LWP 4041)] > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{wx_ref,35,wxFrame,<0.34.0>} > 2> > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffe560e700 (LWP 4041)] > 0x00007fffe27266b0 in ?? () > (gdb) bt > #0 ?0x00007fffe27266b0 in ?? () > #1 ?0x00007fffe29719c1 in egl_dispatch (op=5314, bp=0x9d38f0 "", > port=0x267, caller=659, bins=, bins_sz= optimized out>) > ? ?at gen/gl_funcs.cpp:2206 > #2 ?0x00007fffefc34c8e in gl_dispatch (op=5314, bp=0x9d38e0 "", > caller=659, bins=0x7ffff0041dc0) at wxe_gl.cpp:158 > #3 ?0x00007fffefc2facf in WxeApp::dispatch (this=0x9ffbb0, > batch=0xa8a900, blevel=1, list_type=0) at wxe_impl.cpp:405 > #4 ?0x00007fffefc2fbd7 in WxeApp::dispatch_cmds (this=0x9ffbb0) at > wxe_impl.cpp:359 > #5 ?0x00007fffee589955 in > wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 > #6 ?0x00007fffee589d3f in > wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from > /usr/lib/libwx_baseu-2.8.so.0 > #7 ?0x00007fffee589df2 in wxEvtHandler::ProcessEvent(wxEvent&) () from > /usr/lib/libwx_baseu-2.8.so.0 > #8 ?0x00007fffeea70425 in wxAppBase::ProcessIdle() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #9 ?0x00007fffee9decf2 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0 > #10 0x00007fffeb83c4a3 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 > #11 0x00007fffeb83cc80 in ?? () from /lib/libglib-2.0.so.0 > #12 0x00007fffeb83d2f2 in g_main_loop_run () from /lib/libglib-2.0.so.0 > #13 0x00007fffed5ee2b7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #14 0x00007fffee9f3098 in wxEventLoop::Run() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #15 0x00007fffeea701db in wxAppBase::MainLoop() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #16 0x00007fffee5379ac in wxEntry(int&, wchar_t**) () from > /usr/lib/libwx_baseu-2.8.so.0 > #17 0x00007fffefc2f47c in wxe_main_loop (vpdl=0x96ee38) at wxe_impl.cpp:227 > #18 0x0000000000548e0d in erl_drv_thread_wrapper (vdtid=0x9d3888) at > beam/erl_drv_thread.c:117 > #19 0x000000000060f573 in thr_wrapper (vtwd=0x7ffff527fec0) at > pthread/ethread.c:106 > #20 0x00007ffff72f98ba in start_thread (arg=) at > pthread_create.c:300 > #21 0x00007ffff6e583cd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #22 0x0000000000000000 in ?? () > (gdb) > ================================ > > The fault may be on my side -if not, what can I do to help debugging this ? > > -- > Olivier / http://biniou.net > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From eric.pailleau@REDACTED Mon May 9 22:01:38 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 09 May 2011 22:01:38 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. Message-ID: <4DC84822.3070704@wanadoo.fr> > T=gb_trees:from_orddict([{a1,10},{a2,15},{a3,5},{a4,7}]). {4,{a3,5,{a2,15,{a1,10,nil,nil},nil},{a4,7,nil,nil}}} > gb_trees:lookup(a1,T). {value,10} > f(). ok > T=gb_trees:from_orddict([{10,a1},{15,a2},{5,a3},{7,a4}]). {4,{5,a3,{15,a2,{10,a1,nil,nil},nil},{7,a4,nil,nil}}} > gb_trees:lookup(10,T). none While {value, a1} would be expected. In documentation : Key = Val = Term() . No restriction for key is documented : so a lack of documentation or a bug ... Regards. From ulf.wiger@REDACTED Mon May 9 22:12:25 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 9 May 2011 22:12:25 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <4DC84822.3070704@wanadoo.fr> References: <4DC84822.3070704@wanadoo.fr> Message-ID: <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> On 9 May 2011, at 22:01, PAILLEAU Eric wrote: >> T=gb_trees:from_orddict([{10,a1},{15,a2},{5,a3},{7,a4}]). > {4,{5,a3,{15,a2,{10,a1,nil,nil},nil},{7,a4,nil,nil}}} > >> gb_trees:lookup(10,T). > none > The argument is not an orddict. The reason for the function is speed, obviously, and verifying that the list is in fact ordered would defeat the speed advantage. Thus, it is up to the user to ensure that they actually pass an orddict. This isn't expressly written in the manual... BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From eric.pailleau@REDACTED Mon May 9 22:28:24 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 09 May 2011 22:28:24 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> Message-ID: <4DC84E68.6090505@wanadoo.fr> Hello, this make sens. I was only looking that keys and values can be any terms while the function name was self explicit ... Thanks Ulf. > > The argument is not an orddict. > > The reason for the function is speed, obviously, and verifying that the list is in fact ordered would defeat the speed advantage. Thus, it is up to the user to ensure that they actually pass an orddict. This isn't expressly written in the manual... > From matthias@REDACTED Mon May 9 23:13:40 2011 From: matthias@REDACTED (Matthias Lang) Date: Mon, 9 May 2011 23:13:40 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> Message-ID: <20110509211340.GA4161@corelatus.se> On Monday, May 09, Ulf Wiger wrote: > > On 9 May 2011, at 22:01, PAILLEAU Eric wrote: > > >> T=gb_trees:from_orddict([{10,a1},{15,a2},{5,a3},{7,a4}]). > > {4,{5,a3,{15,a2,{10,a1,nil,nil},nil},{7,a4,nil,nil}}} > > > >> gb_trees:lookup(10,T). > > none > The argument is not an orddict. The above was the important part of your mail, but this made me wonder: > The reason for the function is speed, obviously, and verifying that > the list is in fact ordered would defeat the speed advantage. Checking that the input is ordered should be cheap since you have to traverse the whole input anyway. Here's gb_trees:from_orddict: from_orddict(L) -> S = length(L), {S, balance_list(L, S)}. replacing the length() call with one which also checks input ordering is easy, so I did that. I measured a 5% slowdown on long (1M) lists. I'd live with that, but maybe not everyone would. I then took a look at "who uses gb_trees:from_orddict anyway?". In OTP, it's mostly the beam compiler itself. This code pops up a few times: gb_trees:from_orddict(lists:sort(L)) It feels like there's a function missing in gb_trees, one which inserts a list of tuples which aren't sorted (but do have unique keys). Matt From robert.virding@REDACTED Mon May 9 23:27:00 2011 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 9 May 2011 21:27:00 +0000 (GMT) Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <1705728528.155851304976311885.JavaMail.root@zimbra> Message-ID: <644839884.155871304976420333.JavaMail.root@zimbra> Dict/orddict have a from_list/1 which takes a list of Key-Value tuples in any order. They also accept non-unique keys taking the value of the last key in the list. Robert ----- "Matthias Lang" wrote: > On Monday, May 09, Ulf Wiger wrote: > > > > On 9 May 2011, at 22:01, PAILLEAU Eric wrote: > > > > >> T=gb_trees:from_orddict([{10,a1},{15,a2},{5,a3},{7,a4}]). > > > {4,{5,a3,{15,a2,{10,a1,nil,nil},nil},{7,a4,nil,nil}}} > > > > > >> gb_trees:lookup(10,T). > > > none > > > The argument is not an orddict. > > The above was the important part of your mail, but this made me > wonder: > > > The reason for the function is speed, obviously, and verifying that > > the list is in fact ordered would defeat the speed advantage. > > Checking that the input is ordered should be cheap since you have to > traverse the whole input anyway. Here's gb_trees:from_orddict: > > from_orddict(L) -> > S = length(L), > {S, balance_list(L, S)}. > > replacing the length() call with one which also checks input ordering > is easy, so I did that. I measured a 5% slowdown on long (1M) > lists. I'd live with that, but maybe not everyone would. > > I then took a look at "who uses gb_trees:from_orddict anyway?". In > OTP, it's mostly the beam compiler itself. This code pops up a few > times: > > gb_trees:from_orddict(lists:sort(L)) > > It feels like there's a function missing in gb_trees, one which > inserts a > list of tuples which aren't sorted (but do have unique keys). > > Matt > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From ulf.wiger@REDACTED Mon May 9 23:56:51 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 9 May 2011 23:56:51 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <20110509211340.GA4161@corelatus.se> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> <20110509211340.GA4161@corelatus.se> Message-ID: <08732A1C-DF29-4F06-94CE-C051D4C9EA0F@erlang-solutions.com> On 9 May 2011, at 23:13, Matthias Lang wrote: >> The argument is not an orddict. > > The above was the important part of your mail, but this made me wonder: > >> The reason for the function is speed, obviously, and verifying that >> the list is in fact ordered would defeat the speed advantage. Yeah, I know. I thought the same right after I posted the mail. I figured someone would call me on it. :) BR, Ulf Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From kostis@REDACTED Mon May 9 23:56:35 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 10 May 2011 00:56:35 +0300 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <20110509211340.GA4161@corelatus.se> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> <20110509211340.GA4161@corelatus.se> Message-ID: <4DC86313.3030107@cs.ntua.gr> Matthias Lang wrote: > On Monday, May 09, Ulf Wiger wrote: >> On 9 May 2011, at 22:01, PAILLEAU Eric wrote: >> >>>> T=gb_trees:from_orddict([{10,a1},{15,a2},{5,a3},{7,a4}]). >>> {4,{5,a3,{15,a2,{10,a1,nil,nil},nil},{7,a4,nil,nil}}} >>> >>>> gb_trees:lookup(10,T). >>> none > >> The argument is not an orddict. For the record, let me point out that this is not the first time this question arises. > The above was the important part of your mail, but this made me wonder: > >> The reason for the function is speed, obviously, and verifying that >> the list is in fact ordered would defeat the speed advantage. > > Checking that the input is ordered should be cheap since you have to > traverse the whole input anyway. Here's gb_trees:from_orddict: > > from_orddict(L) -> > S = length(L), > {S, balance_list(L, S)}. > > replacing the length() call with one which also checks input ordering > is easy, so I did that. I measured a 5% slowdown on long (1M) > lists. I'd live with that, but maybe not everyone would. I strongly support adding something like the above to OTP! The benefits of doing so far outweigh the drawbacks. Those that cannot live with this overhead, should better switch to some other language, in my opinion. I have real trouble seeing how this change would make any measurable difference in some application. (On the other hand, it might prevent some accidental hair loss for some developers...) Even better yet, why not make orddict() opaque so that dialyzer can detect constructions of "fake ordicts" (i.e. orddicts that are not produced by calling the functions of the orddict module) ? > I then took a look at "who uses gb_trees:from_orddict anyway?". In > OTP, it's mostly the beam compiler itself. This code pops up a few > times: > > gb_trees:from_orddict(lists:sort(L)) Hmmm... I would have expected the above to read: gb_trees:from_orddict(orddict:from_list(L)) instead, which seems to me more kosher. (*) Is this call to lists:sort/1 correct/intentional? Only the original developer can answer such questions, if he happens to still recall whether this was done just to save a millisecond or for some other reason... God only knows how many possible subtle bugs may be hidden in such (or similar) code. > It feels like there's a function missing in gb_trees, one which inserts a > list of tuples which aren't sorted (but do have unique keys). Right again. Kostis (*) Even stranger is code in beam_clean.erl which reads: Lmap = gb_trees:from_orddict(ordsets:from_list(Lmap0)), and gb_trees:from_orddict(ordsets:from_list(Acc)). From nox@REDACTED Tue May 10 00:26:41 2011 From: nox@REDACTED (Anthony Ramine) Date: Tue, 10 May 2011 00:26:41 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <4DC86313.3030107@cs.ntua.gr> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> <20110509211340.GA4161@corelatus.se> <4DC86313.3030107@cs.ntua.gr> Message-ID: Le 9 mai 2011 ? 23:56, Kostis Sagonas a ?crit : > > > Is this call to lists:sort/1 correct/intentional? Only the original developer can answer such questions, if he happens to still recall whether this was done just to save a millisecond or for some other reason... God only knows how many possible subtle bugs may be hidden in such (or similar) code. lists:ukeysort/2 removes duplicates. -- Anthony Ramine Dev:Extend http://dev-extend.eu From kostis@REDACTED Tue May 10 00:30:06 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 10 May 2011 01:30:06 +0300 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> <20110509211340.GA4161@corelatus.se> <4DC86313.3030107@cs.ntua.gr> Message-ID: <4DC86AEE.10007@cs.ntua.gr> Anthony Ramine wrote: > Le 9 mai 2011 ? 23:56, Kostis Sagonas a ?crit : > >> >> >> Is this call to lists:sort/1 correct/intentional? Only the original developer can answer such questions, if he happens to still recall whether this was done just to save a millisecond or for some other reason... God only knows how many possible subtle bugs may be hidden in such (or similar) code. > > lists:ukeysort/2 removes duplicates. Right, I know. So does lists:usort/1. And your point is what exactly? Kostis From nox@REDACTED Tue May 10 07:43:41 2011 From: nox@REDACTED (Anthony Ramine) Date: Tue, 10 May 2011 07:43:41 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <4DC86AEE.10007@cs.ntua.gr> References: <4DC84822.3070704@wanadoo.fr> <995794D8-CB60-46BC-BF2A-6784D5FB30DA@erlang-solutions.com> <20110509211340.GA4161@corelatus.se> <4DC86313.3030107@cs.ntua.gr> <4DC86AEE.10007@cs.ntua.gr> Message-ID: <9035B91A-197C-4F38-ABBB-B4B6F540CEAF@dev-extend.eu> Le 10 mai 2011 ? 00:30, Kostis Sagonas a ?crit : > Anthony Ramine wrote: >> Le 9 mai 2011 ? 23:56, Kostis Sagonas a ?crit : >>> >>> >>> Is this call to lists:sort/1 correct/intentional? Only the original developer can answer such questions, if he happens to still recall whether this was done just to save a millisecond or for some other reason... God only knows how many possible subtle bugs may be hidden in such (or similar) code. >> lists:ukeysort/2 removes duplicates. > > Right, I know. So does lists:usort/1. > > And your point is what exactly? > > Kostis Sounds like I forgot to type the most important part of the mail. Shouldn't this sort of nasty trick where the rationale tend to be undocumented and forgotten really fast be avoided in the crucial parts of OTP? -- Anthony Ramine Dev:Extend http://dev-extend.eu From robert.virding@REDACTED Wed May 11 03:42:46 2011 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 11 May 2011 01:42:46 +0000 (GMT) Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <9035B91A-197C-4F38-ABBB-B4B6F540CEAF@dev-extend.eu> Message-ID: <1786021815.166821305078166146.JavaMail.root@zimbra> Wouldn't the easiest and cleanest solution to this problem be just add gb_trees:from_list? I have no idea why there isn't one. I don't know if orddict could be an opaque type as the point of it is that the representation is defined to be an ordered list. Robert ----- "Anthony Ramine" wrote: > Le 10 mai 2011 ? 00:30, Kostis Sagonas a ?crit : > > > Anthony Ramine wrote: > >> Le 9 mai 2011 ? 23:56, Kostis Sagonas a ?crit : > >>> > >>> > >>> Is this call to lists:sort/1 correct/intentional? Only the > original developer can answer such questions, if he happens to still > recall whether this was done just to save a millisecond or for some > other reason... God only knows how many possible subtle bugs may be > hidden in such (or similar) code. > >> lists:ukeysort/2 removes duplicates. > > > > Right, I know. So does lists:usort/1. > > > > And your point is what exactly? > > > > Kostis > > Sounds like I forgot to type the most important part of the mail. > Shouldn't this sort of nasty trick where the rationale tend to be > undocumented and forgotten really fast be avoided in the crucial parts > of OTP? > > -- > Anthony Ramine > Dev:Extend > http://dev-extend.eu > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Wed May 11 19:26:27 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 11 May 2011 19:26:27 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <1786021815.166821305078166146.JavaMail.root@zimbra> References: <1786021815.166821305078166146.JavaMail.root@zimbra> Message-ID: <4DCAC6C3.9010902@wanadoo.fr> Le 11/05/2011 03:42, Robert Virding a ?crit : > Wouldn't the easiest and cleanest solution to this problem be just add gb_trees:from_list? I have no idea why there isn't one. > > I don't know if orddict could be an opaque type as the point of it is that the representation is defined to be an ordered list. > > Robert > hello, I didn't figure out that my "newbie mistake" will generate all these answers. The puzzling thing in my mistake is that the function looks to return a valid balanced tree, even if lookup doesn't work properly... As 'ordered list' is not a type, input is not tested and no exception is raised. I do understand. I agree with Robert : a gb_trees:from_list would be necessary because it is unlikely to have ordered list from scratch in real life. It is probable that any call to the function uses 'sort' in the line above or directly in the input, like do the beam compiler :gb_trees:from_orddict(lists:sort(L)) . So the overhead is either done in the module code or in the user code anyway ... In addition to this, there is 'from_list' functions in queue, ordsets, array, orddict, dict, sets and gb_sets modules, but not in gb_trees ... Why not :>) ? Regards. From erlangsiri@REDACTED Thu May 12 12:07:46 2011 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 12 May 2011 12:07:46 +0200 Subject: [erlang-bugs] Reltool and code clash In-Reply-To: References: <05BE8E1C-C3B4-4768-B5DC-385526F36FB8@duomark.com> Message-ID: I did finally manage to re-create the problem as described in the original post - i.e. if the same module is included in two different applications, one included and one excluded - then, depending on the order of processing, the beam file might be completely excluded from the release area. A solution will be included in R14B03. It allows duplicated module names, as long as the configuration clearly states only one actual inclusion. Warnings and errors are emitted. Regards /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.demidenko@REDACTED Thu May 12 14:15:29 2011 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 12 May 2011 19:15:29 +0700 Subject: [erlang-bugs] xmerl_xsd incorrect behavior? Message-ID: Hello, friends! I found two trubles with xmerl_xsd module. When I try to validate "invalid_xml_bug.xml" by "ss.xsd" (see attachment files), I'll get the error: {error, [{"ss_list[1]/ss[4]",xmerl_xsd, {element_not_suitable_with_schema, {ssd,[ssType],[]}, {xsd_state,"ss.xsd", [230908739019541468279786040419060913848], false,".",[], [ssType], [],qualified,unqualified,undefined,undefined, [{"xs",'http://www.w3.org/2001/XMLSchema'}, {"xml",'http://www.w3.org/XML/1998/namespace'}], [{undefined,[{"xs",'http://www.w3.org/2001/XMLSchema'}]}], [{"#this#","ss.xsd",undefined}, {"xml",[],'http://www.w3.org/XML/1998/namespace'}], 16400,false,false,[],[],#Fun,[],2,[],[], [],[],[],[],[],[],[]}}}, {"ss_list[1]/ss[4]",xmerl_xsd, {element_not_suitable_with_schema, {csd,[ssType],[]}, {xsd_state,"ss.xsd", [230908739019541468279786040419060913848], false,".",[], [ssType], [],qualified,unqualified,undefined,undefined, [{"xs",'http://www.w3.org/2001/XMLSchema'}, {"xml",'http://www.w3.org/XML/1998/namespace'}], [{undefined,[{"xs",'http://www.w3.org/2001/XMLSchema'}]}], [{"#this#","ss.xsd",undefined}, {"xml",[],'http://www.w3.org/XML/1998/namespace'}], 16400,false,false,[],[],#Fun,[],2,[],[], [],[],[],[],[],[], [{"ss_list[1]/ss[4]",xmerl_xsd, {element_not_suitable_with_schema, {ssd,[ssType],[]}, {xsd_state,"ss.xsd", [230908739019541468279786040419060913848], false,".",[], [ssType], [],qualified,unqualified,undefined,undefined, [{"xs",'http://www.w3.org/2001/XMLSchema'}, {"xml",'http://www.w3.org/XML/1998/namespace'}], [{undefined, [{"xs",'http://www.w3.org/2001/XMLSchema'}]}], [{"#this#","ss.xsd",undefined}, {"xml",[],'http://www.w3.org/XML/1998/namespace'}], 16400,false,false,[],[],#Fun, [],2,[],[],[],[],[],[],[],[],[]}}}]}}}]} But, as I know, this xml absolutly correct. Second problem is big memory eating. (depends of counts tag inside of ) When I try to validate "memory_leak_bug.xml" by "ss.xsd" my application hang, and memory usage begin increasing. To show this two problems I've wrote "xml_test" module with two methods "invalid_xml_test", "memory_leak_xml_test". -module(xml_test). -export([invalid_xml_test/0, memory_leak_xml_test/0]). read_xml(FileName) -> {ok, Schema} = xmerl_xsd:process_schema("ss.xsd"), {ok, BXml} = file:read_file(FileName), Xml = erlang:binary_to_list(BXml), {XmerXml, _} = xmerl_scan:string(Xml), xmerl_xsd:validate(XmerXml, Schema). invalid_xml_test() -> Result = read_xml("invalid_xml_bug.xml"), io:format("~p~n", [Result]). memory_leak_xml_test() -> Result = read_xml("memory_leak_bug.xml"), io:format("~p~n", [Result]). Tested by Erlang 13B4, xmerl 1.2.4 and 14B2, xmerl 1.2.8 -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- A non-text attachment was scrubbed... Name: XMerlBug.tar.gz Type: application/x-gzip Size: 2328 bytes Desc: not available URL: From matthias@REDACTED Thu May 12 18:36:18 2011 From: matthias@REDACTED (Matthias Lang) Date: Thu, 12 May 2011 18:36:18 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. Message-ID: <20110512163618.GA7315@corelatus.se> Hi, sorry about the missing threading headers. Eric wrote: > In addition to this, there is 'from_list' functions in queue, ordsets, > array, orddict, dict, sets and gb_sets modules, but not in gb_trees ... > Why not :>) ? Completely agree with your observation that more consistency would be nice. My 'favourite' example is deciding the function and argument order when finding out if something's in a structure: lists:member(Element, Structure) ets:member(Structure, Element) string:chr(Structure, Element) [ord]dict:is_key(Element, Structure) sets:is_element(Element, Structure) gb_trees:is_defined(Element, Structure) None of the those present when this happened have chosen to comment on the 'why', here are my guesses: Why did it start? A "just do it!" spirit when Erlang was born, along with different people having different ideas about how to do things. Why is it still that way? Backwards compatibility has always been a high priority in Erlang because it's been used in real products almost from the start. Cleaning up has usually taken a back seat. But changes like adding 'from_list' to gb_trees should be uncontroversial. --- Aside: just spotted a bug in the 'sets' manpage. It says: | This module provides exactly the same interface as the module | ordsets but with a defined representation. The bit about "defined representation" looks like a cut-and-paste error from ordsets. (I looked at R14B0, erlang.org is down for me) Matt From bengt.kleberg@REDACTED Fri May 13 08:27:54 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 13 May 2011 08:27:54 +0200 Subject: [erlang-bugs] Bug in gb_trees ? Integer key not found. In-Reply-To: <20110512163618.GA7315@corelatus.se> References: <20110512163618.GA7315@corelatus.se> Message-ID: <1305268074.5044.41.camel@seasc1137> Greetings, I think it is worth mentioning the attempt made by Ricard C. "Erlang standard library packages". The comments say: Basically following Jonas B. et al., "proposal 15" So some work has been done on this subject. bengt On Thu, 2011-05-12 at 18:36 +0200, Matthias Lang wrote: > Hi, > > sorry about the missing threading headers. > > Eric wrote: > > > In addition to this, there is 'from_list' functions in queue, ordsets, > > array, orddict, dict, sets and gb_sets modules, but not in gb_trees ... > > Why not :>) ? > > Completely agree with your observation that more consistency would be > nice. My 'favourite' example is deciding the function and argument > order when finding out if something's in a structure: > > lists:member(Element, Structure) > ets:member(Structure, Element) > string:chr(Structure, Element) > [ord]dict:is_key(Element, Structure) > sets:is_element(Element, Structure) > gb_trees:is_defined(Element, Structure) > > None of the those present when this happened have chosen to comment on > the 'why', here are my guesses: > > Why did it start? A "just do it!" spirit when Erlang was born, along with > different people having different ideas about how to do things. > > Why is it still that way? Backwards compatibility has always been a > high priority in Erlang because it's been used in real products almost > from the start. Cleaning up has usually taken a back seat. But changes > like adding 'from_list' to gb_trees should be uncontroversial. > > --- > > Aside: just spotted a bug in the 'sets' manpage. It says: > > | This module provides exactly the same interface as the module > | ordsets but with a defined representation. > > The bit about "defined representation" looks like a cut-and-paste > error from ordsets. (I looked at R14B0, erlang.org is down for me) > > Matt > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From boris.muehmer@REDACTED Sat May 14 11:54:59 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Sat, 14 May 2011 11:54:59 +0200 Subject: [erlang-bugs] The gl-example in wx:demo() crashes on Ubuntu 11.04 (64 Bit) using Erlang/OTP R14B02 (Source Install) Message-ID: Running wx:demo() (from a source installation of Erlang/OTP R14B02) and selecting the "gl" example crashes the erlang shell on Ubuntu 11.04 (64 Bit). Other OpenGL-examples (for example Qt demos or Ogre3D) work on this system. I currently don't have access to a 32 bit system where I could test OpenGL. The installation was done using the steps described at: http://boris.muehmer.de/2011/05/07/installing-erlangotp-r14b02-on-ubuntu-11-04-from-source-tarball/ === Shell Session Output: begin === $ /opt/erlang-otp/bin/erl Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.3 (abort with ^G) 1> wx:demo(). {wx_ref,35,wxFrame,<0.34.0>} 2> Speicherzugriffsfehler (Speicherabzug geschrieben) === Shell Session Output: end === === Gdb Session Output: begin === Program terminated with signal 11, Segmentation fault. #0 0x00007f5eb10ef240 in ?? () (gdb) bt #0 0x00007f5eb10ef240 in ?? () #1 0x00007f5eb136751f in egl_dispatch (op=5314, bp=0x1b8c2b0 "", port=0x274, caller=755, bins=, bins_sz=) at gen/gl_funcs.cpp:2206 #2 0x00007f5ec1b4a1b2 in gl_dispatch (op=5314, bp=0x1b8c2a0 "", caller=755, bins=0x1ce82f0) at wxe_gl.cpp:158 #3 0x00007f5ec1b4501f in WxeApp::dispatch (this=0x1c25710, batch=0x1ce2a00, blevel=1, list_type=0) at wxe_impl.cpp:405 #4 0x00007f5ec1b45127 in WxeApp::dispatch_cmds (this=0x1c25710) at wxe_impl.cpp:359 #5 0x00007f5ec0503ad5 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #6 0x00007f5ec0503ebf in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #7 0x00007f5ec0503f72 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0 #8 0x00007f5ec09be635 in wxAppBase::ProcessIdle() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #9 0x00007f5ec092cf8e in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #10 0x00007f5ebd7e5bcd in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007f5ebd7e63a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x00007f5ebd7e69f2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x00007f5ebf585af7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x00007f5ec0941578 in wxEventLoop::Run() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #15 0x00007f5ec09be3eb in wxAppBase::MainLoop() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #16 0x00007f5ec04b153a in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0 #17 0x00007f5ec1b449dc in wxe_main_loop (vpdl=0x1b30d60) at wxe_impl.cpp:227 #18 0x00000000005b01a0 in thr_wrapper (vtwd=0x7f5ec34da9e0) at pthread/ethread.c:106 #19 0x00007f5ec5584d8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #20 0x00007f5ec50c804d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x0000000000000000 in ?? () === Gdb Session Output: end === - boris From boris.muehmer@REDACTED Sat May 14 18:32:25 2011 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Sat, 14 May 2011 18:32:25 +0200 Subject: [erlang-bugs] The gl-example in wx:demo() crashes on Ubuntu 11.04 (64 Bit) using Erlang/OTP R14B02 (Source Install) In-Reply-To: References: Message-ID: Just a small update: I did a fresh Ubuntu 11.04 32 bit installation on one of my "spare" notebooks and the gl example of wx:demo() crashed there as well. - boris 2011/5/14 Boris M?hmer : > Running wx:demo() (from a source installation of Erlang/OTP R14B02) > and selecting the "gl" example crashes the erlang shell on Ubuntu > 11.04 (64 Bit). Other OpenGL-examples (for example Qt demos or Ogre3D) > work on this system. I currently don't have access to a 32 bit system > where I could test OpenGL. > > The installation was done using the steps described at: > ? ?http://boris.muehmer.de/2011/05/07/installing-erlangotp-r14b02-on-ubuntu-11-04-from-source-tarball/ > > === Shell Session Output: begin === > $ /opt/erlang-otp/bin/erl > Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.8.3 ?(abort with ^G) > 1> wx:demo(). > {wx_ref,35,wxFrame,<0.34.0>} > 2> Speicherzugriffsfehler (Speicherabzug geschrieben) > === Shell Session Output: end === > > === Gdb Session Output: begin === > Program terminated with signal 11, Segmentation fault. > #0 ?0x00007f5eb10ef240 in ?? () > (gdb) bt > #0 ?0x00007f5eb10ef240 in ?? () > #1 ?0x00007f5eb136751f in egl_dispatch (op=5314, bp=0x1b8c2b0 "", > port=0x274, caller=755, bins=, > ? ?bins_sz=) at gen/gl_funcs.cpp:2206 > #2 ?0x00007f5ec1b4a1b2 in gl_dispatch (op=5314, bp=0x1b8c2a0 "", > caller=755, bins=0x1ce82f0) at wxe_gl.cpp:158 > #3 ?0x00007f5ec1b4501f in WxeApp::dispatch (this=0x1c25710, > batch=0x1ce2a00, blevel=1, list_type=0) at wxe_impl.cpp:405 > #4 ?0x00007f5ec1b45127 in WxeApp::dispatch_cmds (this=0x1c25710) at > wxe_impl.cpp:359 > #5 ?0x00007f5ec0503ad5 in > wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () > ? from /usr/lib/libwx_baseu-2.8.so.0 > #6 ?0x00007f5ec0503ebf in > wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from > /usr/lib/libwx_baseu-2.8.so.0 > #7 ?0x00007f5ec0503f72 in wxEvtHandler::ProcessEvent(wxEvent&) () from > /usr/lib/libwx_baseu-2.8.so.0 > #8 ?0x00007f5ec09be635 in wxAppBase::ProcessIdle() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #9 ?0x00007f5ec092cf8e in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0 > #10 0x00007f5ebd7e5bcd in g_main_context_dispatch () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #11 0x00007f5ebd7e63a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #12 0x00007f5ebd7e69f2 in g_main_loop_run () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #13 0x00007f5ebf585af7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #14 0x00007f5ec0941578 in wxEventLoop::Run() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #15 0x00007f5ec09be3eb in wxAppBase::MainLoop() () from > /usr/lib/libwx_gtk2u_core-2.8.so.0 > #16 0x00007f5ec04b153a in wxEntry(int&, wchar_t**) () from > /usr/lib/libwx_baseu-2.8.so.0 > #17 0x00007f5ec1b449dc in wxe_main_loop (vpdl=0x1b30d60) at wxe_impl.cpp:227 > #18 0x00000000005b01a0 in thr_wrapper (vtwd=0x7f5ec34da9e0) at > pthread/ethread.c:106 > #19 0x00007f5ec5584d8c in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #20 0x00007f5ec50c804d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #21 0x0000000000000000 in ?? () > === Gdb Session Output: end === > > > ?- boris > From xramtsov@REDACTED Mon May 16 10:45:11 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Mon, 16 May 2011 18:45:11 +1000 Subject: [erlang-bugs] Inter-nodes connection bottle-neck Message-ID: <4DD0E417.9010600@gmail.com> We are facing a problem where inter-node connection becomes a bottle-neck when there are too much traffic between nodes. In such situation we have lots of processes stuck in erlang:send. Since erlang:send_nosuspend is not an option we tried other solutions: 1) Set +zdbbl emulator option. No success. 2) Patched erl_port_task.c so a port with ERTS_PORT_SFLG_DISTRIBUTION flag set is inserted in a head of ErtsRunQueue in enqueue_port(). Alas, this doesn't help as well. 3) Implemented multiple links between 2 nodes. This works very good and we get rid of the bottle-neck, especially when lots of connections are established (20 and more). However, the patch is pretty complex: it envolves improvements in net_kernel.erl, erl_node_table.c, dist.c and so on. Also, as for me, the solution looks a bit ugly. Any ideas what could be done yet? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From john.hughes@REDACTED Mon May 16 18:23:21 2011 From: john.hughes@REDACTED (John Hughes) Date: Mon, 16 May 2011 18:23:21 +0200 Subject: [erlang-bugs] Bad object error in dets in R14B02 Message-ID: QuickCheck found another error in dets. The following test case shows how to provoke a bad object error by starting three concurrent match_object traversals, at the same time as data is inserted into the table. test() -> dets:close(dets_table), file:delete(dets_table), {ok,dets_table} = dets:open_file(dets_table,[{type,bag}]), ok = dets:insert(dets_table,[{0,0},{0,14},{1,0},{1,1},{39,0}]), {[{0,14}],Cont} = dets:match_object(dets_table,{'$1',14},0), ok = dets:insert(dets_table,{2,0}), {[{0,0},{0,14}],_} = dets:match_object(dets_table,{0,'$2'},0), ok = dets:insert(dets_table,[{2,1},{39,1}]), {[{1,0}],_} = dets:match_object(dets_table,{'$1',0},0), {error,{{bad_object,scan},"dets_table"}} = dets:match_object(Cont). This is 100% repeatable--and it seems to be a minimal example. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Mon May 16 18:32:25 2011 From: john.hughes@REDACTED (John Hughes) Date: Mon, 16 May 2011 18:32:25 +0200 Subject: [erlang-bugs] Documentation bug in dets Message-ID: <51958DDAC69244A29C521EA5919C7D91@JohnsTablet2009> The documentation says that delete_object/2 and delete_all_objects/1 returns true, but they return ok. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Mon May 16 18:38:59 2011 From: john.hughes@REDACTED (John Hughes) Date: Mon, 16 May 2011 18:38:59 +0200 Subject: [erlang-bugs] Documentation bug in dets In-Reply-To: <51958DDAC69244A29C521EA5919C7D91@JohnsTablet2009> References: <51958DDAC69244A29C521EA5919C7D91@JohnsTablet2009> Message-ID: <929E7780B4274B8F9AC446DFD81D140B@JohnsTablet2009> Sorry, ignore this one--I was looking at the ets documentation instead. John ----- Original Message ----- From: John Hughes To: Erlang Bugs Sent: Monday, May 16, 2011 6:32 PM Subject: [erlang-bugs] Documentation bug in dets The documentation says that delete_object/2 and delete_all_objects/1 returns true, but they return ok. John ------------------------------------------------------------------------------ _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anders.Ramsell@REDACTED Mon May 16 18:51:45 2011 From: Anders.Ramsell@REDACTED (Anders.Ramsell@REDACTED) Date: Mon, 16 May 2011 18:51:45 +0200 Subject: [erlang-bugs] Infinite loop in async_del in erl_async.c Message-ID: <4B5A1820C84D9E4C9B6A281B2C1DA64E12F0E77A06@EXCCR02TSBRZ2.tcad.telia.se> Hi! We have recently experienced a problem where our linked in driver using the asynchronous thread pool suddenly enters an infinite loop eventually causing the whole Erlang runtime system to shut down (without generating an erl_crash.dump). This problem occured on Windows 2000/2003 Server with SMP support disabled and with 1024 asynchronous threads (+A 1024) running Erlang/OTP R12B-2. After a lot of investigation the error appeared to be in the function async_del in erl_async.c and now one of my colleagues believes he has identified the bug. The problem is that the code does not advance passed the first element in a non-empty queue on a thread. If the first queue element found is not the id we are looking for we get an infinite loop. The code included below includes a suggested fix by my colleague which solves the problem. This bug is still present in R14. static int async_del(long id) { int i; /* scan all queue for an entry with async_id == 'id' */ for (i = 0; i < erts_async_max_threads; i++) { ErlAsync* a; erts_mtx_lock(&async_q[i].mtx); a = async_q[i].head; while(a != NULL) { if (a->async_id == id) { if (a->prev != NULL) a->prev->next = a->next; else async_q[i].head = a->next; if (a->next != NULL) a->next->prev = a->prev; else async_q[i].tail = a->prev; async_q[i].len--; erts_mtx_unlock(&async_q[i].mtx); if (a->async_free != NULL) a->async_free(a->async_data); async_detach(a->hndl); erts_free(ERTS_ALC_T_ASYNC, a); return 1; } a = a->next; //<-- Add this line. } erts_mtx_unlock(&async_q[i].mtx); } return 0; } /Best regards Anders Ramsell From radek.bulat@REDACTED Mon May 16 22:11:34 2011 From: radek.bulat@REDACTED (=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?=) Date: Mon, 16 May 2011 22:11:34 +0200 Subject: [erlang-bugs] typer crash for <<_:32, _:_*8>> Message-ID: I have code like this: -module(erlangbug). -export([bug/0]). bug() -> Bin = <<"Hello World">>, <<(size(Bin)):32, Bin/binary>>. Now i run typer for that file: $ typer --show erlangbug.erl %% File: "erlangbug.erl" %% --------------------- -spec bug() -> <<_:32,_:_*8>>. It seems ok but now I add that spec to the file: -module(erlangbug). -export([bug/0]). -spec bug() -> <<_:32,_:_*8>>. bug() -> Bin = <<"Hello World">>, <<(size(Bin)):32, Bin/binary>>. and run typer again: $ typer --show erlangbug.erl %% File: "erlangbug.erl" %% --------------------- {"init terminating in do_boot",{{case_clause,8},[{erl_types,t_form_to_string,1},{erl_types,t_form_to_string,1},{dialyzer_contracts,contract_to_string_1,1},{typer,get_type_string,4},{typer,'-show_type_info/2-fun-0-',2},{lists,foreach,2},{typer,start,0},{init,start_it,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () -- Pozdrawiam Rados?aw Bu?at http://radarek.jogger.pl - m?j blog From rickard@REDACTED Tue May 17 09:41:16 2011 From: rickard@REDACTED (Rickard Green) Date: Tue, 17 May 2011 09:41:16 +0200 Subject: [erlang-bugs] Infinite loop in async_del in erl_async.c In-Reply-To: <4B5A1820C84D9E4C9B6A281B2C1DA64E12F0E77A06@EXCCR02TSBRZ2.tcad.telia.se> References: <4B5A1820C84D9E4C9B6A281B2C1DA64E12F0E77A06@EXCCR02TSBRZ2.tcad.telia.se> Message-ID: <8C54EDE4-1727-4D4B-9567-8AED873397C3@erlang.org> Thanks! We'll fix this in the soon to be released R14B03. Regards, Rickard Green, Erlang/OTP, Ericsson AB On May 16, 2011, at 6:51 PM, wrote: > > Hi! > > We have recently experienced a problem where our linked in driver > using the asynchronous thread pool suddenly enters an infinite > loop eventually causing the whole Erlang runtime system to shut > down (without generating an erl_crash.dump). > > This problem occured on Windows 2000/2003 Server with SMP support > disabled and with 1024 asynchronous threads (+A 1024) running > Erlang/OTP R12B-2. > > After a lot of investigation the error appeared to be in the > function async_del in erl_async.c and now one of my colleagues > believes he has identified the bug. > > The problem is that the code does not advance passed the first > element in a non-empty queue on a thread. If the first queue > element found is not the id we are looking for we get an infinite > loop. The code included below includes a suggested fix by my > colleague which solves the problem. > > This bug is still present in R14. > > > static int async_del(long id) > { > int i; > /* scan all queue for an entry with async_id == 'id' */ > > for (i = 0; i < erts_async_max_threads; i++) { > ErlAsync* a; > erts_mtx_lock(&async_q[i].mtx); > > a = async_q[i].head; > while(a != NULL) { > if (a->async_id == id) { > if (a->prev != NULL) > a->prev->next = a->next; > else > async_q[i].head = a->next; > if (a->next != NULL) > a->next->prev = a->prev; > else > async_q[i].tail = a->prev; > async_q[i].len--; > erts_mtx_unlock(&async_q[i].mtx); > if (a->async_free != NULL) > a->async_free(a->async_data); > async_detach(a->hndl); > erts_free(ERTS_ALC_T_ASYNC, a); > return 1; > } > a = a->next; //<-- Add this line. > } > erts_mtx_unlock(&async_q[i].mtx); > } > return 0; > } > > > /Best regards > Anders Ramsell > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From john.hughes@REDACTED Tue May 17 15:02:46 2011 From: john.hughes@REDACTED (John Hughes) Date: Tue, 17 May 2011 15:02:46 +0200 Subject: [erlang-bugs] dets hangs sometimes Message-ID: <8A1E0AB8D56F4F659DEBD1800BF2DB66@JohnsTablet2009> QuickCheck found another dets bug at Klarna. The following test makes dets hang: run() -> dets:stop(), file:delete(dets_table), {ok,dets_table} = dets:open_file(dets_table,[{type,bag}]), ok = dets:insert(dets_table,[{0,21},{0,0},{1,0},{2,0},{2,1}]), ok = dets:insert(dets_table,[{1,21}]), true = dets:insert_new(dets_table,[{3,0}]), {[{1,21}],Cont} = dets:match_object(dets_table,{'$1',21},0), {[{0,21}],Cont2} = dets:match_object(Cont), ok = dets:match_delete(dets_table,{'$1','$2'}), true = dets:insert_new(dets_table,[{31,0}]), ok = dets:insert(dets_table,[{2,1},{18,0},{31,1}]), ok = dets:insert(dets_table,[{1,0},{1,1},{2,0}]), [] = dets:match_object(dets_table,{0,0}), io:format("Here it comes..."), %% This call hangs dets:match_object(Cont2), io:format("now!\n"). When I run it: 2> c(dets_stopped). {ok,dets_stopped} 3> dets_stopped:run(). Here it comes... Make sure to run it in a newly started node... dets has some state which can change the behaviour. Maybe it could be simplified some more, but most changes I make to it cause it to pass. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Tue May 17 15:24:58 2011 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 17 May 2011 15:24:58 +0200 Subject: [erlang-bugs] dets hangs sometimes In-Reply-To: <8A1E0AB8D56F4F659DEBD1800BF2DB66@JohnsTablet2009> References: <8A1E0AB8D56F4F659DEBD1800BF2DB66@JohnsTablet2009> Message-ID: <19922.30506.23660.810030@ornendil.otp.ericsson.se> Hi again! [John Hughes:] > QuickCheck found another dets bug at Klarna. The following test makes dets hang: > > run() -> > dets:stop(), > file:delete(dets_table), > {ok,dets_table} = dets:open_file(dets_table,[{type,bag}]), > ok = dets:insert(dets_table,[{0,21},{0,0},{1,0},{2,0},{2,1}]), > ok = dets:insert(dets_table,[{1,21}]), > true = dets:insert_new(dets_table,[{3,0}]), > {[{1,21}],Cont} = dets:match_object(dets_table,{'$1',21},0), > {[{0,21}],Cont2} = dets:match_object(Cont), > ok = dets:match_delete(dets_table,{'$1','$2'}), > true = dets:insert_new(dets_table,[{31,0}]), > ok = dets:insert(dets_table,[{2,1},{18,0},{31,1}]), > ok = dets:insert(dets_table,[{1,0},{1,1},{2,0}]), > [] = dets:match_object(dets_table,{0,0}), > io:format("Here it comes..."), > %% This call hangs > dets:match_object(Cont2), > io:format("now!\n"). > > When I run it: > > 2> c(dets_stopped). > {ok,dets_stopped} > 3> dets_stopped:run(). > Here it comes... > > Make sure to run it in a newly started node... dets has some state which can change the behaviour. > > Maybe it could be simplified some more, but most changes I make to it cause it to pass. It's not a bug. You can try adding the line dets:verbose(), It'll then output =ERROR REPORT==== 17-May-2011::15:20:42 === ** dets: traversal of dets_table needs safe_fixtable The manual states that The table should always be protected using safe_fixtable/2 before calling match_object/3, or errors may occur when call- ing match_object/1. Adding dets:safe_fixtable(dets_table, true), before match_object seems to make it work. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From ulf.wiger@REDACTED Tue May 17 15:30:02 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 17 May 2011 15:30:02 +0200 Subject: [erlang-bugs] dets hangs sometimes In-Reply-To: <19922.30506.23660.810030@ornendil.otp.ericsson.se> References: <8A1E0AB8D56F4F659DEBD1800BF2DB66@JohnsTablet2009> <19922.30506.23660.810030@ornendil.otp.ericsson.se> Message-ID: On 17 May 2011, at 15:24, Hans Bolinder wrote: > Hi again! > > [John Hughes:] >> QuickCheck found another dets bug at Klarna. The following test makes dets hang: >> >> ... > > It's not a bug. You can try adding the line > > dets:verbose(), > > It'll then output > > =ERROR REPORT==== 17-May-2011::15:20:42 === > ** dets: traversal of dets_table needs safe_fixtable Hmm, the more conventional way to signal failure would be to raise an exception, rather than hanging. ;-) BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From john.hughes@REDACTED Tue May 17 16:10:00 2011 From: john.hughes@REDACTED (John Hughes) Date: Tue, 17 May 2011 16:10:00 +0200 Subject: [erlang-bugs] dets hangs sometimes In-Reply-To: <19922.30506.23660.810030@ornendil.otp.ericsson.se> References: <8A1E0AB8D56F4F659DEBD1800BF2DB66@JohnsTablet2009> <19922.30506.23660.810030@ornendil.otp.ericsson.se> Message-ID: <335FBC4F672F41549CB1F2A680930837@JohnsTablet2009> Ah, thank you. I'll try running tests with safe_fixtable included. John ----- Original Message ----- From: "Hans Bolinder" To: Sent: Tuesday, May 17, 2011 3:24 PM Subject: Re: [erlang-bugs] dets hangs sometimes > Hi again! > > [John Hughes:] >> QuickCheck found another dets bug at Klarna. The following test makes >> dets hang: >> >> run() -> >> dets:stop(), >> file:delete(dets_table), >> {ok,dets_table} = dets:open_file(dets_table,[{type,bag}]), >> ok = dets:insert(dets_table,[{0,21},{0,0},{1,0},{2,0},{2,1}]), >> ok = dets:insert(dets_table,[{1,21}]), >> true = dets:insert_new(dets_table,[{3,0}]), >> {[{1,21}],Cont} = dets:match_object(dets_table,{'$1',21},0), >> {[{0,21}],Cont2} = dets:match_object(Cont), >> ok = dets:match_delete(dets_table,{'$1','$2'}), >> true = dets:insert_new(dets_table,[{31,0}]), >> ok = dets:insert(dets_table,[{2,1},{18,0},{31,1}]), >> ok = dets:insert(dets_table,[{1,0},{1,1},{2,0}]), >> [] = dets:match_object(dets_table,{0,0}), >> io:format("Here it comes..."), >> %% This call hangs >> dets:match_object(Cont2), >> io:format("now!\n"). >> >> When I run it: >> >> 2> c(dets_stopped). >> {ok,dets_stopped} >> 3> dets_stopped:run(). >> Here it comes... >> >> Make sure to run it in a newly started node... dets has some state which >> can change the behaviour. >> >> Maybe it could be simplified some more, but most changes I make to it >> cause it to pass. > > It's not a bug. You can try adding the line > > dets:verbose(), > > It'll then output > > =ERROR REPORT==== 17-May-2011::15:20:42 === > ** dets: traversal of dets_table needs safe_fixtable > > The manual states that > > The table should always be protected using safe_fixtable/2 > before calling match_object/3, or errors may occur when call- > ing match_object/1. > > Adding > > dets:safe_fixtable(dets_table, true), > > before match_object seems to make it work. > > Best regards, > > Hans Bolinder, Erlang/OTP team, Ericsson > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From carlsson.richard@REDACTED Tue May 17 18:07:33 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:07:33 +0200 Subject: [erlang-bugs] file:pread 0 bytes in raw mode yields eof Message-ID: <4DD29D45.80201@gmail.com> Normally, file:read and file:pread both return an empty list or binary if the number of bytes to be read is zero, but if the file is opened in raw mode, trying to read zero bytes yields EOF instead. /Richard From carlsson.richard@REDACTED Tue May 17 18:09:40 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 18:09:40 +0200 Subject: [erlang-bugs] Test server does not restore handlers Message-ID: <4DD29DC4.3030307@gmail.com> The function test_server_ctrl:init/1 calls test_server_h:install(), if SASL is running, but the corresponding test_server_h:restore() is never called. When running ct:run_test/1 repeatedly from the shell, the list of handlers just keeps growing and the old handlers sasl_report_tty_h and error_logger_tty_h are not restored. /Richard From john.hughes@REDACTED Tue May 17 18:57:38 2011 From: john.hughes@REDACTED (John Hughes) Date: Tue, 17 May 2011 18:57:38 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? Message-ID: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> QuickCheck turned up another case of odd behaviour at Klarna. The test runs mnesia on two nodes, creates a table on the OTHER node, then adds and deletes a record. After this the record is indeed not IN the table, but dirty_next finds its key anyway! Surely it shouldn't? Here's the test: test() -> Slave = start_mnesia_with_slave(), {atomic,ok} = mnesia:create_table(rec,[{type,set}, {disc_only_copies,[Slave]}]), ok = mnesia:dirty_write({rec,4,1}), %% The next command MUST be done in a transaction, otherwise dirty_next works {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), %% Here's the problem: dirty_next returns 4, but this key is not in the table! 4 = mnesia:dirty_next(rec,0), [] = mnesia:dirty_read(rec,4). I'm starting mnesia and the slave node like this: start_mnesia_with_slave() -> {ok,Dir} = file:get_cwd(), ok = error_logger:tty(false), mnesia:stop(), ok = error_logger:tty(true), delete_file("mnesia"), delete_file("slave"), ok = file:make_dir("mnesia"), ok = file:make_dir("slave"), Slave = slave(), ok = application:set_env(mnesia,dir,Dir++"/mnesia"), ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), ok = mnesia:create_schema([node(),Slave]), ok = mnesia:start(), ok = rpc:call(Slave,mnesia,start,[]), Slave. slave() -> case slave:start_link(net_adm:localhost(),"slave") of {ok,Slave} -> Slave; {error,{already_running,Slave}} -> Slave end. I also have code to delete a file or directory, easy on Linux, darn difficult on Windows. You don't need this really, just run the test in an empty directory. delete_file(Name) -> case filelib:is_dir(Name) of true -> [delete_file(Name++"/"++X) || X <- list_dir(Name)], file:del_dir(Name), delete_file(Name); {error,eaccess} -> delete_file(Name); {error,enoent} -> io:format("Could not find ~p\n",[Name]), ok; false -> case file:delete(Name) of {error,enoent} -> ok; {error,eacces} -> io:format("Could not access ~p\n",[Name]), delete_file(Name); ok -> delete_file(Name) end end. list_dir(Name) -> case file:list_dir(Name) of {ok,Files} -> Files; {error,eacces} -> io:format("Could not list directory ~p\n",[Name]), list_dir(Name); {error,enoent} -> io:format("Could not find directory ~p\n",[Name]), [] end. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue May 17 20:53:41 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 17 May 2011 20:53:41 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: I'm not a mnesia expert, but i THINK the race condition is in the test not mnesia. transaction is still being committed and logged, when the dirty read is issued. if you add a sleep in between or better if you use mnesia:sync_transaction ( http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of mnesia:transaction, the test will fail, i.e the case disappear isn't that the expected behavior or am i missing something? On Tue, May 17, 2011 at 6:57 PM, John Hughes wrote: > QuickCheck turned up another case of odd behaviour at Klarna. > > The test runs mnesia on two nodes, creates a table on the OTHER node, then > adds and deletes a record. After this the record is indeed not IN the table, > but dirty_next finds its key anyway! Surely it shouldn't? > > Here's the test: > > test() -> > Slave = start_mnesia_with_slave(), > {atomic,ok} = mnesia:create_table(rec,[{type,set}, > {disc_only_copies,[Slave]}]), > ok = mnesia:dirty_write({rec,4,1}), > %% The next command MUST be done in a transaction, otherwise dirty_next > works > {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) > end), > %% Here's the problem: dirty_next returns 4, but this key is not in the > table! > 4 = mnesia:dirty_next(rec,0), > [] = mnesia:dirty_read(rec,4). > I'm starting mnesia and the slave node like this: > > start_mnesia_with_slave() -> > {ok,Dir} = file:get_cwd(), > ok = error_logger:tty(false), > mnesia:stop(), > ok = error_logger:tty(true), > delete_file("mnesia"), > delete_file("slave"), > ok = file:make_dir("mnesia"), > ok = file:make_dir("slave"), > Slave = slave(), > ok = application:set_env(mnesia,dir,Dir++"/mnesia"), > ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), > ok = mnesia:create_schema([node(),Slave]), > ok = mnesia:start(), > ok = rpc:call(Slave,mnesia,start,[]), > Slave. > > slave() -> > case slave:start_link(net_adm:localhost(),"slave") of > {ok,Slave} -> > Slave; > {error,{already_running,Slave}} -> > Slave > end. > I also have code to delete a file or directory, easy on Linux, darn > difficult on Windows. You don't need this really, just run the test in an > empty directory. > > delete_file(Name) -> > case filelib:is_dir(Name) of > true -> > [delete_file(Name++"/"++X) || X <- list_dir(Name)], > file:del_dir(Name), > delete_file(Name); > {error,eaccess} -> > delete_file(Name); > {error,enoent} -> > io:format("Could not find ~p\n",[Name]), > ok; > false -> > case file:delete(Name) of > {error,enoent} -> > ok; > {error,eacces} -> > io:format("Could not access ~p\n",[Name]), > delete_file(Name); > ok -> > delete_file(Name) > end > end. > > list_dir(Name) -> > case file:list_dir(Name) of > {ok,Files} -> > Files; > {error,eacces} -> > io:format("Could not list directory ~p\n",[Name]), > list_dir(Name); > {error,enoent} -> > io:format("Could not find directory ~p\n",[Name]), > [] > end. > John > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From peppe@REDACTED Tue May 17 21:36:07 2011 From: peppe@REDACTED (Peter Andersson) Date: Tue, 17 May 2011 21:36:07 +0200 Subject: [erlang-bugs] Test server does not restore handlers In-Reply-To: <4DD29DC4.3030307@gmail.com> References: <4DD29DC4.3030307@gmail.com> Message-ID: Hi Richard, Thanks for the report! Creating a ticket now and will attend to it asap. Best regards, Peppe On Tue, 17 May 2011, Richard Carlsson wrote: > The function test_server_ctrl:init/1 calls test_server_h:install(), if SASL > is running, but the corresponding test_server_h:restore() is never called. > When running ct:run_test/1 repeatedly from the shell, the list of handlers > just keeps growing and the old handlers sasl_report_tty_h and > error_logger_tty_h are not restored. > > /Richard > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From carlsson.richard@REDACTED Tue May 17 22:27:01 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 17 May 2011 22:27:01 +0200 Subject: [erlang-bugs] file:pread 0 bytes in raw mode yields eof In-Reply-To: <4DD29D45.80201@gmail.com> References: <4DD29D45.80201@gmail.com> Message-ID: <4DD2DA15.6040202@gmail.com> On 05/17/2011 06:07 PM, Richard Carlsson wrote: > Normally, file:read and file:pread both return an empty list or binary > if the number of bytes to be read is zero, but if the file is opened in > raw mode, trying to read zero bytes yields EOF instead. Clarification: only file:pread yields eof in raw mode. file:read works as normal. Tested on R13B04 and R14B01. /Richard From john.hughes@REDACTED Tue May 17 22:44:23 2011 From: john.hughes@REDACTED (John Hughes) Date: Tue, 17 May 2011 22:44:23 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: From: Ahmed Omar I'm not a mnesia expert, but i THINK the race condition is in the test not mnesia. transaction is still being committed and logged, when the dirty read is issued. if you add a sleep in between or better if you use mnesia:sync_transaction (http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of mnesia:transaction, the test will fail, i.e the case disappear isn't that the expected behavior or am i missing something? Adding a sleep (I added a second) or using sync_transaction instead changes the behaviour to what I would expect, so it sounds as though you may be right about what's happening. But even so, it's not the behaviour I would expect, at least! There isn't any concurrency in the test. There's only distribution--and there's only one copy of the table, on the slave node. Isn't it weird that when the transaction returns, the SAME process that ran the transaction does not see its side effects? By the way, if I swap the last two operations (which Ulf Wiger suggested), then I see the same kind of behaviour... but now the first operation (which is now a dirty_read) actually retrieves the deleted tuple from the table, while the second operation (now the dirty_next) sees no keys in the table. This doesn't happen if the table is on the same node as the test is executed on, so distribution certainly is not transparent in this case. John On Tue, May 17, 2011 at 6:57 PM, John Hughes wrote: QuickCheck turned up another case of odd behaviour at Klarna. The test runs mnesia on two nodes, creates a table on the OTHER node, then adds and deletes a record. After this the record is indeed not IN the table, but dirty_next finds its key anyway! Surely it shouldn't? Here's the test: test() -> Slave = start_mnesia_with_slave(), {atomic,ok} = mnesia:create_table(rec,[{type,set}, {disc_only_copies,[Slave]}]), ok = mnesia:dirty_write({rec,4,1}), %% The next command MUST be done in a transaction, otherwise dirty_next works {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), %% Here's the problem: dirty_next returns 4, but this key is not in the table! 4 = mnesia:dirty_next(rec,0), [] = mnesia:dirty_read(rec,4). I'm starting mnesia and the slave node like this: start_mnesia_with_slave() -> {ok,Dir} = file:get_cwd(), ok = error_logger:tty(false), mnesia:stop(), ok = error_logger:tty(true), delete_file("mnesia"), delete_file("slave"), ok = file:make_dir("mnesia"), ok = file:make_dir("slave"), Slave = slave(), ok = application:set_env(mnesia,dir,Dir++"/mnesia"), ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), ok = mnesia:create_schema([node(),Slave]), ok = mnesia:start(), ok = rpc:call(Slave,mnesia,start,[]), Slave. slave() -> case slave:start_link(net_adm:localhost(),"slave") of {ok,Slave} -> Slave; {error,{already_running,Slave}} -> Slave end. I also have code to delete a file or directory, easy on Linux, darn difficult on Windows. You don't need this really, just run the test in an empty directory. delete_file(Name) -> case filelib:is_dir(Name) of true -> [delete_file(Name++"/"++X) || X <- list_dir(Name)], file:del_dir(Name), delete_file(Name); {error,eaccess} -> delete_file(Name); {error,enoent} -> io:format("Could not find ~p\n",[Name]), ok; false -> case file:delete(Name) of {error,enoent} -> ok; {error,eacces} -> io:format("Could not access ~p\n",[Name]), delete_file(Name); ok -> delete_file(Name) end end. list_dir(Name) -> case file:list_dir(Name) of {ok,Files} -> Files; {error,eacces} -> io:format("Could not list directory ~p\n",[Name]), list_dir(Name); {error,enoent} -> io:format("Could not find directory ~p\n",[Name]), [] end. John _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue May 17 23:32:19 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 17 May 2011 23:32:19 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: Well, it's not the same process. When mnesia find out that : - there are N of updates to commit, - the protocol to use it async - the node of tid is not the local node it spawns a new process to do the commit. On Tue, May 17, 2011 at 10:44 PM, John Hughes wrote: > > > > *From:* Ahmed Omar > ** > I'm not a mnesia expert, but i THINK the race condition is in the test not > mnesia. transaction is still being committed and logged, when the dirty read > is issued. if you add a sleep in between or better if you use > mnesia:sync_transaction ( > http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of > mnesia:transaction, the test will fail, i.e the case disappear > isn't that the expected behavior or am i missing something? > > > Adding a sleep (I added a second) or using sync_transaction instead changes > the behaviour to what I would expect, so it sounds as though you may be > right about what's happening. But even so, it's not the behaviour I would > expect, at least! > > There isn't any concurrency in the test. There's only distribution--and > there's only one copy of the table, on the slave node. Isn't it weird that > when the transaction returns, the SAME process that ran the transaction does > not see its side effects? > > By the way, if I swap the last two operations (which Ulf Wiger suggested), > then I see the same kind of behaviour... but now the first operation (which > is now a dirty_read) actually retrieves the deleted tuple from the table, > while the second operation (now the dirty_next) sees no keys in the table. > > This doesn't happen if the table is on the same node as the test is > executed on, so distribution certainly is not transparent in this case. > > John > > > > > On Tue, May 17, 2011 at 6:57 PM, John Hughes wrote: > >> QuickCheck turned up another case of odd behaviour at Klarna. >> >> The test runs mnesia on two nodes, creates a table on the OTHER node, then >> adds and deletes a record. After this the record is indeed not IN the table, >> but dirty_next finds its key anyway! Surely it shouldn't? >> >> Here's the test: >> >> test() -> >> Slave = start_mnesia_with_slave(), >> {atomic,ok} = mnesia:create_table(rec,[{type,set}, >> {disc_only_copies,[Slave]}]), >> ok = mnesia:dirty_write({rec,4,1}), >> %% The next command MUST be done in a transaction, otherwise >> dirty_next works >> {atomic,ok} = >> mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), >> %% Here's the problem: dirty_next returns 4, but this key is not in >> the table! >> 4 = mnesia:dirty_next(rec,0), >> [] = mnesia:dirty_read(rec,4). >> I'm starting mnesia and the slave node like this: >> >> start_mnesia_with_slave() -> >> {ok,Dir} = file:get_cwd(), >> ok = error_logger:tty(false), >> mnesia:stop(), >> ok = error_logger:tty(true), >> delete_file("mnesia"), >> delete_file("slave"), >> ok = file:make_dir("mnesia"), >> ok = file:make_dir("slave"), >> Slave = slave(), >> ok = application:set_env(mnesia,dir,Dir++"/mnesia"), >> ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), >> ok = mnesia:create_schema([node(),Slave]), >> ok = mnesia:start(), >> ok = rpc:call(Slave,mnesia,start,[]), >> Slave. >> >> slave() -> >> case slave:start_link(net_adm:localhost(),"slave") of >> {ok,Slave} -> >> Slave; >> {error,{already_running,Slave}} -> >> Slave >> end. >> I also have code to delete a file or directory, easy on Linux, darn >> difficult on Windows. You don't need this really, just run the test in an >> empty directory. >> >> delete_file(Name) -> >> case filelib:is_dir(Name) of >> true -> >> [delete_file(Name++"/"++X) || X <- list_dir(Name)], >> file:del_dir(Name), >> delete_file(Name); >> {error,eaccess} -> >> delete_file(Name); >> {error,enoent} -> >> io:format("Could not find ~p\n",[Name]), >> ok; >> false -> >> case file:delete(Name) of >> {error,enoent} -> >> ok; >> {error,eacces} -> >> io:format("Could not access ~p\n",[Name]), >> delete_file(Name); >> ok -> >> delete_file(Name) >> end >> end. >> >> list_dir(Name) -> >> case file:list_dir(Name) of >> {ok,Files} -> >> Files; >> {error,eacces} -> >> io:format("Could not list directory ~p\n",[Name]), >> list_dir(Name); >> {error,enoent} -> >> io:format("Could not find directory ~p\n",[Name]), >> [] >> end. >> John >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> >> > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Wed May 18 08:22:57 2011 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 18 May 2011 08:22:57 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: The lesson is don't use mnesia:dirty api, especially not in a distributed setting. There is a reason dirty is in the name, and really the dirty operations shouldn't exist at all. They are a product of customer need "we don't care if it's correct in all cases but it should be fast". /Dan On Tue, May 17, 2011 at 11:32 PM, Ahmed Omar wrote: > Well, it's not the same process. When mnesia find out that : > - there are N of updates to commit, > - the protocol to use it async > - the node of tid ?is not the local node > > it spawns a new process to do the commit. > > On Tue, May 17, 2011 at 10:44 PM, John Hughes wrote: >> >> >> >> >> From: Ahmed Omar >> I'm not a mnesia expert, but i THINK the race condition is in the test not >> mnesia. transaction is still being committed and logged, when the dirty read >> is issued. if you add a sleep in between or better if you use >> mnesia:sync_transaction >> (http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3)?instead of >> mnesia:transaction,?the test will fail, i.e the case disappear >> isn't that the expected behavior or am i missing something? >> >> >> Adding a sleep (I added a second) or using sync_transaction instead >> changes the behaviour to what I would expect, so it sounds as though you may >> be right about what's happening. But even so,?it's not the behaviour I would >> expect, at least! >> >> There isn't any concurrency in the test. There's only distribution--and >> there's only one copy of the table, on the slave node. Isn't it weird that >> when the transaction returns, the SAME process that ran the transaction does >> not see its side effects? >> >> By the way, if I swap the last two operations (which Ulf Wiger suggested), >> then I see the same kind of behaviour... but now the first operation (which >> is now a dirty_read) actually retrieves the deleted tuple from the table, >> while the second operation (now the dirty_next) sees no keys in the table. >> >> This doesn't happen if the table is on the same node as the test is >> executed on, so distribution certainly is not transparent in this case. >> >> John >> >> >> >> On Tue, May 17, 2011 at 6:57 PM, John Hughes >> wrote: >>> >>> QuickCheck turned up another case of odd behaviour at Klarna. >>> >>> The test runs mnesia on two nodes, creates a table on the OTHER node, >>> then adds and deletes a record. After this the record is indeed not IN the >>> table, but dirty_next finds its key anyway! Surely it shouldn't? >>> >>> Here's the test: >>> >>> test() -> >>> ??? Slave = start_mnesia_with_slave(), >>> ??? {atomic,ok} = mnesia:create_table(rec,[{type,set}, >>> ??????? {disc_only_copies,[Slave]}]), >>> ??? ok????????? = mnesia:dirty_write({rec,4,1}), >>> ??? %% The next command MUST be done in a transaction, otherwise >>> dirty_next works >>> ??? {atomic,ok} = >>> mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), >>> ??? %% Here's the problem: dirty_next returns 4, but this key is not in >>> the table! >>> ??? 4?????????? = mnesia:dirty_next(rec,0), >>> ??? []????????? = mnesia:dirty_read(rec,4). >>> I'm starting mnesia and the slave node like this: >>> >>> start_mnesia_with_slave() -> >>> ??? {ok,Dir} = file:get_cwd(), >>> ??? ok = error_logger:tty(false), >>> ??? mnesia:stop(), >>> ??? ok = error_logger:tty(true), >>> ??? delete_file("mnesia"), >>> ??? delete_file("slave"), >>> ??? ok = file:make_dir("mnesia"), >>> ??? ok = file:make_dir("slave"), >>> ??? Slave = slave(), >>> ??? ok = application:set_env(mnesia,dir,Dir++"/mnesia"), >>> ??? ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), >>> ??? ok = mnesia:create_schema([node(),Slave]), >>> ??? ok = mnesia:start(), >>> ??? ok = rpc:call(Slave,mnesia,start,[]), >>> ??? Slave. >>> >>> slave() -> >>> ??? case slave:start_link(net_adm:localhost(),"slave") of >>> ?{ok,Slave} -> >>> ???? Slave; >>> ?{error,{already_running,Slave}} -> >>> ???? Slave >>> ??? end. >>> I also have code to delete a file or directory, easy on Linux, darn >>> difficult on Windows. You don't need this really, just run the test in an >>> empty directory. >>> >>> delete_file(Name) -> >>> ??? case filelib:is_dir(Name) of >>> ?true -> >>> ???? [delete_file(Name++"/"++X) || X <- list_dir(Name)], >>> ???? file:del_dir(Name), >>> ???? delete_file(Name); >>> ?{error,eaccess} -> >>> ???? delete_file(Name); >>> ?{error,enoent} -> >>> ???? io:format("Could not find ~p\n",[Name]), >>> ???? ok; >>> ?false -> >>> ???? case file:delete(Name) of >>> ??{error,enoent} -> >>> ????? ok; >>> ??{error,eacces} -> >>> ????? io:format("Could not access ~p\n",[Name]), >>> ????? delete_file(Name); >>> ??ok -> >>> ????? delete_file(Name) >>> ???? end >>> ??? end. >>> >>> list_dir(Name) -> >>> ??? case file:list_dir(Name) of >>> ?{ok,Files} -> >>> ???? Files; >>> ?{error,eacces} -> >>> ???? io:format("Could not list directory ~p\n",[Name]), >>> ???? list_dir(Name); >>> ?{error,enoent} -> >>> ???? io:format("Could not find directory ~p\n",[Name]), >>> ???? [] >>> ??? end. >>> John >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> >> >> >> -- >> Best Regards, >> - Ahmed Omar >> http://nl.linkedin.com/in/adiaa >> Follow me on twitter >> @spawn_think > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From ulf.wiger@REDACTED Wed May 18 09:33:29 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 18 May 2011 09:33:29 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: Well, it's the same process that's calling the functions, so usually one would expect a sequential view of the data. However, in the case of transactions vs dirty, it's not quite as clear-cut, and I don't think the documentation has anything to say about this. except to hint that it's unhealthy to mix dirty and transactions too much. I would agree with John that this behaviour is surprising on the surface of it. Perhaps using mnesia:activity(sync_transaction, F) or mnesia:sync_transaction(F) * would make a difference? I'll admit that I haven't tried. * According to the User Guide, "Synced transactions waits until all active replicas has committed the transaction (to disc) before returning from the mnesia:sync_transaction call." BR, Ulf W On 17 May 2011, at 23:32, Ahmed Omar wrote: > Well, it's not the same process. When mnesia find out that : > - there are N of updates to commit, > - the protocol to use it async > - the node of tid is not the local node > > it spawns a new process to do the commit. > > On Tue, May 17, 2011 at 10:44 PM, John Hughes wrote: > > > From: Ahmed Omar > > I'm not a mnesia expert, but i THINK the race condition is in the test not mnesia. transaction is still being committed and logged, when the dirty read is issued. if you add a sleep in between or better if you use mnesia:sync_transaction (http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of mnesia:transaction, the test will fail, i.e the case disappear > isn't that the expected behavior or am i missing something? > > Adding a sleep (I added a second) or using sync_transaction instead changes the behaviour to what I would expect, so it sounds as though you may be right about what's happening. But even so, it's not the behaviour I would expect, at least! > > There isn't any concurrency in the test. There's only distribution--and there's only one copy of the table, on the slave node. Isn't it weird that when the transaction returns, the SAME process that ran the transaction does not see its side effects? > > By the way, if I swap the last two operations (which Ulf Wiger suggested), then I see the same kind of behaviour... but now the first operation (which is now a dirty_read) actually retrieves the deleted tuple from the table, while the second operation (now the dirty_next) sees no keys in the table. > > This doesn't happen if the table is on the same node as the test is executed on, so distribution certainly is not transparent in this case. > > John > > > > > On Tue, May 17, 2011 at 6:57 PM, John Hughes wrote: > QuickCheck turned up another case of odd behaviour at Klarna. > > The test runs mnesia on two nodes, creates a table on the OTHER node, then adds and deletes a record. After this the record is indeed not IN the table, but dirty_next finds its key anyway! Surely it shouldn't? > > Here's the test: > > test() -> > Slave = start_mnesia_with_slave(), > {atomic,ok} = mnesia:create_table(rec,[{type,set}, > {disc_only_copies,[Slave]}]), > ok = mnesia:dirty_write({rec,4,1}), > %% The next command MUST be done in a transaction, otherwise dirty_next works > {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), > %% Here's the problem: dirty_next returns 4, but this key is not in the table! > 4 = mnesia:dirty_next(rec,0), > [] = mnesia:dirty_read(rec,4). > I'm starting mnesia and the slave node like this: > > start_mnesia_with_slave() -> > {ok,Dir} = file:get_cwd(), > ok = error_logger:tty(false), > mnesia:stop(), > ok = error_logger:tty(true), > delete_file("mnesia"), > delete_file("slave"), > ok = file:make_dir("mnesia"), > ok = file:make_dir("slave"), > Slave = slave(), > ok = application:set_env(mnesia,dir,Dir++"/mnesia"), > ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), > ok = mnesia:create_schema([node(),Slave]), > ok = mnesia:start(), > ok = rpc:call(Slave,mnesia,start,[]), > Slave. > > slave() -> > case slave:start_link(net_adm:localhost(),"slave") of > {ok,Slave} -> > Slave; > {error,{already_running,Slave}} -> > Slave > end. > I also have code to delete a file or directory, easy on Linux, darn difficult on Windows. You don't need this really, just run the test in an empty directory. > > delete_file(Name) -> > case filelib:is_dir(Name) of > true -> > [delete_file(Name++"/"++X) || X <- list_dir(Name)], > file:del_dir(Name), > delete_file(Name); > {error,eaccess} -> > delete_file(Name); > {error,enoent} -> > io:format("Could not find ~p\n",[Name]), > ok; > false -> > case file:delete(Name) of > {error,enoent} -> > ok; > {error,eacces} -> > io:format("Could not access ~p\n",[Name]), > delete_file(Name); > ok -> > delete_file(Name) > end > end. > > list_dir(Name) -> > case file:list_dir(Name) of > {ok,Files} -> > Files; > {error,eacces} -> > io:format("Could not list directory ~p\n",[Name]), > list_dir(Name); > {error,enoent} -> > io:format("Could not find directory ~p\n",[Name]), > [] > end. > John > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > > > > -- > Best Regards, > - Ahmed Omar > http://nl.linkedin.com/in/adiaa > Follow me on twitter > @spawn_think > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Wed May 18 09:56:48 2011 From: john.hughes@REDACTED (John Hughes) Date: Wed, 18 May 2011 09:56:48 +0200 Subject: [erlang-bugs] Funny behaviour of dirty_next in mnesia? In-Reply-To: References: <754779C297FA46F18A4E6FD98DC91892@JohnsTablet2009> Message-ID: <66210E915EFE4DD7A34A871190427746@JohnsTablet2009> From: Ulf Wiger Well, it's the same process that's calling the functions, so usually one would expect a sequential view of the data. However, in the case of transactions vs dirty, it's not quite as clear-cut, and I don't think the documentation has anything to say about this. except to hint that it's unhealthy to mix dirty and transactions too much. I would agree with John that this behaviour is surprising on the surface of it. Perhaps using mnesia:activity(sync_transaction, F) or mnesia:sync_transaction(F) * would make a difference? I'll admit that I haven't tried. * According to the User Guide, "Synced transactions waits until all active replicas has committed the transaction (to disc) before returning from the mnesia:sync_transaction call." BR, Ulf W Yes, using sync_transaction makes the example behave as I would expect. So does doing the guilty operation in a transaction instead of as a dirty read or next. So it seems the lesson is: don't use dirty operations and transactions together, if you expect a sequential view of the data. John On 17 May 2011, at 23:32, Ahmed Omar wrote: Well, it's not the same process. When mnesia find out that : - there are N of updates to commit, - the protocol to use it async - the node of tid is not the local node it spawns a new process to do the commit. On Tue, May 17, 2011 at 10:44 PM, John Hughes wrote: From: Ahmed Omar I'm not a mnesia expert, but i THINK the race condition is in the test not mnesia. transaction is still being committed and logged, when the dirty read is issued. if you add a sleep in between or better if you use mnesia:sync_transaction (http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of mnesia:transaction, the test will fail, i.e the case disappear isn't that the expected behavior or am i missing something? Adding a sleep (I added a second) or using sync_transaction instead changes the behaviour to what I would expect, so it sounds as though you may be right about what's happening. But even so, it's not the behaviour I would expect, at least! There isn't any concurrency in the test. There's only distribution--and there's only one copy of the table, on the slave node. Isn't it weird that when the transaction returns, the SAME process that ran the transaction does not see its side effects? By the way, if I swap the last two operations (which Ulf Wiger suggested), then I see the same kind of behaviour... but now the first operation (which is now a dirty_read) actually retrieves the deleted tuple from the table, while the second operation (now the dirty_next) sees no keys in the table. This doesn't happen if the table is on the same node as the test is executed on, so distribution certainly is not transparent in this case. John On Tue, May 17, 2011 at 6:57 PM, John Hughes wrote: QuickCheck turned up another case of odd behaviour at Klarna. The test runs mnesia on two nodes, creates a table on the OTHER node, then adds and deletes a record. After this the record is indeed not IN the table, but dirty_next finds its key anyway! Surely it shouldn't? Here's the test: test() -> Slave = start_mnesia_with_slave(), {atomic,ok} = mnesia:create_table(rec,[{type,set}, {disc_only_copies,[Slave]}]), ok = mnesia:dirty_write({rec,4,1}), %% The next command MUST be done in a transaction, otherwise dirty_next works {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end), %% Here's the problem: dirty_next returns 4, but this key is not in the table! 4 = mnesia:dirty_next(rec,0), [] = mnesia:dirty_read(rec,4). I'm starting mnesia and the slave node like this: start_mnesia_with_slave() -> {ok,Dir} = file:get_cwd(), ok = error_logger:tty(false), mnesia:stop(), ok = error_logger:tty(true), delete_file("mnesia"), delete_file("slave"), ok = file:make_dir("mnesia"), ok = file:make_dir("slave"), Slave = slave(), ok = application:set_env(mnesia,dir,Dir++"/mnesia"), ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]), ok = mnesia:create_schema([node(),Slave]), ok = mnesia:start(), ok = rpc:call(Slave,mnesia,start,[]), Slave. slave() -> case slave:start_link(net_adm:localhost(),"slave") of {ok,Slave} -> Slave; {error,{already_running,Slave}} -> Slave end. I also have code to delete a file or directory, easy on Linux, darn difficult on Windows. You don't need this really, just run the test in an empty directory. delete_file(Name) -> case filelib:is_dir(Name) of true -> [delete_file(Name++"/"++X) || X <- list_dir(Name)], file:del_dir(Name), delete_file(Name); {error,eaccess} -> delete_file(Name); {error,enoent} -> io:format("Could not find ~p\n",[Name]), ok; false -> case file:delete(Name) of {error,enoent} -> ok; {error,eacces} -> io:format("Could not access ~p\n",[Name]), delete_file(Name); ok -> delete_file(Name) end end. list_dir(Name) -> case file:list_dir(Name) of {ok,Files} -> Files; {error,eacces} -> io:format("Could not list directory ~p\n",[Name]), list_dir(Name); {error,enoent} -> io:format("Could not find directory ~p\n",[Name]), [] end. John _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.girondel@REDACTED Fri May 20 02:59:19 2011 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Fri, 20 May 2011 02:59:19 +0200 Subject: [erlang-bugs] ei_decode_list_header and big lists Message-ID: What if... I send a big list (eg, 80000 elements) to a C-port ? According to http://www.erlang.org/doc/man/ei.html#ei_decode_list_header the list length will be stored into an "int", which obviously will lead to strange behavior ? Am I missing something ? -- Olivier / http://biniou.net From egil@REDACTED Fri May 20 10:44:34 2011 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 20 May 2011 10:44:34 +0200 Subject: [erlang-bugs] ei_decode_list_header and big lists In-Reply-To: References: Message-ID: <4DD629F2.7000708@erix.ericsson.se> On 2011-05-20 02:59, Olivier Girondel wrote: > What if... > > I send a big list (eg, 80000 elements) to a C-port ? > > According to > http://www.erlang.org/doc/man/ei.html#ei_decode_list_header > > the list length will be stored into an "int", > which obviously will lead to strange behavior ? Well, the length should probably be stored as an Uint32 in ei but it isn't, clearly a miss. An int on most C compilers will be a signed 32-bit integer, so all the bits and pieces will be there. But, with the wrong type ... Reference, http://www.erlang.org/doc/apps/erts/erl_ext_dist.html Regards, Bj?rn-Egil From norton@REDACTED Fri May 20 12:44:55 2011 From: norton@REDACTED (Joseph Wayne Norton) Date: Fri, 20 May 2011 19:44:55 +0900 Subject: [erlang-bugs] typo in R14B03 ssl.erl Message-ID: Hello. There is a typo in the R14B03 ssl.erl module. "proplist:property()" should be "proplists:property()" ... correct? https://github.com/erlang/otp/commit/adcf5eb5f43ed83a0bb9aacdffa155c0b02ed0c3 I noticed this issue when building a new dialyzer PLT for R14B03. See the "$(PLT):" make target in Makefile (https://github.com/hibari/hibari/blob/master/Makefile). Unknown types: proplist:property/0 done in 30m0.46s done (warnings were emitted) make: *** [~/.dialyzer_plt.R14B03] Error 2 $ find otp -name "*.erl" -exec grep 'proplist:property()' {} \; -print -spec setopts(#sslsocket{}, [proplist:property()]) -> ok | {error, reason()}. ~/otp/lib/ssl/src/ssl.erl thanks, Joe N -- norton@REDACTED From radek.bulat@REDACTED Fri May 20 14:45:52 2011 From: radek.bulat@REDACTED (=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?=) Date: Fri, 20 May 2011 14:45:52 +0200 Subject: [erlang-bugs] typer crash for <<_:32, _:_*8>> In-Reply-To: <4DD59D3A.2000008@cs.ntua.gr> References: <4DD59D3A.2000008@cs.ntua.gr> Message-ID: 2011/5/20 Kostis Sagonas : > > Can you please try OTP's 'dev' version and tell me what's happening? > I think this problem has been fixed since about a month ago. > > Kostis > I've downloaded otp from http://github.com/erlang/otp/ build it with "./otp_build setup" and run: $ ~/opt/src/otp/bin/i386-apple-darwin10.7.0/typer --show erlangbug.erl # without "/i386-apple-darwin10.7.0/" part it give me "{"init terminating in do_boot",{undef,[{typer,start,[]},{init,start_it,1},{init,start_em,1}]}}" error %% File: "erlangbug.erl" %% --------------------- {"init terminating in do_boot",{{case_clause,8},[{erl_types,t_form_to_string,1},{erl_types,t_form_to_string,1},{dialyzer_contracts,contract_to_string_1,1},{typer,get_type_string,4},{typer,'-show_type_info/2-fun-0-',2},{lists,foreach,2},{typer,start,0},{init,start_it,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () It look like this problem still exists. -- Pozdrawiam Rados?aw Bu?at http://radarek.jogger.pl - m?j blog From kostis@REDACTED Fri May 20 15:07:21 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 20 May 2011 16:07:21 +0300 Subject: [erlang-bugs] typer crash for <<_:32, _:_*8>> In-Reply-To: References: <4DD59D3A.2000008@cs.ntua.gr> Message-ID: <4DD66789.90300@cs.ntua.gr> Rados?aw Bu?at wrote: > 2011/5/20 Kostis Sagonas : >> Can you please try OTP's 'dev' version and tell me what's happening? >> I think this problem has been fixed since about a month ago. >> >> Kostis >> > > I've downloaded otp from http://github.com/erlang/otp/ build it with > "./otp_build setup" and run: > > $ ~/opt/src/otp/bin/i386-apple-darwin10.7.0/typer --show erlangbug.erl > # without "/i386-apple-darwin10.7.0/" part it give me "{"init > terminating in do_boot",{undef,[{typer,start,[]},{init,start_it,1},{init,start_em,1}]}}" > error > > %% File: "erlangbug.erl" > %% --------------------- > {"init terminating in > do_boot",{{case_clause,8},[{erl_types,t_form_to_string,1},{erl_types,t_form_to_string,1},{dialyzer_contracts,contract_to_string_1,1},{typer,get_type_string,4},{typer,'-show_type_info/2-fun-0-',2},{lists,foreach,2},{typer,start,0},{init,start_it,1}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > > It look like this problem still exists. Neither I nor any other person I know of and have asked to check this was able to reproduce the problem. Looks like you have some left over typer from a previous build. Do: make clean ./otp_build autoconf ./configure make and then run the typer which is in otp/bin/typer Kostis From radek.bulat@REDACTED Fri May 20 19:41:28 2011 From: radek.bulat@REDACTED (=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?=) Date: Fri, 20 May 2011 19:41:28 +0200 Subject: [erlang-bugs] typer crash for <<_:32, _:_*8>> In-Reply-To: <4DD66789.90300@cs.ntua.gr> References: <4DD59D3A.2000008@cs.ntua.gr> <4DD66789.90300@cs.ntua.gr> Message-ID: 2011/5/20 Kostis Sagonas : > Neither I nor any other person I know of and have asked to check this was > able to reproduce the problem. Looks like you have some left over typer from > a previous build. > > Do: > > ? ? ? ?make clean > ? ? ? ?./otp_build autoconf > ? ? ? ?./configure > ? ? ? ?make > > and then run the typer which is in otp/bin/typer > I did as you tell me and it works ok. So on master of otp repo there is no such a bug. Thank you very much. -- Pozdrawiam Rados?aw Bu?at http://radarek.jogger.pl - m?j blog From michael.santos@REDACTED Tue May 24 18:04:16 2011 From: michael.santos@REDACTED (Michael Santos) Date: Tue, 24 May 2011 12:04:16 -0400 Subject: [erlang-bugs] ei_decode_list_header and big lists In-Reply-To: <4DD629F2.7000708@erix.ericsson.se> References: <4DD629F2.7000708@erix.ericsson.se> Message-ID: <20110524160416.GB2526@ecn.lan> On Fri, May 20, 2011 at 10:44:34AM +0200, Bj?rn-Egil Dahlberg wrote: > On 2011-05-20 02:59, Olivier Girondel wrote: > >What if... > > > >I send a big list (eg, 80000 elements) to a C-port ? > > > >According to > >http://www.erlang.org/doc/man/ei.html#ei_decode_list_header > > > >the list length will be stored into an "int", > >which obviously will lead to strange behavior ? > > Well, the length should probably be stored as an Uint32 in ei but it > isn't, clearly a miss. An int on most C compilers will be a signed > 32-bit integer, so all the bits and pieces will be there. But, with > the wrong type ... > > Reference, http://www.erlang.org/doc/apps/erts/erl_ext_dist.html The index is an int and so can overflow as well. There are a few other changes that would make ei safer to use: 1. ei_encode_string and ei_encode_atom use strlen() to get the length of the buffer. It looks as if a size_t is an unsigned long long which can overflow the length in ei_encode_string_len. I guess the appropriate thing to do here is to check if strlen(buf) >= INT_MAX. 2. There doesn't seem to be a safe way to call ei_get_type() on some types. For example, the encoded version of the binary <<"foo">> is: <<131,109,0,0,0,3,102,111,111>> If I send fake data like: <<131,109,255,255,255,255,102,111,111>> The size parameter (a signed int) in ei_get_type() will overflow. The ei doc has a nice warning about having an appropriate buffer size. Might be nice to have an example of using ei safely as well. Something like using ei_get_type() to get the message length and failing if it exceeds the caller's expectations: n = read(socket, buf, 1024); ei_get_type(buf, &index, &type, &size); if (size > n) errx(EXIT_FAILURE, "ei length > buf size!"); This still isn't quite right though because it doesn't include the size of the message header. So maybe a new function like ei_get_message_len() is needed. Not sure if anyone is using ei with untrusted data, so these aren't a huge concern. From ferenc.holzhauser@REDACTED Fri May 27 15:03:26 2011 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Fri, 27 May 2011 15:03:26 +0200 Subject: [erlang-bugs] ssl_manager:invalidate_session issues Message-ID: Hi, After upgrading to R14B03 I got these errors: =ERROR REPORT==== 27-May-2011::13:48:25 === Error in process <0.10933.0> on node 'mynodename' with exit value: {undef,[{ssl_session_cache,delete,[{{"remotehost",995},<<32 bytes>>}]}]} The problem seems to be this recently modified part of the ssl_manager: handle_cast({invalidate_session, Host, Port, #session{session_id = ID} = Session}, #state{session_cache = Cache, session_cache_cb = CacheCb} = State) -> CacheCb:update(Cache, {{Host, Port}, ID}, Session#session{is_resumable = false}), >>> timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, [{{Host, Port}, ID}]), <<< {noreply, State}; handle_cast({invalidate_session, Port, #session{session_id = ID} = Session}, #state{session_cache = Cache, session_cache_cb = CacheCb} = State) -> CacheCb:update(Cache, {Port, ID}, Session#session{is_resumable = false}), >>> timer:apply_after(?CLEAN_SESSION_DB, CacheCb, delete, [{Port, ID}]), <<< {noreply, State}; One issue is a typo : missing the Cache from the arguments expected in ssl_session_cache:delete(Cache,Key) Other one is the timer:appy which creates a new timer process and would fail to access the protected table from it This fix works in my environment: handle_cast({invalidate_session, Host, Port, #session{session_id = ID} = Session}, #state{session_cache = Cache, session_cache_cb = CacheCb} = State) -> CacheCb:update(Cache, {{Host, Port}, ID}, Session#session{is_resumable = false}), timer:send_after(?CLEAN_SESSION_DB, self(), {delayed_clean_session, {{Host, Port}, ID}}), {noreply, State}; handle_cast({invalidate_session, Port, #session{session_id = ID} = Session}, #state{session_cache = Cache, session_cache_cb = CacheCb} = State) -> CacheCb:update(Cache, {Port, ID}, Session#session{is_resumable = false}), timer:send_after(?CLEAN_SESSION_DB, self(), {delayed_clean_session, {Port, ID}}), {noreply, State}; %% additional handle_info for delayed session cleaning handle_info({delayed_clean_session, Key}, #state{session_cache = Cache, session_cache_cb = CacheCb } = State) -> CacheCb:delete(Cache, Key), {noreply, State}; Kind Regards, Ferenc -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue May 31 12:15:53 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 31 May 2011 12:15:53 +0200 Subject: [erlang-bugs] file:pread 0 bytes in raw mode yields eof In-Reply-To: <4DB1E2F4.1050603@gmail.com> References: <4DB1DB74.1000107@gmail.com> <4DB1E2F4.1050603@gmail.com> Message-ID: <4DE4BFD9.1010201@gmail.com> On 04/22/2011 10:20 PM, Richard Carlsson wrote: > On 04/22/2011 09:48 PM, Richard Carlsson wrote: >> Normally, file:read and file:pread both return an empty list or binary >> if the number of bytes to be read is zero, but if the file is opened in >> raw mode, trying to read zero bytes yields EOF instead. > > Clarification: only file:pread yields eof in raw mode. file:read works > as normal. Tested on R13B04 and R14B01. Did anybody at OTP notice this mail? I've had no feedback. /Richard From elinsn@REDACTED Tue May 31 12:36:33 2011 From: elinsn@REDACTED (Sergey Yelin) Date: Tue, 31 May 2011 14:36:33 +0400 Subject: [erlang-bugs] snmp:config() error Message-ID: Hi, trying to setup simple snmp agent and manager via snmp:config() as described in "Simple Network Management Protocol (SNMP) 4.20" PDF file (leaving missing lines with defaults) with no luck. Here is error report: 8. Current configuration files will now be overwritten. Ok (y/n)? [y] - - - - - - - - - - - - - The following manager files were written: manager.conf, agents.conf , users.conf and usm.conf - - - - - - - - - - - - - -------------------- Configuration directory for system file (absolute path)? [/home/selin] /home/selin/Projects/snmp {error, {failed, {'EXIT', {function_clause, [{snmp_config,write_sys_config_file_manager_atl_opt, [<0.66.0>,{seqno,false}]}, {snmp_config,write_sys_config_file_manager_atl_opts,2}, {snmp_config,write_sys_config_file_manager_opt,2}, {snmp_config,write_sys_config_file_manager_opts,2}, {snmp_config,write_sys_config_file_service,2}, {snmp_config,write_sys_config_file_services,2}, {snmp_config,write_sys_config_file,2}, {snmp_config,config2,0}]}}}} But this configuration method works well without configuring audit trail log both for agent and manager. Checked on Erlang 14B03 and 14B02. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Tue May 31 13:29:23 2011 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Tue, 31 May 2011 13:29:23 +0200 Subject: [erlang-bugs] file:pread 0 bytes in raw mode yields eof In-Reply-To: <4DE4BFD9.1010201@gmail.com> References: <4DB1DB74.1000107@gmail.com> <4DB1E2F4.1050603@gmail.com> <4DE4BFD9.1010201@gmail.com> Message-ID: <20110531112923.GA9523@erix.ericsson.se> On Tue, May 31, 2011 at 12:15:53PM +0200, Richard Carlsson wrote: > On 04/22/2011 10:20 PM, Richard Carlsson wrote: > >On 04/22/2011 09:48 PM, Richard Carlsson wrote: > >>Normally, file:read and file:pread both return an empty list or binary > >>if the number of bytes to be read is zero, but if the file is opened in > >>raw mode, trying to read zero bytes yields EOF instead. > > > >Clarification: only file:pread yields eof in raw mode. file:read works > >as normal. Tested on R13B04 and R14B01. > > Did anybody at OTP notice this mail? I've had no feedback. Yes, I did. I tagged it as important and moved on. Sorry about that. This time I created a ticket of type Bug. > > /Richard > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB