On Sun, Nov 18, 2012 at 3:35 AM, Norman Feske <norman.feske@...1...> wrote:

Hello Jaeyong,

your observations are actually plausible. Let me shed some light on both
of them.

> I'm trying to understand how env() and env()->parent() work from the source
> code.
> First, I find the body of env function located at:
> genode/base/src/base/env/env.cc
>
> and looks like this:
> namespace Genode {

> Env *env()

> {
> static Genode::Platform_env _env;
> return &_env;
> }
> }
>
> env() function looks like, at namespace Genode, it returns the pointer of
> singleton object _env (static Genode::Platform_env _env).
> But, when I call env() at different places, it returns different addresses.
>
> For instance,
> - at genode/base/src/core/main.cc
> - at dde_linux/src/drivers/usb/nic/nic.cc,
> env() function returns different addresses like the following
> - at genode/base/src/core/main.cc, it returns 801f01a0
> - at dde_linux/src/drivers/usb/nic/nic.cc, it returns 10b716c.

The 'env()' function is part of the env library, which is linked to each
Genode program. For each executable, the linker decides where in the
virtual address space of the program the symbols of the library go. In
your case, you are looking at two different programs (core and usb_drv).
The address space layout of both programs is different. That includes
the layout of the respective BSS segments. For this reason, each program
returns a different address. When calling 'env()' from different
portions of the same program, the returned addresses will be the same.

> And, one more thing: I was trying to print some debug message at Env *env()
> function like the following.
>
> Env *env()
> {

> static Genode::Platform_env _env;
> PDBG("Genode::env() function called"); // my debug message
>
> return &_env;
> }
>
> And, when I run the genode, it always halt at core and child init is not
> running.
> Do you have any clues?

The system does actually not halt at core but right at the start of the
init process. By inserting the 'PDBG' statement, you just created a
cyclic dependency within init. The 'PDBG' function uses the core's LOG
service to print the message. Hence, init needs to create a LOG session,
which is done by calling 'Genode::env()->parent()->session(...)'. Hence,
when 'env()' is called the first time (apparently when init tries to
obtain its config), the function tries to indirectly call 'env()'. To
illustrate the situation, the backtrace of init looks as follows:

main init/main.cc:135
Genode::config os/config.h:90
Genode::Config::Config os/config.h:46
Rom_connection rom_session/connection.h:55
_create_session rom_session/connection.h:36
Genode::Connection::session base/connection.h:93
Genode::env env.cc:31
Genode::printf log_console.cc:141
Genode::vprintf log_console.cc:149
stdout_log_console log_console.cc:115
Log_console log_console.cc:68
Log_connection log_session/connection.h:27
Genode::Connection::session base/connection.h:93
Genode::env env.cc:31
Genode::printf log_console.cc:141
Genode::vprintf log_console.cc:149
stdout_log_console log_console.cc:115

At the second recursion level, the static constructor of 'Platform_env'
is already in locked state ('__cxa_guard_acquire' was called at the
first call of 'env()'). Hence, the programs tries to obtain the same
lock twice and deadlocks.

Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Genode-main mailing list
Genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main