* GDB does not stop in breakpoint!
@ 2010-01-11 8:23 alin.s
2010-01-11 10:00 ` alin.s
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: alin.s @ 2010-01-11 8:23 UTC (permalink / raw)
To: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 8:23 alin.s
@ 2010-01-11 10:00 ` alin.s
2010-01-11 10:24 ` alin.s
2010-01-12 10:03 ` Richard Stallman
2010-01-12 10:03 ` Richard Stallman
2010-01-12 10:03 ` Richard Stallman
2 siblings, 2 replies; 17+ messages in thread
From: alin.s @ 2010-01-11 10:00 UTC (permalink / raw)
To: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 10:00 ` alin.s
@ 2010-01-11 10:24 ` alin.s
2010-01-11 10:52 ` alin.s
` (2 more replies)
2010-01-12 10:03 ` Richard Stallman
1 sibling, 3 replies; 17+ messages in thread
From: alin.s @ 2010-01-11 10:24 UTC (permalink / raw)
To: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 10:24 ` alin.s
@ 2010-01-11 10:52 ` alin.s
2010-01-11 11:41 ` Jan Djärv
2010-01-12 10:03 ` Richard Stallman
2 siblings, 0 replies; 17+ messages in thread
From: alin.s @ 2010-01-11 10:52 UTC (permalink / raw)
To: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 10:24 ` alin.s
2010-01-11 10:52 ` alin.s
@ 2010-01-11 11:41 ` Jan Djärv
2010-01-11 11:59 ` alin.s
2010-01-12 10:03 ` Richard Stallman
2 siblings, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2010-01-11 11:41 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 11:41 ` Jan Djärv
@ 2010-01-11 11:59 ` alin.s
0 siblings, 0 replies; 17+ messages in thread
From: alin.s @ 2010-01-11 11:59 UTC (permalink / raw)
To: Emacs-devel
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 10:00 ` alin.s
2010-01-11 10:24 ` alin.s
@ 2010-01-12 10:03 ` Richard Stallman
2010-01-12 18:49 ` Tom Tromey
1 sibling, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2010-01-12 10:03 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 8:23 alin.s
2010-01-11 10:00 ` alin.s
@ 2010-01-12 10:03 ` Richard Stallman
2010-01-17 17:36 ` alin.s
2010-01-12 10:03 ` Richard Stallman
2 siblings, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2010-01-12 10:03 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 8:23 alin.s
2010-01-11 10:00 ` alin.s
2010-01-12 10:03 ` Richard Stallman
@ 2010-01-12 10:03 ` Richard Stallman
2 siblings, 0 replies; 17+ messages in thread
From: Richard Stallman @ 2010-01-12 10:03 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-11 10:24 ` alin.s
2010-01-11 10:52 ` alin.s
2010-01-11 11:41 ` Jan Djärv
@ 2010-01-12 10:03 ` Richard Stallman
2 siblings, 0 replies; 17+ messages in thread
From: Richard Stallman @ 2010-01-12 10:03 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-12 10:03 ` Richard Stallman
@ 2010-01-12 18:49 ` Tom Tromey
0 siblings, 0 replies; 17+ messages in thread
From: Tom Tromey @ 2010-01-12 18:49 UTC (permalink / raw)
To: rms; +Cc: alin.s, Emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
@ 2010-01-14 8:36 A. Soare
0 siblings, 0 replies; 17+ messages in thread
From: A. Soare @ 2010-01-14 8:36 UTC (permalink / raw)
To: rms; +Cc: Emacs Dev [emacs-devel]
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
@ 2010-01-14 8:49 A. Soare
2010-01-14 13:30 ` tomas
0 siblings, 1 reply; 17+ messages in thread
From: A. Soare @ 2010-01-14 8:49 UTC (permalink / raw)
To: rms; +Cc: Emacs Dev [emacs-devel]
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-14 8:49 GDB does not stop in breakpoint! A. Soare
@ 2010-01-14 13:30 ` tomas
0 siblings, 0 replies; 17+ messages in thread
From: tomas @ 2010-01-14 13:30 UTC (permalink / raw)
To: A. Soare; +Cc: rms, Emacs Dev [emacs-devel]
-----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-----
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-12 10:03 ` Richard Stallman
@ 2010-01-17 17:36 ` alin.s
2010-01-17 18:47 ` Chong Yidong
0 siblings, 1 reply; 17+ messages in thread
From: alin.s @ 2010-01-17 17:36 UTC (permalink / raw)
To: Emacs-devel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
2010-01-17 17:36 ` alin.s
@ 2010-01-17 18:47 ` Chong Yidong
0 siblings, 0 replies; 17+ messages in thread
From: Chong Yidong @ 2010-01-17 18:47 UTC (permalink / raw)
To: alin.s; +Cc: Emacs-devel
"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"?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GDB does not stop in breakpoint!
@ 2010-01-18 8:01 A. Soare
0 siblings, 0 replies; 17+ messages in thread
From: A. Soare @ 2010-01-18 8:01 UTC (permalink / raw)
To: Chong Yidong; +Cc: Emacs Dev [emacs-devel]
> "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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-01-18 8:01 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-14 8:49 GDB does not stop in breakpoint! A. Soare
2010-01-14 13:30 ` tomas
-- strict thread matches above, loose matches on Subject: below --
2010-01-18 8:01 A. Soare
2010-01-14 8:36 A. Soare
2010-01-11 8:23 alin.s
2010-01-11 10:00 ` alin.s
2010-01-11 10:24 ` alin.s
2010-01-11 10:52 ` alin.s
2010-01-11 11:41 ` Jan Djärv
2010-01-11 11:59 ` alin.s
2010-01-12 10:03 ` Richard Stallman
2010-01-12 10:03 ` Richard Stallman
2010-01-12 18:49 ` Tom Tromey
2010-01-12 10:03 ` Richard Stallman
2010-01-17 17:36 ` alin.s
2010-01-17 18:47 ` Chong Yidong
2010-01-12 10:03 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.