Re: GDB does not stop in breakpoint!

Re: GDB does not stop in breakpoint!

[A. Soare]

> "alin.s" <alinsoar@voila.fr> writes:
> 
> > 1. breakpoint in Fx_create_frame
> > 2. run emacs and block X-windows.
> > 3. from a console kill gdb
> > 4. when I return in X, emacs is running , and gdb that started it is dead.
> 
> What do you mean by "block X-windows"?

No running application does not answer (redisplay). The bug reproduces on GNU linux, debian and ubuntu, latest stable versions.

However, notice in the log that gdb stopped in the breakpoint, but X-windows did not refresh the screen.

(before Killed, you can see the prompt of gdb after the br.p.)

I cannot understand this behavior of X server. Please clarify me if you can.







____________________________________________________

Vous n’avez pas encore adressé vos voeux ? Retrouvez nos cartes sur http://carte-de-voeux.voila.fr 

Re: GDB does not stop in breakpoint!

[A. Soare]

>     I put a breakpoint in Fx_create_frame. When I start emacs using "r" , the
>     breakpoint is never reached, and the X windows stops responding.
> 
> There are times, when the screen is grabbed, that stopping the program
> would cause X not to respond.  If you have put the breakpoint at a
> line which is in the middle of a grab, that would explain this.
> 

What means that the screen to be grabbed? How does this happen?


> Most of the code inside Fx_create_frame is NOT in the middle of a
> grab, and this problem should not happen in those places.
> 
> Can you connect from another machine with ssh and run gdb from
> the other machine?
> 
> 


I have a macintosh on my table, and I connect on linux, but there is no use ... over ssh the code will be the code for console, that works well. If I set the DISPLAY var:

Emacs checks at startup whether DISPLAY variable is set, and here is the result.


(gdb) set height 10000
(gdb) show environment 
TERM=xterm-color
SHELL=/bin/bash
XDG_SESSION_COOKIE=28814368defdc69e6f7455fa4b4dfcdd-1263458361.341927-1471763996
SSH_CLIENT=192.168.2.124 50118 22
SSH_TTY=/dev/pts/7
USER=root
LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
PWD=/emacs/src
LANG=en_US.UTF-8
SPEECHD_PORT=6560
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=192.168.2.124 50118 192.168.2.64 22
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/gdb
OLDPWD=/emacs
LINES=24
COLUMNS=80
(gdb) set environment DISPLAY=:0
(gdb) set environment DISPLAY=:0.0
(gdb) r -Q
Starting program: /emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x080f314f in check_x_display_info (object=138336946) at xfns.c:289
289	      dpyinfo = FRAME_X_DISPLAY_INFO (f);
(gdb) 




____________________________________________________

Vous n’avez pas encore adressé vos voeux ? Retrouvez nos cartes sur http://carte-de-voeux.voila.fr 

Re: GDB does not stop in breakpoint!

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 14, 2010 at 09:49:31AM +0100, A. Soare wrote:
> 
> >     I put a breakpoint in Fx_create_frame. When I start emacs using "r" , the
> >     breakpoint is never reached, and the X windows stops responding.
> > 
> > There are times, when the screen is grabbed, that stopping the program
> > would cause X not to respond.  If you have put the breakpoint at a
> > line which is in the middle of a grab, that would explain this.
> > 
> 
> What means that the screen to be grabbed? How does this happen?

That's when the program tells the X server "now give me all events until
I tell you". If the program doesn't react to events (e.g. in a tight
loop) and doesn't release the screen grab, the X sever seems to hang.

Grabs are useful whenwaiting for example for a menu choice to finish
(when the user clicks on the menu, it "opens" and then the program
usually grabs the screen until a choice is made or the menu click is
cancelled).

See, for example the manual pages of XGrabServer, XGrabPointer,
XGrabKeyboard and so on.

Grabs are often used for those all-horrible modal windows which seem to
be becoming en-vogue these days. But I disgress.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLTxyMBcgs9XrR2kYRAjmKAJ9QNt7lS82pV4Hfmfzkbm7Ba0s4/QCcC3Lw
gvAXF80WiW3WIK6P6vVJ0z0=
=YRs3
-----END PGP SIGNATURE-----

Re: GDB does not stop in breakpoint!

[A. Soare]

>     3       breakpoint     keep y   0x081fc176 in funcall_lambda at eval.c:3147
>         stop only if EQ(XCDR(XCAR(arg_vector[0])),Qx)
>         breakpoint already hit 411 times
> 
> 
>     It stops even if XCDR(XCAR(arg_vector[0])) != 'x
> 
> I did not know it was possible to use C macros in GDB.
> But if that does work now, I do not see why this condition would fail
> to work correctly.

The protocol of communication between the debugger and the executable is dwarf for C language. When one create the executable, it must be created following this protocol for gdb to be able to debug.

There is a flag to gcc to add options such that  gdb can render macros. 

> 
> But it is clear that that fails to verify whether arg_vector[0]
> is a cons cell.  So it will sometimes match objects that are the
> wrong type.
> 
> Therefore, it is certain that this
> 
>     cond 3 (CONSP(arg_vector[0]) && CONSP(XCAR(arg_vector[0])) &&
>     EQ(XCAR(XCAR(arg_vector[0])),Qx))
> 

yes, i am required to check.




____________________________________________________

Vous n’avez pas encore adressé vos voeux ? Retrouvez nos cartes sur http://carte-de-voeux.voila.fr 

GDB does not stop in breakpoint!

[alin.s]

I put a breakpoint in Fx_create_frame. When I start emacs using "r" , the
breakpoint is never reached, and the X windows stops responding.

I have to run this command to make it work again: (Gdb stops all Xwindows)

kill -KILL `ps -e | grep gdb | cut -dp  -f1`

Why gdb does not stop ?

On the other hand, I discovered this strange behaviour:


Breakpoint 3, funcall_lambda (fun=137006261, nargs=2, arg_vector=0xbfaf0e14)
at eval.c:3147
3147      int count = SPECPDL_INDEX ();

(gdb) p arg_vector[0]
$406 = 139830890
(gdb) pp arg_vector[0]
cygwin-mount-map-drive-hook-function
(gdb) pp XCAR(arg_vector[0])
34957716
(gdb) pp XCDR(XCAR(arg_vector[0]))
"cygwin-mount-name-hook-function"
(gdb)

Even if arg_vector[0] is not a cons, I can compute car and cdr, and more
than that - they make sense! Why do they make sense?

Here is defined the breakpoint:

3       breakpoint     keep y   0x081fc176 in funcall_lambda at eval.c:3147
        stop only if EQ(XCDR(XCAR(arg_vector[0])),Qx)
        breakpoint already hit 411 times


It stops even if XCDR(XCAR(arg_vector[0])) != 'x

Why ?






-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27107078.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[alin.s]

Here is defined the breakpoint:

3       breakpoint     keep y   0x081fc176 in funcall_lambda at eval.c:3147
        stop only if EQ(XCDR(XCAR(arg_vector[0])),Qx)
        breakpoint already hit 411 times


It stops even if XCDR(XCAR(arg_vector[0])) != 'x

Why ?

Using the condition

cond 3 (CONSP(arg_vector[0]) && CONSP(XCAR(arg_vector[0])) &&
EQ(XCAR(XCAR(arg_vector[0])),Qx))

it stops correctly in funcall lambda.



-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27108115.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[alin.s]

My problem is this bug: it occurs during emacs start up. (emacs is compiled
for gtk):


Program received signal SIGSEGV, Segmentation fault.
0x0811e207 in check_x_display_info (object=138906162) at xfns.c:269
269             dpyinfo = FRAME_X_DISPLAY_INFO (sf);

(sf)->output_data was not initialized correctly.


Can you suggest me some better methods of debugging it?




-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27108386.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[alin.s]

If I try to install a breakpoint directly in Fx_create_frame, gdb hangs.

But I did so:

(gdb) watch Vframe_list
Hardware watchpoint 5: Vframe_list
(gdb) c
Continuing.
Hardware watchpoint 5: Vframe_list

Old value = 138894718
New value = 139227438
Fx_create_frame (parms=139236126) at xfns.c:3453
3453      x_default_parameter (f, parms, Qicon_type, Qt,
(gdb) pp 139236126
((visibility) (window-system . x) (horizontal-scroll-bars . t))
(gdb)


And using a watchpoint it stopped in Fx_create_frame. Very strange. Seems a
bug in gdb...




-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27108668.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[Jan Djärv]

alin.s skrev:
> My problem is this bug: it occurs during emacs start up. (emacs is compiled
> for gtk):
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0811e207 in check_x_display_info (object=138906162) at xfns.c:269
> 269             dpyinfo = FRAME_X_DISPLAY_INFO (sf);
> 
> (sf)->output_data was not initialized correctly.
> 
> 
> Can you suggest me some better methods of debugging it?
> 

Show us how to reproduce the error so someone else can debug it.  It looks 
like your gdb is broken.

	Jan D.

Re: GDB does not stop in breakpoint!

[alin.s]

> Program received signal SIGSEGV, Segmentation fault.
> 0x0811e207 in check_x_display_info (object=138906162) at xfns.c:269
> 269             dpyinfo = FRAME_X_DISPLAY_INFO (sf);
> 
> (sf)->output_data was not initialized correctly.
> 
> 
> Can you suggest me some better methods of debugging it?
> 

Show us how to reproduce the error so someone else can debug it.  It looks 
like your gdb is broken.

Thanks . It is difficult for me to show you, because emacs is modified.


Alin










-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27109372.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[Richard Stallman]

    Program received signal SIGSEGV, Segmentation fault.
    0x0811e207 in check_x_display_info (object=138906162) at xfns.c:269
    269             dpyinfo = FRAME_X_DISPLAY_INFO (sf);

    (sf)->output_data was not initialized correctly.


    Can you suggest me some better methods of debugging it?

First make sure you have code to initialize that slot
in frames that you construct.

If you do, and it strangely gets clobbered, you could try a
watchpoint.

Re: GDB does not stop in breakpoint!

[Richard Stallman]

    3       breakpoint     keep y   0x081fc176 in funcall_lambda at eval.c:3147
	    stop only if EQ(XCDR(XCAR(arg_vector[0])),Qx)
	    breakpoint already hit 411 times


    It stops even if XCDR(XCAR(arg_vector[0])) != 'x

I did not know it was possible to use C macros in GDB.
But if that does work now, I do not see why this condition would fail
to work correctly.

But it is clear that that fails to verify whether arg_vector[0]
is a cons cell.  So it will sometimes match objects that are the
wrong type.

Therefore, it is certain that this

    cond 3 (CONSP(arg_vector[0]) && CONSP(XCAR(arg_vector[0])) &&
    EQ(XCAR(XCAR(arg_vector[0])),Qx))

is the right command to use.

Re: GDB does not stop in breakpoint!

[Tom Tromey]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:

RMS> I did not know it was possible to use C macros in GDB.
RMS> But if that does work now, I do not see why this condition would fail
RMS> to work correctly.

It does work, provided you compile with -g3.

Tom

Re: GDB does not stop in breakpoint!

[Richard Stallman]

    I put a breakpoint in Fx_create_frame. When I start emacs using "r" , the
    breakpoint is never reached, and the X windows stops responding.

There are times, when the screen is grabbed, that stopping the program
would cause X not to respond.  If you have put the breakpoint at a
line which is in the middle of a grab, that would explain this.

Most of the code inside Fx_create_frame is NOT in the middle of a
grab, and this problem should not happen in those places.

Can you connect from another machine with ssh and run gdb from
the other machine?

Re: GDB does not stop in breakpoint!

[alin.s]

Now I reply the experiment on some unpatched sources, and here is a sure way
to reproduce the "bug" (if it'sa bug)

1. breakpoint in Fx_create_frame
2. run emacs and block X-windows.
3. from a console kill gdb
4. when I return in X, emacs is running , and gdb that started it is dead.

If somebody can explain me in detail what happens when X blocks, please
explain me.




debian:/emacs-gtk/src# gdb ./emacs
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x8147e63: file emacs.c, line 431.
Breakpoint 2 at 0x8168760: file sysdep.c, line 1132.
(gdb) break Fx_create_frame
Breakpoint 3 at 0x811ef98: file xfns.c, line 3129.
(gdb) r -Q
Starting program: /emacs-gtk/src/emacs -Q
[Thread debugging using libthread_db enabled]
[New Thread 0xb725d8c0 (LWP 4971)]
[Switching to Thread 0xb725d8c0 (LWP 4971)]

Breakpoint 3, Fx_create_frame (parms=139100246) at xfns.c:3129
3129      int minibuffer_only = 0;
(gdb) Killed
debian:/emacs-gtk/src#   





Richard Stallman wrote:
> 
>     I put a breakpoint in Fx_create_frame. When I start emacs using "r" ,
> the
>     breakpoint is never reached, and the X windows stops responding.
> 
> There are times, when the screen is grabbed, that stopping the program
> would cause X not to respond.  If you have put the breakpoint at a
> line which is in the middle of a grab, that would explain this.
> 
> Most of the code inside Fx_create_frame is NOT in the middle of a
> grab, and this problem should not happen in those places.
> 
> Can you connect from another machine with ssh and run gdb from
> the other machine?
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/GDB-does-not-stop-in-breakpoint%21-tp27107078p27200967.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: GDB does not stop in breakpoint!

[Chong Yidong]

"alin.s" <alinsoar@voila.fr> writes:

> 1. breakpoint in Fx_create_frame
> 2. run emacs and block X-windows.
> 3. from a console kill gdb
> 4. when I return in X, emacs is running , and gdb that started it is dead.

What do you mean by "block X-windows"?

Re: GDB does not stop in breakpoint!

[Richard Stallman]

    Even if arg_vector[0] is not a cons, I can compute car and cdr, and more
    than that - they make sense! Why do they make sense?

XCAR and XCDR just examine the memory inside the object.
If it's not a symbol, they do not care or notice.