headers
William King | 2 Dec 2010 06:01
Picon

Located a segfault in erlang:port_control

While testing the erlang bindings for OpenCL I ran into the segfault. I 
decided to follow this trail rather than changing anything.

Any ideas?

I've tried:
ERL_CRASH_DUMP=crash.dump erl

But that does not result in a crash dump.

Here is the line of code that I've tracked it to:
call(Code, Args) ->
     io:format("Still alive2.5 Port: ~p Code: ~p Args ~p  \n", 
[?CL_PORT, Code, Args]),
     Reply = erlang:port_control(?CL_PORT, Code, Args),
     io:format("Still alive3 \n"),
     case decode(Reply) of
         {event,Ref} ->
             wait_reply(Ref);
         Result ->
             Result
     end.

Here is the output before the segfault:

quentusrex <at> quentusrex-desktop:~/git/quentustech/erlang/cl/examples$ 
ERL_CRASH_DUMP=dump.dump erl
Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:6:6] [rq:6] 
[async-threads:0] [hipe] [kernel-poll:false]
(Continue reading)

Permalink | Reply | 0 comments |
headers
anthony.shipman | 3 Dec 2010 03:45

Re: fix of hipe crashes in gc

I see that the following bug fix is in R14B. I need to stay with a R12B 
system. Would it be OK to apply the same patch to a R12B system (ie copy the 
change as in R14B)?

Are there any related bug fixes for running native code? I have already seen

>fix native code crash when calling unloaded module with on_l
>Posted: Wed Jun 30, 2010 12:32 pm

--------------------------------------------

Posted: Sat Jul 17, 2010 1:08 pm 	
Hello,

I have been experiencing crashes in the garbage collector when running erlang 
with natively compiled modules, and especially with OTP configured 
with --enable-native-libs.

This has been discussed before, including by others:
http://www.erlang.org/cgi-bin/ezmlm-cgi/4/50033
http://www.erlang.org/cgi-bin/ezmlm-cgi/4/39462
http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1583

I finally got a reproduceable case and nailed the bug down. The bug was 
introduced in R12B-0, when the function erts_gc_after_bif_call was updated to 
take 4 parameters but the assembly glue code was not updated to pass proper 
values for the third and fourth parameters.

A fix is available here:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kostis Sagonas | 3 Dec 2010 08:20
Picon

Re: Re: fix of hipe crashes in gc

anthony.shipman <at> symstream.com wrote:
> I see that the following bug fix is in R14B. I need to stay with a R12B 
> system. Would it be OK to apply the same patch to a R12B system (ie copy the 
> change as in R14B)?

Most probably yes.

> Are there any related bug fixes for running native code? I have already seen
> 
>> fix native code crash when calling unloaded module with on_l
>> Posted: Wed Jun 30, 2010 12:32 pm

I am pretty sure you do not need the above fix as "on_load" was 
introduced after R12B.  But you may want to also apply the fix at:

https://github.com/pguyot/otp/commit/e56566abf406cc21a70bc3064408166974c48636

Kostis

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe <at> erlang.org
Permalink | Reply | 2 comments |
headers
Ulf Norell | 6 Dec 2010 09:54

Negative indices in array:to_orddict/1

I was playing around with some simple QuickCheck properties for the array
library when I ran into the following weird behaviour:

