[arch-general] GDB does not work, sometimes

[Rodrigo Rivas]

On Sun, Nov 24, 2013 at 1:03 AM, Timothée Ravier <siosm99 at gmail.com> wrote:

> On 23/11/2013 13:14, Rodrigo Rivas wrote:
> > So it looks like some kind of permission issues. Maybe something related
> to
> > the recent SELinux changes?
>
> Nothing related to SELinux support has been merged in official Arch
> packages for now (as far as I know). And even if it had been, SELinux
> would certainly not be enabled by default without a big news. You can
> cross this one off.
>
> Tim
>

Oh! I have read something about that, but did not check the details...

Anyway, I like mysteries, so I kept on trying to find out the reason for
this... and I think that I found something, after the one of the hardest
debugging sessions I can remember.

The problem is in the "signal mask". It looks like some process masks the
signals in the early boot, and then the signal mask is inherited by all the
process in my session. And, as it seems, `gdb` needs a lot of signals to
work properly, but it assumes that they are not masked at the beginning. I
don't know if this should be considered a gdb bug or not, but the real
problem is elsewhere.

And that also explains why from a VT (or a SSH session, BTW) there is no
problem: there, the shell is not part of the graphic session, and so the
signal mask is correct (and actually the `yuma/ptrace_scope` made no
difference at all).

For example, running:

$ grep SigBlk /proc/$$/status
SigBlk: 00007ffe597b0408

The funny thing is that this number looks nothing like a signal mask, and
everything like a memory address:

$ ldd /usr/bin/true
/linux-vdso.so.1 (0x00007fffc03ac000)
/libc.so.6 => /usr/lib/libc.so.6 (0x00007f7942fea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7943395000)

So I am now pretty sure that some process in the session is corrupting the
signal mask. The only thing left is to know which one...

-- 
Rodrigo