Bug reports for Erlang/OTP

Вадзім Зенька | 1 Aug 2011 11:53

binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly

WHAT:
binary pattern matching fails with 32-bit float, if decimal
representation of the number cannot be converted to binary exactly

EXAMPLE:
following code fails:

% "1.1" does not have exact binary representation
> case <<1.1:32/float>> of <<1.1:32/float>> -> ok end.
** exception error: no case clause matching <<63,140,204,205>>

> case <<63,140,204,205>> of <<1.1:32/float>> -> ok end.
** exception error: no case clause matching <<63,140,204,205>>

although

> case <<1.1:32/float>> of <<63,140,204,205>> -> ok end.
ok

% "1.5" has exact binary representation
> case <<1.5:32/float>> of <<1.5:32/float>> -> ok end.
ok

% 64-bit floats work well
> case <<1.1:64/float>> of <<1.1:64/float>> -> ok end.
ok

--
З павагай, Вадзім Зенька
v <at> vadzim.info

(Continue reading)

headers

Ulf Wiger | 1 Aug 2011 12:06

Re: binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly


Compiling to BEAM ASM illustrates why:

>> case <<1.1:32/float>> of <<1.1:32/float>> -> ok end.
> ** exception error: no case clause matching <<63,140,204,205>>

{function, f, 0, 2}.
  {label,1}.
    {func_info,{atom,bin_match},{atom,f},0}.
  {label,2}.
    {move,{literal,<<63,140,204,205>>},{x,0}}.
    {test,bs_start_match2,{f,3},1,[{x,0},0],{x,1}}.
    {test,bs_get_float2,
          {f,3},
          2,
          [{x,1},
           {integer,32},
           1,
           {field_flags,[{anno,[6,{file,"./bin_match.erl"}]},unsigned,big]}],
          {x,2}}.
    {test,is_eq_exact,{f,3},[{x,2},{float,1.1}]}.
    {test,bs_test_tail2,{f,3},[{x,1},0]}.
    {move,{atom,ok},{x,0}}.
    return.
  {label,3}.
    {case_end,{x,0}}.

The constructor pattern is evaluated at compile-time, so the binary appears in the ASM.
The match pattern uses the bit syntax operators to extract a float, and then checks the result (now using
native float representation) to the hard-coded float 1.1.

(Continue reading)

headers

Вадзім Зенька | 1 Aug 2011 12:09

binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly

Version: Erlang 5.8.4/OTP R14B03

Sorry.

--

-- 
З павагай, Вадзім Зенька
v <at> vadzim.info
vadzim <at> ethno.by
+375.29.407.27.17
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

headers

Lars Thorsen | 9 Aug 2011 15:03

Re: Bug when streaming input to xmerl_scan


Thanks Simon, your fix will be applied in R14B04.

Regards Lars
Erlang/OTP, Ericsson AB

