> Nick> Did you do this with gdb-many-windows set to t? > > tried it with gdb-many-windows set to "t" or "nil", doesn't seem to make > a difference.
You might need to check that there aren't other buffers present which just aren't visible. > Nick> How deep is your stack? > > Only 9 frames in this case, but we have about 130 threads, i.e. under Solaris > that is 260 lightweight processes. Maybe this (besides the image/core size) > causes problems. Then I can't really understand why gdb-ui would take so much longer than GDB on its own. The overheads are due to the GDB commands which are run behind the users back, and the time to update the contents of the associated buffers. I would have thought that the number of threads should make no difference to the time *difference* between the two, unless the threads buffer was present. -- Nick http://www.inet.net.nz/~nickrob _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
