M28 and seccomp sandbox issues, pages fail to load

[Paweł Hajdan, Jr.]

Chris, Julien, and other people reading this:

I'd need some help with debugging https://bugs.gentoo.org/show_bug.cgi?id=471198 - if you know what are the right questions to ask to get more info about the reported bug, feel free to ask directly on the bug or I can just forward them.

Paweł

[Paweł Hajdan, Jr.]

ping - there was an explicit PSA about sandbox problems, and here we have one. :)

Please do take a look and let me know how to further debug it.

Paweł

[Julien Tinnes]

It's the new clone restrictions:

Can you give use the clone flags from "sysdeps/unix/sysv/linux/x86_64/clone.S" ?

RestrictCloneToThreadsAndEPERMFork() needs to be fixed in
sandbox_seccomp_bpf_linux.cc

Chrome should have the very same issue than Chromium in that instance.
If someone can run Chrome, send a crash report and create a bug,
things will be easier!

Julien

On Wed, Jun 12, 2013 at 8:36 PM, Paweł Hajdan, Jr.

[Julien Tinnes]

I had read that thread too fast. We don't know anything from the stack
trace, it's just the watchdog terminating the GPU process. There is
nothing telling us what's happening.

zmo: any advice to get a stack trace from the process that actually did hung ?

[Antoine Labour]

On Wed, Jun 19, 2013 at 2:49 PM, Julien Tinnes <j...@chromium.org> wrote:

I had read that thread too fast. We don't know anything from the stack
trace, it's just the watchdog terminating the GPU process. There is
nothing telling us what's happening.

zmo: any advice to get a stack trace from the process that actually did hung ?

It would be the same process, just looking at the main thread rather than the watchdog thread.

Using chrome and giving us a crash report would give more data.

Antoine

 

On Wed, Jun 19, 2013 at 12:07 PM, Julien Tinnes <j...@chromium.org> wrote:
> It's the new clone restrictions:
>
> Can you give use the clone flags from "sysdeps/unix/sysv/linux/x86_64/clone.S" ?
>
> RestrictCloneToThreadsAndEPERMFork() needs to be fixed in
> sandbox_seccomp_bpf_linux.cc
>
> Chrome should have the very same issue than Chromium in that instance.
> If someone can run Chrome, send a crash report and create a bug,
> things will be easier!
>
> Julien
>
> On Wed, Jun 12, 2013 at 8:36 PM, Paweł Hajdan, Jr.
> <phajd...@chromium.org> wrote:
>> ping - there was an explicit PSA about sandbox problems, and here we have
>> one. :)
>>
>> Please do take a look and let me know how to further debug it.
>>
>> Paweł
>>
>>
>> On Thu, May 30, 2013 at 3:23 PM, Paweł Hajdan, Jr. <phajd...@chromium.org>
>> wrote:
>>>
>>> Chris, Julien, and other people reading this:
>>>
>>> I'd need some help with debugging
>>> https://bugs.gentoo.org/show_bug.cgi?id=471198 - if you know what are the
>>> right questions to ask to get more info about the reported bug, feel free to
>>> ask directly on the bug or I can just forward them.
>>>
>>> Paweł
>>
>>

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Paweł Hajdan, Jr.]

Please see https://bugs.gentoo.org/show_bug.cgi?id=471198#c23 for Timo Breitner's excellent analysis.

Here is simplified stack trace (full one attached to the bug report). Note that this is with glibc malloc (not tcmalloc because that one leads to problems with nvidia drivers). See how a call to free triggers open() of a file in /proc, that later somehow leads to calls to malloc in chromium code which then deadlocks:

#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95

#1  0x00007f857f76c9ac in _L_lock_10139 () at malloc.c:5104

#2  0x00007f857f76a1c5 in __GI___libc_malloc (bytes=55) at malloc.c:2856

#3  0x00007f858773093d in base::malloc (size=55) at base/process_util_linux.cc:810

#4  0x00007f857fb110dd in operator new(unsigned long) ()

#5  0x00007f857fb6e629 in std::string::_Rep::_S_create

#6  0x00007f857fb70015 in char* std::string::_S_construct<char const*>

#7  0x00007f857fb700f3 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string

#8  0x00007f858977b46c in sandbox::BrokerProcess::GetFileNameIfAllowedToOpen (

    this=this@entry=0x7f858bb6ce20, 

    requested_filename=requested_filename@entry=0x7f857f85ae50 "/proc/sys/vm/overcommit_memory", 

    requested_flags=requested_flags@entry=524288, file_to_open=file_to_open@entry=0x0)

    at sandbox/linux/services/broker_process.cc:500

#9  0x00007f858977c328 in sandbox::BrokerProcess::PathAndFlagsSyscall (

    this=this@entry=0x7f858bb6ce20, 

    syscall_type=syscall_type@entry=sandbox::BrokerProcess::kCommandOpen, 

    pathname=0x7f857f85ae50 "/proc/sys/vm/overcommit_memory", flags=524288)

    at sandbox/linux/services/broker_process.cc:223

#10 0x00007f858977c4df in sandbox::BrokerProcess::Open

#11 0x00007f8587ad72e0 in (anonymous namespace)::GpuSIGSYS_Handler

#12 0x00007f858977f555 in playground2::Trap::SigSys

#13 <signal handler called>

#14 0x00007f857f7c8220 in __open_nocancel () at ../sysdeps/unix/syscall-template.S:81

#15 0x00007f857f767a90 in check_may_shrink_heap ()

#16 shrink_heap (diff=139264, h=0x7f856c000000) at arena.c:629

#17 heap_trim (pad=131072, heap=0x7f856c000000) at arena.c:699

#18 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3987

#19 0x00007f85847e64a0 in _XFreeReplyData (dpy=dpy@entry=0x7f858b979610, force=force@entry=0)

#20 0x00007f85847e7934 in _XRead (dpy=0x7f858b979610, data=<optimized out>, size=270408)