headers
Nicolas Charpentier | 1 Apr 2011 08:35

ETS ordered_set not ordered with OTP R14-B02 64 bits

Hi,

Testing our application with R14-B02, we noticed some strange behaviour with the timers. 
Sometimes, timer:send_interval/3 wasn't sending the message to the process.

After some investigations, it seems that in some circumstances, on an ordered_set  ets:first/1 doesn't
give the lowest key. 

The minimal use case is isolated in the script bug.esh. 

The bug can be reproduce on:
- Ubuntu 64bits and Red-Hat 64 bits  (OTP compiled without any particular option )
- MacOS 64 BIts (64 bits compilation forced with ./configure --enable-darwin-64bit)

The bug can't be reproduce on:
- MacOs 32 bits
- Ubuntu 32 bits

Thanks to "git bisect" the bug seems to be introduced by the commit fff4ba0282e42e2942acebff9c10a274075c1c62

$ git start
$ git bisect good OTP_R14B01
$ git bisect bad OTP_R14B02
$ git bisect run <PATH_TO bisect_ets_bug.sh>

Regards,
Nicolas Charpentier
Attachment (bug.esh): application/octet-stream, 520 bytes
(Continue reading)

Permalink | Reply | 1 comment |
headers
pan | 1 Apr 2011 11:04
Favicon
Gravatar

Re: ETS ordered_set not ordered with OTP R14-B02 64 bits

Hi!

Thank you for the awesome error report!

The bug is confirmed (of course) and it looks like a truncated integer in 
the comparision. The attached patch should fix it.

Please verify the patch and I'll add it (together with your testcase) to 
dev.

Cheers,
/Patrik

On Fri, 1 Apr 2011, Nicolas Charpentier wrote:

> Hi,
>
> Testing our application with R14-B02, we noticed some strange behaviour with the timers.
> Sometimes, timer:send_interval/3 wasn't sending the message to the process.
>
> After some investigations, it seems that in some circumstances, on an ordered_set  ets:first/1 doesn't
give the lowest key.
>
> The minimal use case is isolated in the script bug.esh.
>
> The bug can be reproduce on:
> - Ubuntu 64bits and Red-Hat 64 bits  (OTP compiled without any particular option )
> - MacOS 64 BIts (64 bits compilation forced with ./configure --enable-darwin-64bit)
>
> The bug can't be reproduce on:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Bolinder | 4 Apr 2011 13:32
Picon
Favicon

Re: [erlang-bugs 3] Bug in -spec/ <at> doc ordering in new edoc

Hi,

[Andrew Thompson:]
> Hi, I just noticed an odd behaviour where the order in which a  <at> doc and
> a -spec appear affects whether the  <at> doc appears in the edoc output. If I
> put the -spec first, the only documentation for that function is the
> spec, if I put the  <at> doc first, they both show up.

This bug has been reported several times, and finally a fix has
been merged into 'dev' (R14B03 to be):

https://github.com/erlang/otp/commit/efd032654990280daee58463b3208ef843008a2a

Best regards,

Hans Bolinder, Erlang/OTP team, Ericsson
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Ingela Anderton Andin | 4 Apr 2011 14:30
Picon
Picon

Re: [erlang-bugs 8] Re: possible supervisor bug in r14b02

Hi!

We found that your patch was not complete and also a little buggy.
Normally we require a test case for patches, but as this was a
latent bug that was triggered by our latest change we
decided to write a test case our selfs.

We think the solution should look like follows and it
will be included in dev shortly.  (Diff is based on your patch)

index b511545..368dc2e 100644
 <at>  <at>  -344,8 +344,12  <at>  <at>  handle_call({delete_child, Name}, _From, State) ->
handle_call({terminate_child, Name}, _From, State) ->
     case get_child(Name, State) of
     {value, Child} ->