On 07/27/2011 09:12 PM, Simon Cornish wrote:
> Consider the following trivial XML:
>
> <?xml version="1.0" ?>
> <item a="b">blah</item>
>
> If this is being fed to xmerl_scan:string via a continuation_fun and
> the current input runs out at the end of an attribute value (in this
> example, the 2nd " character on the item line) then it will crash.
> This is demonstrated in the small attached module.
> One possible fix that has been tested is also attached.
>
> Regards,
>   Simon
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs <at> erlang.org
> http://erlang.org/mailman/listinfo/erlang-bugs

_______________________________________________
erlang-bugs mailing list

(Continue reading)

headers

Anders.Ramsell | 12 Aug 2011 14:45

Re: filename:join breaks Windows UNC paths


> -----Original Message-----
> Sorry to resurrect an old post, but this just bit me and cost 
> me a day or
> two. Evgeny's patch works and applies to R14B01 and R14B03, 
> though the line
> numbers are now a bit off. I've edited the patch below. 
> 
> Not sure what the proper convention is, but I'd like to vote 
> for this being included in a future release if possible.
> The current assumption that all paths on win32 start with
> a drive letter is no longer valid, especially if
> extended-path name notation is being used 
> (\\?\very\long\path). This is an increasingly common need.

I'd like to add a vote for having this problem fixed since we 
have also been bit by this.

It also appears that some "pathfunctions" like file:get_cwd/0 
already support the "dubble-slash" syntax. The following shell
interaction shows the problem we've had:

1> {ok, Path} = file:get_cwd().
{ok, "//host/share"}
2> filename:join(Path, "file.txt").
"/host/share/file.txt"

Notice that the dubble-slash returned by file:get_cwd/0 gets lost
in the call to filename:join/2.

(Continue reading)

headers

Robert Newson | 12 Aug 2011 23:50

Repeatable output from crypto:rand_uniform with negative Low value

Hi,

I've noticed that repeated calls to crypto:rand_uniform return the
same values if Low is negative and High is (approximately) equal to
-Low, and the answer is also outside of the requested range.

e.g,;

7> crypto:rand_uniform(-10000,10000).
65536
8> crypto:rand_uniform(-10000,10000).
65536
9> crypto:rand_uniform(-10000,10000).
65536

This is with R14B03.

Regards,
B.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

headers

Dave Cottlehuber | 14 Aug 2011 05:02

Re: filename:join breaks Windows UNC paths

On 20 July 2011 05:27, wohali <joant <at> ieee.org> wrote:
> Sorry to resurrect an old post, but this just bit me and cost me a day or
> two. Evgeny's patch works and applies to R14B01 and R14B03, though the line
> numbers are now a bit off. I've edited the patch below.
>
> Not sure what the proper convention is, but I'd like to vote for this being
> included in a future release if possible. The current assumption that all
> paths on win32 start with a drive letter is no longer valid, especially if
> extended-path name notation is being used (\\?\very\long\path). This is an
> increasingly common need.
>
> ------------------- patch --------------------------------
> diff --git a/lib/stdlib/src/filename.erl b/lib/stdlib/src/filename.erl
> index 01c06e4..8da54ef 100644
> --- a/lib/stdlib/src/filename.erl
> +++ b/lib/stdlib/src/filename.erl
>  <at>  <at>  -426,6 +426,10  <at>  <at>  join(Name1, Name2) when is_atom(Name2) ->
>  %% It is the responsibility of the caller to ensure that RelativeName
>  %% is relative.
>
> +join1([$/, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest,
> RelativeName, [], win32)];
> +join1([$/, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest,
> RelativeName, [], win32)];
> +join1([$\\, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest,
> RelativeName, [], win32)];
> +join1([$\\, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest,
> RelativeName, [], win32)];
>  join1([UcLetter, $:|Rest], RelativeName, [], win32)
>  when is_integer(UcLetter), UcLetter >= $A, UcLetter =< $Z ->

(Continue reading)

headers

Filipe David Manana | 15 Aug 2011 00:18

SIGBUS on init:restart()

If I compile OTP R14B03 (also tried R14B01, and got same issue) for
64bits mode in Mac OS X Lion, when calling init:restart() in my
application I get a SIGBUS signal, which causes the VM to terminate
(it happens very often, but not always) with the error message "Bus
error: 10".

Here's some information from gdb which might be useful:

http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR

Ignoring the SIGBUS signal prevents the crash, but this is likely
masking some bug:

diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c
index bafbbb0..86c3f57 100644
--- a/erts/emulator/sys/unix/sys.c
+++ b/erts/emulator/sys/unix/sys.c
 <at>  <at>  -3031,6 +3031,9  <at>  <at>  erts_sys_main_thread(void)
        fd_set readfds;
        int res;

+    signal(SIGPIPE, SIG_IGN);
+    signal(SIGBUS, SIG_IGN);
+
        FD_ZERO(&readfds);
        FD_SET(erts_darwin_main_thread_pipe[0], &readfds);
        res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds,
NULL, NULL, NULL);

OTP was configured like this:

(Continue reading)

headers

Filipe David Manana | 15 Aug 2011 02:58

Re: SIGBUS on init:restart()

Found out the issue. It turned out to be a bad cast in linked in
driver from CouchDB:

diff --git a/src/couchdb/priv/icu_driver/couch_icu_driver.c
b/src/couchdb/priv/icu_driver/couch_icu_driver.c
index 9f20e99..edfd84a 100644
--- a/src/couchdb/priv/icu_driver/couch_icu_driver.c
+++ b/src/couchdb/priv/icu_driver/couch_icu_driver.c
 <at>  <at>  -45,7 +45,7  <at>  <at>  static void couch_drv_stop(ErlDrvData data)
     if (pData->collNoCase) {
         ucol_close(pData->collNoCase);
     }
-    driver_free((char*)pData);
+    driver_free((void*)pData);
 }

 static ErlDrvData couch_drv_start(ErlDrvPort port, char *buff)

On Sun, Aug 14, 2011 at 3:18 PM, Filipe David Manana
<fdmanana <at> apache.org> wrote:
> If I compile OTP R14B03 (also tried R14B01, and got same issue) for
> 64bits mode in Mac OS X Lion, when calling init:restart() in my
> application I get a SIGBUS signal, which causes the VM to terminate
> (it happens very often, but not always) with the error message "Bus
> error: 10".
>
> Here's some information from gdb which might be useful:
>
> http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR
>

(Continue reading)

headers

Patrick Baggett | 15 Aug 2011 03:45

Re: SIGBUS on init:restart()

A typecast? That shouldn't affect code generation like that. Are you sure you didn't just need to do a clean build or something?

On Sun, Aug 14, 2011 at 7:58 PM, Filipe David Manana <fdmanana <at> apache.org> wrote:

Found out the issue. It turned out to be a bad cast in linked in
driver from CouchDB:

diff --git a/src/couchdb/priv/icu_driver/couch_icu_driver.c
b/src/couchdb/priv/icu_driver/couch_icu_driver.c
index 9f20e99..edfd84a 100644
--- a/src/couchdb/priv/icu_driver/couch_icu_driver.c
+++ b/src/couchdb/priv/icu_driver/couch_icu_driver.c
<at> <at> -45,7 +45,7 <at> <at> static void couch_drv_stop(ErlDrvData data)
if (pData->collNoCase) {
ucol_close(pData->collNoCase);
}
- driver_free((char*)pData);
+ driver_free((void*)pData);
}

static ErlDrvData couch_drv_start(ErlDrvPort port, char *buff)

On Sun, Aug 14, 2011 at 3:18 PM, Filipe David Manana
<fdmanana <at> apache.org> wrote:
> If I compile OTP R14B03 (also tried R14B01, and got same issue) for
> 64bits mode in Mac OS X Lion, when calling init:restart() in my
> application I get a SIGBUS signal, which causes the VM to terminate
> (it happens very often, but not always) with the error message "Bus
> error: 10".
>
> Here's some information from gdb which might be useful:
>
> http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR
>
> Ignoring the SIGBUS signal prevents the crash, but this is likely
> masking some bug:
>
> diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c
> index bafbbb0..86c3f57 100644
> --- a/erts/emulator/sys/unix/sys.c
> +++ b/erts/emulator/sys/unix/sys.c
> <at> <at> -3031,6 +3031,9 <at> <at> erts_sys_main_thread(void)
> fd_set readfds;
> int res;
>
> + signal(SIGPIPE, SIG_IGN);
> + signal(SIGBUS, SIG_IGN);
> +
> FD_ZERO(&readfds);
> FD_SET(erts_darwin_main_thread_pipe[0], &readfds);
> res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds,
> NULL, NULL, NULL);
>
>
> OTP was configured like this:
>
> $ CFLAGS="-O0" ./configure --enable-darwin-64bit --prefix=/opt/r14b03
>
> Without the --enable-darwin-64bit option, the issue doesn't happen.
>
> Is this a known issue or can it be application-specific? How to debug
> it further?
>
> This issue doesn't seem to happen on Linux and Mac OS X snowleopard systems.
>
> thanks
>
>
> --
> Filipe David Manana,
> fdmanana <at> gmail.com, fdmanana <at> apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>

--
Filipe David Manana,
fdmanana <at> gmail.com, fdmanana <at> apache.org

"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

59	May 2013
47	April 2013
45	March 2013
84	February 2013
82	January 2013
41	December 2012
65	November 2012
74	October 2012
44	September 2012
55	August 2012
20	July 2012
43	June 2012
47	May 2012
41	April 2012
41	March 2012
36	February 2012
28	January 2012
34	December 2011
47	November 2011
43	October 2011
29	September 2011
24	August 2011
40	July 2011
58	June 2011
78	May 2011
67	April 2011
73	March 2011
23	February 2011
33	January 2011
38	December 2010
22	November 2010
43	October 2010
68	September 2010
54	August 2010
38	July 2010
54	June 2010
37	May 2010
18	April 2010
40	March 2010
28	February 2010
35	January 2010
46	December 2009
33	November 2009
37	October 2009
53	September 2009
48	August 2009
53	July 2009
79	June 2009
30	May 2009
35	April 2009
32	March 2009
31	February 2009
40	January 2009
35	December 2008
34	November 2008
53	October 2008
58	September 2008
66	August 2008
43	July 2008
43	June 2008
52	May 2008
58	April 2008
42	March 2008
33	February 2008
55	January 2008
61	December 2007
30	November 2007
31	October 2007
53	September 2007
16	August 2007
19	July 2007
19	June 2007
18	May 2007
21	April 2007
6	March 2007
25	February 2007
9	January 2007
23	December 2006
17	November 2006
15	October 2006
14	September 2006
12	August 2006
7	July 2006
11	June 2006
11	May 2006
5	April 2006
13	March 2006
9	January 2006
5	December 2005
10	November 2005
3	October 2005
4	September 2005
10	August 2005
3	July 2005
4	June 2005
4	May 2005
4	April 2005
13	March 2005
16	February 2005
8	January 2005
6	December 2004
4	November 2004
6	October 2004
17	September 2004
3	July 2004
2	April 2004
1	February 2004
4	December 2003
1	November 2003
3	October 2003
5	September 2003
1	August 2003
6	July 2003
1	June 2003
1	May 2003
1	April 2003

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31