From kostis@REDACTED Wed Feb 2 11:50:49 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 02 Feb 2011 12:50:49 +0200 Subject: [erlang-bugs] HiPE bug with comparison of floats with integers In-Reply-To: References: Message-ID: <4D493709.7050909@cs.ntua.gr> Paul Guyot wrote: > Hello, > > There is a bug in HiPE compilation with the comparison of floats with integers. > This bug happens with the following two functions: > > ------ > -module(hipe_zero). > -export([f/1, g/2]). > > f(X) -> > Y = X / 2, > Y == 0. > > g(X, Z) -> > Y = X / 2, > case Z of > test when Y == 0 -> test_zero; > test -> test_non_zero; > other -> other > end. > ------ > > Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE properly evaluates hipe_zero:f/1 to true if passed {icode_inline_bifs, false}. However, not inlining the '==' bif just masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) to test_zero. This has now been fixed. The relevant fetch command is: git fetch git://github.com/kostis/otp.git icode-range-fix If one wants to apply the change manually to a previous OTP version, the last commit on that branch shows the fix that needs to be applied (basically change two calls in hipe_icode_range.erl from lists:any/2 to calls to lists:all/2). Thanks to Paul for reporting this. Kostis From burbas@REDACTED Wed Feb 2 17:15:36 2011 From: burbas@REDACTED (Niclas Axelsson) Date: Wed, 2 Feb 2011 17:15:36 +0100 Subject: [erlang-patches] Re: [erlang-bugs] HiPE bug with comparison of floats with integers In-Reply-To: <4D493709.7050909@cs.ntua.gr> References: <4D493709.7050909@cs.ntua.gr> Message-ID: <4D498328.5010209@erlang.org> On 02/02/2011 11:50 AM, Kostis Sagonas wrote: > Paul Guyot wrote: >> Hello, >> >> There is a bug in HiPE compilation with the comparison of floats with >> integers. >> This bug happens with the following two functions: >> >> ------ >> -module(hipe_zero). >> -export([f/1, g/2]). >> >> f(X) -> >> Y = X / 2, >> Y == 0. >> >> g(X, Z) -> >> Y = X / 2, >> case Z of >> test when Y == 0 -> test_zero; >> test -> test_non_zero; >> other -> other >> end. >> ------ >> >> Beam will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to true, while >> HiPE will evaluate hipe_zero:f(0) and hipe_zero:f(0.0) to false. HiPE >> properly evaluates hipe_zero:f/1 to true if passed >> {icode_inline_bifs, false}. However, not inlining the '==' bif just >> masks the bug as HiPE does not properly evaluate hipe_zero:g(0, test) >> to test_zero. > > This has now been fixed. The relevant fetch command is: > > git fetch git://github.com/kostis/otp.git icode-range-fix > > If one wants to apply the change manually to a previous OTP version, > the last commit on that branch shows the fix that needs to be applied > (basically change two calls in hipe_icode_range.erl from lists:any/2 > to calls to lists:all/2). > > Thanks to Paul for reporting this. > > Kostis > > ________________________________________________________________ > erlang-patches (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED Thanks Kostis and Paul, The patch is now included into 'pu'. Regards, Niclas Axelsson, Erlang/OTP From kruber@REDACTED Thu Feb 3 11:36:42 2011 From: kruber@REDACTED (Nico Kruber) Date: Thu, 3 Feb 2011 11:36:42 +0100 Subject: dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... Message-ID: <201102031136.47707.kruber@zib.de> I ran into the following error with the dialyzer, today - maybe you can give me a hint on what is wrong or maybe it is even a bug in the dialyzer(?) ---------- Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes Proceeding with analysis... =ERROR REPORT==== 3-Feb-2011::11:19:57 === Error in process <0.29.0> with exit value: {{badmatch,none},[{erl_types,t_limit_k,2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,t_limit_k,2},{dialyzer_typesig,enter_type,3},{dialyzer_typesig,enter_type_list,2},{dialyzer_typesig... dialyzer: Analysis failed with error: {{badmatch,none}, [{erl_types,t_limit_k,2}, {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, {erl_types,t_limit_k,2}, {dialyzer_typesig,enter_type,3}, {dialyzer_typesig,enter_type_list,2}, {dialyzer_typesig,solve_subtype,...}, {dialyzer_typesig,...}]} Last messages in the log cache: Typesig analysis for SCC: [{group_tob,module_info,0}] Typesig analysis for SCC: [{group_tob,module_info,1}] Typesig analysis for SCC: [{group_tob,is_current_decision,2}] Typesig analysis for SCC: [{group_tob,is_past_decision,2}] Typesig analysis for SCC: [{group_tob,is_decision_from_other_group_id,2}] Typesig analysis for SCC: [{mockup_dht_node,module_state_to_my_state,2}] Typesig analysis for SCC: [{mockup_dht_node,module_info,1}] Typesig analysis for SCC: [{mockup_dht_node,start_link,2}] Typesig analysis for SCC: [{mockup_dht_node,module_info,0}] Typesig analysis for SCC: [{mockup_dht_node,on,2}] ---------- Regards, Nico Kruber -------------- 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 kostis@REDACTED Thu Feb 3 12:02:53 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 03 Feb 2011 13:02:53 +0200 Subject: [erlang-bugs] dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... In-Reply-To: <201102031136.47707.kruber@zib.de> References: <201102031136.47707.kruber@zib.de> Message-ID: <4D4A8B5D.7030102@cs.ntua.gr> Nico Kruber wrote: > I ran into the following error with the dialyzer, today - maybe you can give me a hint on what is wrong or maybe it is even a bug in the dialyzer(?) Of course it's a bug of some sort in dialyzer. The program should not crash under any circumstances. But I/we cannot be of more help without more information. You've really given us nothing here. Which OTP version is this? What does your PLT contain? How does your program look like? ... What I suggest you do is to check whether you get the same error with OTP's 'dev' version from GitHub. If it is still there, send me, preferably off list, a (minimized) test case that shows the problem and information on what the PLT should contain in order to be able to reproduce and hopefully fix this soon. If the problem does not appear in 'dev', sorry but you are on your own to find out which change fixes this. Best, Kostis From kruber@REDACTED Thu Feb 3 12:08:14 2011 From: kruber@REDACTED (Nico Kruber) Date: Thu, 3 Feb 2011 12:08:14 +0100 Subject: [erlang-bugs] dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... In-Reply-To: <201102031136.47707.kruber@zib.de> References: <201102031136.47707.kruber@zib.de> Message-ID: <201102031208.20501.kruber@zib.de> sorry, I forgot to mention how to reproduce it.I suppose, I cannot create a minimal case since this is some limit (?), but you can test it using our code base: svn checkout http://scalaris.googlecode.com/svn/trunk/ scalaris cd scalaris ./configure dialyzer -Dtid_not_builtin -Dwith_export_type_support -Werror_handling -Wrace_conditions -Wunmatched_returns -I include/ -I contrib/yaws/include/ -I contrib/log4erl/include/ --src -c src src/*/ test/unittest_helper.erl test/tester*.erl test/mockup*.erl (this is for R14B01) without the test/mockup*.erl modules, dialyzer runs fine... On Thursday 03 February 2011 11:36:42 Nico Kruber wrote: > I ran into the following error with the dialyzer, today - maybe you can give me a hint on what is wrong or maybe it is even a bug in the dialyzer(?) > ---------- > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > Proceeding with analysis... > =ERROR REPORT==== 3-Feb-2011::11:19:57 === > Error in process <0.29.0> with exit value: {{badmatch,none},[{erl_types,t_limit_k,2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,t_limit_k,2},{dialyzer_typesig,enter_type,3},{dialyzer_typesig,enter_type_list,2},{dialyzer_typesig... > > > dialyzer: Analysis failed with error: {{badmatch,none}, > [{erl_types,t_limit_k,2}, > {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, > {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, > {erl_types,t_limit_k,2}, > {dialyzer_typesig,enter_type,3}, > {dialyzer_typesig,enter_type_list,2}, > {dialyzer_typesig,solve_subtype,...}, > {dialyzer_typesig,...}]} > Last messages in the log cache: > Typesig analysis for SCC: [{group_tob,module_info,0}] > Typesig analysis for SCC: [{group_tob,module_info,1}] > Typesig analysis for SCC: [{group_tob,is_current_decision,2}] > Typesig analysis for SCC: [{group_tob,is_past_decision,2}] > Typesig analysis for SCC: [{group_tob,is_decision_from_other_group_id,2}] > Typesig analysis for SCC: [{mockup_dht_node,module_state_to_my_state,2}] > Typesig analysis for SCC: [{mockup_dht_node,module_info,1}] > Typesig analysis for SCC: [{mockup_dht_node,start_link,2}] > Typesig analysis for SCC: [{mockup_dht_node,module_info,0}] > Typesig analysis for SCC: [{mockup_dht_node,on,2}] > ---------- > > Regards, > Nico Kruber -------------- 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 Feb 3 12:14:50 2011 From: kruber@REDACTED (Nico Kruber) Date: Thu, 3 Feb 2011 12:14:50 +0100 Subject: [erlang-bugs] dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... In-Reply-To: <201102031208.20501.kruber@zib.de> References: <201102031136.47707.kruber@zib.de> <201102031208.20501.kruber@zib.de> Message-ID: <201102031214.51104.kruber@zib.de> attached is a (compressed) version of my plt's contents On Thursday 03 February 2011 12:08:14 Nico Kruber wrote: > sorry, I forgot to mention how to reproduce it.I suppose, I cannot create a minimal case since this is some limit (?), but you can test it using our code base: > svn checkout http://scalaris.googlecode.com/svn/trunk/ scalaris > cd scalaris > ./configure > dialyzer -Dtid_not_builtin -Dwith_export_type_support -Werror_handling -Wrace_conditions -Wunmatched_returns -I include/ -I contrib/yaws/include/ -I contrib/log4erl/include/ --src -c src src/*/ test/unittest_helper.erl test/tester*.erl test/mockup*.erl > > (this is for R14B01) > > without the test/mockup*.erl modules, dialyzer runs fine... > > > On Thursday 03 February 2011 11:36:42 Nico Kruber wrote: > > I ran into the following error with the dialyzer, today - maybe you can give me a hint on what is wrong or maybe it is even a bug in the dialyzer(?) > > ---------- > > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > > Proceeding with analysis... > > =ERROR REPORT==== 3-Feb-2011::11:19:57 === > > Error in process <0.29.0> with exit value: {{badmatch,none},[{erl_types,t_limit_k,2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,t_limit_k,2},{dialyzer_typesig,enter_type,3},{dialyzer_typesig,enter_type_list,2},{dialyzer_typesig... > > > > > > dialyzer: Analysis failed with error: {{badmatch,none}, > > [{erl_types,t_limit_k,2}, > > {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, > > {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, > > {erl_types,t_limit_k,2}, > > {dialyzer_typesig,enter_type,3}, > > {dialyzer_typesig,enter_type_list,2}, > > {dialyzer_typesig,solve_subtype,...}, > > {dialyzer_typesig,...}]} > > Last messages in the log cache: > > Typesig analysis for SCC: [{group_tob,module_info,0}] > > Typesig analysis for SCC: [{group_tob,module_info,1}] > > Typesig analysis for SCC: [{group_tob,is_current_decision,2}] > > Typesig analysis for SCC: [{group_tob,is_past_decision,2}] > > Typesig analysis for SCC: [{group_tob,is_decision_from_other_group_id,2}] > > Typesig analysis for SCC: [{mockup_dht_node,module_state_to_my_state,2}] > > Typesig analysis for SCC: [{mockup_dht_node,module_info,1}] > > Typesig analysis for SCC: [{mockup_dht_node,start_link,2}] > > Typesig analysis for SCC: [{mockup_dht_node,module_info,0}] > > Typesig analysis for SCC: [{mockup_dht_node,on,2}] > > ---------- > > > > Regards, > > Nico Kruber -------------- next part -------------- A non-text attachment was scrubbed... Name: plt.info.gz Type: application/x-gzip Size: 6485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From anthony.shipman@REDACTED Fri Feb 4 02:21:18 2011 From: anthony.shipman@REDACTED (anthony.shipman@REDACTED) Date: Fri, 4 Feb 2011 12:21:18 +1100 Subject: [erlang-bugs] dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... In-Reply-To: <201102031136.47707.kruber@zib.de> References: <201102031136.47707.kruber@zib.de> Message-ID: <201102041221.18271.anthony.shipman@symstream.com> On Thursday 03 February 2011 21:36, Nico Kruber wrote: > I ran into the following error with the dialyzer, today - maybe you can > give me a hint on what is wrong or maybe it is even a bug in the > dialyzer(?) ---------- > ? Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > ? Proceeding with analysis... > =ERROR REPORT==== 3-Feb-2011::11:19:57 === > Error in process <0.29.0> with exit value: > {{badmatch,none},[{erl_types,t_limit_k,2},{erl_types,'-t_limit_k/2-lc$^0/1- >2-',2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,t_limit_k,2},{dial >yzer_typesig,enter_type,3},{dialyzer_typesig,enter_type_list,2},{dialyzer_ty >pesig... > > > dialyzer: Analysis failed with error: {{badmatch,none}, > ?[{erl_types,t_limit_k,2}, > ? {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, When I get an error like this it is usually due to a .beam file whose name does not match the module name. -- Anthony Shipman | Will take your health responsibility Anthony.Shipman@REDACTED | by the superlative quality From kruber@REDACTED Fri Feb 4 07:39:49 2011 From: kruber@REDACTED (Nico Kruber) Date: Fri, 4 Feb 2011 07:39:49 +0100 Subject: [erlang-bugs] dialyzer: {{badmatch,none},[{erl_types,t_limit_k,2},... In-Reply-To: <201102041221.18271.anthony.shipman@symstream.com> References: <201102031136.47707.kruber@zib.de> <201102041221.18271.anthony.shipman@symstream.com> Message-ID: <201102040740.14095.kruber@zib.de> On Friday 04 February 2011 02:21:18 anthony.shipman@REDACTED wrote: > On Thursday 03 February 2011 21:36, Nico Kruber wrote: > > I ran into the following error with the dialyzer, today - maybe you can > > give me a hint on what is wrong or maybe it is even a bug in the > > dialyzer(?) ---------- > > Checking whether the PLT /home/nico/.dialyzer_plt is up-to-date... yes > > Proceeding with analysis... > > =ERROR REPORT==== 3-Feb-2011::11:19:57 === > > Error in process <0.29.0> with exit value: > > {{badmatch,none},[{erl_types,t_limit_k,2},{erl_types,'-t_limit_k/2-lc$^0/ > > 1- > > > >2-',2},{erl_types,'-t_limit_k/2-lc$^0/1-2-',2},{erl_types,t_limit_k,2},{di > >al > >yzer_typesig,enter_type,3},{dialyzer_typesig,enter_type_list,2},{dialyzer > >_ty pesig... > > > > dialyzer: Analysis failed with error: {{badmatch,none}, > > [{erl_types,t_limit_k,2}, > > {erl_types,'-t_limit_k/2-lc$^0/1-2-',2}, > > When I get an error like this it is usually due to a .beam file whose name > does not match the module name. Kostis ran a detailed analysis and there was a type which expanded to [none()] - I wanted to reserve the type the list contains for future use but had no use atm. I set this type to none() so that the only valid list is the empty list []. -> changing this to [] instead allowed dialyzer to run without this error He'll fix dialyzer so that it shouldn't crash in this case anymore. 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 kwidoyo@REDACTED Fri Feb 4 07:55:47 2011 From: kwidoyo@REDACTED (Kustarto Widoyo) Date: Fri, 04 Feb 2011 15:55:47 +0900 Subject: Segmentation fault in erts_printf_char (R13B04) Message-ID: <4D4BA2F3.2080405@geminimobile.com> Hi All, We found that our application was crashed and core dump file was generated, but not found any erl_crash.dump file created. * The application uses erlang distribution protocol that more than 50 nodes are involving in. All nodes run on Redhat 5.3. * We're using Erlang R13B04 64 bit built from source and the following patches have been applied: otp_src_R13B04-OTP-8475.patch otp_src_R13B04-OTP-8612.patch otp_src_R13B04-OTP-8643.patch otp_src_R13B04-OTP-8658.patch otp_src_R13B04-OTP-8661.patch otp_src_R13B04-OTP-8662.patch otp_src_R13B04-beam-break.patch otp_src_R13B04-emacs.patch otp_src_R13B04-erl_poll.patch otp_src_R13B04-erts_de_busy_limit.patch otp_src_R13B04-eunit.patch otp_src_R13B04-httpc-memoryleak.patch otp_src_R13B04-patch-etop.patch otp_src_R13B04-patch-odbc-oracleworkaround.patch otp_src_R13B04-supervisor.patch * The erl command line we use: $ /usr/local/gemini/ert/R13B04/lib/erlang/erts-5.7.5/bin/beam.smp -A 64 -K true -S 0 -- -root /usr/local/gemini/ert/R13B04/lib/erlang -progname erl -- -home /export/home/mmssys -- -smp enable -noshell -noinput -noshell -sname gdss1 -kernel net_ticktime 20 -boot /usr/local/gemini/gdss/1.0.0/lib/app/gdss_all -config /usr/local/gemini/gdss/1.0.0/../var/data/node1.config -pa /usr/local/gemini/gdss/1.0.0/lib/app-patches -pz /usr/local/gemini/gdss/1.0.0/lib/app -pz /usr/local/gemini/gdss/1.0.0/lib -central_config /usr/local/gemini/gdss/1.0.0/etc/central.conf -ticket_broker_config /usr/local/gemini/gdss/1.0.0/etc/broker.conf * The following is gdb and backtrace output: ------------------------ [root@REDACTED data]# gdb /usr/local/gemini/ert/R13B04/lib/erlang/erts-5.7.5/bin/beam.smp core.14720 GNU gdb Fedora (6.8-27.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"... Reading symbols from /lib64/libutil.so.1...done. Loaded symbols for /lib64/libutil.so.1 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libm.so.6...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /usr/lib64/libncurses.so.5...done. Loaded symbols for /usr/lib64/libncurses.so.5 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/librt.so.1...done. Loaded symbols for /lib64/librt.so.1 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/local/gemini/ert/R13B04/lib/erlang/lib/crypto-1.6.4/priv/lib/crypto_drv.so...done. Loaded symbols for /usr/local/gemini/ert/R13B04/lib/erlang/lib/crypto-1.6.4/priv/lib/crypto_drv.so Reading symbols from /usr/local/gemini/ert/R13B04/openssl/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/local/gemini/ert/R13B04/openssl/lib/libcrypto.so.0.9.8 Core was generated by `/usr/local/gemini/ert/R13B04/lib/erlang/erts-5.7.5/bin/beam.smp -A 64 -K true -'. Program terminated with signal 11, Segmentation fault. [New process 14798] snip ... snip ... snip ... #0 0x0000000000585ea8 in erts_printf_char (fn=0x5880f0 , arg=0xb750930, c=91 '[') at common/erl_printf_format.c:840 840 common/erl_printf_format.c: No such file or directory. in common/erl_printf_format.c (gdb) bt #0 0x0000000000585ea8 in erts_printf_char (fn=0x5880f0 , arg=0xb750930, c=91 '[') at common/erl_printf_format.c:840 #1 0x000000000048c6d8 in print_term (fn=0x5880f0 , arg=0xb750930, obj=5800176, dcount=0x458f2bc8) at beam/erl_printf_term.c:346 #2 0x000000000048c740 in print_term (fn=0x5880f0 , arg=0xb750930, obj=, dcount=0x458f2bc8) at beam/erl_printf_term.c:349 #3 0x000000000048c740 in print_term (fn=0x5880f0 , arg=0xb750930, obj=, dcount=0x458f2bc8) at beam/erl_printf_term.c:349 snip ... snip ... snip ... ------------------------ * And in syslog, we found: Jan 27 23:48:21 gds001c kernel: beam.smp[14798]: segfault at 0000000044ef3ff8 rip 0000000000585ea8 rsp 0000000044ef4000 error 6 Please let me know, if there is anything else we have to provide. Regards, -- Kustarto Widoyo Gemini Mobile Technologies From kwidoyo@REDACTED Fri Feb 4 08:09:41 2011 From: kwidoyo@REDACTED (Kustarto Widoyo) Date: Fri, 04 Feb 2011 16:09:41 +0900 Subject: [erlang-bugs] Segmentation fault in erts_printf_char (R13B04) In-Reply-To: <4D4BA2F3.2080405@geminimobile.com> References: <4D4BA2F3.2080405@geminimobile.com> Message-ID: <4D4BA635.8050001@geminimobile.com> Oops, forgot to put the url address for the patches. https://github.com/hibari/patches > * We're using Erlang R13B04 64 bit built from source and the following > patches have been applied: > otp_src_R13B04-OTP-8475.patch > otp_src_R13B04-OTP-8612.patch > otp_src_R13B04-OTP-8643.patch > otp_src_R13B04-OTP-8658.patch > otp_src_R13B04-OTP-8661.patch > otp_src_R13B04-OTP-8662.patch > otp_src_R13B04-beam-break.patch > otp_src_R13B04-emacs.patch > otp_src_R13B04-erl_poll.patch > otp_src_R13B04-erts_de_busy_limit.patch > otp_src_R13B04-eunit.patch > otp_src_R13B04-httpc-memoryleak.patch > otp_src_R13B04-patch-etop.patch > otp_src_R13B04-patch-odbc-oracleworkaround.patch > otp_src_R13B04-supervisor.patch Regards, -- Kustarto Widoyo Gemini Mobile Technologies From kenji.rikitake@REDACTED Sun Feb 13 04:32:20 2011 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 13 Feb 2011 12:32:20 +0900 Subject: FreeBSD strtod() implementation bug affects Erlang R14B01 float handling Message-ID: <20110213033220.GA25271@k2r.org> This is not necessarily an Erlang bug, but a notable FreeBSD-specific issue. Forwarded from the mochiweb Google Group. Kenji Rikitake ----- Forwarded message from Kenji Rikitake ----- Date: Sun, 13 Feb 2011 12:26:41 +0900 From: Kenji Rikitake To: mochiweb@REDACTED Subject: Re: [mochiweb] mochinum BigDenorm test case failure on FreeBSD 7.3-RELEASE i386 and R14B01 Reply-To: mochiweb@REDACTED Paul Guyot has already raised this issue. http://code.google.com/p/mochiweb/issues/detail?id=59#c0 And FreeBSD PR kern/143037 says this is fixed in FreeBSD 8.1 and later. http://www.freebsd.org/cgi/query-pr.cgi?pr=143037&cat=kern So this should be treated as a known bug for FreeBSD 7.x and 8.0. Thanks for the assistance. Regards, Kenji Rikitake ++> Bob Ippolito [2011-02-13 10:33:09 +0800]: > Date: Sun, 13 Feb 2011 10:33:33 +0800 > From: Bob Ippolito > To: mochiweb@REDACTED > Subject: Re: [mochiweb] mochinum BigDenorm test case failure on FreeBSD > 7.3-RELEASE i386 and R14B01 > Reply-To: mochiweb@REDACTED > > I have heard of this before, the best I can tell is that FreeBSD (or > Erlang on FreeBSD) is just slightly broken with regard to extreme > floats. Erlang probably uses a libc function for list_to_float and it > doesn't give the correct result? > > 1> <<2.225073858507201e-308/float>>. > <<0,15,255,255,255,255,255,255>> > 2> <<2.2250738585072014e-308/float>>. > <<0,16,0,0,0,0,0,0>> > > Looking at the code in erts/emulator/beam/bif.c it calls > sys_chars_to_double from erts/emulator/sys/unix/sys_float.c which ends > up calling the libc strtod. The bug is probably there. > > On Sun, Feb 13, 2011 at 9:16 AM, Kenji Rikitake wrote: > > Found the following test case failure on > > running mochiweb tests on a FreeBSD 7.3-RELEASE i386 > > and R14B01. > > Fload handling issues? > > > > module 'mochinum' > > ?mochinum: int_ceil_test...ok > > ?mochinum: int_pow_test...ok > > ?mochinum: digits_test...*failed* > > ::error:{assertEqual_failed, > > ? ? ? ? ?[{module,mochinum}, > > ? ? ? ? ? {line,301}, > > ? ? ? ? ? {expression,"list_to_float ( digits ( BigDenorm ) )"}, > > ? ? ? ? ? {expected,2.225073858507201e-308}, > > ? ? ? ? ? {value,2.2250738585072014e-308}]} > > ?in function mochinum:'-digits_test/0-fun-13-'/2 > > ?in call from mochinum:digits_test/0 > > > > > > ?mochinum: frexp_test...ok > > ?[done in 0.012 s] > > > > -- > > You received this message because you are subscribed to the Google Groups "MochiWeb" group. > > To post to this group, send email to mochiweb@REDACTED > > To unsubscribe from this group, send email to mochiweb+unsubscribe@REDACTED > > For more options, visit this group at http://groups.google.com/group/mochiweb?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups "MochiWeb" group. > To post to this group, send email to mochiweb@REDACTED > To unsubscribe from this group, send email to mochiweb+unsubscribe@REDACTED > For more options, visit this group at http://groups.google.com/group/mochiweb?hl=en. -- You received this message because you are subscribed to the Google Groups "MochiWeb" group. To post to this group, send email to mochiweb@REDACTED To unsubscribe from this group, send email to mochiweb+unsubscribe@REDACTED For more options, visit this group at http://groups.google.com/group/mochiweb?hl=en. ----- End forwarded message ----- From andrew@REDACTED Sun Feb 13 08:06:23 2011 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 13 Feb 2011 02:06:23 -0500 Subject: filename.erl throws HiPE compiler into infinite loop on R14B01 Message-ID: <20110213070623.GJ17893@hijacked.us> So, I was playing around with --enable-native-libs on OSX 10.6 tonight and I found that the compiler stalls on stdlib/filename.erl, erlc sits there eating a bunch of cpu but it never seems to finish compiling. If I compile it without +native it works fine. This is on OSX 10.6 with no ./configure flags other than --enable-native-libs. I can cd into lib/stdlib/src and run `erlc +native filename.erl` and the compiler never finishes. Everything else seems to compile and run fine, which is quite an improvemnt over the last time I tried this, at least. Andrew From andrey.pampukha@REDACTED Sun Feb 13 08:36:07 2011 From: andrey.pampukha@REDACTED (Andrey Pampukha) Date: Sun, 13 Feb 2011 10:36:07 +0300 Subject: [erlang-bugs] filename.erl throws HiPE compiler into infinite loop on R14B01 In-Reply-To: <20110213070623.GJ17893@hijacked.us> References: <20110213070623.GJ17893@hijacked.us> Message-ID: The same for Ubuntu 10.10 x86_64. beam.smp process (erlc) is consuming ~180% of dualcore CPU. 2011/2/13 Andrew Thompson > So, I was playing around with --enable-native-libs on OSX 10.6 tonight > and I found that the compiler stalls on stdlib/filename.erl, erlc sits > there eating a bunch of cpu but it never seems to finish compiling. If I > compile it without +native it works fine. > > This is on OSX 10.6 with no ./configure flags other than > --enable-native-libs. I can cd into lib/stdlib/src and run `erlc +native > filename.erl` and the compiler never finishes. > > Everything else seems to compile and run fine, which is quite an > improvemnt over the last time I tried this, at least. > > Andrew > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > From kostis@REDACTED Sun Feb 13 08:47:53 2011 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 13 Feb 2011 09:47:53 +0200 Subject: [erlang-bugs] filename.erl throws HiPE compiler into infinite loop on R14B01 In-Reply-To: <20110213070623.GJ17893@hijacked.us> References: <20110213070623.GJ17893@hijacked.us> Message-ID: <4D578CA9.2090306@cs.ntua.gr> Andrew Thompson wrote: > So, I was playing around with --enable-native-libs on OSX 10.6 tonight > and I found that the compiler stalls on stdlib/filename.erl, erlc sits > there eating a bunch of cpu but it never seems to finish compiling. If I > compile it without +native it works fine. > > This is on OSX 10.6 with no ./configure flags other than > --enable-native-libs. I can cd into lib/stdlib/src and run `erlc +native > filename.erl` and the compiler never finishes. This is a known problem, which has long been fixed. Try the Erlang/OTP 'dev' version from github or apply the following patch: https://github.com/kostis/otp/commit/8b92ac49d021b4634d660c5b2637c3ebec0f1d9f Kostis From andrew@REDACTED Sun Feb 13 19:34:14 2011 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 13 Feb 2011 13:34:14 -0500 Subject: [erlang-bugs] filename.erl throws HiPE compiler into infinite loop on R14B01 In-Reply-To: <4D578CA9.2090306@cs.ntua.gr> References: <20110213070623.GJ17893@hijacked.us> <4D578CA9.2090306@cs.ntua.gr> Message-ID: <20110213183414.GK17893@hijacked.us> On Sun, Feb 13, 2011 at 09:47:53AM +0200, Kostis Sagonas wrote: > Andrew Thompson wrote: > >So, I was playing around with --enable-native-libs on OSX 10.6 tonight > >and I found that the compiler stalls on stdlib/filename.erl, erlc sits > >there eating a bunch of cpu but it never seems to finish compiling. If I > >compile it without +native it works fine. > > > >This is on OSX 10.6 with no ./configure flags other than > >--enable-native-libs. I can cd into lib/stdlib/src and run `erlc +native > >filename.erl` and the compiler never finishes. > > This is a known problem, which has long been fixed. Try the > Erlang/OTP 'dev' version from github or apply the following patch: > > https://github.com/kostis/otp/commit/8b92ac49d021b4634d660c5b2637c3ebec0f1d9f > Ah, thanks, just wanted to make sure it was on the radar for B02. Andrew From eric.pailleau@REDACTED Tue Feb 15 22:40:40 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 15 Feb 2011 22:40:40 +0100 Subject: wx undefined symbol Message-ID: <4D5AF2D8.4070105@wanadoo.fr> Hello, After struggling a bit with WX on my linux box, and finally discovered there was an wx unicode version of devel lib in addition to main one. (configure seem to need this one...) I reach finally to compile my R14B01 with WX. A tear drop from my eyes, what a pleasure... Las... by trying the wx:demo() (but same problem with any wx function) I get : __________________________________________________________________________ Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.2 (abort with ^G) 1> wx:demo(). =ERROR REPORT==== 15-Feb-2011::22:22:29 === WX Failed loading "wxe_driver"@"/usr/local/lib/erlang/lib/wx-0.98.8/priv" {error,{{load_driver,"undefined symbol: _ZN12wxEvtHandler10QueueEventEP7wxEvent"}, [{wxe_server,start,0}, {wx,new,1}, {demo,init,1}, {wx_object,init_it,6}, {proc_lib,init_p_do_apply,3}]}} 2> ___________________________________________________________________________ the wxe_driver.so in /usr/local/lib/erlang/lib/wx-0.98.8 is the one I compile with success as far its mtime is the same of my compilation. $> file /usr/local/lib/erlang/lib/wx-0.98.8/priv/wxe_driver.so /usr/local/lib/erlang/lib/wx-0.98.8/priv/wxe_driver.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped $> ldd /usr/local/lib/erlang/lib/wx-0.98.8/priv/wxe_driver.so linux-gate.so.1 => (0xffffe000) libwx_gtk2u_stc-2.8.so.0 => /usr/lib/libwx_gtk2u_stc-2.8.so.0 (0xb7669000) libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/libwx_gtk2u_xrc-2.8.so.0 (0xb75d9000) libwx_gtk2u_html-2.8.so.0 => /usr/lib/libwx_gtk2u_html-2.8.so.0 (0xb753f000) libwx_gtk2u_adv-2.8.so.0 => /usr/lib/libwx_gtk2u_adv-2.8.so.0 (0xb7481000) libwx_gtk2u_core-2.8.so.0 => /usr/lib/libwx_gtk2u_core-2.8.so.0 (0xb7114000) libwx_baseu-2.8.so.0 => /usr/lib/libwx_baseu-2.8.so.0 (0xb6fc2000) libwx_gtk2u_gl-2.8.so.0 => /usr/lib/libwx_gtk2u_gl-2.8.so.0 (0xb6fb6000) libwx_gtk2u_aui-2.8.so.0 => /usr/lib/libwx_gtk2u_aui-2.8.so.0 (0xb6f4a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6e5a000) libm.so.6 => /lib/i686/libm.so.6 (0xb6e31000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6e14000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb6dfa000) libc.so.6 => /lib/i686/libc.so.6 (0xb6c99000) /lib/ld-linux.so.2 (0xb78cd000) libwx_baseu_xml-2.8.so.0 => /usr/lib/libwx_baseu_xml-2.8.so.0 (0xb6c8e000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb687e000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb67dc000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb67c1000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb677f000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb66bb000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6588000) libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb64d0000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6488000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6482000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb647e000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6477000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb646d000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6442000) libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb640c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb63aa000) libz.so.1 => /lib/libz.so.1 (0xb6396000) libdl.so.2 => /lib/libdl.so.2 (0xb6391000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb6321000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb62f9000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb62ed000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb62e6000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb62c8000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6249000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb61a1000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6177000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6142000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb613d000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb6132000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6129000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb611e000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb611a000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6108000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6104000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb60fa000) libpcre.so.0 => /lib/libpcre.so.0 (0xb60cb000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb60ad000) libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb6094000) libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0xb6012000) libggi.so.2 => /usr/lib/libggi.so.2 (0xb5f73000) libaa.so.1 => /usr/lib/libaa.so.1 (0xb5f57000) librt.so.1 => /lib/i686/librt.so.1 (0xb5f4d000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb5f32000) libjbig.so.1 => /usr/lib/libjbig.so.1 (0xb5f25000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb5f19000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb5e97000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb5e2e000) libresolv.so.2 => /lib/libresolv.so.2 (0xb5e17000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb5cd7000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb5cd3000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5ccc000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb5c72000) libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0xb5c66000) libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0xb5c4f000) libncurses.so.5 => /lib/libncurses.so.5 (0xb5c05000) libgii.so.1 => /usr/lib/libgii.so.1 (0xb5be7000) libXxf86dga.so.1 => /usr/lib/libXxf86dga.so.1 (0xb5be0000) libgg.so.1 => /usr/lib/libgg.so.1 (0xb5bd3000) libslang.so.2 => /usr/lib/libslang.so.2 (0xb5ac4000) Any idea of the problem ? I'm stuck in the mud. OS : Mandriva Linux release 2010.0 (Official) for i586 Kernel 2.6.31.14-desktop-1mnb on a Dual-processor i686 / \l RPM installed : libwxgtk2.8 - Base shared library part of wxGTK? ? libwxgtk2.8-devel - Header files and development documentation for wxGTK? libwxgtku2.8-devel - Header files and development documentation for wxGTK - unicode? libwxgtku2.8 - Base shared library part of wxGTK - Unicode enabled? From eric.pailleau@REDACTED Tue Feb 15 22:54:26 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 15 Feb 2011 22:54:26 +0100 Subject: [erlang-bugs] wx undefined symbol In-Reply-To: <4D5AF2D8.4070105@wanadoo.fr> References: <4D5AF2D8.4070105@wanadoo.fr> Message-ID: <4D5AF612.3010701@wanadoo.fr> Sorry, I forgot the WX library version : $> wx-config-unicode --version-full 2.8.10.0 From alex.demidenko@REDACTED Thu Feb 17 08:54:09 2011 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 17 Feb 2011 13:54:09 +0600 Subject: Incorrect scope for a variable Message-ID: Dear friends! Let me explain?with an synthetic example. Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.5 ?(abort with ^G) 1> {case 1 of X -> X end, case 2 of X -> X; _ -> 4 end}. ** exception error: no match of right hand side value 1 opposite successful example with bit change: 2> f(). ok 3> begin X=1, {case 1 of X -> X; _ -> 3 end, case 2 of X -> X; _ -> 4 end} end. {1,4} In first example, erlang assume X=2 in second 'case' (why?) and trow exception before return tuple. I'm think this is incorrect behavior. Isn't it? -- --------------------------------------------- With best regards, Alexander. From bengt.kleberg@REDACTED Thu Feb 17 09:08:28 2011 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 17 Feb 2011 09:08:28 +0100 Subject: [erlang-bugs] Incorrect scope for a variable In-Reply-To: References: Message-ID: <1297930108.4835.9.camel@seasc1137> Greetings, There is a very old feature in Erlang that exports variables from case statements. bengt On Thu, 2011-02-17 at 08:54 +0100, Alexander Demidenko wrote: > Dear friends! > > Let me explain with an synthetic example. > > Erlang R13B04 (erts-5.7.5) [source] [smp:2:2] [rq:2] [async-threads:0] > [kernel-poll:false] > Eshell V5.7.5 (abort with ^G) > > 1> {case 1 of X -> X end, case 2 of X -> X; _ -> 4 end}. > ** exception error: no match of right hand side value 1 > > opposite successful example with bit change: > 2> f(). > ok > 3> begin X=1, {case 1 of X -> X; _ -> 3 end, case 2 of X -> X; _ -> 4 end} end. > {1,4} > > In first example, erlang assume X=2 in second 'case' (why?) and trow > exception before return tuple. > > I'm think this is incorrect behavior. Isn't it? > > -- > --------------------------------------------- > With best regards, > Alexander. > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From robert.newson@REDACTED Sat Feb 19 15:01:37 2011 From: robert.newson@REDACTED (Robert Newson) Date: Sat, 19 Feb 2011 14:01:37 +0000 Subject: reproduceable livelock (?) in R13B04 Message-ID: Hi, I've reproduced the 100% cpu livelock on R14B01. It took just over 30 minutes, which is perhaps why previous posters did not notice it. I reproduced in on R13B04 also but noticed a further behavior, if you leave it long enough after it goes 100% cpu, it comes back out of it. It seemingly enters and leaves this state cyclically. As this is unfixed in the latest release, I felt obliged to post (hope this appears threaded with the original messages, I joined the mailing list after the original posts). B. From vinoski@REDACTED Tue Feb 22 06:54:46 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 22 Feb 2011 00:54:46 -0500 Subject: enif_make_badarg crashes is_binary Message-ID: I was recently writing a nif and had one C function returning an ERL_NIF_TERM that was then being passed to a second C function. The second one checked the passed term using enif_inspect_iolist_as_binary(), and it crashed. I debugged it and it's apparently caused by the fact that the ERL_NIF_TERM being passed was returned from enif_make_badarg(), so it was a 0. It caused this error on my Macbook Pro: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xfffffffe The reason for that invalid address is the is_binary(x) macro at the beginning of enif_inspect_iolist_as_binary(). It expands to if (((!(((((term)))) & (0x3 -0x2))) && (((*((Eterm*) (((((term))) - 0x2)))) & (0x3F -(0x3 << 2))) == (0x0|(0x8 << 2))))) { The first test, which I believe comes from _unchecked_is_boxed(x), passes because it's testing !0 which of course is 1, then the second test which I believe is _unchecked_boxed_val(x) fails with the invalid address error because the code more or less dereferences a null pointer. I think the fix is to make macros like is_binary(x) first check the term using is_value(x). --steve From mikpe@REDACTED Tue Feb 22 09:37:05 2011 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 22 Feb 2011 09:37:05 +0100 Subject: [erlang-bugs] enif_make_badarg crashes is_binary In-Reply-To: References: Message-ID: <19811.30129.265021.747435@pilspetsen.it.uu.se> Steve Vinoski writes: > I was recently writing a nif and had one C function returning an > ERL_NIF_TERM that was then being passed to a second C function. The > second one checked the passed term using > enif_inspect_iolist_as_binary(), and it crashed. I debugged it and > it's apparently caused by the fact that the ERL_NIF_TERM being passed > was returned from enif_make_badarg(), so it was a 0. It caused this > error on my Macbook Pro: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0xfffffffe > > The reason for that invalid address is the is_binary(x) macro at the > beginning of enif_inspect_iolist_as_binary(). It expands to > > if (((!(((((term)))) & (0x3 -0x2))) && (((*((Eterm*) (((((term))) > - 0x2)))) & (0x3F -(0x3 << 2))) == (0x0|(0x8 << 2))))) { > > The first test, which I believe comes from _unchecked_is_boxed(x), > passes because it's testing !0 which of course is 1, then the second > test which I believe is _unchecked_boxed_val(x) fails with the invalid > address error because the code more or less dereferences a null > pointer. > > I think the fix is to make macros like is_binary(x) first check the > term using is_value(x). No. Non-values are emphatically NOT permitted inside Erlang process heaps, live BEAM VM registers, live terms, or as parameters to internal C functions (except for very few special cases). The non-values are very private to the VM, and are (as I recall, it's been a while since I wrote that code), limited to (a) indicating exception returns from C BIFs (handled immediately by beam_emu), (b) temporary magic markers during GC, and (c) signalling error returns from some internal C functions. In no case is a non-value allowed to leak into application-visible Erlang state. The fix, therefore, is to catch whatever produced that non-value (error from a C function?) and turn that into an error return or Erlang exception rather than trying to pass it on as a valid term. /Mikael From sverker@REDACTED Tue Feb 22 11:27:29 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 22 Feb 2011 11:27:29 +0100 Subject: [erlang-bugs] enif_make_badarg crashes is_binary In-Reply-To: <19811.30129.265021.747435@pilspetsen.it.uu.se> References: <19811.30129.265021.747435@pilspetsen.it.uu.se> Message-ID: <4D638F91.6090604@erix.ericsson.se> Mikael Pettersson wrote: > Steve Vinoski writes: > > I was recently writing a nif and had one C function returning an > > ERL_NIF_TERM that was then being passed to a second C function. The > > second one checked the passed term using > > enif_inspect_iolist_as_binary(), and it crashed. I debugged it and > > it's apparently caused by the fact that the ERL_NIF_TERM being passed > > was returned from enif_make_badarg(), so it was a 0. It caused this > > error on my Macbook Pro: > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_INVALID_ADDRESS at address: 0xfffffffe > > > > The reason for that invalid address is the is_binary(x) macro at the > > beginning of enif_inspect_iolist_as_binary(). It expands to > > > > if (((!(((((term)))) & (0x3 -0x2))) && (((*((Eterm*) (((((term))) > > - 0x2)))) & (0x3F -(0x3 << 2))) == (0x0|(0x8 << 2))))) { > > > > The first test, which I believe comes from _unchecked_is_boxed(x), > > passes because it's testing !0 which of course is 1, then the second > > test which I believe is _unchecked_boxed_val(x) fails with the invalid > > address error because the code more or less dereferences a null > > pointer. > > > > I think the fix is to make macros like is_binary(x) first check the > > term using is_value(x). > > No. Non-values are emphatically NOT permitted inside Erlang process > heaps, live BEAM VM registers, live terms, or as parameters to internal > C functions (except for very few special cases). The non-values are > very private to the VM, and are (as I recall, it's been a while since > I wrote that code), limited to (a) indicating exception returns from > C BIFs (handled immediately by beam_emu), (b) temporary magic markers > during GC, and (c) signalling error returns from some internal C > functions. In no case is a non-value allowed to leak into > application-visible Erlang state. > > The fix, therefore, is to catch whatever produced that non-value > (error from a C function?) and turn that into an error return or > Erlang exception rather than trying to pass it on as a valid term. > > /Mikael > > Yes, Mikael is right. The documentation could be more clear about the only valid use of enif_make_badarg(); return its value from the nif. You are not even allowed to change your mind, once enif_make_badarg() has been called, its return value *must* be returned from the nif. enif_make_badarg() was a bit of a quick fix just to get the most common use case to work. In future we might want functions to throw customized exceptions. A small step in that direction could be an enif_is_value() (or maybe enif_is_exception) in order to distinguish values from exceptions. /Sverker, Erlang/OTP From vinoski@REDACTED Tue Feb 22 16:02:34 2011 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 22 Feb 2011 10:02:34 -0500 Subject: [erlang-bugs] enif_make_badarg crashes is_binary In-Reply-To: <4D638F91.6090604@erix.ericsson.se> References: <19811.30129.265021.747435@pilspetsen.it.uu.se> <4D638F91.6090604@erix.ericsson.se> Message-ID: On Tue, Feb 22, 2011 at 5:27 AM, Sverker Eriksson wrote: > Mikael Pettersson wrote: >> >> Steve Vinoski writes: >> ?> I was recently writing a nif and had one C function returning an >> ?> ERL_NIF_TERM that was then being passed to a second C function. The >> ?> second one checked the passed term using >> ?> enif_inspect_iolist_as_binary(), and it crashed. I debugged it and >> ?> it's apparently caused by the fact that the ERL_NIF_TERM being passed >> ?> was returned from enif_make_badarg(), so it was a 0. It caused this >> ?> error on my Macbook Pro: >> ?> ?> Program received signal EXC_BAD_ACCESS, Could not access memory. >> ?> Reason: KERN_INVALID_ADDRESS at address: 0xfffffffe >> ?> ?> The reason for that invalid address is the is_binary(x) macro at the >> ?> beginning of enif_inspect_iolist_as_binary(). It expands to >> ?> ?> ? ? if (((!(((((term)))) & (0x3 -0x2))) && (((*((Eterm*) >> (((((term))) >> ?> - 0x2)))) & (0x3F -(0x3 << 2))) == (0x0|(0x8 << 2))))) { >> ?> ?> The first test, which I believe comes from _unchecked_is_boxed(x), >> ?> passes because it's testing !0 which of course is 1, then the second >> ?> test which I believe is _unchecked_boxed_val(x) fails with the invalid >> ?> address error because the code more or less dereferences a null >> ?> pointer. >> ?> ?> I think the fix is to make macros like is_binary(x) first check the >> ?> term using is_value(x). >> >> No. ?Non-values are emphatically NOT permitted inside Erlang process >> heaps, live BEAM VM registers, live terms, or as parameters to internal >> C functions (except for very few special cases). ?The non-values are >> very private to the VM, and are (as I recall, it's been a while since >> I wrote that code), limited to (a) indicating exception returns from >> C BIFs (handled immediately by beam_emu), (b) temporary magic markers >> during GC, and (c) signalling error returns from some internal C >> functions. ?In no case is a non-value allowed to leak into >> application-visible Erlang state. >> >> The fix, therefore, is to catch whatever produced that non-value >> (error from a C function?) and turn that into an error return or >> Erlang exception rather than trying to pass it on as a valid term. >> >> /Mikael >> >> > > Yes, Mikael is right. > The documentation could be more clear about the only valid use of > enif_make_badarg(); return its value from the nif. You are not even allowed > to change your mind, once enif_make_badarg() has been called, its return > value *must* be returned from the nif. > enif_make_badarg() was a bit of a quick fix just to get the most common use > case to work. In future we might want functions to throw customized > exceptions. A small step in that direction could be an enif_is_value() (or > maybe enif_is_exception) in order to ?distinguish values from exceptions. Thanks, Sverker and Mikael, this makes sense. I didn't bother trying to create a patch for this because I didn't feel I understood the original intent. I think enif_is_exception() could be very handy. It would be perfect for the code I described in my initial message, since it would allow me to check the return value from the secondary function to see if it was an exception and if so return it immediately from the primary function. Not having enif_is_exception() wasn't too hard to work around for my case since badarg was all I needed and so I could just return a success/fail from the secondary function instead and create and return the badarg from the primary function, but if more exceptions are added in the future, enif_is_exception() will almost certainly be needed. thanks, --steve From philippu@REDACTED Wed Feb 23 16:14:48 2011 From: philippu@REDACTED (Philipp Unterbrunner) Date: Wed, 23 Feb 2011 16:14:48 +0100 Subject: Distributed node crashes silently when initially receiving a big chunk of messages from another node Message-ID: <4D652468.7000404@inf.ethz.ch> Hello, I have run into a serious and very annoying bug. Affects (at least); R13B04, R14A, R14B, R14B01 Platform: Ubuntu Linux 10.10, kernel 2.6.35-25-server (SMP) When a newly started distributed node receives a high number of messages from another node, the newly started node crashes silently. Nothing is printed to the console. No crash dump or core dump is produced. In trying to find a work-around, I found the following curious behavior: * The bug *only* occurs for distributed nodes (but regardless of whether the nodes run on the same machine). * Waiting a few seconds (or even longer) before sending the first message to the newly started node does *not* make a difference. The node will still crash when confronted with a large number of incoming messages later. * Speed matters. When doing a debug build, the bug appears less often then when doing a release build, especially when HiPE is enabled. However, I managed to cause the bug even in debug mode, and when OTP was not compiled with native libs. The bug is simply much less likely to be observed. * The number of messages sent *initially* matters most. Slowly "ramping up" the load is a work-around. Once a node is working at high throughput, it is OK to stop sending messages for an arbitrary period and at a later point send a big chunk of messages that would have killed the node if sent initially. * Timing matters. Running the receiver node with +T 7 or higher makes the problem disappear. * Setting the sender node's distribution buffer size to the minimum (+zdbbl 1) makes the problem appear less often. I have reproduced the bug in various applications. The behavior described above also makes it fairly obvious that the application is not at fault. Rather, it appears that the receiver node is unable to buffer incoming messages and crashes. Of particular interest here is the fact that "ramping up" the load is a work-around. I suspect a low-level race condition where the receiver node does not allocate sufficient buffer space in time and crashes. Given that the existing work-arounds are not desirable ("ramp up" requires changes to the application code, +T 7 and +zdbbl 1 decrease performance), and given that the bug now persists over multiple releases, I hope someone can soon look into it. Thank you, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: