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

[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@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
>>>
>>>
>>>     
> 
> 
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>