[Bug uprobes/9826] gdb/uprobes deathmatch goes to OT

["srikar at linux dot vnet dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-02-09 10:58 -------
Update from Jim Keniston:
-------------------------

For the purposes of fixing this particular bug, I think it's sufficient 
to modify the code that calls uprobe_delay_signal() to refuse to delay the 
signal if it's a SIGSEGV -- something like this:  

        if (signal_action == UTRACE_SIGNAL_DELIVER && utask->active_probe && 
                                        info->si_signo != SSTEP_SIGNAL) { 
                if (info->si_signo == SIGSEGV) {
                        /*
                         * Give up and let the SIGSEGV be delivered.
                         * uprobe_report_exit() will unlock the semaphores, etc.
                         */
                        return UTRACE_SIGNAL_DELIVER | UTRACE_RESUME;
                } else {                      
                        uprobe_delay_signal(utask, info);
                        uprobe_decref_process(uproc);
                        return UTRACE_SIGNAL_IGN | UTRACE_SINGLESTEP;
                }
        }
                                                                               
                                                         
A more robust solution might enforce a limit on the number of times 
uprobe_report_signal() can be called -- for a particular task, while
attempting a particular single-step operation -- before you give up 
and abort the single-step.  But again, be more tolerant of signals like 
SIGPROF and SIGALRM.
                                                                               
                                                         
BTW, in this particular case, another indication that things are fubar 
is that regs->ip no longer points to the right SSOL slot.  (gdb has 
decremented regs->ip, thinking that it's backing up to the beginning 
of the probed instruction.)  But that indication doesn't work on 
architectures where the breakpoint instruction doesn't advance the IP.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |srikar at linux dot vnet dot
                   |redhat dot com              |ibm dot com
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=9826

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.