-        NChild = do_terminate(Child, State#state.name),
-        {reply, ok, replace_child(NChild, State)};
+        case do_terminate(Child, State#state.name) of
+        #child{restart_type = temporary} = NChild ->
+            {reply, ok, state_del_child(NChild, State)};
+        NChild ->
+            {reply, ok, replace_child(NChild, State)}
+        end;
     _ ->
         {reply, {error, not_found}, State}
     end;
 <at>  <at>  -818,11 +822,11  <at>  <at>  state_del_child(Child, State) ->
     State#state{children = NChildren}.

 del_child(Name, [Ch|Chs]) when Ch#child.name =:= Name,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Filipe David Manana | 4 Apr 2011 15:39
Picon
Favicon
Gravatar

Re: [erlang-bugs 8] Re: possible supervisor bug in r14b02

Oh, yes, I definitely made a mistake by putting the rest of the
children list inside another list. Copy-paste curse :)
Looks fine to me.

Thanks Ingela.

On Mon, Apr 4, 2011 at 1:30 PM, Ingela Anderton Andin
<ingela <at> erix.ericsson.se> wrote:
> Hi!
>
> We found that your patch was not complete and also a little buggy.
> Normally we require a test case for patches, but as this was a
> latent bug that was triggered by our latest change we
> decided to write a test case our selfs.
>
> We think the solution should look like follows and it
> will be included in dev shortly.  (Diff is based on your patch)
>
> index b511545..368dc2e 100644
>  <at>  <at>  -344,8 +344,12  <at>  <at>  handle_call({delete_child, Name}, _From, State) ->
> handle_call({terminate_child, Name}, _From, State) ->
>    case get_child(Name, State) of
>    {value, Child} ->
> -        NChild = do_terminate(Child, State#state.name),
> -        {reply, ok, replace_child(NChild, State)};
> +        case do_terminate(Child, State#state.name) of
> +        #child{restart_type = temporary} = NChild ->
> +            {reply, ok, state_del_child(NChild, State)};
> +        NChild ->
> +            {reply, ok, replace_child(NChild, State)}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Per Melin | 4 Apr 2011 20:35
Picon

Crash in VTS (Common Test)

=ERROR REPORT==== 4-Apr-2011::20:22:11 ===
Error in process <0.58.0> on node 'ct <at> fanboy' with exit value:
{badarg,[{erlang,integer_to_list,[unknown]},{vts,result_summary_body,1},{vts,result_summary_frame1,1},{vts,loop,1}]}

Minimal test case:

-module(vts_crash_SUITE).

-include_lib("common_test/include/ct.hrl").

-export([all/0, groups/0]).
-export([noop/1]).

all() ->
    [{group, main}].

groups() ->
    [{main, [{repeat, 2}], [noop]}].
    % {repeat, 1} does not crash

noop(_Config) ->
    ok.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 3 comments |
headers
Peter Andersson | 5 Apr 2011 09:20
Picon
Picon

Re: Crash in VTS (Common Test)


Hi Per,

How did you start your test (with which parameters)?

   /Peter

On Mon, 4 Apr 2011, Per Melin wrote:

> =ERROR REPORT==== 4-Apr-2011::20:22:11 ===
> Error in process <0.58.0> on node 'ct <at> fanboy' with exit value:
> {badarg,[{erlang,integer_to_list,[unknown]},{vts,result_summary_body,1},{vts,result_summary_frame1,1},{vts,loop,1}]}
>
>
> Minimal test case:
>
> -module(vts_crash_SUITE).
>
> -include_lib("common_test/include/ct.hrl").
>
> -export([all/0, groups/0]).
> -export([noop/1]).
>
> all() ->
>    [{group, main}].
>
> groups() ->
>    [{main, [{repeat, 2}], [noop]}].
>    % {repeat, 1} does not crash
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Per Melin | 5 Apr 2011 09:35
Picon

Re: Crash in VTS (Common Test)

On Tue, Apr 5, 2011 at 9:20 AM, Peter Andersson <peppe <at> erix.ericsson.se> wrote:
>
> Hi Per,
>
> How did you start your test (with which parameters)?

Put the test case in an otherwise empty directory.

ct_run -vts -suite $(pwd)/vts_crash_SUITE -browser open

Click Run.
Click Run Test.

(The "open" parameter for -browser will open the default browser on OS X.)
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 1 comment |
headers
Peter Andersson | 5 Apr 2011 10:06
Picon
Picon

Re: Crash in VTS (Common Test)


Thanks for reporting! I'll have a look at this and get back to you.

   /Peter

On Tue, 5 Apr 2011, Per Melin wrote:

> On Tue, Apr 5, 2011 at 9:20 AM, Peter Andersson <peppe <at> erix.ericsson.se> wrote:
>>
>> Hi Per,
>>
>> How did you start your test (with which parameters)?
>
> Put the test case in an otherwise empty directory.
>
> ct_run -vts -suite $(pwd)/vts_crash_SUITE -browser open
>
> Click Run.
> Click Run Test.
>
> (The "open" parameter for -browser will open the default browser on OS X.)
>
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Benjamin Winkler | 7 Apr 2011 09:53

erl_interface and threads

Hi!

We are using Erlang and specifically the erl_interface for C (Visual 
Studio C++ 2008, Windows 7) to connect to our Erlang servers. We have 
noticed weird errors when creating (and freeing) terms in different 
threads. It seems to me that the memory allocation module is not 
thread-aware.

I have managed to isolate the problem and written an exemplary program 
(see end of mail) where several threads create and free erlang terms 
(tuples "{hello,world}"). The terms are continously checked for 
correctness by assertions (assert(type != ERL_UNDEF)). Note, that the 
terms are local in regard to the thread.

When running a single thread, everything is just fine. No memory leaks, 
no exceptions, no assertions. However, when I use multiple threads 
something goes wrong (usually just several milliseconds after starting) 
and I get completely unpredictable results:
- sometimes an atom that I have just created in the preceding line is 
suddenly a tuple (assertion fails)
- sometimes a tuple references itself as a child, thus creating a 
recursion and a stack overflow when checking its children
- sometimes the type of a term becomes ERL_UNDEF
- etc.

I have tried this with the precompiled binaries for version R12B05 and 
with the most recent version R14B02. (In the latter case I had to link 
with "ei_md.lib" and "erl_interface_md.lib", since I don't have the 
corresponding VS2005-Debug-Runtime-DLLs)
(Continue reading)

Permalink | Reply | 3 comments |

Gmane