On 01/31/2015 01:58 PM, Jakub Jermar wrote:
> On 01/29/2015 11:13 PM, Michal Koutný wrote:
>> iii) Last one is the most insidious. In my version of init I ran into
>> a page fault error raised inside VFS related libc code (below
>> uspace/lib/c/generic/vfs/vfs.c:175). Somehow all but one ('fqsn')
>> arguments of the function 'mount' are zeroed after return from
>> 'loc_service_get_id' (line 167). This fault is not present when I
>> increase time between devman start and considered 'mount' call
>> (uspace/app/einit/init.c:213). I think that call to
>> 'loc_service_get_id' blocks in the former case and does not in the
>> latter. Is there something I should know about fibrils that could
>> cause such a behavior? I've put relevant branch to Launchpad [1], I
>> tried it on IA32 build with standard 'ew.py' start script.
<snip>
> It rather looks like something bad is happening with the stack.
So the problem appears to be in your version of srv_startl():
task_wait_t wait;
int rc = task_spawn(&id, &wait, path, cnt, ap);
Unlike in mainline, you do not call task_wait(), so you basically use a
variable located on the stack (wait) for receiving an asynchronous IPC
answer.
In your scenario, the stack used by srv_startl() and wait.result is
later reused for the copies of your fqsn and opts arguments to mount().
mount() gets blocked and in the meantime the process started by
srv_startl (fat, IIRC) answers to what used to be the wait structure and
corrupts arguments to mount().
Jakub
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
