Any way I can confirm that this is the bug? I'm happy to wash my hands of it, but I'd rather not brush it under the carept if I have my finger on a nasty bug we can solve.
Jer On Thu, 2002-02-14 at 22:21, Jim Gettys wrote: > That disaster.... > > Smells like the infamous netscape doesn't do locking with Xlib properly > bug... > > Keith Packard and I looked into something that smells the same (triggered > frequently on my machine by a Java app) about 18 months ago, and tried to get > Netscape to fix it... They unfortunately never have. > > The fault was netscape reentering Xlib without telling Xlib to > run with locking. Needless to say, things get confused, and > the result was netscape looping. > > The bug is a heisenbug: can occur anytime, but certain timing tends to > trigger it differently. If it is the same bug, the difference is just > that the server is running at a different speed than it used to... > > So if it is the same bug, there ain't a thing we can do about it... > It is buried in Netscape, a dead product. > Sigh... > - Jim > > > -- > Jim Gettys > Cambridge Research Laboratory > Compaq Computer Corporation > [EMAIL PROTECTED] > > > > Sender: [EMAIL PROTECTED] > > From: Jeremy White <[EMAIL PROTECTED]> > > Date: 14 Feb 2002 22:12:45 -0600 > > To: [EMAIL PROTECTED] > > Subject: [Xpert]Request for help on possible 4.1.0 bug > > ----- > > We're trying to track down a regression that occurs when using > > Quicktime in conjunction with Netscape 4.72. It works > > on X 3.3.6, but fails on 4.1.0. > > > > The failure behavior is that Netscape, while loading a > > web page with Quicktime content, goes into a nearly > > infinite spin loop, calling select() again and > > again. The socket it is calling select > > on is connected to /tmp/.X11-unix/X0. > > > > An strace of the app as it runs sheds some clues, > > but I was hoping to ask for further help from > > the experts. > > > > Specifically, the behavior is that we see a > > write() to the X socket which returns an > > EAGAIN. Now, when I run strace on other, > > success, cases, I never see a write() return > > EAGAIN (I only see writev return EAGAIN). Shortly after > > the write() occurs, the app goes into the > > select() spin loop. > > > > I was hoping to ask for help in several ways. > > First, as a newbie to this list, please feel free to correct me. > > If I should post elsewhere, or if there is a FM I should > > go read; I will cheerfully go off and do more > > homework. > > > > Second, I was hoping to get help pinpointing > > where in the source a write() to the > > socket with a potentially buggy EAGAIN > > handler might be, so I can see if I can > > spot a bug. To that end, I was hoping someone > > could teach me how to decode the X protocol. > > > > I have from the strace log the header of the > > request written, but I don't know how to decode it; > > again, I'd appreciate pointers to TFM or > > source code. > > > > I have attached the relevant fragment of the > > strace log; the write call in particular is > > on line 5 (you can see the select() spin loop > > starting at line 27). > > > > Thanks for any help you can offer, > > > > Jeremy > > > > Enclosed text file: strace.fragment (9 KBytes) _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
