Re: Linux/Alpha show-stopper



Miguel de Icaza wrote:

> Which OS are you running, which versions of the gnome components are
> you running?

(continued from previous message) and egcs-1.1.1.

> Could you try to figure out which routines are being invoked
> internally?

OK, I can do a little better than the last post.  I went backwards from
__syscall_poll through poll and found the only GNOME component with this
symbol is glib, where it is called by g_main_iterate (via g_main_poll),
which in turn is called by g_main_pending, g_main_iteration, and
g_main_run.  These seem to me to be the only gateways to __syscall_poll
from any GNOME-related library or program, based on 'nm /usr/lib/* | grep
poll'.

Tracing up in a ddd gnumeric session, it goes: (libc) __syscall_poll, poll,
(glib) g_main_poll, g_main_iterate, g_main_run, (gtk+) gtk_main, (gnumeric)
gnumeric_main in main.c line 79.  So it was as I suspected, this
cpu-loading loop begins in gtk_main.

I also found gnumeric interrupting once or twice in __gettimeofday, which
traces to (glib) g_get_current_time, g_main_iterate, same from there up.

Another new interrupt location: __ioctl, traces up to
_X11TransSocketBytesReadable, _X11TransBytesReadable, _XEventsQueued,
XPending, (gdk) gdk_events_queue, gdk_event_prepare, (glib) g_main_iterate,
etc.

Another: __errno_location, poll, g_main_poll, etc.

Okay, so it doesn't always break on __syscall_poll, but it does always seem
to break somewhere below g_main_iterate, and *never* on __select.  Perhaps
I should send this bug report to a gtk+ list...

Zeen,

-Adam `Cold Fusion' Powell, IV http://www.ctcms.nist.gov/~powell/ ____
USDoC, National Institute of Standards & Technology (NIST)  |\ ||<  |
Center for Theoretical and Computational Materials Science  | \||_> |





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]