Cannot run MBox on Linux 3.16.3-1

[Sidnioulz]

Hi,

When running MBox with a GTK+ program (which used to work) and no specific arguments, I get:

    [steve@valencia ~]$ mbox epiphany

    ** (epiphany:5634): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

    Stop executing pid=5635: Should wait until other syscalls to be done
    Sandbox Root:
    > /tmp/sandbox-5630

But running basic commands like sh or ls works. Looking at the code, this is a rather broad condition and I couldn't figure out which system call is blocking. If I strace mbox, I get 30k of system calls to review so I gave up on that! I've been running gdb as well to break on has_any_entering_proc() but it seems very generic and I can't figure out what parameters should look like.

What should I look for to debug? What can cause such locks?

[tsgates]

Hi Steve Dodier-Lazaro,

Thank you for playing with mbox. The error comes from mprotect()
system call, which is conservative design decision to prevent TICTOU
problem: stop if there is any other system call running, before
enabling WRITE priv on some memory.

You can easily 1) relax the condition down or 2) wait and recheck.

Thanks,
Taesoo

On 10/27/14 at 03:27am, Steve Dodier-Lazaro wrote:

Hi,

When running MBox with a GTK+ program (which used to work) and no specific arguments, I get:

    [steve@valencia ~]$ mbox epiphany

    ** (epiphany:5634): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

    Stop executing pid=5635: Should wait until other syscalls to be done
    Sandbox Root:
    > /tmp/sandbox-5630

But running basic commands like sh or ls works. Looking at the code, this is a rather broad condition and I couldn't figure out which system call is blocking. If I strace mbox, I get 30k of system calls to review so I gave up on that! I've been tracing executions but has_any_entering_proc() seems very generic.

What should I look for to debug? What can cause such locks?

---

Reply to this email directly or view it on GitHub:
#28

[Sidnioulz]

Hi Taesoo,

Thanks for the comment. I'll look at relaxing the race condition checks and see if it works for me.

I'm still curious, do you know what kind of calls could cause the race condition check to permanently deadlock? It's quite likely to be some low-level GLib initialisation since only GTK+ apps seem affected. If you're curious to find out and can give me instructions I can provide detailled logs.

(for the record, I need to run MBox in "production" environments, as I'll deploy it on random Linux users' machines for a usability study, so I need to ensure that it doesn't lock at all on recent Linuxes.)