1> A = array:set(10, b, array:relax(array:resize(0, array:set(10, a,
array:new())))).
...
2> io:format("~w~n", [array:to_orddict(A)]).
[{-90,undefined},{-89,undefined},{-88,undefined},{-87,undefined},{-86,undefined},{-85,undefined},{-84,undefined},{-83,undefined},{-82,undefined},{-81,undefined},{-80,a},{-79,undefined},{-78,undefined},{-77,undefined},{-76,undefined},{-75,undefined},{-74,undefined},{-73,undefined},{-72,undefined},{-71,undefined},{-70,undefined},{-69,undefined},{-68,undefined},{-67,undefined},{-66,undefined},{-65,undefined},{-64,undefined},{-63,undefined},{-62,undefined},{-61,undefined},{-60,undefined},{-59,undefined},{-58,undefined},{-57,undefined},{-56,undefined},{-55,undefined},{-54,undefined},{-53,undefined},{-52,undefined},{-51,undefined},{-50,undefined},{-49,undefined},{-48,undefined},{-47,undefined},{-46,undefined},{-45,undefined},{-44,undefined},{-43,undefined},{-42,undefined},{-41,undefined},{-40,undefined},{-39,undefined},{-38,undefined},{-37,undefined},{-36,undefined},{-35,undefined},{-34,undefined},{-33,undefined},{-32,undefined},{-31,undefined},{-30,undefined},{-29,undefined},{-28,undefined},{-27,undefined},{-26,undefined},{-25,undefined},{-24,undefined},{-23,undefined},{-22,undefined},{-21,undefined},{-20,undefined},{-19,undefined},{-18,undefined},{-17,undefined},{-16,undefined},{-15,undefined},{-14,undefined},{-13,undefined},{-12,undefined},{-11,undefined},{-10,undefined},{-9,undefined},{-8,undefined},{-7,undefined},{-6,undefined},{-5,undefined},{-4,undefined},{-3,undefined},{-2,undefined},{-1,undefined},{0,undefined},{1,undefined},{2,undefined},{3,undefined},{4,undefined},{5,undefined},{6,undefined},{7,undefined},{8,undefined},{9,undefined},{10,b}]

Using a number smaller than 10 gives the expected result (indices 0 to N).
Numbers bigger than 10 results in the same weird behaviour as 10.

/ Ulf
Permalink | Reply | 0 comments |
headers
Erik Søe Sørensen | 7 Dec 2010 01:34
Picon

Erlang segfaults in erts_remove_monitor

Hi there -
while working on the distribution subsystem of Erjang, I ran into this: 
beam core dumping, reproducibly.

Setup:
(1) An Erjang node[1] is started as j <at> mcilroy; an Erlang node (R14B) is 
started as c <at> mcilroy.
(2) (c <at> mcilroy)1> net_adm:ping(j <at> mcilroy).
(3) (j <at> mcilroy)1> global:register_name(foo, self()), throw(x).

Result:

Output from  c <at>  :

    Segmentation fault

