From matt.keenan@REDACTED Wed Apr 13 15:46:39 2016 From: matt.keenan@REDACTED (Matt Keenan) Date: Wed, 13 Apr 2016 14:46:39 +0100 Subject: [erlang-bugs] math:exp() erlang bug on SPARC Message-ID: <570E4DBF.8090102@oracle.com> Hi, Just wanted to report a SPARC specific issue with Erlang. See discussions: https://github.com/rabbitmq/rabbitmq-server/issues/132 https://groups.google.com/forum/#!topic/rabbitmq-users/Gca8vW52gB8 Only happens on SPARC systems does not occur on X86 architecture. e.g.: On s11u3 x86: 1> math:exp(-1162.102134881488). 0.0 On s11u3 SPARC: 1> math:exp(-1162.102134881488). ** exception error: an error occurred when evaluating an arithmetic expression in function math:exp/1 called as math:exp(-1162.102134881488) Both systems are running 64-bit Erlang 17.5 in a 64-bit environment. Has an issue related to this been posted before ? cheers Matt From jesper.louis.andersen@REDACTED Thu Apr 14 13:24:36 2016 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 14 Apr 2016 13:24:36 +0200 Subject: [erlang-bugs] math:exp() erlang bug on SPARC In-Reply-To: <570E4DBF.8090102@oracle.com> References: <570E4DBF.8090102@oracle.com> Message-ID: On Wed, Apr 13, 2016 at 3:46 PM, Matt Keenan wrote: > Just wanted to report a SPARC specific issue with Erlang. I'm not entirely convinced it is with Erlang, so consider this inquiry. Sparc uses a 64bit wide internal representation of IEEE 754 double binary fp numbers, whereas the internal representation in x86 is 80 bit wide (due to that being the width of the 387 coprocessor back in the day). exp(-1162.102134881488) is 2.02048... x 10^-505 which is smaller than the smallest representable float. The limit, as x -> -infty is 0 for exp(_), so one would argue that the correct output in this case is 0.0. Erlang simply calls into the C math.h exp function for this, but it does FP exception checks around the point. One way to figure out what happens would be to get hold of a SPARC machine, write a simple C program doing the same and verifying that the SPARC compilers agrees on that one with an x86 program. I could imagine some way it provokes an FP exception on the SPARC architecture, but not on x86 due to the extra bits x86 has in internal encoding width. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benmmurphy@REDACTED Thu Apr 14 13:59:04 2016 From: benmmurphy@REDACTED (Ben Murphy) Date: Thu, 14 Apr 2016 12:59:04 +0100 Subject: [erlang-bugs] math:exp() erlang bug on SPARC In-Reply-To: References: <570E4DBF.8090102@oracle.com> Message-ID: I think the issue is with Solaris implementation of exp in libm (i don't know if it is actually correct or not....): You can take the code exp.c code from illumos (opensolaris fork) https://github.com/joyent/illumos-joyent/blob/master/usr/src/lib/libm/common/C/exp.c#L334 and run it on x86 and you will see the same issue. It falls over on: if (-x > threshold2) So if you do exp(x) and x < -7.45133219101941108420e+02 then you trigger it On Thu, Apr 14, 2016 at 12:24 PM, Jesper Louis Andersen wrote: > > On Wed, Apr 13, 2016 at 3:46 PM, Matt Keenan wrote: >> >> Just wanted to report a SPARC specific issue with Erlang. > > > I'm not entirely convinced it is with Erlang, so consider this inquiry. > Sparc uses a 64bit wide internal representation of IEEE 754 double binary fp > numbers, whereas the internal representation in x86 is 80 bit wide (due to > that being the width of the 387 coprocessor back in the day). > > exp(-1162.102134881488) > > is 2.02048... x 10^-505 which is smaller than the smallest representable > float. The limit, as x -> -infty is 0 for exp(_), so one would argue that > the correct output in this case is 0.0. > > Erlang simply calls into the C math.h exp function for this, but it does FP > exception checks around the point. One way to figure out what happens would > be to get hold of a SPARC machine, write a simple C program doing the same > and verifying that the SPARC compilers agrees on that one with an x86 > program. I could imagine some way it provokes an FP exception on the SPARC > architecture, but not on x86 due to the extra bits x86 has in internal > encoding width. > > -- > J. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From Aleksander.Nycz@REDACTED Sat Apr 16 07:33:53 2016 From: Aleksander.Nycz@REDACTED (Aleksander Nycz) Date: Sat, 16 Apr 2016 07:33:53 +0200 Subject: [erlang-bugs] gen_server error report issue Message-ID: <5711CEC1.60402@comarch.pl> Hello, I think I've found some problem in gen_server error report: when terminate callback throw errors then earlier errors (eg. from handle_call callback) is not reported. Please compile and run provided simple_server.erl module, that implement gen_server behaviour: (compilation12836@REDACTED)4> simple_server:start_link(false). {ok,<0.128.0>} (compilation12836@REDACTED)5> simple_server:perform(false). ok (compilation12836@REDACTED)6> simple_server:perform(true). ** exception exit: perform_error_in_handle_call *in function simple_server:handle_call/3 (loadController/src/simple_server.erl, line 89)* in call from gen_server:try_handle_call/4 (gen_server.erl, line 629) in call from gen_server:handle_msg/5 (gen_server.erl, line 661) in call from proc_lib:init_p_do_apply/3 (proc_lib.erl, line 240) (compilation12836@REDACTED)7> =ERROR REPORT==== 16-Mar-2016::15:36:35 === ** Generic server simple_server terminating ** Last message in was {perform,true} ** When Server state == {state,false} ** Reason for termination == ** {perform_error_in_handle_call, [{simple_server,handle_call,3, [{file,"loadController/src/simple_server.erl"},{line,89}]}, {gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,629}]}, {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,661}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]} In this case we can see that exception was thrown 'in function simple_server:handle_call/3 (loadController/src/simple_server.erl, line 89)' And now please start server in this way: (compilation12836@REDACTED)7> simple_server:start_link(true). {ok,<0.133.0>} (compilation12836@REDACTED)8> simple_server:perform(false). ok (compilation12836@REDACTED)9> simple_server:perform(true). =ERROR REPORT==== 16-Mar-2016::15:37:30 === ** Generic server simple_server terminating ** Last message in was {perform,true} ** When Server state == {state,true} ** Reason for termination == ** {throw_error_in_terminate_callback, [{simple_server,terminate,2, [{file,"loadController/src/simple_server.erl"},{line,141}]}, {gen_server,try_terminate,3,[{file,"gen_server.erl"},{line,643}]}, {gen_server,terminate,7,[{file,"gen_server.erl"},{line,809}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]} ** exception exit: throw_error_in_terminate_callback in function simple_server:terminate/2 (loadController/src/simple_server.erl, line 141) in call from gen_server:try_terminate/3 (gen_server.erl, line 643) in call from gen_server:terminate/7 (gen_server.erl, line 809) in call from proc_lib:init_p_do_apply/3 (proc_lib.erl, line 240) Now gen_server is also terminating, but we can only see exception from terminate callback. Exception that causes gen_server termination is not reported. I rather expect that both exceptions will be shown. Regards Aleksander Nycz -- Aleksander Nycz Chief Designer Telco_021 BSS R&D Comarch SA Phone: +48 17 785 5909 Mobile: +48 691 464 275 website:www.comarch.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %%%------------------------------------------------------------------- %%% @author ANycz %%% @copyright (C) 2016, %%% @doc %%% %%% @end %%% Created : 16. mar 2016 15:30 %%%------------------------------------------------------------------- -module(simple_server). -author("ANycz"). -behaviour(gen_server). %% API -export([start_link/1, perform/1]). %% gen_server callbacks -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -define(SERVER, ?MODULE). -record(state, {throw_error_in_terminate_callback :: boolean()}). %%%=================================================================== %%% API %%%=================================================================== perform(ThrowError) -> gen_server:call(?MODULE, {perform, ThrowError}) . %%-------------------------------------------------------------------- %% @doc %% Starts the server %% %% @end %%-------------------------------------------------------------------- -spec(start_link(ThrowError::boolean) -> {ok, Pid :: pid()} | ignore | {error, Reason :: term()}). start_link(ThrowError) -> gen_server:start_link({local, ?SERVER}, ?MODULE, ThrowError, []). %%%=================================================================== %%% gen_server callbacks %%%=================================================================== %%-------------------------------------------------------------------- %% @private %% @doc %% Initializes the server %% %% @spec init(Args) -> {ok, State} | %% {ok, State, Timeout} | %% ignore | %% {stop, Reason} %% @end %%-------------------------------------------------------------------- -spec(init(Args :: term()) -> {ok, State :: #state{}} | {ok, State :: #state{}, timeout() | hibernate} | {stop, Reason :: term()} | ignore). init(ThrowError) -> {ok, #state{throw_error_in_terminate_callback = ThrowError}}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling call messages %% %% @end %%-------------------------------------------------------------------- -spec(handle_call(Request :: term(), From :: {pid(), Tag :: term()}, State :: #state{}) -> {reply, Reply :: term(), NewState :: #state{}} | {reply, Reply :: term(), NewState :: #state{}, timeout() | hibernate} | {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), Reply :: term(), NewState :: #state{}} | {stop, Reason :: term(), NewState :: #state{}}). handle_call({perform, false}, _From, State) -> {reply, ok, State}; handle_call({perform, true}, _From, State) -> erlang:error(perform_error_in_handle_call), {reply, ok, State}; handle_call(_Request, _From, State) -> {reply, ok, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling cast messages %% %% @end %%-------------------------------------------------------------------- -spec(handle_cast(Request :: term(), State :: #state{}) -> {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), NewState :: #state{}}). handle_cast(_Request, State) -> {noreply, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% Handling all non call/cast messages %% %% @spec handle_info(Info, State) -> {noreply, State} | %% {noreply, State, Timeout} | %% {stop, Reason, State} %% @end %%-------------------------------------------------------------------- -spec(handle_info(Info :: timeout() | term(), State :: #state{}) -> {noreply, NewState :: #state{}} | {noreply, NewState :: #state{}, timeout() | hibernate} | {stop, Reason :: term(), NewState :: #state{}}). handle_info(_Info, State) -> {noreply, State}. %%-------------------------------------------------------------------- %% @private %% @doc %% This function is called by a gen_server when it is about to %% terminate. It should be the opposite of Module:init/1 and do any %% necessary cleaning up. When it returns, the gen_server terminates %% with Reason. The return value is ignored. %% %% @spec terminate(Reason, State) -> void() %% @end %%-------------------------------------------------------------------- -spec(terminate(Reason :: (normal | shutdown | {shutdown, term()} | term()), State :: #state{}) -> term()). terminate(_Reason, #state{throw_error_in_terminate_callback = false}) -> ok; terminate(_Reason, #state{throw_error_in_terminate_callback = true}) -> erlang:error(throw_error_in_terminate_callback), ok. %%-------------------------------------------------------------------- %% @private %% @doc %% Convert process state when code is changed %% %% @spec code_change(OldVsn, State, Extra) -> {ok, NewState} %% @end %%-------------------------------------------------------------------- -spec(code_change(OldVsn :: term() | {down, term()}, State :: #state{}, Extra :: term()) -> {ok, NewState :: #state{}} | {error, Reason :: term()}). code_change(_OldVsn, State, _Extra) -> {ok, State}. %%%=================================================================== %%% Internal functions %%%=================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From mikpelinux@REDACTED Sat Apr 16 21:12:08 2016 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 16 Apr 2016 21:12:08 +0200 Subject: [erlang-bugs] math:exp() erlang bug on SPARC In-Reply-To: <570E4DBF.8090102@oracle.com> References: <570E4DBF.8090102@oracle.com> Message-ID: <22290.36488.969395.622822@gargle.gargle.HOWL> Matt Keenan writes: > Hi, > > Just wanted to report a SPARC specific issue with Erlang. > > See discussions: > https://github.com/rabbitmq/rabbitmq-server/issues/132 > https://groups.google.com/forum/#!topic/rabbitmq-users/Gca8vW52gB8 > > Only happens on SPARC systems does not occur on X86 architecture. > e.g.: > > On s11u3 x86: > 1> math:exp(-1162.102134881488). > 0.0 > > On s11u3 SPARC: > 1> math:exp(-1162.102134881488). > ** exception error: an error occurred when evaluating an arithmetic > expression in function math:exp/1 called as math:exp(-1162.102134881488) > > Both systems are running 64-bit Erlang 17.5 in a 64-bit environment. > > Has an issue related to this been posted before ? After reproducing this on Solaris 10 / SPARC I recalled: http://erlang.org/pipermail/erlang-bugs/2014-December/004731.html First, this call to exp(-1162.1...) goes straight to libm's exp(), which detects an underflow and returns an error on both Solaris (SPARC) and Linux (x86_64, sparc64, ARMv7) [all glibc]. In this case, exp() returns 0, sets errno, and sets flag bits testable by fetestexcept(). On Solaris, libm also calls matherr() as per ancient SVID, and ERTS treats that as an implicit FP exception. After exp() returns, ERTS checks (1) if the return value is !isfinite() [but here it's a finite 0], or (2) if the thread's FP exception flag is set. On Solaris it's set due to the matherr() call, so the call is treated as an error. On Linux we see a finite return value, don't check the error indicators, and go on as if no error occurred. (That may be correct for underflow errors, I don't know.) The older email thread was about a similar issue with math:pow/2. Our treatment of matherr() is completely wrong. With FP exceptions disabled, we derive no information from matherr() calls, so all error checking is expressed in the code around those libm calls. For libm calls, checking for real FP exceptions is needed to reset parts of the FPU controls, but that isn't needed for the fake FP exceptions derived from matherr() calls. In short, I think matherr() should be a no-op regardless of NO_FPE_SIGNALS. The path below should fix your issue on Solaris. I'll issue a PR later. /Mikael diff --git a/erts/emulator/sys/ose/sys_float.c b/erts/emulator/sys/ose/sys_float.c index 5187579..764c35b 100644 --- a/erts/emulator/sys/ose/sys_float.c +++ b/erts/emulator/sys/ose/sys_float.c @@ -836,10 +836,5 @@ sys_chars_to_double(char* buf, double* fp) int matherr(struct exception *exc) { -#if !defined(NO_FPE_SIGNALS) - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); - if (fpexnp != NULL) - *fpexnp = (unsigned long)__builtin_return_address(0); -#endif return 1; } diff --git a/erts/emulator/sys/unix/sys_float.c b/erts/emulator/sys/unix/sys_float.c index 8fe7e59..beb5cb5 100644 --- a/erts/emulator/sys/unix/sys_float.c +++ b/erts/emulator/sys/unix/sys_float.c @@ -838,11 +838,6 @@ sys_chars_to_double(char* buf, double* fp) int matherr(struct exception *exc) { -#if !defined(NO_FPE_SIGNALS) - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); - if (fpexnp != NULL) - *fpexnp = (unsigned long)__builtin_return_address(0); -#endif return 1; } diff --git a/erts/emulator/sys/win32/sys_float.c b/erts/emulator/sys/win32/sys_float.c index 86e822d..14d4fa0 100644 --- a/erts/emulator/sys/win32/sys_float.c +++ b/erts/emulator/sys/win32/sys_float.c @@ -139,8 +139,7 @@ sys_double_to_chars_ext(double fp, char *buffer, size_t buffer_size, size_t deci int matherr(struct _exception *exc) { - erl_fp_exception = 1; - DEBUGF(("FP exception (matherr) (0x%x) (%d)\n", exc->type, erl_fp_exception)); + DEBUGF(("FP exception (matherr) (0x%x)\n", exc->type)); return 1; } From matt.keenan@REDACTED Mon Apr 18 18:04:41 2016 From: matt.keenan@REDACTED (Matt Keenan) Date: Mon, 18 Apr 2016 17:04:41 +0100 Subject: [erlang-bugs] math:exp() erlang bug on SPARC In-Reply-To: <22290.36488.969395.622822@gargle.gargle.HOWL> References: <570E4DBF.8090102@oracle.com> <22290.36488.969395.622822@gargle.gargle.HOWL> Message-ID: <57150599.4070906@oracle.com> Mikael, This is great, I'll attempt applying your code changes below on a local Solaris build of Erlang and verify if it fixes the issue for me. thanks Matt On 16/04/2016 20:12, Mikael Pettersson wrote: > Matt Keenan writes: > > Hi, > > > > Just wanted to report a SPARC specific issue with Erlang. > > > > See discussions: > > https://github.com/rabbitmq/rabbitmq-server/issues/132 > > https://groups.google.com/forum/#!topic/rabbitmq-users/Gca8vW52gB8 > > > > Only happens on SPARC systems does not occur on X86 architecture. > > e.g.: > > > > On s11u3 x86: > > 1> math:exp(-1162.102134881488). > > 0.0 > > > > On s11u3 SPARC: > > 1> math:exp(-1162.102134881488). > > ** exception error: an error occurred when evaluating an arithmetic > > expression in function math:exp/1 called as math:exp(-1162.102134881488) > > > > Both systems are running 64-bit Erlang 17.5 in a 64-bit environment. > > > > Has an issue related to this been posted before ? > > After reproducing this on Solaris 10 / SPARC I recalled: > http://erlang.org/pipermail/erlang-bugs/2014-December/004731.html > > First, this call to exp(-1162.1...) goes straight to libm's exp(), which > detects an underflow and returns an error on both Solaris (SPARC) and Linux > (x86_64, sparc64, ARMv7) [all glibc]. In this case, exp() returns 0, > sets errno, and sets flag bits testable by fetestexcept(). > > On Solaris, libm also calls matherr() as per ancient SVID, and ERTS treats > that as an implicit FP exception. > > After exp() returns, ERTS checks (1) if the return value is !isfinite() > [but here it's a finite 0], or (2) if the thread's FP exception flag is set. > On Solaris it's set due to the matherr() call, so the call is treated as > an error. On Linux we see a finite return value, don't check the error > indicators, and go on as if no error occurred. (That may be correct for > underflow errors, I don't know.) > > The older email thread was about a similar issue with math:pow/2. > > Our treatment of matherr() is completely wrong. With FP exceptions disabled, > we derive no information from matherr() calls, so all error checking is > expressed in the code around those libm calls. For libm calls, checking for > real FP exceptions is needed to reset parts of the FPU controls, but that > isn't needed for the fake FP exceptions derived from matherr() calls. > > In short, I think matherr() should be a no-op regardless of NO_FPE_SIGNALS. > > The path below should fix your issue on Solaris. I'll issue a PR later. > > /Mikael > > diff --git a/erts/emulator/sys/ose/sys_float.c b/erts/emulator/sys/ose/sys_float.c > index 5187579..764c35b 100644 > --- a/erts/emulator/sys/ose/sys_float.c > +++ b/erts/emulator/sys/ose/sys_float.c > @@ -836,10 +836,5 @@ sys_chars_to_double(char* buf, double* fp) > int > matherr(struct exception *exc) > { > -#if !defined(NO_FPE_SIGNALS) > - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > - if (fpexnp != NULL) > - *fpexnp = (unsigned long)__builtin_return_address(0); > -#endif > return 1; > } > diff --git a/erts/emulator/sys/unix/sys_float.c b/erts/emulator/sys/unix/sys_float.c > index 8fe7e59..beb5cb5 100644 > --- a/erts/emulator/sys/unix/sys_float.c > +++ b/erts/emulator/sys/unix/sys_float.c > @@ -838,11 +838,6 @@ sys_chars_to_double(char* buf, double* fp) > int > matherr(struct exception *exc) > { > -#if !defined(NO_FPE_SIGNALS) > - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > - if (fpexnp != NULL) > - *fpexnp = (unsigned long)__builtin_return_address(0); > -#endif > return 1; > } > > diff --git a/erts/emulator/sys/win32/sys_float.c b/erts/emulator/sys/win32/sys_float.c > index 86e822d..14d4fa0 100644 > --- a/erts/emulator/sys/win32/sys_float.c > +++ b/erts/emulator/sys/win32/sys_float.c > @@ -139,8 +139,7 @@ sys_double_to_chars_ext(double fp, char *buffer, size_t buffer_size, size_t deci > int > matherr(struct _exception *exc) > { > - erl_fp_exception = 1; > - DEBUGF(("FP exception (matherr) (0x%x) (%d)\n", exc->type, erl_fp_exception)); > + DEBUGF(("FP exception (matherr) (0x%x)\n", exc->type)); > return 1; > } > > From matt.keenan@REDACTED Tue Apr 19 16:35:28 2016 From: matt.keenan@REDACTED (Matt Keenan) Date: Tue, 19 Apr 2016 15:35:28 +0100 Subject: [erlang-bugs] math:exp() erlang bug on SPARC In-Reply-To: <22290.36488.969395.622822@gargle.gargle.HOWL> References: <570E4DBF.8090102@oracle.com> <22290.36488.969395.622822@gargle.gargle.HOWL> Message-ID: <57164230.4090102@oracle.com> Hi Mikael, Just wanted to confirm that your recommended patch below works on my Local SPARC box. thanks Matt On 04/16/16 20:12, Mikael Pettersson wrote: > Matt Keenan writes: > > Hi, > > > > Just wanted to report a SPARC specific issue with Erlang. > > > > See discussions: > > https://github.com/rabbitmq/rabbitmq-server/issues/132 > > https://groups.google.com/forum/#!topic/rabbitmq-users/Gca8vW52gB8 > > > > Only happens on SPARC systems does not occur on X86 architecture. > > e.g.: > > > > On s11u3 x86: > > 1> math:exp(-1162.102134881488). > > 0.0 > > > > On s11u3 SPARC: > > 1> math:exp(-1162.102134881488). > > ** exception error: an error occurred when evaluating an arithmetic > > expression in function math:exp/1 called as math:exp(-1162.102134881488) > > > > Both systems are running 64-bit Erlang 17.5 in a 64-bit environment. > > > > Has an issue related to this been posted before ? > > After reproducing this on Solaris 10 / SPARC I recalled: > http://erlang.org/pipermail/erlang-bugs/2014-December/004731.html > > First, this call to exp(-1162.1...) goes straight to libm's exp(), which > detects an underflow and returns an error on both Solaris (SPARC) and Linux > (x86_64, sparc64, ARMv7) [all glibc]. In this case, exp() returns 0, > sets errno, and sets flag bits testable by fetestexcept(). > > On Solaris, libm also calls matherr() as per ancient SVID, and ERTS treats > that as an implicit FP exception. > > After exp() returns, ERTS checks (1) if the return value is !isfinite() > [but here it's a finite 0], or (2) if the thread's FP exception flag is set. > On Solaris it's set due to the matherr() call, so the call is treated as > an error. On Linux we see a finite return value, don't check the error > indicators, and go on as if no error occurred. (That may be correct for > underflow errors, I don't know.) > > The older email thread was about a similar issue with math:pow/2. > > Our treatment of matherr() is completely wrong. With FP exceptions disabled, > we derive no information from matherr() calls, so all error checking is > expressed in the code around those libm calls. For libm calls, checking for > real FP exceptions is needed to reset parts of the FPU controls, but that > isn't needed for the fake FP exceptions derived from matherr() calls. > > In short, I think matherr() should be a no-op regardless of NO_FPE_SIGNALS. > > The path below should fix your issue on Solaris. I'll issue a PR later. > > /Mikael > > diff --git a/erts/emulator/sys/ose/sys_float.c b/erts/emulator/sys/ose/sys_float.c > index 5187579..764c35b 100644 > --- a/erts/emulator/sys/ose/sys_float.c > +++ b/erts/emulator/sys/ose/sys_float.c > @@ -836,10 +836,5 @@ sys_chars_to_double(char* buf, double* fp) > int > matherr(struct exception *exc) > { > -#if !defined(NO_FPE_SIGNALS) > - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > - if (fpexnp != NULL) > - *fpexnp = (unsigned long)__builtin_return_address(0); > -#endif > return 1; > } > diff --git a/erts/emulator/sys/unix/sys_float.c b/erts/emulator/sys/unix/sys_float.c > index 8fe7e59..beb5cb5 100644 > --- a/erts/emulator/sys/unix/sys_float.c > +++ b/erts/emulator/sys/unix/sys_float.c > @@ -838,11 +838,6 @@ sys_chars_to_double(char* buf, double* fp) > int > matherr(struct exception *exc) > { > -#if !defined(NO_FPE_SIGNALS) > - volatile unsigned long *fpexnp = erts_get_current_fp_exception(); > - if (fpexnp != NULL) > - *fpexnp = (unsigned long)__builtin_return_address(0); > -#endif > return 1; > } > > diff --git a/erts/emulator/sys/win32/sys_float.c b/erts/emulator/sys/win32/sys_float.c > index 86e822d..14d4fa0 100644 > --- a/erts/emulator/sys/win32/sys_float.c > +++ b/erts/emulator/sys/win32/sys_float.c > @@ -139,8 +139,7 @@ sys_double_to_chars_ext(double fp, char *buffer, size_t buffer_size, size_t deci > int > matherr(struct _exception *exc) > { > - erl_fp_exception = 1; > - DEBUGF(("FP exception (matherr) (0x%x) (%d)\n", exc->type, erl_fp_exception)); > + DEBUGF(("FP exception (matherr) (0x%x)\n", exc->type)); > return 1; > } > > From rob@REDACTED Thu Apr 21 12:45:55 2016 From: rob@REDACTED (Rob A'Court) Date: Thu, 21 Apr 2016 10:45:55 +0000 Subject: [erlang-bugs] Issue using variable length fields with Erlang ODBC In-Reply-To: References: Message-ID: When querying variable length fields using ODBC in Erlang, the response returned seems to be gibberish. I've posted this on the questions board and it has been suggested that this is a real bug. We can query tables in a MS SQL Server database but if the table contains a VarCharMax or NVarCharMax field (both variable length) then the result returned is not what we expect. For NVarCharMax a binary is returned which has part of the original query and other seemingly random data as if it's the wrong area of memory. For VarCharMax an empty list is always returned. In our particular scenario we are trying to get a ShowPlanXML from MS SQL Server which comes back as a NVarCharMax and there is no way of converting it to a fixed length field type to work around the issue. The issue does not seem to be with the ODBC driver as trying the same thing in python works fine. Here is what we are trying to do in Elixir: :odbc.start {:ok, connection} = :odbc.connect('Driver={ODBC Driver 11 for SQL Server}; Server=TheServer;Uid=sa;Pwd=password;Database=TheDatabase',[]) IO.inspect :odbc.sql_query(connection, 'set showplan_xml on') IO.inspect :odbc.sql_query(connection, 'Select * from customers'), limit: 9000 Here is the equivalent in python that works fine: #!/usr/bin/env python import pyodbc conn = pyodbc.connect('Driver={ODBC Driver 11 for SQL Server}; Server=TheServer;Uid=sa;Pwd=password;Database=TheDatabase') cur = conn.cursor() cur.execute('set showplan_xml on') cur.execute('Select * from customers') for row in cur : print row Many thanks! Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: