Bug235 Editing
On my system, with a clean checkout from cvs (or, at least, cvs diff gives no differences), I get the following behaviour: - run fresco-demo -> no display, server starts using lots of cpu; stopping fresco-demo does not reduce the cpu load - run fresco-demo3D -> works fine, can can be run ok in parallel with a failed fresco-demo If I run the server with tracing, then the last line before pinging starts is a SubjectImpl::notify call. Maybe this is causing a deadlock or similar condition. I'm guessing a race condition, since I did manage to run the demo a couple of times, and this has only started happening with a very recent cvs. This is with gcc2.95.4/omni3 (debian almost-unstable). Its not been seen on other machines running gcc3.2/omni4, but that might be due to them being slower machines, perhaps? (ie. not triggering a race?) Mine is XP1700+, if it makes a difference. But I could be talking nonsense, please correct me :)
Yep! I just spent last night debugging this with kentyman. It looks like one of the observers being notified is blocking. I'd like a trace to tell us which one. The problem is triggered through the EditTextDemo calling TextBuffer insert_string. Kent Johnson reported that it was the last line in insert_string calling SubjectImpl::notify which is triggering the problem. Perhaps Tobias is familiar with the TextBuffers and knows what might be wrong?
A bigger trace portion, using: $ bin/berlin -t 2>&1 |grep -v Babylon |grep -v ping is: ... 6.403233|4 enter TextBufferImpl::insert_string(...) 6.403543|4 enter SubjectImpl::notify 6.403597|4 enter VisualTextBufferImpl::Observer::update(...) 6.404105|4 enter VisualTextBufferImpl::update(...) 6.413734|4 enter VisualTextBufferImpl::insert(...) 6.413780|4 enter TextBufferImpl::get_chars(...) 6.413786|4 leave TextBufferImpl::get_chars(...) took 0.000006 6.414444|4 leave VisualTextBufferImpl::insert(...) took 0.000710 6.414483|4 enter SubjectImpl::notify [that is as far as thread 4 gets.] Things to try now: - check that its not a case of textbuffer observing visualtextbuffer observering textbuffer.. (seems unlikely, doesn't explain why its not seen on gcc3/omni4 systems) - rebuild omni4 with gcc2.9x -> test - rebuild omni3 with gcc3 (if it does?!) -> test I might have time to try the omni4/2.9x combo; perhaps kent could try the latter too. An arch-wizard could look at whether there's a valid reason for it blocking :)
Thanks for tracking this down into the VisualTextBuffer! Now, what shall we do about it? I don't really like the code and am in fact reworking the complete bidirectional-handling. The new code cannot really do what the current one is supposed to do yet, but it allready has a couple of bugs fixed. The main goal of this rework is to get most of the code out of the VisualTextBuffer and into Babylon, turning the VTB into a wrapper around Babylon instead of it doing the bidir-handling all lone.
I don't see what neiljp sees, but I managed to trigger this quite accidentally when looking for something else. I loaded the pinyin-demo and then clicked on the "Input:" entry box and tried to type. The server froze such that the mouse didn't work and when I gdb'd it, I found that it was stuck in SubjectImpl::notify. The call trace shows the TextBuffer hanging in the attempt to notify an Observer and holding up the main Event/ScreenManager thread: (gdb) bt #0 0x402d0831 in _0RL_lcfn_9a8225d1cab19e95_10000000(omniCallDescriptor*, omniServant*) () from /home/nicholas/Fresco/lib/libFresco.so #1 0x40550f10 in omni::omniOrbPOA::dispatch(omniCallDescriptor&, omniLocalIdentity*) () from /usr/lib/libomniORB4.so.0 #2 0x4053784c in omniLocalIdentity::dispatch(omniCallDescriptor&) () from /usr/lib/libomniORB4.so.0 #3 0x405445f7 in omniObjRef::_invoke(omniCallDescriptor&, bool) () from /usr/lib/libomniORB4.so.0 #4 0x402d08a3 in Fresco::_objref_Observer::update(CORBA::Any const&) () from /home/nicholas/Fresco/lib/libFresco.so #5 0x40873d11 in SubjectImpl::notify(CORBA::Any const&) (this=0x8be9b78, change=@0xbefff3bc) at /usr/include/omniORB4/templatedecls.h:416 #6 0x40873fe4 in virtual thunk to SubjectImpl::notify(CORBA::Any const&) () at ../include/Berlin/SubjectImpl.hh:36 #7 0x40c498c8 in TextBufferImpl::insert_char(unsigned short) (this=0x8be9b78, u=97) at TextBufferImpl.cc:161 #8 0x40c4a539 in virtual thunk to TextBufferImpl::insert_char(unsigned short) () at TextBufferImpl.hh:36 #9 0x402838af in _0RL_lcfn_adc5d68713ae794a_80000000(omniCallDescriptor*, omniServant*) () from /home/nicholas/Fresco/lib/libFresco.so #10 0x40550f10 in omni::omniOrbPOA::dispatch(omniCallDescriptor&, omniLocalIdentity*) () from /usr/lib/libomniORB4.so.0 #11 0x4053784c in omniLocalIdentity::dispatch(omniCallDescriptor&) () from /usr/lib/libomniORB4.so.0 ---Type <return> to continue, or q <return> to quit--- #12 0x405445f7 in omniObjRef::_invoke(omniCallDescriptor&, bool) () from /usr/lib/libomniORB4.so.0 #13 0x40283918 in Fresco::_objref_TextBuffer::insert_char(unsigned short) () from /home/nicholas/Fresco/lib/libFresco.so #14 0x411a917e in Berlin::ToolKit::TextInput::key_press(Fresco::Input::Event const&) (this=0x8ba50e8, event=@0x4c92d530) at /usr/include/omniORB4/templatedecls.h:416 #15 0x40862b94 in ControllerImpl::handle_non_positional(Fresco::Input::Event const&) (this=0x8ba50e8, event=@0x4c92d530) at ControllerImpl.cc:425 #16 0x40863677 in virtual thunk to ControllerImpl::handle_non_positional(Fresco::Input::Event const&) () at ../include/Berlin/ControllerImpl.hh:40 #17 0x402d5c9c in _0RL_lcfn_0d9567ea8dd9475c_12000000(omniCallDescriptor*, omniServant*) () from /home/nicholas/Fresco/lib/libFresco.so #18 0x40550f10 in omni::omniOrbPOA::dispatch(omniCallDescriptor&, omniLocalIdentity*) () from /usr/lib/libomniORB4.so.0 #19 0x4053784c in omniLocalIdentity::dispatch(omniCallDescriptor&) () from /usr/lib/libomniORB4.so.0 #20 0x405445f7 in omniObjRef::_invoke(omniCallDescriptor&, bool) () from /usr/lib/libomniORB4.so.0 #21 0x402d5d01 in Fresco::_objref_Controller::handle_non_positional(Fresco::Input::Event const&) () from /home/nicholas/Fresco/lib/libFresco.so #22 0x4087233f in NonPositionalFocus::dispatch(Fresco::Input::Event&) ( this=0x82e39e8, event=@0x4c92d530) at /usr/include/omniORB4/templatedecls.h:416 ---Type <return> to continue, or q <return> to quit--- #23 0x4086ba8d in EventManager::next_event() (this=0x0) at /usr/include/c++/3.2/bits/stl_vector.h:335 #24 0x4086ac8b in ScreenManager::run() (this=0x82f22c8) at ScreenManager.cc:154 #25 0x4086a963 in ScreenManager::run_thread(void*) (X=0x82f22c8) at ScreenManager.cc:128 #26 0x40084916 in Prague::Thread::start(void*) (X=0x82f22f8) at Sys/Thread.cc:135 #27 0x400add53 in pthread_start_thread () from /lib/libpthread.so.0
Strange but true: The TermDemo works agian for me. I haven't changed anything... did someone else fix this? I get a different behaviour wrt. the pinyin-demo too: That just aborts while creating some graphics for me.
The pinyin demo is broken for me too; I can't trigger the same bug as before, but I've now migrated to gcc3...
I have split out the pinyin demo part of this report into bug276. I'll close this bug now since there no longer is a VisualTextBuffer. I still love that idea, unfortunately it does not stand up to the reality check. We won't get around doing all the reordering in the actual renerer.
not logged in
register
Home