Re: [Bug-gdb] GDB and X11 server grabs

2000-09-18 Thread Kevin Buettner

On Sep 18, 11:46am, Pierre Sarrazin wrote:

> Dixit Kevin Buettner  (2000-09-14 16:34):
> > Also, it's possible to run commands in the shell via the `shell'
> > command, so the original poster (Pierre) could put something like the
> > following in his .gdbinit file:
> > 
> > define hook-stop
> > shell clear_xgrab
> > end
> > 
> > Provided that a suitable external program called `clear_xgrab' was
> > created, this would do what the original posted wanted.
> 
> I wrote a program that calls XUngrabServer(), but it did not have
> any effect.  I added a call to XGrabServer() juste before, but still
> without effect.  Perhaps a server grab is specific to each X11 client.
> Ungrabbing from one X11 client would not affect grabs by other clients.

Perhaps you need to use XUngrabPointer() ?

> I wouldn't mind patching my own copy of GDB to experiment
> with XUngrabServer().  Could someone tell me what function
> of the GDB sources I should study to do this?  I would like
> to add some code where GDB writes its prompt.

Take a look at command_loop() in top.c.

However, if you can't get your clear_xgrab (or whatever you called it)
program to work, I don't think you'll have any more success via this
route.  Keep in mind that gdb is not part of the X11 client that
you're attempting to debug.  That being the case, it shouldn't matter
whether your ungrab code is in gdb or in a separate program.  (Either
it'll work in both places or fail in both places.)

Kevin
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb



Re: [Bug-gdb] GDB and X11 server grabs

2000-09-18 Thread Pierre Sarrazin

Dixit Kevin Buettner  (2000-09-14 16:34):
> Also, it's possible to run commands in the shell via the `shell'
> command, so the original poster (Pierre) could put something like the
> following in his .gdbinit file:
> 
> define hook-stop
> shell clear_xgrab
> end
> 
> Provided that a suitable external program called `clear_xgrab' was
> created, this would do what the original posted wanted.
> 
> (I still think it's better to use two machines to do this type of
> debugging though.)

I wrote a program that calls XUngrabServer(), but it did not have
any effect.  I added a call to XGrabServer() juste before, but still
without effect.  Perhaps a server grab is specific to each X11 client.
Ungrabbing from one X11 client would not affect grabs by other clients.

I also tried to run Xnest, as Gary Aviv suggested, but it
failed this way:

failed to set default font path 
'/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/'
Fatal server error:
could not open default font 'fixed'

I guess I could make these two solutions work if I hack at
them somewhat.  However, it would remain unusually complicated
to debug an X11 application under GDB.  A Windows programmer
would be quick to point out that this situation does not
happen on his platform.  (Although the drop down menu remains
displayed over the Visual Studio window...)  I would be curious
to know how this problem is handled under Windows.

I wouldn't mind patching my own copy of GDB to experiment
with XUngrabServer().  Could someone tell me what function
of the GDB sources I should study to do this?  I would like
to add some code where GDB writes its prompt.

-- 
Pierre Sarrazin 
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb



Re: [Bug-gdb] GDB and X11 server grabs

2000-09-14 Thread Kevin Buettner

On Sep 14,  6:42pm, Benoit Hudson wrote:

> On Thu, Sep 14, 2000 at 01:06:47PM -0700, Kevin Buettner wrote:
> > other things too.  E.g, it might be okay if you added a hook which says
> > to run a user specified shell command every time gdb stops and
> > displays a prompt.  (I still don't know if such a patch would be
> > accepted, but it'd have a much better shot than one which has explicit
> > knowledge about the X Window system.)
> 
> Isn't that the 'commands' command?

No.  The 'commands' command is used to attach some commands to a
breakpoint.  They won't run the commands when single stepping or
gdb stops due to some signal.

But I found the following in the gdb manual:

In addition, a pseudo-command, `stop' exists.  Defining
(`hook-stop') makes the associated commands execute every time
execution stops in your program:  before breakpoint commands are
run, displays are printed, or the stack frame is printed.

Also, it's possible to run commands in the shell via the `shell'
command, so the original poster (Pierre) could put something like the
following in his .gdbinit file:

define hook-stop
shell clear_xgrab
end

Provided that a suitable external program called `clear_xgrab' was
created, this would do what the original posted wanted.

(I still think it's better to use two machines to do this type of
debugging though.)

Kevin
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb



Re: [Bug-gdb] GDB and X11 server grabs

2000-09-14 Thread Benoit Hudson

On Thu, Sep 14, 2000 at 01:06:47PM -0700, Kevin Buettner wrote:
> other things too.  E.g, it might be okay if you added a hook which says
> to run a user specified shell command every time gdb stops and
> displays a prompt.  (I still don't know if such a patch would be
> accepted, but it'd have a much better shot than one which has explicit
> knowledge about the X Window system.)

Isn't that the 'commands' command?

-- BenoƮt
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb



Re: [Bug-gdb] GDB and X11 server grabs

2000-09-14 Thread Gary Aviv

On Thu, 14 Sep 2000, Pierre Sarrazin wrote:

> A GDB breakpoint can totally freeze an X11 display when debugging
> a GUI application, if the app makes a "server grab."
> 
> For example, if the application has a pull-down menu and I put
> a breakpoint in the menu's callback, then the following happens:
> 
> - the menu is opened and an X11 server grab happens (in order to
>   catch all mouse events even if they are outside the menu's window);
> 
> - the callback is called and GDB stops on it due to the breakpoint;
> 
> - GDB expects commands from the user, but the user cannot type
>   anything anywhere in the display because of the server grab;
>   of course, the menu cannot be closed because the app is stopped.
> 
> One way to get out of this is to login through the network and
> kill GDB.  Usually, I access the machine through a VNC remote
> display.  In addition, I telnet into the machine and run GDB in it,
> sending the display to the VNC/X11 server.  When the breakpoint is
> reached, I can still control GDB through the telnet session.
> 
> Is there a better way?  I would imagine that GDB could automatically
> try to end an X11 server grab every time it displays its prompt.
> 
> -- 
> Pierre Sarrazin <[EMAIL PROTECTED]>
> ___
> Bug-gdb mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/bug-gdb
> 

Yes. Use Xnest which gives you a X server which runs inside your host X server.
So the procedure is something like this:

Xnest :1 &  # from a local xterm, an X server is run in a window as screen 1
twm -display :1 &   # run a window manager in Xnest, for example twm,
xhost + # to turn off security in Xnest server

Now run your application under gdb (or in emacs, etc.) passing the application
the additional argument "-display :1". The application will then run
in a window under Xnest. If your application does not accept the -display
argument you will have to "set env DISPLAY=:1" in gdb  prior to running it.

Now you can set breakpoints even during pointer grabs because the grab
occurs only in the Xnest session. So, you will not get locked up as you
describe above.

[EMAIL PROTECTED]

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb



Re: [Bug-gdb] GDB and X11 server grabs

2000-09-14 Thread Kevin Buettner

On Sep 14,  3:32pm, Pierre Sarrazin wrote:

> A GDB breakpoint can totally freeze an X11 display when debugging
> a GUI application, if the app makes a "server grab."
> 
> For example, if the application has a pull-down menu and I put
> a breakpoint in the menu's callback, then the following happens:
> 
> - the menu is opened and an X11 server grab happens (in order to
>   catch all mouse events even if they are outside the menu's window);
> 
> - the callback is called and GDB stops on it due to the breakpoint;
> 
> - GDB expects commands from the user, but the user cannot type
>   anything anywhere in the display because of the server grab;
>   of course, the menu cannot be closed because the app is stopped.
> 
> One way to get out of this is to login through the network and
> kill GDB.  Usually, I access the machine through a VNC remote
> display.  In addition, I telnet into the machine and run GDB in it,
> sending the display to the VNC/X11 server.  When the breakpoint is
> reached, I can still control GDB through the telnet session.
> 
> Is there a better way?  I would imagine that GDB could automatically
> try to end an X11 server grab every time it displays its prompt.

The best way to debug the portions of a GUI application that have to
interact with the display is to do it from another display.  Although
it is possible to use Xnest or Xvnc to give the illusion of multiple
displays on a single display, in practice, this usually doesn't work
out very well since you end up having to move the mouse (thus
generating more X events) to give focus back to gdb.  This means that
you're really better off having two machines, one on which to run the
app that you're debugging and the other for displaying your debugger
session.

It might be possible to hack gdb to release the grab, but IMO this
would be a really ugly hack both from the gdb side of the world as
well as from the X11 side.  If I were the maintainer for the affected
part of gdb, I would probably not accept such a patch unless it were
in the form of some sort of generic hook that could be used to do
other things too.  E.g, it might be okay if you added a hook which says
to run a user specified shell command every time gdb stops and
displays a prompt.  (I still don't know if such a patch would be
accepted, but it'd have a much better shot than one which has explicit
knowledge about the X Window system.)

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb