Red Hat Bugzilla – Bug 660204
ptrace: watchpoint-zeroaddr: EINVAL on PTRACE_POKEUSER of DR7
Last modified: 2013-05-22 12:54:34 EDT
Description of problem:
When you set first DR7 and then DR0 - the setting of DR7 fails, because DR0 has still address 0 that time. The process is still stopped so there is no reason for a sanity check that time.
This is a regression.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
wget -O watchpoint-zeroaddr.c http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/watchpoint-zeroaddr.c?cvsroot=systemtap; gcc -o watchpoint-zeroaddr watchpoint-zeroaddr.c -Wall -g; ./watchpoint-zeroaddr; echo $?
(In reply to comment #0)
> When you set first DR7 and then DR0 - the setting of DR7 fails,
> because DR0 has still address 0 that time.
More precisely, it fails because ptrace_write_dr7() never tries
to allocate the perf_event connected to this bpnum, it blindly
calls ptrace_modify_breakpoint(bp => NULL) which obviously fails
And it is not trivial to change this, despite its name
ptrace_write_dr7() doesn't write dr7, we do not have debugreg7
any longer. We really need bp != NULL to store the necessary
Another problem is that this code has other bugs, and those
who wrote this code do not reply at all.
So. This is upstream problem. Unlike the previous regression
(watchpoints && fork), this one looks like a bug to me.
But. I do not know how long will it take to fix.
Just in case, to clarify once again... "zeroaddr" is fine.
The problem is, with the recent changes there is no "adrress"
at all before the tracer writes to u_debugreg. But if you
try to read u_debugreg, get_watchpoint() will happily return
Isn't this nice...
Did this ever get fixed?
(In reply to comment #2)
> Did this ever get fixed?
argh.... thanks for reminding. Should be fixed upstream iirc.
Damn. I'll _try_ to look further this week. I forgot the details,
but afaics we already fixed other (more serious) problems which
delayed this problem...
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
Is this still a problem with 3.9 based F19 kernels?
Yes; BTW the reproducer in Comment 0 is really simple to run.
(In reply to comment #7)
> Yes; BTW the reproducer in Comment 0 is really simple to run.
All I can say is: sorry for delay.
I constantly forgot about this problem. Fortunataly, it seems that
today the fix should be simple. Still it is complicated by the fact
that this code needs cleanups, in particular we should kill
ptrace_get_breakpoints() and ->ptrace_bp_refcnt, and this needs
I am working on the patches.
Cough. Jan, suddenly I started to doubt this should be fixed.
Lets discuss this upstream, you were cc'ed. I already sent the
preparation patches, the actual fix should be trivial.
But. Could you please tell me if gdb really wants this fix?
Recent GDB versions are fully compatible with recent Linux kernels, there was a special care about it:
Old GDBs were also compatible, although just accidentally:
/* Finally, actually pass the info to the inferior. */
i386_dr_low.set_addr (i, addr);
Unfortunately I really do not remember which specific use case had a problem with it. I was heavily patching this GDB code before so some Fedora/RHEL GDB could be dependent on it, or maybe just some my work-in-progress patches that time.
I do not see any Red Hat business reason for it. I still believe it is a needless ABI backward compatibility breakage but I do not mind if the kernel developers do not agree and WONTFIX it.
(In reply to comment #10)
> I still believe it is a
> needless ABI backward compatibility breakage
Yes, yes, I agree. But given that this was broken a long ago...
> but I do not mind if the kernel
> developers do not agree and WONTFIX it.
OK. Thanks Jan. Lets wait for other upstream comments, then
we will see.
(In reply to comment #11)
> Yes, yes, I agree. But given that this was broken a long ago...
The kernel ABI got broken ~3 years ago. Most of the "recent" users run Ubuntu 10.04 which I believe was still before the breakage. Other users run even more old GNU/Linux releases. The users still may not have noticed the change.
(In reply to comment #12)
> (In reply to comment #11)
> > Yes, yes, I agree. But given that this was broken a long ago...
> The kernel ABI got broken ~3 years ago. Most of the "recent" users run
> Ubuntu 10.04 which I believe was still before the breakage. Other users run
> even more old GNU/Linux releases. The users still may not have noticed the
The patches are already in -mm, and they were acked. Can we close
If the testcase really PASSes there then OK, CLOSED-UPSTREAM.
(In reply to Jan Kratochvil from comment #14)
> If the testcase really PASSes there then OK, CLOSED-UPSTREAM.
Yes, yes, I even wrote the new test-case (the old one passes too).