[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Help with Output global in PCB. . . .
Bill,
> > Any pointers on the definition and use of the variable Output would be
> > appreciated!
>
> It's declared as a global in data.c along with the other global structs
> such as Crosshair and Settings.
Thanks! I found that after I posted. However, I am still working out
how it gets built. Following along with gdb does show that it gets
built correctly, AFAICT.
> Stuart, would it help to know if others running Fedora do or don't have
> this problem? Maybe they could chime in with a yes or no... Anybody?
> Or does anybody see it on another distribution?
I have observed it on both Fedora 2 & Fedora 3. I use only the
vanilla Fedora installs (i.e. no fancy themes or skins).
I get the warning spew both when I
load a new board via "File->Load layout", and also when I start a new
board via "File->Start new layout".
The warning spew comes after program flow leavs the fcn
gui_output_drawing_area_expose_event_cb. At that point, the gtk
dispatcher is running around making sure all widgets got the
"GDK_EVENT_EXPOSE" signal. It is basically doing internal gkt
housekeeping. When it invokes the internal GTK fcn
"flush_all_displays", then the warning spew occurs.
Note that the warning spew doesn't always occur after leaving
gui_output_drawing_area_expose_event_cb. It only occurs in the
context of loading a board or starting a new layout. Therefore, the
act of loading or starting a board must do something funny. Any ideas
what's unique about those actions?
While tracing this bug with gdb I have noticed that
gui_output_drawing_area_expose_event_cb is frequently called with bad
args. Perhaps this is a part of the puzzle? Here is an example:
Breakpoint 1, gui_output_drawing_area_expose_event_cb
(widget=0xfeeb56f0,
ev=0xfeeb56f0, out=0x80f7720) at gui-output-events.c:908
Note that widget and ev both point to the same place. However, they
shouldn't! widget is a GTK widget (pointer), and ev is a GDK event (pointer).
When I go up to the calling fcn, I find that the calling args are
correct. This kind of problem with the stack is usually due to a
loose pointer or bad memory malloc or something like that. However, I
haven't found any obvious problems yet.
Any ideas?
Stuart