Kernel Bug Tracker – Bug 6787
suspend to ram fails when process is being debugged
Last modified: 2006-09-08 04:39:05 UTC
Most recent kernel where this bug did not occur: not sure
Hardware Environment:Lenovo Thinkpad X60
When a process is being debugged (stopped in a breakpoint, for example), suspend
Steps to reproduce:
Start program under gdb. Set breakpoint. Run program until it hits breakpoint.
Attempt to suspend.
It would be nice to get email@example.com to Cc, but he apparently does not have
bugzilla account (or has it under different name?)
Okay, I can reproduce it on fairly recent 2.6.17-git.
I think the "freeze" signal is catched due to ptrace() before the process
has a chance to go to the refrigerator. Then the parent is supposed to do
something, but if it's already frozen, it can't.
If that's what really happens, the signal-handling code will need a fix.
Created attachment 8555 [details]
More precisely, if the ptraced task has already hit a breakpoint, it is in the
TASK_TRACED state and we can't deliver any signals directly to it until the
parent decides what to do with it. However, if the parent is frozen, it can't
do anything and the ptraced task becomes unfreezeable. Thus it seems we should
treat it as such in kernel/power/process.c#freezeable(). If that really is the
case, this patch should help, so please try it.
Created attachment 8561 [details]
This patch should fix the problem (works on my box).
I believe it won't break any other corner cases related to the tracing of
Created attachment 8625 [details]
This patch fixes the problem on my box.