From rapsey@REDACTED Mon Dec 1 09:28:05 2008 From: rapsey@REDACTED (Rapsey) Date: Mon, 1 Dec 2008 09:28:05 +0100 Subject: [erlang-bugs] cpu usage strangely high with timers on os x Message-ID: <97619b170812010028w1cc6b8e2uab37fb2ab6d5cb16@mail.gmail.com> Running this simple process on a mac: -module(tester). -compile(export_all). t(1000) -> true; t(N) -> receive {timeout} -> erlang:send_after(10, self(), {timeout}), % timer:sleep(10), % self() ! {timeout}, t(N+1) end. > T = spawn(fun() -> tester:t(0) end). > T ! {timeout}. Will cause beam.smp process to consume 8% of cpu time as measured by the activity monitor (or top). Using timer:sleep instead of send_after has the same effect. If I run this program on a windows machine, werl process will not move above 0%. This should not be normal behavior or should it? I'm using R12B-5 on both machines. thank you, Sergej -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Tue Dec 2 11:26:25 2008 From: john.hughes@REDACTED (John Hughes) Date: Tue, 2 Dec 2008 11:26:25 +0100 Subject: [erlang-bugs] Bug in expansion of ?LINE macro References: Message-ID: Given this macro definition: -define(RECEIVE(Msg,Body), receive Msg -> Body; M -> exit({unexpected_message,M,on_line,?LINE,was_expecting,??Msg}) after 10000 -> exit({timeout,on_line,?LINE,was_expecting,??Msg}) end). the first occurrence of ?LINE expands to the line number on which ?RECEIVE appears, but the second occurrence of ?LINE expands to 1. John From oscar@REDACTED Tue Dec 2 11:59:24 2008 From: oscar@REDACTED (=?ISO-8859-1?Q?Oscar_Hellstr=F6m?=) Date: Tue, 02 Dec 2008 10:59:24 +0000 Subject: [erlang-bugs] Typo in gen_event docs Message-ID: <4935150C.2080002@erlang-consulting.com> Hi, In the table where relationships between the behaviour functions and the callback functions are illustrated gen_event:add_sup_handler is written gen_event:add_suphandler Best regards -- Oscar Hellstr?m, oscar@REDACTED Office: +44 20 7655 0337 Mobile: +44 798 45 44 773 Erlang Training and Consulting http://www.erlang-consulting.com/ From saleyn@REDACTED Tue Dec 2 13:23:00 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Tue, 02 Dec 2008 07:23:00 -0500 Subject: [erlang-bugs] [erlang-patches] Bug in snmp_generic Message-ID: <493528A4.2070802@gmail.com> The following patch addresses an initialization error in snmp_generic that can be reproduced by calling: snmp_generic:is_any_noinit( {noinit,2,noinit}, [{1,dummy},{3,dummy}]). Expected: false Result: true Serge --- lib/snmp/src/agent/snmp_generic.erl.orig 2008-10-13 09:57:02.000000000 -0500 +++ lib/snmp/src/agent/snmp_generic.erl 2008-12-01 16:30:33.000000000 -0600 @@ -447,7 +447,7 @@ is_any_noinit(Row, Cols) -> is_any_noinit(tuple_to_list(Row), Cols, 1). is_any_noinit([noinit | Vals], [{N, _Value} | Cols], N) -> - is_any_noinit(Vals, Cols, N); + is_any_noinit(Vals, Cols, N+1); is_any_noinit([noinit | _Vals], _Cols, _N) -> true; is_any_noinit([_ | Vals], [{N, _Value} | Cols], N) -> _______________________________________________ erlang-patches mailing list erlang-patches@REDACTED http://www.erlang.org/mailman/listinfo/erlang-patches From fredrik.svahn@REDACTED Tue Dec 2 23:28:37 2008 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Tue, 2 Dec 2008 23:28:37 +0100 Subject: [erlang-bugs] Rounding errors with hipe Message-ID: I get rounding errors for some odd cases when running one of the programs in the Computer Language Shootout with Hipe. So far I have only seen it on 32-bit (x86) targets. I am guessing this might be a known problem/limitation in Hipe. I have however not seen any previous bug reports on it, so better safe than sorry; Here is a minimal test program with different results for byte code and natively compiled code. > otp_src_R12B-5/bin/erlc testmath.erl > otp_src_R12B-5/bin/erl -noshell -run testmath main 0.0 > otp_src_R12B-5/bin/erlc +native testmath.erl > otp_src_R12B-5/bin/erl -noshell -run testmath main 3.122502256758253e-17 > uname -a Linux host 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007 i686 i686 i386 GNU/Linux --- -module(testmath). -export([main/0]). main()-> foo(2/1600). foo(Y)-> io:format("~p~n",[Y*1200-1.5]), halt(0). Best Regards /Fredrik Svahn -------------- next part -------------- An HTML attachment was scrubbed... URL: From art_den@REDACTED Wed Dec 3 06:13:23 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Wed, 03 Dec 2008 08:13:23 +0300 Subject: [erlang-bugs] =?koi8-r?b?T0RCQyBSMTJCLTUgV2luMzI6IFNlbGVjdCBzdGF0?= =?koi8-r?b?ZW1lbnQgZG9lc24ndCB3b3Jr?= In-Reply-To: References: Message-ID: Another results of my investigations: it looks like author of ODBC Erlang library didn't provide the support of Unicode at all. I could to avoid "not supported type" error messages by adding case SQL_WCHAR: case SQL_WVARCHAR: case SQL_WLONGVARCHAR: into map_sql_2_c_column function of odbcserver.c file like this: static db_result_msg map_sql_2_c_column(db_column* column) { db_result_msg msg; msg = encode_empty_message(); switch(column -> type.sql) { case SQL_CHAR: case SQL_VARCHAR: case SQL_BINARY: case SQL_LONGVARCHAR: case SQL_VARBINARY: case SQL_LONGVARBINARY: case SQL_WCHAR: // case SQL_WVARCHAR: // I've added this lines case SQL_WLONGVARCHAR: // column -> type.len = (column -> type.col_size) + ... ... and by recompiling odbcserver.exe with changed sources. Error messages don't occur this way, but the data is retrieved in raw format depending of charset of database. For example, word "?????" is retrieved as {[208,148,208,181,208,189,208,184,209,129]} for UTF-8 charset. Will ODBC library support unicode correctly? From mikpe@REDACTED Wed Dec 3 10:35:58 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 3 Dec 2008 10:35:58 +0100 Subject: [erlang-bugs] Rounding errors with hipe In-Reply-To: References: Message-ID: <18742.21246.978128.537@harpo.it.uu.se> Fredrik Svahn writes: > I get rounding errors for some odd cases when running one of the programs in > the Computer Language Shootout with Hipe. So far I have only seen it on > 32-bit (x86) targets. > > I am guessing this might be a known problem/limitation in Hipe. I have > however not seen any previous bug reports on it, so better safe than sorry; > Here is a minimal test program with different results for byte code and > natively compiled code. > > > otp_src_R12B-5/bin/erlc testmath.erl > > otp_src_R12B-5/bin/erl -noshell -run testmath main > 0.0 > > otp_src_R12B-5/bin/erlc +native testmath.erl > > otp_src_R12B-5/bin/erl -noshell -run testmath main > 3.122502256758253e-17 > > > uname -a > Linux host 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007 i686 i686 > i386 GNU/Linux First of all you do know that floating-point (FP) is inherently imprecise, right? However, the problem here is the quirky nature of the old x87 FP unit, which is what 32-bit x86s use by default in most OS environments. (I believe MacOSX is one of the few to default to SSE2 even in 32-bit.) The x87 computes internally with an 80-bit format different from standard IEEE 64-bit floats. It does however round the result of each computation according to the precision control (which defaults to the 80-bit extended format), and it rounds when storing values to IEEE 64-bit floats in memory. So the final result is highly sensitive to the sequence of loads, arithmetics, and stores done during the computation. The BEAM virtual machine will store each intermediate result to memory, causing rounding to the IEEE 64-bit format. HiPE on x86-32/x87 will keep intermediate results in the x87 register file (which technically is a stack) as long as possible. The benefit is improved performance from avoiding memory accesses. It also improves accuracy by avoiding some rounding operations. And that's the problem. The nature of FP is such that computing a more accurate result can be considered an error. A possible solution might be to program the x87's rounding control to always round to standard double precision. That should make BEAM and HiPE produce similar results, but it might break FP library routines. Having HiPE store each intermediate value just for the sake of BEAM compatibility would be awful. The real solution is to forget about x87 and go to x86-64/SSE2. /Mikael From fredrik.svahn@REDACTED Wed Dec 3 13:16:41 2008 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Wed, 3 Dec 2008 13:16:41 +0100 Subject: [erlang-bugs] Fwd: Rounding errors with hipe In-Reply-To: References: <18742.21246.978128.537@harpo.it.uu.se> Message-ID: > > First of all you do know that floating-point (FP) is inherently > imprecise, right? > Oh yes, that's why I wrote the disclaimer about "known problem"... :-) Its trivial to write a c program with the exact same behaviour, unless you add e.g. "-mfpmath=sse -msse2" for gcc (as you say, this is enabled by default on x86-64). > However, the problem here is the quirky nature of the old x87 FP unit, > which is what 32-bit x86s use by default in most OS environments. > (I believe MacOSX is one of the few to default to SSE2 even in 32-bit.) > > The x87 computes internally with an 80-bit format different from > standard IEEE 64-bit floats. It does however round the result of > each computation according to the precision control (which defaults > to the 80-bit extended format), and it rounds when storing values > to IEEE 64-bit floats in memory. So the final result is highly > sensitive to the sequence of loads, arithmetics, and stores done > during the computation. > > The BEAM virtual machine will store each intermediate result to > memory, causing rounding to the IEEE 64-bit format. > > HiPE on x86-32/x87 will keep intermediate results in the x87 > register file (which technically is a stack) as long as possible. > The benefit is improved performance from avoiding memory accesses. > It also improves accuracy by avoiding some rounding operations. > > And that's the problem. The nature of FP is such that computing > a more accurate result can be considered an error. > > A possible solution might be to program the x87's rounding control > to always round to standard double precision. That should make BEAM > and HiPE produce similar results, but it might break FP library > routines. > > Having HiPE store each intermediate value just for the sake of > BEAM compatibility would be awful. > I fully agree! > > The real solution is to forget about x87 and go to x86-64/SSE2. > sse/sse2 support on x86-32 is not an option? I am just asking out of curiosity, I already have a workaround so this is not critical for me in any way. I guess money/time is better spent elsewhere if this is a lot of work. BR /Fredrik > /Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Wed Dec 3 15:37:45 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 03 Dec 2008 15:37:45 +0100 Subject: [erlang-bugs] ODBC R12B-5 Win32: Select statement doesn't work In-Reply-To: References: Message-ID: <493699B9.3000107@erix.ericsson.se> Hi! After your first mail I tried to reproduce the problem but failed. After your second mail it explains it. Erlang does not have a full unicode support but it will have more support for it in R13 after that we can see how it could be used in applications such as odbc. In the meantime of course we could add so that the c-code handles the SQL-datatypes and make it up to the user to handle the list of bytes that will be returned. If you have such a patch we can include it for R13. And after that we will look into what could be done for odbc. Regards Ingela Erlang/OTP -Ericsson ????? ??????? wrote: > Another results of my investigations: it looks like author of ODBC Erlang library didn't provide the support of Unicode at all. > > I could to avoid "not supported type" error messages by adding > > case SQL_WCHAR: > case SQL_WVARCHAR: > case SQL_WLONGVARCHAR: > > into map_sql_2_c_column function of odbcserver.c file like this: > > static db_result_msg map_sql_2_c_column(db_column* column) > { > db_result_msg msg; > > msg = encode_empty_message(); > > switch(column -> type.sql) { > case SQL_CHAR: > case SQL_VARCHAR: > > case SQL_BINARY: > case SQL_LONGVARCHAR: > case SQL_VARBINARY: > case SQL_LONGVARBINARY: > > case SQL_WCHAR: // > case SQL_WVARCHAR: // I've added this lines > case SQL_WLONGVARCHAR: // > > column -> type.len = (column -> type.col_size) + > > ... > > ... and by recompiling odbcserver.exe with changed sources. > > Error messages don't occur this way, but the data is retrieved in raw format depending of charset of database. For example, word "?????" is retrieved as {[208,148,208,181,208,189,208,184,209,129]} for UTF-8 charset. > > Will ODBC library support unicode correctly? > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From hans.bolinder@REDACTED Wed Dec 3 17:20:00 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 3 Dec 2008 17:20:00 +0100 Subject: [erlang-bugs] Bug in expansion of ?LINE macro In-Reply-To: References: Message-ID: <18742.45488.569413.601699@ornendil.du.uab.ericsson.se> [John Hughes:] > Given this macro definition: > > -define(RECEIVE(Msg,Body), > receive > Msg -> Body; > M -> > exit({unexpected_message,M,on_line,?LINE,was_expecting,??Msg}) > after 10000 -> > exit({timeout,on_line,?LINE,was_expecting,??Msg}) > end). > > the first occurrence of ?LINE expands to the line number on which ?RECEIVE > appears, but the second occurrence of ?LINE expands to 1. Thanks for the bug report. We'll fix the problem in R13A. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson *** /usr/local/otp/releases/otp_beam_linux_sles10_x64_r12b_patched/lib/stdlib-1.15.5/src/epp.erl Thu Nov 6 12:10:07 2008 --- epp.erl Wed Dec 3 16:21:01 2008 *************** *** 870,876 **** case dict:find(V, Bs) of {ok,Val} -> %% lists:append(Val, expand_macro(Ts, L, Rest, Bs)); ! expand_arg(stringify(Val), Ts, L, Rest, Bs); error -> [{var,L,V}|expand_macro(Ts, L, Rest, Bs)] end; --- 870,876 ---- case dict:find(V, Bs) of {ok,Val} -> %% lists:append(Val, expand_macro(Ts, L, Rest, Bs)); ! expand_arg(stringify(Val, L), Ts, L, Rest, Bs); error -> [{var,L,V}|expand_macro(Ts, L, Rest, Bs)] end; *************** *** 907,915 **** stringify1([T | Tokens]) -> [io_lib:format(" ~s", [token_src(T)]) | stringify1(Tokens)]. ! stringify(L) -> ! [$\s | S] = lists:flatten(stringify1(L)), ! [{string, 1, S}]. %% epp_request(Epp) %% epp_request(Epp, Request) --- 907,915 ---- stringify1([T | Tokens]) -> [io_lib:format(" ~s", [token_src(T)]) | stringify1(Tokens)]. ! stringify(Ts, L) -> ! [$\s | S] = lists:flatten(stringify1(Ts)), ! [{string, L, S}]. %% epp_request(Epp) %% epp_request(Epp, Request) From art_den@REDACTED Wed Dec 3 05:32:23 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Wed, 03 Dec 2008 07:32:23 +0300 Subject: [erlang-bugs] =?koi8-r?b?T0RCQyBSMTJCLTUgV2luMzI6IFNlbGVjdCBzdGF0?= =?koi8-r?b?ZW1lbnQgZG9lc24ndCB3b3Jr?= In-Reply-To: References: Message-ID: Also I found out: if not to use UTF-8 coding, everything works fine! From art_den@REDACTED Thu Dec 4 14:15:29 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Thu, 04 Dec 2008 16:15:29 +0300 Subject: [erlang-bugs] =?koi8-r?b?T0RCQyBSMTJCLTUgV2luMzI6IFNlbGVjdCBzdGF0?= =?koi8-r?b?ZW1lbnQgZG9lc24ndCB3b3Jr?= In-Reply-To: <493699B9.3000107@erix.ericsson.se> References: <493699B9.3000107@erix.ericsson.se> Message-ID: First: my previous message in mailing list "Also I found out: if not to use UTF-8 coding, everything works fine!" was send long time ago, but appeared only now. Don't read it :) Second: probably I will wait full Unicode support and changing in ODBC library. Btw, when will R13 be released? May be it will be better for me to change odbc library myself before? PS: sorry for my bad English. -----Original Message----- From: Ingela Anderton Andin To: ????? ??????? Date: Wed, 03 Dec 2008 15:37:45 +0100 Subject: Re: [erlang-bugs] ODBC R12B-5 Win32: Select statement doesn't work > > Hi! > > After your first mail I tried to reproduce the problem but failed. After > your second mail it explains it. > Erlang does not have a full unicode support but it will have more > support for it in R13 after that we can > see how it could be used in applications such as odbc. In the meantime > of course we could add > so that the c-code handles the SQL-datatypes and make it up to the user > to handle the list of bytes that will be returned. > If you have such a patch we can include it for R13. And after that we > will look into what could be done for odbc. > > Regards Ingela Erlang/OTP -Ericsson > From chaoslawful@REDACTED Tue Dec 9 05:14:27 2008 From: chaoslawful@REDACTED (Chaos Wang) Date: Tue, 09 Dec 2008 12:14:27 +0800 Subject: [erlang-bugs] Changing HTTP request version in inets http module caused warning logs Message-ID: <493DF0A3.9050507@gmail.com> Hi, I'm running Erlang OTP/R12B5 with inets-5.0.12, and want to send a request using http:request/4 function in HTTP/1.0 instead of the default HTTP/1.1. When I call it like this: http:request('head',{"http://www.erlang.org",[]},[{version,"HTTP/1.0"}],[]). There will be a warning said: =INFO REPORT==== 9-Dec-2008::11:52:12 === Invalid option {version,"HTTP/1.0"} ignored But actually the request type has been changed to HTTP/1.0. After tracking down into inets source, I find that the following code in inets-5.0.12/src/http.erl:266 (in http:handle_request/6) ... Version = http_util:to_upper(proplists:get_value(version, HTTPOptions, "HTTP/1.1")), ... which treat the value of version property as a string. But in inets-5.0.12/src/http.erl:364 (in http:http_options/2) ... http_options([{version, Val} | Settings], Acc) when is_atom(Val)-> http_options(Settings, Acc#http_options{version = Val}); ... treat the value of version property as an atom. And this is the origin of the warning log. So it looks like inets httpc treated the type of 'version' property inconsistently. From lars@REDACTED Tue Dec 9 07:19:34 2008 From: lars@REDACTED (Lars Strojny) Date: Tue, 09 Dec 2008 07:19:34 +0100 Subject: [erlang-bugs] Executable stack in beam.smp and beam Message-ID: <1228803574.7797.6.camel@localhost> Hello everybody, the package management system of the Linux distribution Gentoo - Portage - has some QA mechanisms in place to verify a freshly compiled package "behaves well". On of these mechanisms is the check for executable stack with scanelf. While installing R12B I've stumbled upon executable stack in the executables beamp.smp and beam. The scanelf log is attached, the relevant Gentoo bug can be found at https://bugs.gentoo.org/show_bug.cgi?id=249328 Thanks in advance, Lars -------------- next part -------------- RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam.smp !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_bifs.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_glue.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_bifs.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_glue.o RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam.smp RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.smp.debug RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.debug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lars@REDACTED Tue Dec 9 07:07:58 2008 From: lars@REDACTED (Lars Strojny) Date: Tue, 09 Dec 2008 07:07:58 +0100 Subject: [erlang-bugs] Executable stack in beam.smp and beam Message-ID: <1228802878.7797.5.camel@localhost> Hello everybody, the package management system of the Linux distribution Gentoo - Portage - has some QA mechanisms in place to verify a freshly compiled package "behaves well". On of these mechanisms is the check for executable stack with scanelf. While installing R12B I've stumbled upon executable stack in the executables beamp.smp and beam. The scanelf log is attached, the relevant Gentoo bug can be found at https://bugs.gentoo.org/show_bug.cgi?id=249328 Thanks in advance, Lars -------------- next part -------------- RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam.smp !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_bifs.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_glue.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_bifs.o !WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_glue.o RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam.smp RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.smp.debug RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.debug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mikpe@REDACTED Tue Dec 9 09:25:05 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 9 Dec 2008 09:25:05 +0100 Subject: [erlang-bugs] Executable stack in beam.smp and beam In-Reply-To: <1228802878.7797.5.camel@localhost> References: <1228802878.7797.5.camel@localhost> Message-ID: <18750.11105.906435.838975@harpo.it.uu.se> Lars Strojny writes: >the package management system of the Linux distribution Gentoo - Portage >- has some QA mechanisms in place to verify a freshly compiled package >"behaves well". On of these mechanisms is the check for executable stack >with scanelf. While installing R12B I've stumbled upon executable stack >in the executables beamp.smp and beam. The scanelf log is attached, the >relevant Gentoo bug can be found at >https://bugs.gentoo.org/show_bug.cgi?id=3D249328 > >Thanks in advance, >Lars > >RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam >RWX --- --- work/otp_src_R12B-5/bin/x86_64-pc-linux-gnu/beam.smp >!WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_bifs.o >!WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/smp/hipe_amd64_glue.o >!WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_bifs.o >!WX --- --- work/otp_src_R12B-5/erts/emulator/obj/x86_64-pc-linux-gnu/opt/plain/hipe_amd64_glue.o >RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam >RWX --- --- image/usr/lib64/erlang/erts-5.6.5/bin/beam.smp >RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.smp.debug >RWX --- --- image/usr/lib/debug/usr/lib64/erlang/erts-5.6.5/bin/beam.debug I see no actual install failure in either the above message or the gentoo bug report linked to above. And the scanelf log tells me nothing useful. Anyway I strongly suspect this is a false positive. AFAIK the Erlang/OTP runtime system uses no nested C functions or anything else that would generate code on the stack. It does however contain hand-written assembly file modules, which do not have those magic .GNU.stack (sp?) annotations. Please show us exactly where the executable stack occurs. From art_den@REDACTED Tue Dec 9 13:29:16 2008 From: art_den@REDACTED (=?koi8-r?Q?=E4=C5=CE=C9=D3_=E1=D2=D4=A3=CD=CF=D7?=) Date: Tue, 09 Dec 2008 15:29:16 +0300 Subject: [erlang-bugs] =?koi8-r?b?U05NUCBtYW5hZ2VyOiBzdHJhbmdlIGJlaGF2aW91?= =?koi8-r?b?cg==?= Message-ID: This source code if work fine for me: -module(test_snmp). -behaviour(snmpm_user). -export([ start/1, handle_error/3, handle_agent/4, handle_pdu/5, handle_trap/4, handle_inform/4, handle_report/4 ]). -define(ENGINE_ID, [16#50, 16#6f, 16#6c, 16#79, 16#43, 16#6f, 16#6d, 16#2d, 16#33, 16#30, 16#30, 16#55, 16#2d, 16#31, 16#47, 16#54]). -define(USER, lalala). -define(USER_NAME, "username"). start(_Arg) -> catch start_safe(), snmpm:stop(). start_safe() -> ok = crypto:start(), ok = snmpm:start(), ok = snmpm:register_user(?USER, ?MODULE, undefined), AuthKey = snmp:passwd2localized_key(md5, "123456789", ?ENGINE_ID), PrivKey = snmp:passwd2localized_key(md5, "123456789", ?ENGINE_ID), ok = snmpm:register_usm_user(?ENGINE_ID, ?USER_NAME, [ {auth, usmHMACMD5AuthProtocol}, {sec_name, ?USER_NAME }, {auth_key, AuthKey }, {priv, usmDESPrivProtocol }, {priv_key, PrivKey } ] ), ok = snmpm:register_agent( ?USER, [192,168,0,179], [ {version, v3 }, {engine_id, ?ENGINE_ID }, {sec_model, usm }, {sec_name, ?USER_NAME }, {sec_level, authPriv } ] ), % If to uncomment code below, error occurs when calling snmpm:g!!! % ok = snmpm:register_agent( % ?USER, % [192,168,0,180], % [ % {version, v1 }, % {community, "public"} % ] % ), Result1 = snmpm:g(?USER, {192,168,0,179}, [[1,3,6,1,2,1,1,1,0]]), io:format("Result1=~p~n", [Result1]), Result2 = snmpm:g(?USER, {192,168,0,179}, [[1,3,6,1,2,1,1,1,0]]), io:format("Result2=~p~n", [Result2]), ok. handle_error(ReqId, Reason, UserData) -> io:format ( "handle_error(ReqId=~p, Reason=~p, UserData=~p)~n", [ReqId, Reason, UserData] ), ignore. handle_agent(Addr, Port, SnmpInfo, UserData) -> io:format ( "handle_agent(Addr=~p, Port=~p, SnmpInfo=~p, UserData=~p)~n", [Addr, Port, SnmpInfo, UserData] ), ignore. handle_pdu(Addr, Port, ReqId, SnmpResponse, UserData) -> io:format ( "handle_pdu(Addr=~p, Port=~p, ReqId=~p, SnmpResponse=~p, UserData=~p)~n", [Addr, Port, ReqId, SnmpResponse, UserData] ), ignore. handle_trap(Addr, Port, SnmpTrapInfo, UserData) -> io:format ( "handle_trap(Addr=~p, Port=~p, SnmpTrapInfo=~p, UserData=~p)~n", [Addr, Port, SnmpTrapInfo, UserData] ), ignore. handle_inform(Addr, Port, SnmpInfo, UserData) -> io:format ( "handle_inform(Addr=~p, Port=~p, SnmpInfo=~p, UserData=~p)~n", [Addr, Port, SnmpInfo, UserData] ), ignore. handle_report(Addr, Port, SnmpInfo, UserData) -> io:format ( "handle_report(Addr=~p, Port=~p, SnmpInfo=~p, UserData=~p)~n", [Addr, Port, SnmpInfo, UserData] ), ignore. but if to uncomment code where another agent is registered with SNMP v1, then info report appears in the screen after calling of snmpm:g function: Eshell V5.6.5 (abort with ^G) (snmpman_server@REDACTED)1> Result1={error,{send_failed,1628668040,unknownSecurityName}} (snmpman_server@REDACTED)1> Result2={error,{send_failed,1628668041,unknownSecurityName}} (snmpman_server@REDACTED)1> =ERROR REPORT==== 9-Dec-2008::17:15:25 === [ snmp : manager : snmpm_mpd : <0.57.0> ] MPD: CONFIG ERROR: unknownSecurityName (message: {message,'version-3', {v3_hdr,1393084258,484, [7], 3,undefined,undefined}, [48,50,4,16,80,111,108,121, 67,111,109,45,51,48,48,85, 45,49,71,84,4,0,160,28,2,4, 97,19,128,136,2,1,0,2,1,0, 48,14,48,12,6,8,43,6,1,2,1, 1,1,0,5,0]}) (snmpman_server@REDACTED)1> =ERROR REPORT==== 9-Dec-2008::17:15:25 === [ snmp : manager : snmpm_mpd : <0.57.0> ] MPD: CONFIG ERROR: unknownSecurityName (message: {message,'version-3', {v3_hdr,1393084259,484, [7], 3,undefined,undefined}, [48,50,4,16,80,111,108,121, 67,111,109,45,51,48,48,85, 45,49,71,84,4,0,160,28,2,4, 97,19,128,137,2,1,0,2,1,0, 48,14,48,12,6,8,43,6,1,2,1, 1,1,0,5,0]}) text of my manager.conf is: {port, 162}. {engine_id, "manager id"}. {max_message_size, 484}. Is it bug in my code or in erlang SNMP library? How to force to register both snmp-v1 and snmp-v3 agents without errors? From colm.dougan@REDACTED Fri Dec 12 20:09:27 2008 From: colm.dougan@REDACTED (Colm Dougan) Date: Fri, 12 Dec 2008 19:09:27 +0000 Subject: [erlang-bugs] Segfault on amd64 Debian with HiPE Message-ID: <24d4f39c0812121109q63450ce0j9df17bd6c61d3652@mail.gmail.com> Hi, I have a reproducible segfault when running some stuff on an amd64 Debian where some of the modules involved are compiled with HiPE. I can get around the problem by not compiling one particular module natively. I don't seem to get the same behavior on an i386 Debian with the same code. Unfortunately the problem seems to be a very subtle interaction between many different modules in our system, some of which are compiled natively and others which are not, which makes it rather difficult to boil doing to a stand-alone test script I can send you. However, I'd be happy to work (probably off-list) with anyone who wants more information. To give a brief, and I appreciate rather vague, synopsis of the code: the offending module does a pattern on a binary and produces smaller binaries which are then passed into another module which does more binary chopping up and eventually hands off to another process which does ets/mnesia inserts with data. It seems that the segfault happens in the GC code somewhere in the final part of that process. Here is the gdb backtrace : Core was generated by `/usr/lib/erlang/erts-5.6.5/bin/beam.smp -K true -- -root /usr/lib/erlang -progn'. Program terminated with signal 11, Segmentation fault. #0 0x000000000050b0b2 in gensweep_nstack () (gdb) bt #0 0x000000000050b0b2 in gensweep_nstack () #1 0x00000000004c0dc5 in erts_gc_info () #2 0x00000000004c1911 in erts_garbage_collect () #3 0x000000000050c8cf in hipe_gc () #4 0x000000000050d934 in nbif_gc_1 () #5 0x00002aaaad12ebd8 in ?? () #6 0x00002aaaad12ee50 in ?? () #7 0x0000000000000007 in ?? () #8 0x00002aaaaaae8f08 in ?? () #9 0x00002aaaace29060 in ?? () #10 0x00002aaaace2b4d8 in ?? () #11 0x00002aaaace2b4d8 in ?? () #12 0x000000000050b784 in hipe_mode_switch () #13 0x00000000004ddfd6 in process_main () #14 0x0000000000481f8f in erts_pid2proc_not_running () #15 0x000000000054f834 in ethr_thr_create () #16 0x00002b8e5f91bf1a in start_thread () from /lib/libpthread.so.0 #17 0x00002b8e5fbfe5d2 in clone () from /lib/libc.so.6 #18 0x0000000000000000 in ?? () Thanks, Colm From nick.smallbone@REDACTED Mon Dec 15 11:57:35 2008 From: nick.smallbone@REDACTED (Nick Smallbone) Date: Mon, 15 Dec 2008 11:57:35 +0100 Subject: [erlang-bugs] R12B: erl_syntax_lib:annotate_bindings mishandles receives Message-ID: erl_syntax_lib:annotate_bindings claims that the following expression binds no variables: receive X -> ok end. The problem seems to be that vann_receive_expr requires the timeout action to bind X too, even though there's no timeout. Nick Smallbone From kruber@REDACTED Mon Dec 15 15:21:19 2008 From: kruber@REDACTED (Nico Kruber) Date: Mon, 15 Dec 2008 15:21:19 +0100 Subject: [erlang-bugs] Bugfix for OTP-7330 in JInterface had some side-effects Message-ID: <200812151521.19343.kruber@zib.de> Assume you're working on computer "some-pc" and you're creating a node "node1@REDACTED". In former versions (up until and including 1.4.0) it was possible to connect from Java/JInterface to that node by using "node1@REDACTED" and everything worked fine - unlike the bugfix description suggested. This is not possible anymore which prevents easy distribution of software containing a java interface using an erlang node on the same host bugfix notes from the release notes: Jinterface now refuses to connect to another node that does not agree on the other node's name. This has been a problem in that a connection was set up, but not used on a following send, which caused a second erroneous connection attemt to fail since the other (Erlang) node rejects a connection due to name disagreement. Problem reported and dissected by Alexander Lamb Own Id: OTP-7330 From hpjcon@REDACTED Mon Dec 15 19:31:16 2008 From: hpjcon@REDACTED (Jan Jacobs) Date: Mon, 15 Dec 2008 20:31:16 +0200 Subject: [erlang-bugs] ODBC param_query issues. Message-ID: Hi, While adding the handling of SQL_TYPE_TIMESTAMP to param_query, I have picked up the following: 1) In the source code (odbc.erl) for param_query the following statement appears: [{_,Values}|_]=Params This is wrong according to the documentation: Params = [{odbc_data_type(), [value()]}] |[{odbc_data_type(), in_or_out(), [value()]}] I changed it to: Values = case Params of [{_, Vs} | _] -> Vs; [{_, _, Vs} | _] -> Vs end, 2) Adding additional types requires a lot of changes in the C source in different places. I want to know if I can change the internals of the source code to C++. I need to handle additional types in the param_query. Thanks Jan From mikpe@REDACTED Tue Dec 16 10:14:19 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 16 Dec 2008 10:14:19 +0100 Subject: [erlang-bugs] Segfault on amd64 Debian with HiPE In-Reply-To: <24d4f39c0812121109q63450ce0j9df17bd6c61d3652@mail.gmail.com> References: <24d4f39c0812121109q63450ce0j9df17bd6c61d3652@mail.gmail.com> Message-ID: <18759.29035.360658.762728@harpo.it.uu.se> Colm Dougan writes: > Hi, > > I have a reproducible segfault when running some stuff on an amd64 > Debian where some of the modules involved are compiled with HiPE. I > can get around the problem by not compiling one particular module > natively. I don't seem to get the same behavior on an i386 Debian > with the same code. > > Unfortunately the problem seems to be a very subtle interaction > between many different modules in our system, some of which are > compiled natively and others which are not, which makes it rather > difficult to boil doing to a stand-alone test script I can send you. > However, I'd be happy to work (probably off-list) with anyone who > wants more information. > > To give a brief, and I appreciate rather vague, synopsis of the code: > the offending module does a pattern on a binary and produces smaller > binaries which are then passed into another module which does more > binary chopping up and eventually hands off to another process which > does ets/mnesia inserts with data. It seems that the segfault happens > in the GC code somewhere in the final part of that process. Without a test case which allows us to reproduce the problem it's going to be very difficult for us to diagnose it. Having said that, a segfault in gensweep_nstack() is most likely caused by the compiler assigning an incorrect type to a temporary register: only one type of temps can refer to Erlang terms, and only those temps are traced during garbage collection. A incorrect type assignment can cause a live term to be collected or a non-term to be traced. But to debug this we'd need to see the actual Erlang code which gets miscompiled. From ingela@REDACTED Tue Dec 16 10:10:35 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 16 Dec 2008 10:10:35 +0100 Subject: [erlang-bugs] ODBC param_query issues. In-Reply-To: References: Message-ID: <4947708B.40400@erix.ericsson.se> Hi! Jan Jacobs wrote: > Hi, > > While adding the handling of SQL_TYPE_TIMESTAMP to param_query, I have > picked up the following: > > 1) In the source code (odbc.erl) for param_query the following statement > appears: > [{_,Values}|_]=Params > This is wrong according to the documentation: > Params = [{odbc_data_type(), [value()]}] |[{odbc_data_type(), > in_or_out(), [value()]}] > > I changed it to: > Values = > case Params of > [{_, Vs} | _] -> Vs; > [{_, _, Vs} | _] -> Vs > end, > Well the in_or_out functionality was submitted as a patch and I guess this was missed. No test case was submitted with the patch but we added it as it did not seem to do any harm to other functionality. Of course it would be great to have a test case, it is on the "todo-list", but odbc issues does not tend to come very high on the "prio-list" I am afraid. I will add your change above. > > 2) Adding additional types requires a lot of changes in the C source in > different places. I want to know if I can change the internals of the > source code to C++. I need to handle additional types in the > param_query. > > If you want to submit your new implementation as a patch that will make it into the erlang release you will have to stick with c. Changing it to c++ is a far to big change for us to handle as we have very limited recourses to put into the odbc application. You are free to create an abstract data type if that helps. Adding another c-file is no problem. Regards Ingela Erlang/OTP - Ericsson From erlang@REDACTED Tue Dec 16 11:03:49 2008 From: erlang@REDACTED (Andreas Stenius) Date: Tue, 16 Dec 2008 11:03:49 +0100 Subject: [erlang-bugs] ssl_accept/3 not exported Message-ID: <14295635.21229421830216.JavaMail.Andreas@HP-slim> Hi, I'm fiddling about with SSL, and most notably, the new implementation, since I need to upgrade an existing connection, and if I'm not missread the documentation, only the new implementation supports that. However, using ssl_accept on the server side, one cannot specify the timeout value as documented: ssl_accept(ListenSocket, SslOptions, Timeout) -> {ok, Socket} | {error, Reason} since ssl_accept/3 is not exported from ssl.erl. I guess this is just a minor miss-feat. Best regards, Andreas Stenius -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Thu Dec 18 11:18:51 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 18 Dec 2008 11:18:51 +0100 Subject: [erlang-bugs] ssl_accept/3 not exported In-Reply-To: <14295635.21229421830216.JavaMail.Andreas@HP-slim> References: <14295635.21229421830216.JavaMail.Andreas@HP-slim> Message-ID: <494A238B.5060700@erix.ericsson.se> Hi! Thank you for reporting this, it will be exported in the upcoming release of ssl. Regards Ingela Erlang/OTP - Ericsson Andreas Stenius wrote: > Hi, > > I'm fiddling about with SSL, and most notably, the new implementation, > since I need to upgrade an existing connection, and if I'm not > missread the documentation, only the new implementation supports that. > > However, using ssl_accept on the server side, one cannot specify the > timeout value as documented: > > > ssl_accept(ListenSocket, SslOptions, Timeout) -> {ok, Socket} | > {error, Reason} > > > > since ssl_accept/3 is not exported from ssl.erl. I guess this is just > a minor miss-feat. > > Best regards, > Andreas Stenius > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From raimo+erlang-bugs@REDACTED Thu Dec 18 16:49:30 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 18 Dec 2008 16:49:30 +0100 Subject: [erlang-bugs] Bugfix for OTP-7330 in JInterface had some side-effects In-Reply-To: <200812151521.19343.kruber@zib.de> References: <200812151521.19343.kruber@zib.de> Message-ID: <20081218154930.GA23981@erix.ericsson.se> On Mon, Dec 15, 2008 at 03:21:19PM +0100, Nico Kruber wrote: > Assume you're working on computer "some-pc" and you're creating a node > "node1@REDACTED". > In former versions (up until and including 1.4.0) it was possible to connect > from Java/JInterface to that node by using "node1@REDACTED" and everything > worked fine - unlike the bugfix description suggested. > This is not possible anymore which prevents easy distribution of software > containing a java interface using an erlang node on the same host The old behaviour was erroneous from an Erlang point of view. It has never been possible to have different names on nodes from the connection endpoints when two Erlang nodes communicate. The connection setup fails when they find the name difference. A solution would be either to force the Erlang node's name to be 'node1@REDACTED', or to find the hostname from Java and use "node1@REDACTED" in Jinterface. > > bugfix notes from the release notes: > Jinterface now refuses to connect to another node that does not agree on the > other node's name. This has been a problem in that a connection was set up, > but not used on a following send, which caused a second erroneous connection > attemt to fail since the other (Erlang) node rejects a connection due to name > disagreement. > Problem reported and dissected by Alexander Lamb > Own Id: OTP-7330 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ulf@REDACTED Fri Dec 19 12:14:21 2008 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 19 Dec 2008 12:14:21 +0100 Subject: [erlang-bugs] out of memory and crash when using linebuf io In-Reply-To: References: Message-ID: <8209f740812190314n5ab2b753k10cafe0c01161977@mail.gmail.com> What is the status of this issue, reported Aug 5 by Fredrik Svahn? BR, Ulf W 2008/8/5 Fredrik Svahn : > Hi, > > I knew that the new regexp library ("re") in Erlang/OTP R12B-3 is > fast. But I wanted to know just how fast "erlgrep" could be compared > to the well-known unix grep which has been around since 1973. My input > file was quite big (about 980 Mb) and in the first attempt it took > some 30 minutes for my io:get_line-based program to scan through the > input compared to 8 minutes for grep. However, I quickly discovered > that io was the bottleneck rather than the regexps. Also to my > surprise, the beam process grew until it had a resident size of 950 Mb > (according to top). Not quite what I had hoped for. I wonder what > would have happened on my machine with 2 Gb RAM if the file had been > three times the size? > > I then tried the well-known "open_port({fd,0,1}, [eof,binary,line])" > approach, and ended up in a program that quickly grew until there was > no memory left (>1.2 Gb before top stopped working) and then > *completely* locking up the computer for some 20 minutes before I > finally managed to take beam down by force. > > I believe the later issue is the same that was discussed a about a > year ago by Ulf Wiger and others and the suggestion then was to add > some kind of flow control to line oriented port io. So I hereby humbly > submit a patch to add some very very basic flow control. I am sure > that more skilled designers can easily improve it to also handle > io:get_line() on large files without beam growth. I am also sure there > is a corner case or two which I have not thought of. > > This is arguably not a bug since piping big chunks of data into beam > was not what the system originally was built for, but I am still > hoping to get away with sending it to erlang-bugs and getting it in > since: > > a) It has been experienced by others as well that it is easy to crash > beam if you have big piped input files > b) Currently there is no *fast* way to read data from stdin without > risking beam growth/crash - this is a serious limitation > c) I have provided a patch (which also seems to keep the memory > consumption at more normal levels) > > > *** erts/emulator/beam/io.c.old 2008-08-01 00:29:16.000000000 +0200 > --- erts/emulator/beam/io.c 2008-08-04 22:26:00.000000000 +0200 > *************** static void missing_drv_callback(Port *p > *** 2437,2447 **** > --- 2437,2472 ---- > void > erts_port_ready_input(Port *p, ErlDrvEvent hndl) > { > + Process *rp = NULL; > + ErtsProcLocks rp_locks = ERTS_PROC_LOCK_MSGQ; > + > ERTS_SMP_CHK_NO_PROC_LOCKS; > ERTS_SMP_LC_ASSERT(erts_lc_is_port_locked(p)); > > ASSERT((p->status & ERTS_PORT_SFLGS_DEAD) == 0); > > + /* When using linebuf_io there is a risk of ending up with an ever growing > + * message queue in the connected process since there is no flow control > + * and we usually end up with many small messages instead of one large. > + > + * The obvious disadvantage with the simple flow control below is that a > + * message queue which has grown for other reasons than io may > temporarily > + * stop io messages to the controlling process. On the other hand if we > + * have a message queue of 4*ERL_MESSAGE_BUF_SZ then it is not helping us > + * to fill it up with even more messages. > + > + * With this patch at least we will not run out of memory and crash, and > + * this makes it easier to analyse the problem... */ > + > + if (p->status & ERTS_PORT_SFLG_LINEBUF_IO) { > + rp = erts_pid2proc(NULL, 0, p->connected, rp_locks); > + if (rp) { > + int mq_too_long = rp->msg.len > 4*ERL_MESSAGE_BUF_SZ; > + erts_smp_proc_unlock(rp, rp_locks); > + if (mq_too_long) return; > + } > + } > + > if (!p->drv_ptr->ready_input) > missing_drv_callback(p, hndl, DO_READ); > else { > > > BR /Fredrik > > PS. So how did the new re library match up to grep with the above > patch? Quite well I would say. Almost two minutes faster than grep > (using the mmap option to grep only made a few seconds difference). > Even though I knew re was fast from previous experiments I was quite > pleasantly surprised. It is still using more memory than grep, for > sure, but still, I am willing to make that trade-off in this case. > > > $ time otp_src_R12B-3/bin/erl -smp disable -user logreader < > /tmp/messages.4 > output2.txt > > real 6m16.410s > user 6m12.910s > sys 0m3.220s > > $ time grep -E '(Mar|Apr) *[0-9]+ *0(1|2):' < /tmp/messages.4 > output3.txt > > real 8m17.259s > user 8m15.170s > sys 0m1.640s > > $ diff output2.txt output3.txt > $ > From anton.krasovsky@REDACTED Tue Dec 23 01:47:37 2008 From: anton.krasovsky@REDACTED (Anton Krasovsky) Date: Tue, 23 Dec 2008 00:47:37 +0000 Subject: [erlang-bugs] ssh:connect() documentation Message-ID: <46167e6a0812221647y739015ay72d10469e5d62204@mail.gmail.com> Documentation for ssh:connect() says: {connect_timeout, Milliseconds | infinity} Sets the default timeout when trying to connect to. however the actual option is 'timeout'. anton From c.romain@REDACTED Sun Dec 28 23:42:13 2008 From: c.romain@REDACTED (cyril Romain) Date: Sun, 28 Dec 2008 23:42:13 +0100 Subject: [erlang-bugs] code:load_abs/1 fails for packaged modules Message-ID: <495800C5.6050709@laposte.net> Hi, _StepToReproduce_: Let's assume you have /home/me/project/src/test/mymodule.erl and '-module(test.mymodule)' defined in mymodule.erl. And the corresponding beam file: /home/me/project/ebin/test/mymodule.beam. Run Erlang from the project directory with 'erl -pa ebin'. Now in Erlang code:load_abs("/home/me/project/ebin/test/mymodule") fails with the following error report: _ErrorReport_: =ERROR REPORT==== 28-Dec-2008::22:12:10 === beam/beam_load.c(1035): Error loading module mymodule: module name in object code is test.mymodule =ERROR REPORT==== 28-Dec-2008::22:12:10 === Loading of /home/cyril/ebin/test/mymodule.beam failed: badfile {error,badfile} _Problem_: In kernel-2.12.5/src/code_server.erl in load_abs/3 the try_load_module/4 call can fail if Mod0 is [] and if the module is a packaged module (i.e. a module within a namespace). It is worth noting that code:load_abs/2 succeed though. Indeed code:load_abs("/home/me/project/ebin/test/mymodule", test.mymodule) returns {module,'test.mymodule'}. Unfortunately I'm in a case where I only know the file name and not the module name. FYI, I'm trying to fix dialyzer to support packaged module. Dialyzer assumes the module name is the filename:basename, which is wrong for packaged modules. And dialyzer cannot guess the module name without loading the beam file, hence the load_abs/1 call. _Workaround_: Although I could make the application loading the /path/to/mymodule.beam by successive call to code:load_abs("/path/to/mymodule", mymodule), then code:load_abs("/path/to/mymodule", to.mymodule), etc. until success, I think Erlang should support packages module (at least because packaged modules were officially introduced in OTP/Erlang). I could also give up using packaged module, so that I can use dialyzer and don't have to fix the Erlang tools I want to use that do not support packaged module. But if packaged module are the way to go and unless packaged module is considered a bad or wrongly implemented or about-to-be-removed thing, I'll try to use them. _FixSuggestions_: I think in code_server.erl the load_abs/3 function should be fix so that it: - Successively calls try_load_module with mymodule, to.mymodule, path.to.mymodule, stopping on sucess. Not so elegant though... - Calls try_load_module with mymodule (it actually does). But if the module name in object code does match mymodule, try_load_module with the module name found in object code. So that there is at most 2 calls of try_load_module. Problem: the object code (and the module name) is read by a C function (in beam_load.c) and it seems not straightforward to let Erlang know about the module name read in that object code. - Reading the file once, and use the module name defined within; avoiding multiple call to try_load_module. Better solution, but is it possible ? Best regards, Cyril From chsu79@REDACTED Mon Dec 29 01:31:18 2008 From: chsu79@REDACTED (Christian) Date: Mon, 29 Dec 2008 01:31:18 +0100 Subject: [erlang-bugs] A bug in file:pread or not? Message-ID: Sending a LocNum to file:pread/2 where the Size is zero returns eof rather than an empty binary. 2> {ok, File} = file:open("transpose.erl", [binary, read, raw]). {ok,{file_descriptor,prim_file,{#Port<0.93>,7}}} 3> file:pread(File, []). {ok,[]} 4> file:pread(File, [{10,10}]). {ok,[<<"ranspose).">>]} 5> file:pread(File, [{10,1}]). {ok,[<<"r">>]} 6> file:pread(File, [{10,0}]). {ok,[eof]} If I do: 8> file:pread(File, [{10, 10}, {10, 1}, {10,0}]). {ok,[<<"ranspose).">>,<<"r">>,eof]} Then I see this syscalls being performed using 'strace': pread64(7, "ranspose).", 10, 10) = 10 pread64(7, "r", 1, 10) = 1 pread64(7, "", 0, 10) = 0 So it looks like the syscall tell you that zero bytes were read. It is just reported as having tried to read outside the file. From chsu79@REDACTED Mon Dec 29 01:31:19 2008 From: chsu79@REDACTED (Christian) Date: Mon, 29 Dec 2008 01:31:19 +0100 Subject: [erlang-bugs] A bug in file:pread or not? Message-ID: Sending a LocNum to file:pread/2 where the Size is zero returns eof rather than an empty binary. 2> {ok, File} = file:open("transpose.erl", [binary, read, raw]). {ok,{file_descriptor,prim_file,{#Port<0.93>,7}}} 3> file:pread(File, []). {ok,[]} 4> file:pread(File, [{10,10}]). {ok,[<<"ranspose).">>]} 5> file:pread(File, [{10,1}]). {ok,[<<"r">>]} 6> file:pread(File, [{10,0}]). {ok,[eof]} If I do: 8> file:pread(File, [{10, 10}, {10, 1}, {10,0}]). {ok,[<<"ranspose).">>,<<"r">>,eof]} Then I see this syscalls being performed using 'strace': pread64(7, "ranspose).", 10, 10) = 10 pread64(7, "r", 1, 10) = 1 pread64(7, "", 0, 10) = 0 So it looks like the syscall tell you that zero bytes were read. It is just reported as having tried to read outside the file. From john.hughes@REDACTED Wed Dec 31 14:52:00 2008 From: john.hughes@REDACTED (John Hughes) Date: Wed, 31 Dec 2008 14:52:00 +0100 Subject: [erlang-bugs] EUnit discards all output Message-ID: <3E7B459FEA684B97BC8F5091EC883EEE@JTablet2007> >From the eunit Users' Guide: EUnit captures standard output If your test code writes to the standard output, you may be surprised to see that the text does not appear on the console when the tests are running. This is because EUnit captures all standard output from test functions (this also includes setup and cleanup functions, but not generator functions), so that it can be included in the test report if errors occur. OK, it says the output CAN be included in the test report if errors occur, not that it WILL be--but I nevertheless expected the latter to happen. When I run EUnit, however, ALL output is discarded, even output from failing tests. Is that really the intention? Maybe I'm just doing something wrong here--but I have not found any documented way to turn ON reporting of output from failed tests. I'm running the latest R12B under Windows XP. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hughes@REDACTED Wed Dec 31 15:04:49 2008 From: john.hughes@REDACTED (John Hughes) Date: Wed, 31 Dec 2008 15:04:49 +0100 Subject: [erlang-bugs] EUnit treats a process that kills itself as a successful test Message-ID: Here's my code: -module(eunit_example). -include_lib("eunit/include/eunit.hrl"). exit_test() -> exit(self(),die). In the shell, I run: 1> c(eunit_example). {ok,eunit_example} 2> eunit_example:test(). Test successful. ok Is that really the intention? Likewise, this test passes: spawn_test() -> spawn_link(erlang,exit,[dying]), timer:sleep(1). (The sleep is there to allow time for the child process to die, and the exit signal to be propagated). Presumably the process running the test is trapping exits--but is that really appropriate? As in this last example, crashes in child processes won't cause the test to fail. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfisher@REDACTED Wed Dec 31 22:09:39 2008 From: pfisher@REDACTED (Paul Fisher) Date: Wed, 31 Dec 2008 15:09:39 -0600 Subject: [erlang-bugs] erts_sys_ddll_open_noext() breaks on Opensolaris 2008.11 (and Nevada > svn95) Message-ID: <495BDF93.4000204@alertlogic.net> The erl_ddll module ultimately depends on the following little gem: int erts_sys_ddll_open_noext(char *dlname, void **handle) { int ret = ERL_DE_NO_ERROR; char *str; dlerror(); *handle = dlopen(dlname, RTLD_NOW); if ( (str = dlerror())) { /* Remove prefix filename to avoid exploading number of errorcodes on extreme usage */ if (strstr(str,dlname) == str) { char *save_str = str; str += strlen(dlname); while (*str == ':' || *str == ' ') { ++str; } if (*str == '\0') { /* Better with filename than nothing... */ str = save_str; } } ret = ERL_DE_DYNAMIC_ERROR_OFFSET - find_errcode(str); } return ret; } Unfortunately, this breaks on Opensolaris 2008.11 and Nevada > svn 95 builds because of what seems to be a change in the behavior of dlerror() returning a non-null value even when the dlopen() succeeds in returning a handle. What follows is a test program and output from my system (which is up-to-date 2008.11) that reproduces the problem. Given the following test program: #include #include int main( int argc, const char * const argv[] ) { const char *library = (argc > 1 ? argv[1] : "libuuid.so"); const char *error; void *handle; int ret = 0; /* clear out any lingering dlerror value just in case. */ dlerror(); /* open the specified library and if it fails bail with diagnostics. */ handle = dlopen( library, RTLD_NOW ); if( handle == 0 ) { printf( "dlopen( \"%s\", RTLD_NOW ) failed\n", library ); printf( "dlerror() reports the error as:\n %s\n", dlerror() ); return 1; } /* open seems to have worked, check what dlerror thinks of our dlopen call. */ printf( "dlopen( \"%s\", RTLD_NOW ) succeeded\n", library ); if( (error = dlerror()) != 0 ) { printf( "dlerror() still return returned non-null value:\n %s\n", error ); ret = 2; } /* close the handle, and make sure that succeeds. */ if( dlclose( handle ) == 0 ) printf( "dlclose() of handle succeeded\n" ); else { printf( "dlclose() of handle failed\n" ); printf( "dlerror() returned: %s\n", dlerror() ); ret = 3; } return ret; } compiled like so: pfisher@REDACTED:/tmp$ gcc -m64 -f -fPIC -c test.c pfisher@REDACTED:/tmp$ g++ -m64 test.o -o /tmp/test -lsocket -lnsl -pthread -lumem -lrt -ldl The following results from specifying libuuid.so to the test program: pfisher@REDACTED:/tmp$ truss -o /tmp/truss-fails.txt ./test libuuid.so dlopen( "libuuid.so", RTLD_NOW ) succeeded dlerror() still return returned non-null value: ld.so.1: test: fatal: libmapmalloc.so.1: No such file or directory dlclose() of handle succeeded This seems to be related to the behavior that was covered in http://www.virtualbox.org/ticket/1840 regarding /usr/lib/mps/64/libnspr4.so. but another library that does not pull in libnspr4.so works just fine: pfisher@REDACTED:/tmp$ truss -o /tmp/truss.txt ./test libcrypto.so dlopen( "libcrypto.so", RTLD_NOW ) succeeded dlclose() of handle succeeded The seemly obvious solution to this problem is to only fail when dlopen() returns a non-NULL value, only then checking the value of dlerror(). This would seem to be valid on all unix flavor systems, but there are always exceptions... -- paul From pfisher@REDACTED Wed Dec 31 22:14:16 2008 From: pfisher@REDACTED (Paul Fisher) Date: Wed, 31 Dec 2008 15:14:16 -0600 Subject: [erlang-bugs] R12B-5 hide private libpcre patch Message-ID: <495BE0A8.4010500@alertlogic.net> A while ago I had reported that the libpcre code compiled into beam(.smp) interfered with linked-in drivers because of incompatible changes to the code. The solution is to hide the entry points so that they are not resolved from linked-in driver code that expects to dynamically resolve to libpcre.so.3. The following patch renames the public entry points to be prefixed with erts_pcre_ and has worked in our environment: diff -ur otp_src_R12B-5.orig/erts/emulator/beam/erl_bif_re.c otp_src_R12B-5/erts/emulator/beam/erl_bif_re.c --- otp_src_R12B-5.orig/erts/emulator/beam/erl_bif_re.c 2008-11-24 08:48:37.920967010 -0600 +++ otp_src_R12B-5/erts/emulator/beam/erl_bif_re.c 2008-11-24 09:22:54.770789631 -0600 @@ -61,10 +61,10 @@ void erts_init_bif_re(void) { - pcre_malloc = &erts_pcre_malloc; - pcre_free = &erts_pcre_free; - pcre_stack_malloc = &erts_pcre_stack_malloc; - pcre_stack_free = &erts_pcre_stack_free; + erts_pcre_malloc_f = &erts_pcre_malloc; + erts_pcre_free_f = &erts_pcre_free; + erts_pcre_stack_malloc_f = &erts_pcre_stack_malloc; + erts_pcre_stack_free_f = &erts_pcre_stack_free; default_table = NULL; /* ISO8859-1 default, forced into pcre */ max_loop_limit = CONTEXT_REDS * LOOP_FACTOR; @@ -389,12 +389,12 @@ hp += 3; ret = TUPLE2(hp, error_tag, ret); } else { - pcre_fullinfo(result, NULL, PCRE_INFO_SIZE, &pattern_size); - pcre_fullinfo(result, NULL, PCRE_INFO_CAPTURECOUNT, &capture_count); + erts_pcre_fullinfo(result, NULL, PCRE_INFO_SIZE, &pattern_size); + erts_pcre_fullinfo(result, NULL, PCRE_INFO_CAPTURECOUNT, &capture_count); /* XXX: Optimize - keep in offheap binary to allow this to be kept across traps w/o need of copying */ ret = new_binary(p, (byte *) result, pattern_size); - pcre_free(result); + erts_pcre_free(result); hp = HAlloc(p, (with_ok) ? (3+5) : 5); ret = TUPLE4(hp,am_re_pattern, make_small(capture_count), make_small(unicode),ret); if (with_ok) { @@ -448,8 +448,8 @@ BIF_ERROR(BIF_P,BADARG); } expr[slen]='\0'; - result = pcre_compile2(expr, options, &errcode, - &errstr, &errofset, default_table); + result = erts_pcre_compile2(expr, options, &errcode, + &errstr, &errofset, default_table); ret = build_compile_result(BIF_P, am_error, result, errcode, errstr, errofset, unicode, 1); @@ -495,7 +495,7 @@ static void cleanup_restart_context(RestartContext *rc) { if (rc->restart_data != NULL) { - pcre_free_restart_data(rc->restart_data); + erts_pcre_free_restart_data(rc->restart_data); rc->restart_data = NULL; } if (rc->ovector != NULL) { @@ -767,7 +767,7 @@ } tmpb[slen] = '\0'; } - if ((ri->v[ri->num_spec - 1] = pcre_get_stringnumber(code,tmpb)) == + if ((ri->v[ri->num_spec - 1] = erts_pcre_get_stringnumber(code,tmpb)) == PCRE_ERROR_NOSUBSTRING) { ri->v[ri->num_spec - 1] = -1; } @@ -849,8 +849,8 @@ BIF_ERROR(BIF_P,BADARG); } expr[slen]='\0'; - result = pcre_compile2(expr, comp_options, &errcode, - &errstr, &errofset, default_table); + result = erts_pcre_compile2(expr, comp_options, &errcode, + &errstr, &errofset, default_table); if (!result) { erts_free(ERTS_ALC_T_RE_TMP_BUF, expr); /* Compilation error gives badarg except in the compile @@ -876,12 +876,12 @@ BIF_TRAP3(grun_trap_exportp, BIF_P, BIF_ARG_1, precompiled, r); } - pcre_fullinfo(result, NULL, PCRE_INFO_SIZE, &code_size); - pcre_fullinfo(result, NULL, PCRE_INFO_CAPTURECOUNT, &capture_count); + erts_pcre_fullinfo(result, NULL, PCRE_INFO_SIZE, &code_size); + erts_pcre_fullinfo(result, NULL, PCRE_INFO_CAPTURECOUNT, &capture_count); ovsize = 3*(capture_count+1); restart.code = erts_alloc(ERTS_ALC_T_RE_SUBJECT, code_size); memcpy(restart.code, result, code_size); - pcre_free(result); + erts_pcre_free(result); erts_free(ERTS_ALC_T_RE_TMP_BUF, expr); /*unicode = (pflags & PARSE_FLAG_UNICODE) ? 1 : 0;*/ } else { @@ -967,7 +967,7 @@ loop_count = 0xFFFFFFFF; #endif - rc = pcre_exec(restart.code, &(restart.extra), restart.subject, slength, startoffset, + rc = erts_pcre_exec(restart.code, &(restart.extra), restart.subject, slength, startoffset, options, restart.ovector, ovsize); ASSERT(loop_count != 0xFFFFFFFF); BUMP_REDS(BIF_P, loop_count / LOOP_FACTOR); @@ -1035,7 +1035,7 @@ #ifdef DEBUG loop_count = 0xFFFFFFFF; #endif - rc = pcre_exec(NULL, &(restartp->extra), NULL, 0, 0, 0, NULL, 0); + rc = erts_pcre_exec(NULL, &(restartp->extra), NULL, 0, 0, 0, NULL, 0); ASSERT(loop_count != 0xFFFFFFFF); BUMP_REDS(BIF_P, loop_count / LOOP_FACTOR); if (rc == PCRE_ERROR_LOOP_LIMIT) { diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_compile.c otp_src_R12B-5/erts/emulator/pcre/pcre_compile.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_compile.c 2008-11-24 08:48:37.874132417 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_compile.c 2008-11-24 09:22:26.143832254 -0600 @@ -5786,15 +5786,15 @@ */ PCRE_EXP_DEFN pcre * -pcre_compile(const char *pattern, int options, const char **errorptr, +erts_pcre_compile(const char *pattern, int options, const char **errorptr, int *erroroffset, const unsigned char *tables) { -return pcre_compile2(pattern, options, NULL, errorptr, erroroffset, tables); +return erts_pcre_compile2(pattern, options, NULL, errorptr, erroroffset, tables); } PCRE_EXP_DEFN pcre * -pcre_compile2(const char *pattern, int options, int *errorcodeptr, +erts_pcre_compile2(const char *pattern, int options, int *errorcodeptr, const char **errorptr, int *erroroffset, const unsigned char *tables) { real_pcre *re; @@ -6022,7 +6022,7 @@ cd->name_entry_size. */ size = length + sizeof(real_pcre) + cd->names_found * (cd->name_entry_size + 3); -re = (real_pcre *)(pcre_malloc)(size); +re = (real_pcre *)(erts_pcre_malloc_f)(size); if (re == NULL) { @@ -6118,7 +6118,7 @@ if (errorcode != 0) { - (pcre_free)(re); + (erts_pcre_free_f)(re); PCRE_EARLY_ERROR_RETURN: *erroroffset = ptr - (const uschar *)pattern; PCRE_EARLY_ERROR_RETURN2: @@ -6206,7 +6206,7 @@ if (code - codestart > length) { - (pcre_free)(re); + (erts_pcre_free_f)(re); *errorptr = find_error_text(ERR23); *erroroffset = ptr - (uschar *)pattern; if (errorcodeptr != NULL) *errorcodeptr = ERR23; diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_config.c otp_src_R12B-5/erts/emulator/pcre/pcre_config.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_config.c 2008-11-24 08:48:37.896839943 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_config.c 2008-11-24 09:11:51.900473970 -0600 @@ -63,7 +63,7 @@ */ PCRE_EXP_DEFN int -pcre_config(int what, void *where) +erts_pcre_config(int what, void *where) { switch (what) { diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_dfa_exec.c otp_src_R12B-5/erts/emulator/pcre/pcre_dfa_exec.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_dfa_exec.c 2008-11-24 08:48:37.875955067 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_dfa_exec.c 2008-11-24 09:22:12.611173554 -0600 @@ -2404,7 +2404,7 @@ /* Handle callouts */ case OP_CALLOUT: - if (pcre_callout != NULL) + if (erts_pcre_callout_f != NULL) { int rrc; pcre_callout_block cb; @@ -2420,7 +2420,7 @@ cb.capture_top = 1; cb.capture_last = -1; cb.callout_data = md->callout_data; - if ((rrc = (*pcre_callout)(&cb)) < 0) return rrc; /* Abandon */ + if ((rrc = (*erts_pcre_callout_f)(&cb)) < 0) return rrc; /* Abandon */ if (rrc == 0) { ADD_ACTIVE(state_offset + 2 + 2*LINK_SIZE, 0); } } break; @@ -2506,7 +2506,7 @@ */ PCRE_EXP_DEFN int -pcre_dfa_exec(const pcre *argument_re, const pcre_extra *extra_data, +erts_pcre_dfa_exec(const pcre *argument_re, const pcre_extra *extra_data, const char *subject, int length, int start_offset, int options, int *offsets, int offsetcount, int *workspace, int wscount) { diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_exec.c otp_src_R12B-5/erts/emulator/pcre/pcre_exec.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_exec.c 2008-11-24 08:48:37.876553392 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_exec.c 2008-11-24 09:22:23.386491532 -0600 @@ -275,7 +275,7 @@ #define RMATCH(ra,rb,rc,rd,re,rf,rg,rw)\ {\ - heapframe *newframe = (pcre_stack_malloc)(sizeof(heapframe));\ + heapframe *newframe = (erts_pcre_stack_malloc_f)(sizeof(heapframe));\ frame->Xwhere = rw; \ newframe->Xeptr = ra;\ newframe->Xecode = rb;\ @@ -298,7 +298,7 @@ {\ heapframe *newframe = frame;\ frame = newframe->Xprevframe;\ - (pcre_stack_free)(newframe);\ + (erts_pcre_stack_free_f)(newframe);\ if (frame != NULL)\ {\ rrc = ra;\ @@ -315,7 +315,7 @@ {\ heapframe *newframe = frame;\ frame = newframe->Xprevframe;\ - (pcre_stack_free)(newframe);\ + (erts_pcre_stack_free_f)(newframe);\ if (frame != NULL)\ {\ rrc = ra;\ @@ -491,11 +491,11 @@ EDEBUGF(("Break restore!")); goto LOOP_COUNT_RETURN; } -frame = (pcre_stack_malloc)(sizeof(heapframe)); +frame = (erts_pcre_stack_malloc_f)(sizeof(heapframe)); #else #define COST(N) #define COST_CHK(N) -heapframe *frame = (pcre_stack_malloc)(sizeof(heapframe)); +heapframe *frame = (erts_pcre_stack_malloc_f)(sizeof(heapframe)); #endif frame->Xprevframe = NULL; /* Marks the top level */ @@ -1038,7 +1038,7 @@ function is able to force a failure. */ case OP_CALLOUT: - if (pcre_callout != NULL) + if (erts_pcre_callout_f != NULL) { pcre_callout_block cb; cb.version = 1; /* Version 1 of the callout block */ @@ -1053,7 +1053,7 @@ cb.capture_top = offset_top/2; cb.capture_last = md->capture_last; cb.callout_data = md->callout_data; - if ((rrc = (*pcre_callout)(&cb)) > 0) RRETURN(MATCH_NOMATCH); + if ((rrc = (*erts_pcre_callout_f)(&cb)) > 0) RRETURN(MATCH_NOMATCH); if (rrc < 0) RRETURN(rrc); } ecode += 2 + 2*LINK_SIZE; @@ -1102,7 +1102,7 @@ else { new_recursive.offset_save = - (int *)(pcre_malloc)(new_recursive.saved_max * sizeof(int)); + (int *)(erts_pcre_malloc_f)(new_recursive.saved_max * sizeof(int)); if (new_recursive.offset_save == NULL) RRETURN(PCRE_ERROR_NOMEMORY); } @@ -1125,7 +1125,7 @@ DPRINTF(("Recursion matched\n")); md->recursive = new_recursive.prevrec; if (new_recursive.offset_save != stacksave) - (pcre_free)(new_recursive.offset_save); + (erts_pcre_free_f)(new_recursive.offset_save); RRETURN(MATCH_MATCH); } else if (rrc != MATCH_NOMATCH && rrc != MATCH_THEN) @@ -1144,7 +1144,7 @@ DPRINTF(("Recursion didn't match\n")); md->recursive = new_recursive.prevrec; if (new_recursive.offset_save != stacksave) - (pcre_free)(new_recursive.offset_save); + (erts_pcre_free_f)(new_recursive.offset_save); RRETURN(MATCH_NOMATCH); } /* Control never reaches here */ @@ -4442,7 +4442,7 @@ utf8 = newframe->Xcur_is_word; minimize = newframe->Xcondition; possessive = newframe->Xprev_is_word; - (pcre_stack_free)(newframe); + (erts_pcre_stack_free_f)(newframe); EDEBUGF(("LOOP_COUNT_RETURN: %d",frame->Xwhere)); switch (frame->Xwhere) { @@ -4467,7 +4467,7 @@ * possessive Xprev_is_word */ { - heapframe *newframe = (pcre_stack_malloc)(sizeof(heapframe)); + heapframe *newframe = (erts_pcre_stack_malloc_f)(sizeof(heapframe)); newframe->Xprevframe = frame; newframe->Xop = rrc; newframe->Xfi = i; @@ -4489,7 +4489,7 @@ static void free_saved_match_state(heapframe *top) { while (top != NULL) { heapframe *nxt = top->Xprevframe; - (pcre_stack_free)(top); + (erts_pcre_stack_free_f)(top); top = nxt; } } @@ -4617,7 +4617,7 @@ #endif PCRE_EXP_DEFN int -pcre_exec(const pcre *argument_re, const pcre_extra *extra_data, +erts_pcre_exec(const pcre *argument_re, const pcre_extra *extra_data, PCRE_SPTR subject, int length, int start_offset, int options, int *offsets, int offsetcount) { @@ -4721,7 +4721,7 @@ } else { if (extra_data != NULL && (extra_data->flags & PCRE_EXTRA_LOOP_LIMIT)) { - exec_context = (PcreExecContext *) (pcre_malloc)(sizeof(PcreExecContext)); + exec_context = (PcreExecContext *) (erts_pcre_malloc_f)(sizeof(PcreExecContext)); *(extra_data->restart_data) = (void *) exec_context; /* need freeing by special routine from client */ } else { @@ -4944,7 +4944,7 @@ if (re->top_backref > 0 && re->top_backref >= ocount/3) { ocount = re->top_backref * 3 + 3; - md->offset_vector = (int *)(pcre_malloc)(ocount * sizeof(int)); + md->offset_vector = (int *)(erts_pcre_malloc_f)(ocount * sizeof(int)); if (md->offset_vector == NULL) return PCRE_ERROR_NOMEMORY; using_temporary_offsets = TRUE; DPRINTF(("Got memory to hold back references\n")); @@ -5304,10 +5304,10 @@ #ifdef ERLANG_INTEGRATION if (extra_data == NULL || !(extra_data->flags & PCRE_EXTRA_LOOP_LIMIT)) { - (pcre_free)(md->offset_vector); + (erts_pcre_free_f)(md->offset_vector); } #else - (pcre_free)(md->offset_vector); + (erts_pcre_free_f)(md->offset_vector); #endif } @@ -5336,7 +5336,7 @@ if (using_temporary_offsets) { DPRINTF(("Freeing temporary memory\n")); - (pcre_free)(md->offset_vector); + (erts_pcre_free_f)(md->offset_vector); } if (rc != MATCH_NOMATCH) @@ -5375,16 +5375,16 @@ #undef re #undef ims -void pcre_free_restart_data(void *restart_data) { +void erts_pcre_free_restart_data(void *restart_data) { PcreExecContext *top = (PcreExecContext *) restart_data; /* We might be done, or we might not, so there might be some saved match_states here */ if (top != NULL) { match_data *md = top->Xmd; if (top->Xusing_temporary_offsets && md->offset_vector != NULL) { - (pcre_free)(md->offset_vector); + (erts_pcre_free_f)(md->offset_vector); } free_saved_match_state(top->Xmd->state_save); - (pcre_free)(top); + (erts_pcre_free_f)(top); } } #endif diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_fullinfo.c otp_src_R12B-5/erts/emulator/pcre/pcre_fullinfo.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_fullinfo.c 2008-11-24 08:48:37.874225285 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_fullinfo.c 2008-11-24 09:11:46.425871337 -0600 @@ -66,8 +66,8 @@ */ PCRE_EXP_DEFN int -pcre_fullinfo(const pcre *argument_re, const pcre_extra *extra_data, int what, - void *where) +erts_pcre_fullinfo(const pcre *argument_re, const pcre_extra *extra_data, + int what, void *where) { real_pcre internal_re; pcre_study_data internal_study; diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_get.c otp_src_R12B-5/erts/emulator/pcre/pcre_get.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_get.c 2008-11-24 08:48:37.896368417 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_get.c 2008-11-24 12:42:06.283498362 -0600 @@ -65,21 +65,22 @@ (PCRE_ERROR_NOSUBSTRING) if not found */ +PCRE_EXP_DEFN int -pcre_get_stringnumber(const pcre *code, const char *stringname) +erts_pcre_get_stringnumber(const pcre *code, const char *stringname) { int rc; int entrysize; int top, bot; uschar *nametable; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMECOUNT, &top)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMECOUNT, &top)) != 0) return rc; if (top <= 0) return PCRE_ERROR_NOSUBSTRING; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMEENTRYSIZE, &entrysize)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMEENTRYSIZE, &entrysize)) != 0) return rc; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMETABLE, &nametable)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMETABLE, &nametable)) != 0) return rc; bot = 0; @@ -114,8 +115,9 @@ (PCRE_ERROR_NOSUBSTRING) if not found */ +PCRE_EXP_DEFN int -pcre_get_stringtable_entries(const pcre *code, const char *stringname, +erts_pcre_get_stringtable_entries(const pcre *code, const char *stringname, char **firstptr, char **lastptr) { int rc; @@ -123,13 +125,13 @@ int top, bot; uschar *nametable, *lastentry; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMECOUNT, &top)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMECOUNT, &top)) != 0) return rc; if (top <= 0) return PCRE_ERROR_NOSUBSTRING; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMEENTRYSIZE, &entrysize)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMEENTRYSIZE, &entrysize)) != 0) return rc; -if ((rc = pcre_fullinfo(code, NULL, PCRE_INFO_NAMETABLE, &nametable)) != 0) +if ((rc = erts_pcre_fullinfo(code, NULL, PCRE_INFO_NAMETABLE, &nametable)) != 0) return rc; lastentry = nametable + entrysize * (top - 1); @@ -190,8 +192,8 @@ char *first, *last; uschar *entry; if ((re->options & PCRE_DUPNAMES) == 0 && (re->flags & PCRE_JCHANGED) == 0) - return pcre_get_stringnumber(code, stringname); -entrysize = pcre_get_stringtable_entries(code, stringname, &first, &last); + return erts_pcre_get_stringnumber(code, stringname); +entrysize = erts_pcre_get_stringtable_entries(code, stringname, &first, &last); if (entrysize <= 0) return entrysize; for (entry = (uschar *)first; entry <= (uschar *)last; entry += entrysize) { @@ -231,8 +233,9 @@ PCRE_ERROR_NOSUBSTRING (-7) no such captured substring */ +PCRE_EXP_DEFN int -pcre_copy_substring(const char *subject, int *ovector, int stringcount, +erts_pcre_copy_substring(const char *subject, int *ovector, int stringcount, int stringnumber, char *buffer, int size) { int yield; @@ -276,13 +279,14 @@ PCRE_ERROR_NOSUBSTRING (-7) no such captured substring */ +PCRE_EXP_DEFN int -pcre_copy_named_substring(const pcre *code, const char *subject, int *ovector, +erts_pcre_copy_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, char *buffer, int size) { int n = get_first_set(code, stringname, ovector); if (n <= 0) return n; -return pcre_copy_substring(subject, ovector, stringcount, n, buffer, size); +return erts_pcre_copy_substring(subject, ovector, stringcount, n, buffer, size); } @@ -308,8 +312,9 @@ PCRE_ERROR_NOMEMORY (-6) failed to get store */ +PCRE_EXP_DEFN int -pcre_get_substring_list(const char *subject, int *ovector, int stringcount, +erts_pcre_get_substring_list(const char *subject, int *ovector, int stringcount, const char ***listptr) { int i; @@ -321,7 +326,7 @@ for (i = 0; i < double_count; i += 2) size += sizeof(char *) + ovector[i+1] - ovector[i] + 1; -stringlist = (char **)(pcre_malloc)(size); +stringlist = (char **)(erts_pcre_malloc_f)(size); if (stringlist == NULL) return PCRE_ERROR_NOMEMORY; *listptr = (const char **)stringlist; @@ -353,10 +358,11 @@ Returns: nothing */ +PCRE_EXP_DEFN void -pcre_free_substring_list(const char **pointer) +erts_pcre_free_substring_list(const char **pointer) { -(pcre_free)((void *)pointer); +(erts_pcre_free_f)((void *)pointer); } @@ -386,8 +392,9 @@ PCRE_ERROR_NOSUBSTRING (-7) substring not present */ +PCRE_EXP_DEFN int -pcre_get_substring(const char *subject, int *ovector, int stringcount, +erts_pcre_get_substring(const char *subject, int *ovector, int stringcount, int stringnumber, const char **stringptr) { int yield; @@ -396,7 +403,7 @@ return PCRE_ERROR_NOSUBSTRING; stringnumber *= 2; yield = ovector[stringnumber+1] - ovector[stringnumber]; -substring = (char *)(pcre_malloc)(yield + 1); +substring = (char *)(erts_pcre_malloc_f)(yield + 1); if (substring == NULL) return PCRE_ERROR_NOMEMORY; memcpy(substring, subject + ovector[stringnumber], yield); substring[yield] = 0; @@ -433,13 +440,14 @@ PCRE_ERROR_NOSUBSTRING (-7) no such captured substring */ +PCRE_EXP_DEFN int -pcre_get_named_substring(const pcre *code, const char *subject, int *ovector, +erts_pcre_get_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, const char **stringptr) { int n = get_first_set(code, stringname, ovector); if (n <= 0) return n; -return pcre_get_substring(subject, ovector, stringcount, n, stringptr); +return erts_pcre_get_substring(subject, ovector, stringcount, n, stringptr); } @@ -456,10 +464,11 @@ Returns: nothing */ +PCRE_EXP_DEFN void -pcre_free_substring(const char *pointer) +erts_pcre_free_substring(const char *pointer) { -(pcre_free)((void *)pointer); +(erts_pcre_free_f)((void *)pointer); } /* End of pcre_get.c */ Only in otp_src_R12B-5/erts/emulator/pcre: pcre_get.c~ diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_globals.c otp_src_R12B-5/erts/emulator/pcre/pcre_globals.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_globals.c 2008-11-24 08:48:37.876134005 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_globals.c 2008-11-24 09:22:21.490581180 -0600 @@ -53,11 +53,11 @@ #include "pcre_internal.h" #ifndef VPCOMPAT -PCRE_EXP_DATA_DEFN void *(*pcre_malloc)(size_t) = malloc; -PCRE_EXP_DATA_DEFN void (*pcre_free)(void *) = free; -PCRE_EXP_DATA_DEFN void *(*pcre_stack_malloc)(size_t) = malloc; -PCRE_EXP_DATA_DEFN void (*pcre_stack_free)(void *) = free; -PCRE_EXP_DATA_DEFN int (*pcre_callout)(pcre_callout_block *) = NULL; +PCRE_EXP_DATA_DEFN void *(*erts_pcre_malloc_f)(size_t) = malloc; +PCRE_EXP_DATA_DEFN void (*erts_pcre_free_f)(void *) = free; +PCRE_EXP_DATA_DEFN void *(*erts_pcre_stack_malloc_f)(size_t) = malloc; +PCRE_EXP_DATA_DEFN void (*erts_pcre_stack_free_f)(void *) = free; +PCRE_EXP_DATA_DEFN int (*erts_pcre_callout_f)(pcre_callout_block *) = NULL; #endif /* End of pcre_globals.c */ diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre.h otp_src_R12B-5/erts/emulator/pcre/pcre.h --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre.h 2008-11-24 08:48:37.895104421 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre.h 2008-11-24 09:17:42.955780881 -0600 @@ -261,55 +261,55 @@ have to take another form. */ #ifndef VPCOMPAT -PCRE_EXP_DECL void *(*pcre_malloc)(size_t); -PCRE_EXP_DECL void (*pcre_free)(void *); -PCRE_EXP_DECL void *(*pcre_stack_malloc)(size_t); -PCRE_EXP_DECL void (*pcre_stack_free)(void *); -PCRE_EXP_DECL int (*pcre_callout)(pcre_callout_block *); +PCRE_EXP_DECL void *(*erts_pcre_malloc_f)(size_t); +PCRE_EXP_DECL void (*erts_pcre_free_f)(void *); +PCRE_EXP_DECL void *(*erts_pcre_stack_malloc_f)(size_t); +PCRE_EXP_DECL void (*erts_pcre_stack_free_f)(void *); +PCRE_EXP_DECL int (*erts_pcre_callout_f)(pcre_callout_block *); #else /* VPCOMPAT */ -PCRE_EXP_DECL void *pcre_malloc(size_t); -PCRE_EXP_DECL void pcre_free(void *); -PCRE_EXP_DECL void *pcre_stack_malloc(size_t); -PCRE_EXP_DECL void pcre_stack_free(void *); -PCRE_EXP_DECL int pcre_callout(pcre_callout_block *); +PCRE_EXP_DECL void *erts_pcre_malloc_f(size_t); +PCRE_EXP_DECL void erts_pcre_free_f(void *); +PCRE_EXP_DECL void *erts_pcre_stack_malloc_f(size_t); +PCRE_EXP_DECL void erts_pcre_stack_free_f(void *); +PCRE_EXP_DECL int erts_pcre_callout_f(pcre_callout_block *); #endif /* VPCOMPAT */ /* Exported PCRE functions */ -PCRE_EXP_DECL pcre *pcre_compile(const char *, int, const char **, int *, +PCRE_EXP_DECL pcre *erts_pcre_compile(const char *, int, const char **, int *, const unsigned char *); -PCRE_EXP_DECL pcre *pcre_compile2(const char *, int, int *, const char **, +PCRE_EXP_DECL pcre *erts_pcre_compile2(const char *, int, int *, const char **, int *, const unsigned char *); -PCRE_EXP_DECL int pcre_config(int, void *); -PCRE_EXP_DECL int pcre_copy_named_substring(const pcre *, const char *, +PCRE_EXP_DECL int erts_pcre_config(int, void *); +PCRE_EXP_DECL int erts_pcre_copy_named_substring(const pcre *, const char *, int *, int, const char *, char *, int); -PCRE_EXP_DECL int pcre_copy_substring(const char *, int *, int, int, char *, +PCRE_EXP_DECL int erts_pcre_copy_substring(const char *, int *, int, int, char *, int); -PCRE_EXP_DECL int pcre_dfa_exec(const pcre *, const pcre_extra *, +PCRE_EXP_DECL int erts_pcre_dfa_exec(const pcre *, const pcre_extra *, const char *, int, int, int, int *, int , int *, int); -PCRE_EXP_DECL int pcre_exec(const pcre *, const pcre_extra *, PCRE_SPTR, +PCRE_EXP_DECL int erts_pcre_exec(const pcre *, const pcre_extra *, PCRE_SPTR, int, int, int, int *, int); -PCRE_EXP_DECL void pcre_free_substring(const char *); -PCRE_EXP_DECL void pcre_free_substring_list(const char **); -PCRE_EXP_DECL int pcre_fullinfo(const pcre *, const pcre_extra *, int, +PCRE_EXP_DECL void erts_pcre_free_substring(const char *); +PCRE_EXP_DECL void erts_pcre_free_substring_list(const char **); +PCRE_EXP_DECL int erts_pcre_fullinfo(const pcre *, const pcre_extra *, int, void *); -PCRE_EXP_DECL int pcre_get_named_substring(const pcre *, const char *, +PCRE_EXP_DECL int erts_pcre_get_named_substring(const pcre *, const char *, int *, int, const char *, const char **); -PCRE_EXP_DECL int pcre_get_stringnumber(const pcre *, const char *); -PCRE_EXP_DECL int pcre_get_stringtable_entries(const pcre *, const char *, +PCRE_EXP_DECL int erts_pcre_get_stringnumber(const pcre *, const char *); +PCRE_EXP_DECL int erts_pcre_get_stringtable_entries(const pcre *, const char *, char **, char **); -PCRE_EXP_DECL int pcre_get_substring(const char *, int *, int, int, +PCRE_EXP_DECL int erts_pcre_get_substring(const char *, int *, int, int, const char **); -PCRE_EXP_DECL int pcre_get_substring_list(const char *, int *, int, +PCRE_EXP_DECL int erts_pcre_get_substring_list(const char *, int *, int, const char ***); -PCRE_EXP_DECL int pcre_info(const pcre *, int *, int *); -PCRE_EXP_DECL const unsigned char *pcre_maketables(void); -PCRE_EXP_DECL int pcre_refcount(pcre *, int); -PCRE_EXP_DECL pcre_extra *pcre_study(const pcre *, int, const char **); -PCRE_EXP_DECL const char *pcre_version(void); +PCRE_EXP_DECL int erts_pcre_info(const pcre *, int *, int *); +PCRE_EXP_DECL const unsigned char *erts_pcre_maketables(void); +PCRE_EXP_DECL int erts_pcre_refcount(pcre *, int); +PCRE_EXP_DECL pcre_extra *erts_pcre_study(const pcre *, int, const char **); +PCRE_EXP_DECL const char *erts_pcre_version(void); #ifdef ERLANG_INTEGRATION -PCRE_EXP_DECL void pcre_free_restart_data(void *restart_data); +PCRE_EXP_DECL void erts_pcre_free_restart_data(void *restart_data); #endif #ifdef __cplusplus } /* extern "C" */ diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_info.c otp_src_R12B-5/erts/emulator/pcre/pcre_info.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_info.c 2008-11-24 08:48:37.876051985 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_info.c 2008-11-24 09:11:44.595525247 -0600 @@ -73,7 +73,7 @@ */ PCRE_EXP_DEFN int -pcre_info(const pcre *argument_re, int *optptr, int *first_byte) +erts_pcre_info(const pcre *argument_re, int *optptr, int *first_byte) { real_pcre internal_re; const real_pcre *re = (const real_pcre *)argument_re; diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_maketables.c otp_src_R12B-5/erts/emulator/pcre/pcre_maketables.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_maketables.c 2008-11-24 08:48:37.897015923 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_maketables.c 2008-11-24 09:22:27.483868368 -0600 @@ -73,7 +73,7 @@ int i; #ifndef DFTABLES -yield = (unsigned char*)(pcre_malloc)(tables_length); +yield = (unsigned char*)(erts_pcre_malloc_f)(tables_length); #else yield = (unsigned char*)malloc(tables_length); #endif diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_refcount.c otp_src_R12B-5/erts/emulator/pcre/pcre_refcount.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_refcount.c 2008-11-24 08:48:37.896195159 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_refcount.c 2008-11-24 09:11:42.645337836 -0600 @@ -69,7 +69,7 @@ */ PCRE_EXP_DEFN int -pcre_refcount(pcre *argument_re, int adjust) +erts_pcre_refcount(pcre *argument_re, int adjust) { real_pcre *re = (real_pcre *)argument_re; if (re == NULL) return PCRE_ERROR_NULL; diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_study.c otp_src_R12B-5/erts/emulator/pcre/pcre_study.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_study.c 2008-11-24 08:48:37.896931557 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_study.c 2008-11-24 09:19:15.702477776 -0600 @@ -496,7 +496,7 @@ */ PCRE_EXP_DEFN pcre_extra * -pcre_study(const pcre *external_re, int options, const char **errorptr) +erts_pcre_study(const pcre *external_re, int options, const char **errorptr) { uschar start_bits[32]; pcre_extra *extra; @@ -556,7 +556,7 @@ the pcre_fullinfo() function so that if it becomes variable in the future, we don't have to change that code. */ -extra = (pcre_extra *)(pcre_malloc) +extra = (pcre_extra *)(erts_pcre_malloc_f) (sizeof(pcre_extra) + sizeof(pcre_study_data)); if (extra == NULL) diff -ur otp_src_R12B-5.orig/erts/emulator/pcre/pcre_version.c otp_src_R12B-5/erts/emulator/pcre/pcre_version.c --- otp_src_R12B-5.orig/erts/emulator/pcre/pcre_version.c 2008-11-24 08:48:37.896282894 -0600 +++ otp_src_R12B-5/erts/emulator/pcre/pcre_version.c 2008-11-24 09:11:38.519598556 -0600 @@ -80,7 +80,7 @@ the STRING macro with an empty argument when doing the test. */ PCRE_EXP_DEFN const char * -pcre_version(void) +erts_pcre_version(void) { return (XSTRING(Z PCRE_PRERELEASE)[1] == 0)? XSTRING(PCRE_MAJOR.PCRE_MINOR PCRE_DATE) : -- paul