> > yeah... what loop in vncserver would make it 100% busy waiting for the > > packet (data/lock/etc)? could you have a brief look? may be I could add > > more debugging printfs ;-) > Doh! Thought about wrong bug when answering. :) keeping too many open bugs handy? :)
> In general you are right that more debugging statements would be good. > An alternative aproach is to compile it with debugging symbols, run > it though gdb and then break it when it stalls. ;-) it is running with debug symbols... actually I've reported my attempts to see WTF attaching to it with gdb whenever it stalls -just have a quick look at one of my previous reports at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431485 > Something have gone wrong and we obviously have a busy loop somewhere. > Trying to do something and can not get out of that loop. yeah... one of previous gdb attempts showed: > (gdb) bt > #0 0x00002b39af69cf12 in fork () from /lib/libc.so.6 > #1 0x000000000043cd73 in Popen () > #2 0x000000000043e864 in LoadAuthorization () > #3 0x000000000043ea46 in CheckAuthorization () > #4 0x0000000000439a25 in ClientAuthorized () > #5 0x000000000041e396 in ProcEstablishConnection () > #6 0x0000000000424672 in Dispatch () > #7 0x000000000040b145 in main () But that was after I closed it and then was trying to reattach I guess... though I could be wrong... I should be more careful and do not detach it it halts and then try to gdb it I guess. I have limited experience though debugging multithreaded apps... -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
