[Bug breakpoints/11415] New: Fix problem of hitting watchpoint of one thread while doing eval function on another

[Bug breakpoints/11415] New: Fix problem of hitting watchpoint of one thread while doing eval function on another

[danny dot geist at gmail dot com]

If gdb receives an event on one thread while doing an eval of
a function on another then an error occurs as follows:
"
The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function 
(XXX) will be abandoned.\n\
When the function is done executing, GDB will silently stop.
"

I hacked this a bit seems like a very small 4 line addition in the resume
function in file infrun.c fixes the problem. heres a diff of the fix from
version 7.0

1284,1287d1283
<       else if(inferior_thread ()->in_infcall)
<         {
< 	  resume_ptid = inferior_ptid;
< 	}

I dont know what the impact other than it does seem to work and does not look
like it breaks anything. I would like to get this fixed and am willing to do it
if I get guidance as to how to test it and maybe on aspects I dont understand. I
tried to do it very locally but maybe it requires more effort.
Thanks,
Danny

-- 
           Summary: Fix problem of hitting watchpoint of one thread while
                    doing eval function on another
           Product: gdb
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: danny dot geist at gmail dot com
                CC: gdb-prs at sourceware dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug breakpoints/11415] Fix problem of hitting watchpoint of one thread while doing eval function on another

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-03-25 18:46 -------
Subject: Re:  New: Fix problem of hitting watchpoint of one thread while doing eval function on another

On Monday 22 March 2010 14:36:02, danny dot geist at gmail dot com wrote:
> If gdb receives an event on one thread while doing an eval of
> a function on another then an error occurs as follows:
> "
> The program received a signal in another thread while
> making a function call from GDB.
> Evaluation of the expression containing the function 
> (XXX) will be abandoned.\n\
> When the function is done executing, GDB will silently stop.
> "

Yeah, this is actually intended behavior.

> 
> I hacked this a bit seems like a very small 4 line addition in the resume
> function in file infrun.c fixes the problem. heres a diff of the fix from
> version 7.0
> 
> 1284,1287d1283
> <       else if(inferior_thread ()->in_infcall)
> <         {
> <         resume_ptid = inferior_ptid;
> <       }

It seems this would do the same as
setting "scheduler-locking on" before doing the function call.
Did you try that?

(btw, the default diff format is mostly unreadable;
`(cvs) diff -up', or `(cvs) diff -p' is much better)

> I dont know what the impact other than it does seem to work and does not look
> like it breaks anything. I would like to get this fixed and am willing to do it
> if I get guidance as to how to test it and maybe on aspects I dont understand. I
> tried to do it very locally but maybe it requires more effort.

What this breaks is calling a function that ends up waiting
on a lock.  In that case, since all other threads are held
frozen, the function call never finishes.

This is an area that perhaps could be controlled with
a different setting, or explicit switch to eval
commands.  I haven't thought which is the best way
to handle it.  One other option is to leave the events
in other threads pending until the function call finishes,
but that is still prone to the deadlock issue, so probably
would need a knob as well.  So, several ways to address
this, including doing nothing and having the users control
this with the scheduler-locking setting.


------- Additional Comments From pedro at codesourcery dot com  2010-08-14 03:05 -------
Closing, as this works as intended/documented.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.