gdb-ui / fring coredump question

gdb-ui / fring coredump question

[Miles Bader]

I'm getting a coredump if I use gdb-ui inside of emacs, as soon as I set
a breakpoint; the basic problem seems to be that in displaying the
stop-sign icon in the fringe, it's trying to push more than 2 elements on
the iterator stack (the max iterator stack-size is two).

I wanted to see if I could debug it in standard CVS emacs, since I have
a lot of my own display hacks, but discovered something funny:  if I use
gdb-ui in standard CVS emacs, it uses the display "margin" to display
the stop-sign icon instead of using the fringe, whereas in my personal
emacs it uses the fringe!  Is this correct?  How does gdb-ui determine
which display mechanism (margin for stop-sign and fringe for arrow, or
fringe for both) to use?  [I looked briefly at the lisp code, and saw no
obvious reason for this behavior.]

Unfortunately, the combined stop/arrow in the fringe seems to be a
necessary ingredient in the crash.  Oh, and also I suppose xassert is
disabled by default (whereas my emacs doesn't); hmmm, maybe I'll have to
enable that in CVS and try again.

Also, anyone know offhand if recent display changes could have caused the
max iterator stack-size to increase past two?  [Otherwise it must be
missing a pop somewhere]

Thanks,

-Miles

Stack backtrace follows.  The line numbers are off from CVS, but the
place it's dying seems to be the following xassert in xdsip.c:

	push_it (it)
	     struct it *it;
	{
	  struct iterator_stack_entry *p;
	
	  xassert (it->sp < 2);
	  p = it->stack + it->sp;

#0  abort () at /usr/local/src/emacs/miles/src/emacs.c:454
#1  0x0809a325 in push_it (it=0xbfffcd30)
    at /usr/local/src/emacs/miles/src/xdisp.c:4536
#2  0x08098b61 in handle_single_display_spec (it=0xbfffcd30, spec=142897157, 
    object=143344835, position=0xbfffcddc, display_replaced_before_p=0)
    at /usr/local/src/emacs/miles/src/xdisp.c:3748
#3  0x08098472 in handle_display_prop (it=0xbfffcd30)
    at /usr/local/src/emacs/miles/src/xdisp.c:3474
#4  0x0809a7d5 in back_to_previous_visible_line_start (it=0xbfffd570)
    at /usr/local/src/emacs/miles/src/xdisp.c:4723
#5  0x0809ca4c in move_it_vertically_backward (it=0xbfffd570, dy=111)
    at /usr/local/src/emacs/miles/src/xdisp.c:6270
#6  0x080a5ab3 in redisplay_window (window=143124060, just_this_one_p=0)
    at /usr/local/src/emacs/miles/src/xdisp.c:12253
#7  0x080a3673 in redisplay_window_0 (window=-1073754832)
    at /usr/local/src/emacs/miles/src/xdisp.c:10835
#8  0x081853b4 in internal_condition_case_1 (
    bfun=0x80a3640 <redisplay_window_0>, arg=143124060, handlers=137648461, 
    hfun=0x80a3620 <redisplay_window_error>)
    at /usr/local/src/emacs/miles/src/eval.c:1500
#9  0x080a361b in redisplay_windows (window=480)
    at /usr/local/src/emacs/miles/src/xdisp.c:10814
#10 0x080a35d4 in redisplay_windows (window=480)
    at /usr/local/src/emacs/miles/src/xdisp.c:10808
#11 0x080a2925 in redisplay_internal (preserve_echo_area=1)
    at /usr/local/src/emacs/miles/src/xdisp.c:10396
#12 0x080a322c in redisplay_preserve_echo_area (from_where=-1073754832)
    at /usr/local/src/emacs/miles/src/xdisp.c:10625
#13 0x081b8084 in wait_reading_process_output (time_limit=30, microsecs=0, 
    read_kbd=-1, do_display=1, wait_for_cell=137621521, wait_proc=0x0, 
    just_wait_proc=0) at /usr/local/src/emacs/miles/src/process.c:4561
#14 0x0808bcc7 in sit_for (sec=30, usec=0, reading=1, display=1, 
    initial_display=0) at /usr/local/src/emacs/miles/src/dispnew.c:6371
#15 0x08126aa6 in read_char (commandflag=1, nmaps=3, maps=0xbfffe55c, 
    prev_event=137621521, used_mouse_menu=0xbfffe598)
    at /usr/local/src/emacs/miles/src/keyboard.c:2765
#16 0x0812d534 in read_key_sequence (keybuf=0xbfffe6c0, bufsize=30, 
    prompt=137621521, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at /usr/local/src/emacs/miles/src/keyboard.c:8799
#17 0x08123ce3 in command_loop_1 ()
    at /usr/local/src/emacs/miles/src/keyboard.c:1534
#18 0x081852ae in internal_condition_case (bfun=0x8123b50 <command_loop_1>, 
    handlers=137682609, hfun=0x8123640 <cmd_error>)
    at /usr/local/src/emacs/miles/src/eval.c:1459
#19 0x0812399e in command_loop_2 ()
    at /usr/local/src/emacs/miles/src/keyboard.c:1315
#20 0x08184deb in internal_catch (tag=-1073754832, 
    func=0x8123970 <command_loop_2>, arg=137621521)
    at /usr/local/src/emacs/miles/src/eval.c:1218
#21 0x08123943 in command_loop ()
    at /usr/local/src/emacs/miles/src/keyboard.c:1294
#22 0x081233a4 in recursive_edit_1 ()
    at /usr/local/src/emacs/miles/src/keyboard.c:987
#23 0x081234e1 in Frecursive_edit ()
    at /usr/local/src/emacs/miles/src/keyboard.c:1048
#24 0x08121a4d in main (argc=3, argv=0xbfffed74)
    at /usr/local/src/emacs/miles/src/emacs.c:1763


-- 
Quidquid latine dictum sit, altum viditur.

Re: gdb-ui / fring coredump question

[Miles Bader]

BTW, I want to enable xassert by default -- it seems absurd that
redisplay is still being hacked on without that being the case.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: gdb-ui / fring coredump question

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I'm getting a coredump if I use gdb-ui inside of emacs, as soon as I set
> a breakpoint; the basic problem seems to be that in displaying the
> stop-sign icon in the fringe, it's trying to push more than 2 elements on
> the iterator stack (the max iterator stack-size is two).

Thanks.  I have installed a fix.

gdb-ui / fring coredump question

[Nick Roberts]

 > I'm getting a coredump if I use gdb-ui inside of emacs, as soon as I set
 > a breakpoint; the basic problem seems to be that in displaying the
 > stop-sign icon in the fringe, it's trying to push more than 2 elements on
 > the iterator stack (the max iterator stack-size is two).

I have not seen this behaviour. In any case, Kim seems to have installed a
fix.

 > I wanted to see if I could debug it in standard CVS emacs, since I have
 > a lot of my own display hacks, but discovered something funny:  if I use
 > gdb-ui in standard CVS emacs, it uses the display "margin" to display
 > the stop-sign icon instead of using the fringe, whereas in my personal
 > emacs it uses the fringe!  Is this correct?  How does gdb-ui determine
 > which display mechanism (margin for stop-sign and fringe for arrow, or
 > fringe for both) to use?  [I looked briefly at the lisp code, and saw no
 > obvious reason for this behavior.]

By default, if the fringe is present, both arrow and breakpoint icons should
display there. The only way that I can get breakpoint icons to display in the
margin when the fringe is present, is to make the fringe under eight pixels
wide (what value do you have for fringe-mode?). Going slightly offtopic, when
the margin is used you can disable/enable it with mouse-3. However, I can't
get this behaviour to work in the fringe because, in this case, there are no
associated text-properties to store breakpoint information. Perhaps this could
be addressed after the release.

Nick

gdb-ui / fring coredump question

[Nick Roberts]

 > ...Going slightly offtopic, when the margin is used you can disable/enable
 > it with mouse-3.
   ^^

I mean the breakpoint not the margin.

Nick

Re: gdb-ui / fring coredump question

[Miles Bader]

>  I have installed a fix.

Thanks Kim, that did the trick.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: gdb-ui / fring coredump question

[Miles Bader]

> By default, if the fringe is present, both arrow and breakpoint icons should
> display there. The only way that I can get breakpoint icons to display in the
> margin when the fringe is present, is to make the fringe under eight pixels
> wide

I'm confused what you mean above.  Do you mean that you _want_ to use
the margin for breakpoint icons, but that there's some strange
interaction between the fringe and margin such that this doesn't work
when the fringe is 8 or more pixels wide?  That sounds a bit strange.

I'd think that the most desirable method would be to use the fringe
for both; as you mention below, there's a click issue, but at least
for my use, clickability is not very important, I'd prefer to have the
nicer display properties of the fringe-only mode.

> (what value do you have for fringe-mode?).

fringe-mode's value is nil

> Going slightly offtopic, when
> the margin is used you can disable/enable it with mouse-3. However, I can't
> get this behaviour to work in the fringe because, in this case, there are no
> associated text-properties to store breakpoint information. 

Another problem I saw in passing with the both-fringe-and-margins mode
is that for some reason once the margin had been displayed, it would
sometimes start blinking on and off (I mean, it would display first
without the margin, then redisplay with the margin, etc).  I don't
have an easy test case for this though.

I wonder if it's related to the bug I reported earlier, where I get
repeated alternating redisplay of octal-encoded ecapes for 8-bit
values and "displayed as european characters" display; that bug is
still not fixed.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: gdb-ui / fring coredump question

[Nick Roberts]

 > > By default, if the fringe is present, both arrow and breakpoint icons
 > > should display there. The only way that I can get breakpoint icons to
 > > display in the margin when the fringe is present, is to make the fringe
 > > under eight pixels wide
 > 
 > I'm confused what you mean above.  Do you mean that you _want_ to use
 > the margin for breakpoint icons, but that there's some strange
 > interaction between the fringe and margin such that this doesn't work
 > when the fringe is 8 or more pixels wide?  That sounds a bit strange.

No. I mean thats the only way I can see that behaviour.

 > I'd think that the most desirable method would be to use the fringe
 > for both;...

Yes. That's what should happen.

 > > (what value do you have for fringe-mode?).
 > 
 > fringe-mode's value is nil

This should be easy to debug if you instrument gdb-put-breakpoint-icon with
Edebug, click on the fringe to set a breakpoint, and step through the
function. The first gdb-put-string (anachronistic name) puts a bitmap in the
fringe (if reached), while put-image puts an image in the margin.

I've noticed that, in my case, although fringe-mode is nil, so that the
fringes should have the default width (8 pixels), (window-fringes) gives (10
11 nil). Just a guess, but if you are using a different toolkit (GTK?) perhaps
(window-fringes) gives something different again with a car of less than 8.

This is Kim's code so he can probably shed more light.

[Note for Kim: The doco for the variable fringe-mode mentions 'toggle-fringe'
but there doesn't appear to be any such function.]

 > Another problem I saw in passing with the both-fringe-and-margins mode
 > is that for some reason once the margin had been displayed, it would
 > sometimes start blinking on and off (I mean, it would display first
 > without the margin, then redisplay with the margin, etc).  I don't
 > have an easy test case for this though.

I have seen something similar in an xterm but both-fringe-and-margins
mode shouldn't happen ordinarily. Lets debug one problem at a time.


Nick

Re: gdb-ui / fring coredump question

[Robert J. Chassell]

   ... if you are using a different toolkit (GTK?) perhaps
   (window-fringes) gives something different again with a car of less
   than 8.

No.  (window-fringes)  gives you   (8 8 nil)
*unless* you specify a non-default font size.


Using yesterdays's GNU Emacs CVS snapshot,  Tue, 2005 Feb  1  13:09 UTC
GNU Emacs 21.3.50.49 (i686-pc-linux-gnu, GTK+ Version 2.4.14)
started with

    emacs -Q

[I evaluated

  (custom-set-faces '(fringe ((((class color)) (:background "blue")))))

to see the fringes.]

The default:

    (window-fringes)  evaluates to     (8 8 nil)

    and fringe-mode   evaluates to     nil

After I evaluated

    (set-frame-font "10x20")

 (window-fringes)  evaluates to     (10 10 nil)

 and fringe-mode   continues to evaluate to     nil

Incidently, to set-fringe-mode on the left only, I must load "fringe";
otherwise I enter the debugger.

(progn
  (load "fringe")
  ;; Fringe only on left
  (set-fringe-mode '(nil . 0)))

Then (window-fringes)  evaluates to     (10 0 nil)
for the larger font and

    (8 0 nil) for the default

and fringe-mode    evaluates to    (nil . 0)

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: gdb-ui / fring coredump question

[Nick Roberts]

 > No.  (window-fringes)  gives you   (8 8 nil)
 > *unless* you specify a non-default font size.
 
Yes. This looks right. I'm not sure why, in my case, the right fringe should
be one pixel wider than the left one [ (10 11 nil) ].

In this case, I think the documentation for fringe-mode should reflect
this:

doc> fringe-mode's value is nil

doc> *Specify appearance of fringes on all frames.
doc> This variable can be nil (the default) meaning the fringes should have
doc> the default width (8 pixels),...

Nick

Re: gdb-ui / fring coredump question

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > No.  (window-fringes)  gives you   (8 8 nil)
>  > *unless* you specify a non-default font size.
>  
> Yes. This looks right. I'm not sure why, in my case, the right fringe should
> be one pixel wider than the left one [ (10 11 nil) ].
>
> In this case, I think the documentation for fringe-mode should reflect
> this:
>
> doc> fringe-mode's value is nil
>
> doc> *Specify appearance of fringes on all frames.
> doc> This variable can be nil (the default) meaning the fringes should have
> doc> the default width (8 pixels),...

The default is a little more complex:

The width of left and right fringe together must equal the width of a whole
number of default column widths, but be at least 8 pixels each.

If your default frame font is 7 pixels wide, 2 x 7 is below the minimum 2 x 8,
so we have to take 3 x 7 pixels, giving 10 pixels for the left and 11 pixels
for the right fringe.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk