[erlang-questions] Common Test and base applications

Fred Hebert <>
Mon Feb 13 13:34:05 CET 2012


I tried it with R14B04 also, and it still doesn't work for me. I'll try a
few more things to try and discover what it might be. I'm a bit surprised
this can even happen in the first place, though.

On Mon, Feb 13, 2012 at 5:44 AM, Ahmed Omar <> wrote:

> I tried to reproduce it using same steps, but i get this when i use
> ct:pal("~p",[application:which_applications()])
> i get
>
> *** User  2012-02-13 11:39:24.901 ***
> [{crypto,"CRYPTO version 2","2.0.4"},
>   {stdlib,"ERTS  CXC 138 10","1.17.5"},
>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>
> maybe i'm doing something different..
>
> i'm using Erlang R14B04 (erts-5.8.5)
>
> On Sun, Feb 12, 2012 at 4:59 PM, Fred Hebert <> wrote:
>
>> I start them with distributed test specifications:
>>
>> {node, master, ''}.
>> {node, a, ''}.
>> {node, b, ''}.
>>
>> {init, a, [{node_start, [{monitor_master, true},
>>                          {boot_timeout, 10},
>>                          {startup_functions,
>> [{application,start,[crypto]},
>>
>> {application,start,[m8ball]}]},
>>                          {erl_flags, "-pa
>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/"
>>                                      "-config
>> dist_m8ball_SUITE_data/main.config"}]}]}.
>> {init, b, [{node_start, [{monitor_master, true},
>>                          {boot_timeout, 10},
>>                          {startup_functions,
>> [{application,start,[crypto]},
>>
>> {application,start,[m8ball]}]},
>>                          {erl_flags, "-pa
>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ "
>>                                      "-config
>> dist_m8ball_SUITE_data/backup.config"}]}]}.
>>
>> And I start it with:
>>
>> $ erl -name ct -pa ../ebin/
>> Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0]
>> [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G)
>>
>> ()1> ct_master:run("m8ball_dist.spec").
>>
>> And whenever I use ct:pal("~p",[application:which_applications()]) in
>> the suite, I get [] as a result. Further inspection shows that the
>> distributed applications I have are read by the controllers, but stdlib and
>> kernel are not started.
>>
>>
>> On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar <>wrote:
>>
>>> Hi Fred,
>>> 1- How do you start the ct_slave nodes?
>>> ()1> ct_slave:start(omarmb, testnode,[]).
>>> {}
>>> ()2> rpc:call('', application,
>>> which_applications,[]).
>>> [{stdlib,"ERTS  CXC 138 10","1.17.5"},
>>>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>>>
>>> 2- You can use erl_flags to specify more options to your slave node,
>>> e.g:
>>> ()3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s
>>> mnesia"}]).
>>> {}
>>> ()4> rpc:call('', application,
>>> which_applications,[]).
>>> [{mnesia,"MNESIA  CXC 138 12","4.5"},
>>>  {stdlib,"ERTS  CXC 138 10","1.17.5"},
>>>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>>>
>>>  On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert <>wrote:
>>>
>>>>  I should specify this problem is something I noticed when using
>>>> distributed tests based on ct_slave; I would suspect that local tests being
>>>> run from a shell started manually do not suffer from this.
>>>>
>>>>
>>>> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert <>wrote:
>>>>
>>>>> I've recently discovered that Common Test appears to not be starting
>>>>> basic applications such as kernel and stdlib, but it still starts things
>>>>> like application controllers and whatnot.
>>>>>
>>>>> This gives me a few problems because it breaks a few behaviours such
>>>>> as application:which_applications(), being able to start a few applications
>>>>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually
>>>>> starting kernel fails because  a bunch of processes already have that
>>>>> name).
>>>>>
>>>>> It will also play negatively with things like manually calling
>>>>> application:set_env/3 before starting an application to configure it (after
>>>>> loading it) as just starting it will overwrite all values, etc.
>>>>>
>>>>> This causes me a few problems because it forces me to test everything
>>>>> below the application level, and I can't automate testing of things like
>>>>> distributed applications and their failover/takeover mechanisms.
>>>>>
>>>>> Is there any workaround for these problems?
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120213/d691a79b/attachment.html>


More information about the erlang-questions mailing list