On Sun, Nov 24, 2013 at 1:03 AM, Timothée Ravier <siosm99@xxxxxxxxx> 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
