Dear Maintainer,

template questions :

   * What led up to the situation?

	Debuging a small quick program written in plain C (hello world level)

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

	GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jg/sketchbook/thermocouple/a.out...done.
(gdb) b main
Breakpoint 1 at 0x4006b5: file conv.c, line 18.
(gdb) r 123
Starting program: /home/jg/sketchbook/thermocouple/a.out 123
123 :
11011110000000000000000000000000 :
EEERCCCCCCCCCCCCERTTTTTTTTTTTTTT :
TTTTTTTTTTTTTTRECCCCCCCCCCCCREEE :

During startup program exited normally.

 -> program is completely simple (just some binary dump of entered int against a template to test a bitfield

   * What was the outcome of this action?

	none, the program ran normally instead of breaking

   * What outcome did you expect instead?

	breaking on a breakpoint
------------------------------
i went to the undernet debian channel,
this is reproducible and confirmed by another user :

23:30 < frikinz> Jegeva: I can confirm with kernel linux-image-3.12-rc7-686-pae, libc 2.17-93, gdb
                 7.6.1-1 and a void main{printf("hello");} with gcc -g
------------------------------

I also ran into this bug in GDB 7.6.1-1 on Debian Jessie AMD64. I
compiled upstream GDB 7.6.1 and confirmed that the bug is present
there as well. I then compiled the latest GDB from the master branch
of its Git repository, which unfortunately exhibits the same behavior.
Curiously, neither the latest upstream commit, upstream 7.6.1, or
7.6.1-1 exhibit the same when compiled for and run on Debian Wheezy.
Also, both upstream 7.4.1 and 7.4.1+dfsg-0.1 exhibit the buggy
behavior on Jessie but not on Wheezy. This leads me to believe that
the problem is not in GDB itself, but in another package it relies on.
Of course, my conjecture could be completely wrong. Unfortunately I'm
not sure how to proceed apart from contributing my findings to this
bug report, otherwise I would continue tracking this bug to its source.

I can confirm I do encountre the very same issue.
On Debian Jessie AMD64.

I used strace on the gdb. It looks like I found a problem:

5561
stat("/home/lumag/Projects/Gost/libksba/tests/.libs/lt-cert-basic",
{st_mode=S_IFREG|0755, st_size=60503, ...}) = 0
5561  write(1, "Starting program: /home/lumag/Pr"..., 104) = 104
5561  personality(0xffffffff /* PER_??? */) = 0
5561  personality(0x40000 /* PER_??? */) = 0
5561  personality(0xffffffff /* PER_??? */) = 262144
5561  vfork()                           = 5563
5563  getpid( <unfinished ...>
5561  rt_sigprocmask(SIG_BLOCK, [CHLD],  <unfinished ...>
5563  <... getpid resumed> )            = 5563
5561  <... rt_sigprocmask resumed> ~[HUP INT QUIT ILL ABRT FPE KILL SEGV
PIPE ALRM STKFLT CHLD STOP TSTP TTIN XCPU WINCH PWR RTMIN RT_1 RT_16
RT_17 RT_18 RT_19 RT_20 RT_21 RT_22 RT_23 RT_24
RT_25 RT_26 RT_27 RT_28 RT_29 RT_30 RT_31], 8) = 0
5563  getpid( <unfinished ...>
5561  wait4(-1,  <unfinished ...>
5563  <... getpid resumed> )            = 5563
5561  <... wait4 resumed> 0x7fffe0155544, WNOHANG|__WCLONE, NULL) = 0
5561  wait4(-1,  <unfinished ...>
5563  setpgid(5563, 5563 <unfinished ...>
5561  <... wait4 resumed> 0x7fffe0155544, WNOHANG, NULL) = 0
5563  <... setpgid resumed> )           = 0
5561  rt_sigsuspend(~[HUP INT QUIT ILL ABRT FPE KILL SEGV PIPE ALRM
STKFLT CHLD STOP TSTP TTIN XCPU WINCH PWR RTMIN RT_1 RT_16 RT_17 RT_18
RT_19 RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_29 RT_30
RT_31] <unfinished ...>
5563  ptrace(PTRACE_TRACEME, 0, 0, 0)   = -1 EPERM (Operation not
permitted)


See that ptrace(PTRACE_TRACEME) failing? It looks like that is a
problem.

Hello.
I also found this problem in gdb 7.6.2-1, but I found breakpoints working in gdb 7.4.1.

I heard that you can't use ptrace from a program that's being run
under strace, which may be the cause of the EPERM error.

Unfortunately, gdb doesn't log the fact that ptrace failed, nor what
errno was set to, so there's no way to get gdb to tell us if ptrace
is failing, and if so, what errno is.

I went to the source to add some perror calls, only to find that gdb
calls ptrace from about 50 million separate lines of code. Sometimes
it uses what appears to be an internal error-reporting routine, which
I suppose must be sending those errors to /dev/null, because I can't
see them.

An EPERM error could be caused by a new misguided kernel security feature
that basically disables ptrace completely to prevent both security breaches
and programming on Linux, other than with simple scripting languages.

With that in mind, I followed two separate suggestions, which are
the only ideas that Google was able to dredge up:

    - I used the "setcap" command with root privileges on GDB
      as follows:

         setcap cap_sys_ptrace=ep

    - I echoed a '0' into the file /proc/sys/kernel/yama

Upon using the first suggestion, I was able to stop at a
breakpoint in GDB under single-user mode (but I couldn't inspect
any variables), but the old behavior returned as soon as I
went to runlevel 2, even when running as root. I have yet to
return to single-user mode to see if the error has returned
there, too.

I am plumb out of ideas. I guess it's time to move on to Fedora Core or
something, cause I can't get any work done without GDB.