wxe_server bug? (and patch)

[Mazen Harake-2]

Hi,

There is a situation in the wx library that causes the wxe_server to
crash when it receives a message with a pid which is considered by
distributed Erlang to come from another node when in fact it isn't. This
happens when net_kernel is started explicitly (I.e. Erlang going into
distribution mode) and an wx_object (which was created before net_kernel
was started) is destroyed.

Here is a simple example:
Create this module:
-module(test).
-compile(export_all).

start() ->
  wx:new(),
  wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).

close(_, _) ->
  wx_object:call(?MODULE, stop).
 
init(Wx) ->
  wx:set_env(Wx),
  Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
  wxFrame:show(Mf),
  wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
  {Mf, Mf}.
 
handle_call(stop, _From, Mf) ->
  wxFrame:destroy(Mf),
  {stop, normal, ok, Mf}.
 
terminate(normal, _) ->
  ok.

Then run this in the shell:
Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]

Eshell V5.7.1  (abort with ^G)
1> c(test).
{ok,test}
2> test:start().
{wx_ref,35,wxFrame,<0.42.0>}
3>

This should give you a small frame, don't close it yet,
Now do this:
3> net_kernel:start([bad,shortnames]).
{ok,<0.49.0>}
(bad@prestine)4>

Now close the frame and you should see:
=ERROR REPORT==== 14-Oct-2009::13:17:08 ===
** Generic server <0.39.0> terminating
** Last message in was {'_wxe_destroy_',<3.42.0>}
** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
                               
{1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
                               [<0.57.0>],
                               {1,{#Fun<test.close.2>,1,nil,nil}},
                               2}
** Reason for termination ==
** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
            {wxe_server,handle_info,2},
            {gen_server,handle_msg,5},
            {proc_lib,init_p_do_apply,3}]}


The pid which comes from the port is not recognized as a local pid and
thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
this a "feature" or a bug? I think this is a bug but I'm not sure what
is expected from the wx library point of view. IMHO it shouldn't crash
and just ignore it in this case because the wxe_server shouldn't be
allowed to crash.

Anyway I put in a patch as well just in case this is something that
should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.

Cheers,

/Mazen





--- wxe_server.original.erl 2009-09-24 11:00:48.000000000 +0200
+++ wxe_server.erl 2009-10-14 15:06:41.141000000 +0200
@@ -177,12 +177,11 @@
     {noreply, State}
     end;
 handle_info(Msg = {'_wxe_destroy_', Pid}, State) ->
-    case erlang:is_process_alive(Pid) of
- true ->
-    Pid ! Msg,
-    ok;
- false ->
-    ok
+    try
+      true = erlang:is_process_alive(Pid),
+      Pid ! Msg
+    catch
+      error:_ -> ok
     end,
     {noreply, State};
 handle_info(_Info, State) ->


________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

[Mazen Harake-2]

A quick note:
I just realized that this example doesn't work unless you have applied
my previous patch for wx_object.erl. Either apply that or change the
code to call the wx_object with the form (somehow) :)

/Mazen

Mazen Harake wrote:

> Hi,
>
> There is a situation in the wx library that causes the wxe_server to
> crash when it receives a message with a pid which is considered by
> distributed Erlang to come from another node when in fact it isn't.
> This happens when net_kernel is started explicitly (I.e. Erlang going
> into distribution mode) and an wx_object (which was created before
> net_kernel was started) is destroyed.
>
> Here is a simple example:
> Create this module:
> -module(test).
> -compile(export_all).
>
> start() ->
>  wx:new(),
>  wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>
> close(_, _) ->
>  wx_object:call(?MODULE, stop).
>
> init(Wx) ->
>  wx:set_env(Wx),
>  Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>  wxFrame:show(Mf),
>  wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>  {Mf, Mf}.
>
> handle_call(stop, _From, Mf) ->
>  wxFrame:destroy(Mf),
>  {stop, normal, ok, Mf}.
>
> terminate(normal, _) ->
>  ok.
>
> Then run this in the shell:
> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>
> Eshell V5.7.1  (abort with ^G)
> 1> c(test).
> {ok,test}
> 2> test:start().
> {wx_ref,35,wxFrame,<0.42.0>}
> 3>
>
> This should give you a small frame, don't close it yet,
> Now do this:
> 3> net_kernel:start([bad,shortnames]).
> {ok,<0.49.0>}
> (bad@prestine)4>
>
> Now close the frame and you should see:
> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
> ** Generic server <0.39.0> terminating
> ** Last message in was {'_wxe_destroy_',<3.42.0>}
> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>                              
> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>                               [<0.57.0>],
>                               {1,{#Fun<test.close.2>,1,nil,nil}},
>                               2}
> ** Reason for termination ==
> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>            {wxe_server,handle_info,2},
>            {gen_server,handle_msg,5},
>            {proc_lib,init_p_do_apply,3}]}
>
>
> The pid which comes from the port is not recognized as a local pid and
> thus erlang:is_process_alive/1 will exit with badarg. My question is:
> Is this a "feature" or a bug? I think this is a bug but I'm not sure
> what is expected from the wx library point of view. IMHO it shouldn't
> crash and just ignore it in this case because the wxe_server shouldn't
> be allowed to crash.
>
> Anyway I put in a patch as well just in case this is something that
> should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>
> Cheers,
>
> /Mazen
>
>
>
>
> ------------------------------------------------------------------------
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

[Dan Gudmundsson]

I'll fix the problem, in the right way(tm).

/Dan
PS: I just applied your wx_object patch but I allowed pids as well as
registered names and
added wx_object:cast/2.

On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
<mazen.harake@...> wrote:

> A quick note:
> I just realized that this example doesn't work unless you have applied my
> previous patch for wx_object.erl. Either apply that or change the code to
> call the wx_object with the form (somehow) :)
>
> /Mazen
>
> Mazen Harake wrote:
>>
>> Hi,
>>
>> There is a situation in the wx library that causes the wxe_server to crash
>> when it receives a message with a pid which is considered by distributed
>> Erlang to come from another node when in fact it isn't. This happens when
>> net_kernel is started explicitly (I.e. Erlang going into distribution mode)
>> and an wx_object (which was created before net_kernel was started) is
>> destroyed.
>>
>> Here is a simple example:
>> Create this module:
>> -module(test).
>> -compile(export_all).
>>
>> start() ->
>>  wx:new(),
>>  wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>
>> close(_, _) ->
>>  wx_object:call(?MODULE, stop).
>>
>> init(Wx) ->
>>  wx:set_env(Wx),
>>  Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>>  wxFrame:show(Mf),
>>  wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>>  {Mf, Mf}.
>>
>> handle_call(stop, _From, Mf) ->
>>  wxFrame:destroy(Mf),
>>  {stop, normal, ok, Mf}.
>>
>> terminate(normal, _) ->
>>  ok.
>>
>> Then run this in the shell:
>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>
>> Eshell V5.7.1  (abort with ^G)
>> 1> c(test).
>> {ok,test}
>> 2> test:start().
>> {wx_ref,35,wxFrame,<0.42.0>}
>> 3>
>>
>> This should give you a small frame, don't close it yet,
>> Now do this:
>> 3> net_kernel:start([bad,shortnames]).
>> {ok,<0.49.0>}
>> (bad@prestine)4>
>>
>> Now close the frame and you should see:
>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>> ** Generic server <0.39.0> terminating
>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>
>>  {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>>                              [<0.57.0>],
>>                              {1,{#Fun<test.close.2>,1,nil,nil}},
>>                              2}
>> ** Reason for termination ==
>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>>           {wxe_server,handle_info,2},
>>           {gen_server,handle_msg,5},
>>           {proc_lib,init_p_do_apply,3}]}
>>
>>
>> The pid which comes from the port is not recognized as a local pid and
>> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
>> this a "feature" or a bug? I think this is a bug but I'm not sure what is
>> expected from the wx library point of view. IMHO it shouldn't crash and just
>> ignore it in this case because the wxe_server shouldn't be allowed to crash.
>>
>> Anyway I put in a patch as well just in case this is something that should
>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>
>> Cheers,
>>
>> /Mazen
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ________________________________________________________________
>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>> erlang-patches (at) erlang.org
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

[Mazen Harake-2]

Yeah I can see how using pids are useful but the semantic difference is
that you can't really get the pid from somewhere unless you register it?
I mean the return value is a wxWindow() type. I dunno... just a thought :)

Waiting patiently to learn the right way ;)

/Mazen

Dan Gudmundsson wrote:

> I'll fix the problem, in the right way(tm).
>
> /Dan
> PS: I just applied your wx_object patch but I allowed pids as well as
> registered names and
> added wx_object:cast/2.
>
> On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
> <mazen.harake@...> wrote:
>  
>> A quick note:
>> I just realized that this example doesn't work unless you have applied my
>> previous patch for wx_object.erl. Either apply that or change the code to
>> call the wx_object with the form (somehow) :)
>>
>> /Mazen
>>
>> Mazen Harake wrote:
>>    
>>> Hi,
>>>
>>> There is a situation in the wx library that causes the wxe_server to crash
>>> when it receives a message with a pid which is considered by distributed
>>> Erlang to come from another node when in fact it isn't. This happens when
>>> net_kernel is started explicitly (I.e. Erlang going into distribution mode)
>>> and an wx_object (which was created before net_kernel was started) is
>>> destroyed.
>>>
>>> Here is a simple example:
>>> Create this module:
>>> -module(test).
>>> -compile(export_all).
>>>
>>> start() ->
>>>  wx:new(),
>>>  wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>>
>>> close(_, _) ->
>>>  wx_object:call(?MODULE, stop).
>>>
>>> init(Wx) ->
>>>  wx:set_env(Wx),
>>>  Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>>>  wxFrame:show(Mf),
>>>  wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>>>  {Mf, Mf}.
>>>
>>> handle_call(stop, _From, Mf) ->
>>>  wxFrame:destroy(Mf),
>>>  {stop, normal, ok, Mf}.
>>>
>>> terminate(normal, _) ->
>>>  ok.
>>>
>>> Then run this in the shell:
>>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>>
>>> Eshell V5.7.1  (abort with ^G)
>>> 1> c(test).
>>> {ok,test}
>>> 2> test:start().
>>> {wx_ref,35,wxFrame,<0.42.0>}
>>> 3>
>>>
>>> This should give you a small frame, don't close it yet,
>>> Now do this:
>>> 3> net_kernel:start([bad,shortnames]).
>>> {ok,<0.49.0>}
>>> (bad@prestine)4>
>>>
>>> Now close the frame and you should see:
>>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>>> ** Generic server <0.39.0> terminating
>>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>>
>>>  {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>>>                              [<0.57.0>],
>>>                              {1,{#Fun<test.close.2>,1,nil,nil}},
>>>                              2}
>>> ** Reason for termination ==
>>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>>>           {wxe_server,handle_info,2},
>>>           {gen_server,handle_msg,5},
>>>           {proc_lib,init_p_do_apply,3}]}
>>>
>>>
>>> The pid which comes from the port is not recognized as a local pid and
>>> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
>>> this a "feature" or a bug? I think this is a bug but I'm not sure what is
>>> expected from the wx library point of view. IMHO it shouldn't crash and just
>>> ignore it in this case because the wxe_server shouldn't be allowed to crash.
>>>
>>> Anyway I put in a patch as well just in case this is something that should
>>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>>
>>> Cheers,
>>>
>>> /Mazen
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ________________________________________________________________
>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>> erlang-patches (at) erlang.org
>>>      
>> ________________________________________________________________
>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>> erlang-patches (at) erlang.org
>>
>>
>>    

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

[Dan Gudmundsson]

Mazen Harake wrote:
> Yeah I can see how using pids are useful but the semantic difference is
> that you can't really get the pid from somewhere unless you register it?
> I mean the return value is a wxWindow() type. I dunno... just a thought :)

wx_object:get_pid(Ref).

>
> Waiting patiently to learn the right way ;)

The right way is to not use term_to_binary(self()) when registrering the process
with the driver, because that representation changes when the node becomes distributed.

I.e. more code and changes in the driver, but better, nicer and uses less memory,
that code wasn't the best I have written :-)

/Dan

>
> /Mazen
>
> Dan Gudmundsson wrote:
>> I'll fix the problem, in the right way(tm).
>>
>> /Dan
>> PS: I just applied your wx_object patch but I allowed pids as well as
>> registered names and
>> added wx_object:cast/2.
>>
>> On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
>> <mazen.harake@...> wrote:
>>  
>>> A quick note:
>>> I just realized that this example doesn't work unless you have
>>> applied my
>>> previous patch for wx_object.erl. Either apply that or change the
>>> code to
>>> call the wx_object with the form (somehow) :)
>>>
>>> /Mazen
>>>
>>> Mazen Harake wrote:
>>>    
>>>> Hi,
>>>>
>>>> There is a situation in the wx library that causes the wxe_server to
>>>> crash
>>>> when it receives a message with a pid which is considered by
>>>> distributed
>>>> Erlang to come from another node when in fact it isn't. This happens
>>>> when
>>>> net_kernel is started explicitly (I.e. Erlang going into
>>>> distribution mode)
>>>> and an wx_object (which was created before net_kernel was started) is
>>>> destroyed.
>>>>
>>>> Here is a simple example:
>>>> Create this module:
>>>> -module(test).
>>>> -compile(export_all).
>>>>
>>>> start() ->
>>>>  wx:new(),
>>>>  wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>>>
>>>> close(_, _) ->
>>>>  wx_object:call(?MODULE, stop).
>>>>
>>>> init(Wx) ->
>>>>  wx:set_env(Wx),
>>>>  Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>>>>  wxFrame:show(Mf),
>>>>  wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>>>>  {Mf, Mf}.
>>>>
>>>> handle_call(stop, _From, Mf) ->
>>>>  wxFrame:destroy(Mf),
>>>>  {stop, normal, ok, Mf}.
>>>>
>>>> terminate(normal, _) ->
>>>>  ok.
>>>>
>>>> Then run this in the shell:
>>>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>>>
>>>> Eshell V5.7.1  (abort with ^G)
>>>> 1> c(test).
>>>> {ok,test}
>>>> 2> test:start().
>>>> {wx_ref,35,wxFrame,<0.42.0>}
>>>> 3>
>>>>
>>>> This should give you a small frame, don't close it yet,
>>>> Now do this:
>>>> 3> net_kernel:start([bad,shortnames]).
>>>> {ok,<0.49.0>}
>>>> (bad@prestine)4>
>>>>
>>>> Now close the frame and you should see:
>>>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>>>> ** Generic server <0.39.0> terminating
>>>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>>>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>>>
>>>>  {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>>>>                              [<0.57.0>],
>>>>                              {1,{#Fun<test.close.2>,1,nil,nil}},
>>>>                              2}
>>>> ** Reason for termination ==
>>>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>>>>           {wxe_server,handle_info,2},
>>>>           {gen_server,handle_msg,5},
>>>>           {proc_lib,init_p_do_apply,3}]}
>>>>
>>>>
>>>> The pid which comes from the port is not recognized as a local pid and
>>>> thus erlang:is_process_alive/1 will exit with badarg. My question
>>>> is: Is
>>>> this a "feature" or a bug? I think this is a bug but I'm not sure
>>>> what is
>>>> expected from the wx library point of view. IMHO it shouldn't crash
>>>> and just
>>>> ignore it in this case because the wxe_server shouldn't be allowed
>>>> to crash.
>>>>
>>>> Anyway I put in a patch as well just in case this is something that
>>>> should
>>>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>>>
>>>> Cheers,
>>>>
>>>> /Mazen
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ________________________________________________________________
>>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>>> erlang-patches (at) erlang.org
>>>>      
>>> ________________________________________________________________
>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>> erlang-patches (at) erlang.org
>>>
>>>
>>>    
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org