On 7/2/2013 11:41 AM, Rockefeller, Harry wrote:
When I start emacs I get this message: (emacs:192): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion `extra_space >= 0' failed
Are you saying that this happens every time you start emacs? Does it even happen when you start with 'emacs -Q'? If not, maybe you could do some testing to figure out what in your initialization (including X11 initialization) triggers it. This might help to pin down the bug.
Maybe when zombies are present (as reported by 'top') I get several of these messages: (emacs:192): Gtk-WARNING **: gtk_window_parse_geometry() called on a window with no visible children; the window should be set up before gtk_window_parse_geometry() is called.
This is a bogus warning and can be ignored. It will be suppressed in future releases of emacs.
Perhaps I have too many 'helper' programs running? e.g., why are there 3 dbus-daemon processes? Here is the result of 'ps': PID PPID PGID WINPID TTY UID STIME COMMAND 6028 1 4792 3460 ? 11097 08:24:51 /usr/lib/at-spi/at-spi-bus-launcher 7632 5844 7632 3256 pty2 11097 10:07:40 /usr/bin/ps 5908 1 4792 4804 ? 11097 08:24:52 /usr/lib/at-spi/at-spi2-registryd 2480 1 2480 2480 ? 11097 08:22:47 /usr/bin/XWin 5772 6028 4792 5820 ? 11097 08:24:52 /usr/bin/dbus-daemon I 5388 1968 5388 5696 pty0 11097 08:23:02 /usr/bin/bash 192 5388 192 4688 pty0 11097 08:24:44 /usr/bin/emacs-X11 4696 5388 5388 604 pty0 11097 08:23:11 /usr/bin/xterm 1968 1 1968 1968 cons0 11097 08:23:00 /usr/bin/xterm 5844 4696 5844 228 pty2 11097 08:23:12 /usr/bin/bash 4792 1 4792 4792 ? 11097 08:24:51 /usr/bin/dbus-daemon 3436 1 192 3436 pty0 11097 08:24:51 /usr/bin/dbus-launch 5576 1 5576 5576 ? 11097 08:23:13 /usr/bin/dbus-daemon
My system is similar, but I only have two dbus-daemons running. And when I exit from the X server, all these 'helper' processes disappear.
I think I might have mentioned once before when you wrote about zombie processes that there is a known problem in emacs-24.3 that can cause problems with subprocesses. This is caused by race conditions between emacs and glib. The problem has recently been fixed on the emacs development trunk. If you'd like, I could build emacs from a snapshot of the trunk and let you test it to see if some of your problems go away.
Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple