[Bug gdb/17253] New: missing TRY_CATCH in handle_vfork_child_exec_or_exit ?

[Bug gdb/17253] New: missing TRY_CATCH in handle_vfork_child_exec_or_exit ?

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17253

            Bug ID: 17253
           Summary: missing TRY_CATCH in handle_vfork_child_exec_or_exit ?
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com

[ran across this while looking into something else,
filing so it's not forgotten]

Is there a missing TRY_CATCH here (or appropriate cleanup) ?
What if something throws before inf->pspace/aspace is restored?

          /* We're about to detach from the parent, which implicitly            
             removes breakpoints from its address space.  There's a             
             catch here: we want to reuse the spaces for the child,             
             but, parent/child are still sharing the pspace at this             
             point, although the exec in reality makes the kernel give          
             the child a fresh set of new pages.  The problem here is           
             that the breakpoints module being unaware of this, would           
             likely chose the child process to write to the parent              
             address space.  Swapping the child temporarily away from           
             the spaces has the desired effect.  Yes, this is "sort             
             of" a hack.  */

          pspace = inf->pspace;
          aspace = inf->aspace;
          inf->aspace = NULL;
          inf->pspace = NULL;

          if (debug_infrun || info_verbose)
            {
              target_terminal_ours ();

              if (exec)
                fprintf_filtered (gdb_stdlog,
                                  "Detaching vfork parent process "
                                  "%d after child exec.\n",
                                  inf->vfork_parent->pid);
              else
                fprintf_filtered (gdb_stdlog,
                                  "Detaching vfork parent process "
                                  "%d after child exit.\n",
                                  inf->vfork_parent->pid);
            }

          target_detach (NULL, 0);

          /* Put it back.  */
          inf->pspace = pspace;
          inf->aspace = aspace;

-- 
You are receiving this mail because:
You are on the CC list for the bug.