Output from j <at>  (mostly distribution-related debugging messages):

    sending msg {global_name_server,c <at> mcilroy} !
    {'$gen_call',{<1.0.52>,{#Ref<j <at> mcilroy.1.0.0.49>,c <at> mcilroy}},{set_lock,{global,<1.0.52>}}}
    sending msg {global_name_server,c <at> mcilroy} !
    {'$gen_call',{<1.0.52>,{#Ref<j <at> mcilroy.1.0.0.53>,c <at> mcilroy}},{register,foo,<1.0.518>,#Fun<global.0.16294063>}}
    sending msg {global_name_server,c <at> mcilroy} !
    {'$gen_call',{<1.0.52>,{#Ref<j <at> mcilroy.1.0.0.57>,c <at> mcilroy}},{del_lock,{global,<1.0.52>}}}
    ** exception throw: x
          in function  apply/3
    [snip stack trace]

Reproducing the problem with GDB attached reveals this:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tuncer Ayaz | 8 Dec 2010 22:57
Picon

filename.erl native compile hang

When building a --enable-native-libs configured otp.git dev tree it
takes an indefinite amount of time to compile filename.erl natively.
Without --enable-native-libs it works.

A quick bisect revealed:
4cf08709189ea8b7e2ae20f85c390abd04ae48ae is the first bad commit
commit 4cf08709189ea8b7e2ae20f85c390abd04ae48ae
Author: Patrik Nyblom <pan <at> erlang.org>
Date:   Wed Oct 13 17:08:32 2010 +0200

    Teach filename to accept raw data and add filename enc option to emu

:040000 040000 d28390c9db2b82038400e18214cb662adcba9e73
    f0e669ceebd50ec1c93747b5ef088f9624ae8e5f M      erts
:040000 040000 049cf26200961246118308baa458aff5336d914b
    b5dfd3c945c33ee820013759cf1c36f2dfaa9243 M      lib

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe <at> erlang.org
Permalink | Reply | 4 comments |
headers
Ahmed Omar | 10 Dec 2010 14:00
Picon
Gravatar

race condition in the concurrency profiler (percept)?

In percept_db, the function start/1 if it find an instance running , it will
send a message to stop the running db and spawn a process to start a new
one, which leads to a race condition.

It can be reproduced with enough stress testing. But one way to easily
reproduce it, you can call percept:analyze/2 two subsequent times.

63> percept:analyze("test.dat").
Parsing: "test.dat"

=ERROR REPORT==== 10-Dec-2010::13:52:46 ===
Error in process <0.252.0> with exit value:
{badarg,[{ets,new,[pdb_info,[named_table,private,{keypos,2},set]]},{percept_db,init_percept_db,0}]}

=ERROR REPORT==== 10-Dec-2010::13:52:46 ===
Error in process <0.253.0> with exit value:
{badarg,[{percept_db,insert,1},{percept,trace_parser,2},{dbg,tc_loop,3}]}

{error,{badarg,[{percept_db,insert,1},
                {percept,trace_parser,2},
                {dbg,tc_loop,3}]}}

--

-- 
Best Regards,
- Ahmed Omar
http://nl.linkedin.com/in/adiaa
Follow me on twitter
 <at> spawn_think <http://twitter.com/#!/spawn_think>
Permalink | Reply | 2 comments |
headers
Ahmed Omar | 10 Dec 2010 14:27
Picon
Gravatar

Re: race condition in the concurrency profiler (percept)?

if you confirm it's a bug i can submit a patch supported with a test case

On Fri, Dec 10, 2010 at 2:00 PM, Ahmed Omar <spawn.think <at> gmail.com> wrote:

> In percept_db, the function start/1 if it find an instance running , it
> will send a message to stop the running db and spawn a process to start a
> new one, which leads to a race condition.
>
> It can be reproduced with enough stress testing. But one way to easily
> reproduce it, you can call percept:analyze/2 two subsequent times.
>
> 63> percept:analyze("test.dat").
> Parsing: "test.dat"
>
> =ERROR REPORT==== 10-Dec-2010::13:52:46 ===
> Error in process <0.252.0> with exit value:
> {badarg,[{ets,new,[pdb_info,[named_table,private,{keypos,2},set]]},{percept_db,init_percept_db,0}]}
>
>
> =ERROR REPORT==== 10-Dec-2010::13:52:46 ===
> Error in process <0.253.0> with exit value:
> {badarg,[{percept_db,insert,1},{percept,trace_parser,2},{dbg,tc_loop,3}]}
>
> {error,{badarg,[{percept_db,insert,1},
>                 {percept,trace_parser,2},
>                 {dbg,tc_loop,3}]}}
>
>
> --
> Best Regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ulf Wiger | 11 Dec 2010 12:46
Gravatar

mnesia dumps core when merging schema mods


- start mnesia on N1 with a disk schema
- create a table, t, with {disc_copies, [N1]}
- start N2 with {extra_db_nodes,[N1]}
- run mnesia:change_table_copy_type(schema,N2,disc_copies)
- on N2, mnesia:add_table_copy(t, N2, disc_copies)
- start N3 the same way
- kill N1
- change N3's schema to disc_copies
- on N3, mnesia:add_table_copy(t, N3, ram_copies).
- restart N1, start mnesia on N1  (it now knows of N3's ram_copy of t)
- kill N1 again
- on N3, mnesia:change_table_copy_type(t, N3, disc_copies).
- restart N1

Mnesia now dumps core on N1, since it finds both a ram_copy and 
a disc_copy entry of table t for N3.

This was from the start a completely made up example, so I don't know
of any crisis involving any live system due to this. Still, mnesia should 
handle the situation better.

BR,
Ulf 

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulf Wiger | 13 Dec 2010 07:29
Gravatar

mnesia:lock(Item, sticky_write) bad return value


Eshell V5.8.1  (abort with ^G)
1> mnesia:create_schema([node()]).
ok
2> mnesia:start().
ok
3> mnesia:create_table(t,[{ram_copies,[node()]}]).
{atomic,ok}
4> mnesia:transaction(fun() -> mnesia:lock({table,t},sticky_write) end).
{atomic,[nonode <at> nohost]}
5> mnesia:transaction(fun() -> mnesia:lock({table,t},sticky_write) end).
{atomic,granted}

According to the manual, mnesia:lock/2 returns Nodes | ok | transaction abort

When using the lock type sticky_write, you get the correct return value
the first time, but not for subsequent calls.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe <at> erlang.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane