[erlang-patches] wxe_server bug? (and patch)

[Mazen Harake]

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@REDACTED> 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@REDACTED)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
>>
>>
>>