hv wrote (in fltk.bugs): > I am seeing a real problem in a quite simple (about 1.5K lines) > C++ app. > > This is an application sampling data at 50 hz from 8 different sensors. > It puts up Fl_Chart objects and plots this data from all the sensors. > Also, it updates Fl_Output objects via their 'value() to reflect > the values from the sensors. > > GDB reports that this is often crashing (as, indeed, the app does....) > with a 'where' trace that looks like this: > > #0 0xb804f430 in __kernel_vsyscall () > #1 0xb7c6c8a0 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7c6e268 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7caa16d in ?? () from /lib/tls/i686/cmov/libc.so.6 > #4 0xb7cb0454 in ?? () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7cb3f4d in ?? () from /lib/tls/i686/cmov/libc.so.6 > #6 0xb7cb4de6 in realloc () from /lib/tls/i686/cmov/libc.so.6 > #7 0xb7f3829c in ?? () from /usr/lib/libX11.so.6 > #8 0xb7f38e45 in ?? () from /usr/lib/libX11.so.6 > #9 0xb7f39055 in XUnionRegion () from /usr/lib/libX11.so.6 > #10 0xb7f391d4 in XUnionRectWithRegion () from /usr/lib/libX11.so.6 > #11 0x08053bf3 in Fl_Widget::damage (this=0x9ac24f8, fl=1 '\001', X=250, Y=70, > W=105, H=25) at Fl.cxx:1191 > #12 0x08053cd8 in Fl_Widget::damage (this=0x9ac24f8, fl=2 '\002') > at Fl.cxx:1135 > #13 0x0805de32 in Fl_Input_::minimal_update (this=0x9ac24f8, p=8) > at Fl_Input_.cxx:157 > #14 0x0805e8cb in Fl_Input_::static_value (this=0x9ac24f8, > str=0xbfd5071c "00:33.677635", len=12) at Fl_Input_.cxx:865 > #15 0x0805e993 in Fl_Input_::value (this=0x9ac24f8, > str=0xbfd5071c "00:33.677635", len=12) at Fl_Input_.cxx:885 > #16 0x0805e9f0 in Fl_Input_::value (this=0x9ac24f8, > str=0xbfd5071c "00:33.677635") at Fl_Input_.cxx:891 > #17 0x0804da8e in HandleAlarmFindPacket (iAlarm=14) at bior_step_1.cpp:1046 > #18 <signal handler called> > #19 0xb804f430 in __kernel_vsyscall () > #20 0xb7d1adf1 in select () from /lib/tls/i686/cmov/libc.so.6 > #21 0x08067dd8 in fl_wait (time_to_wait=1e+20) at Fl_x.cxx:226 > #22 0x0805568c in Fl::wait (time_to_wait=1e+20) at Fl.cxx:372 > #23 0x08055712 in Fl::run () at Fl.cxx:380 > #24 0x0805021c in main (argc=1, argv=0xbfd512b4) at bior_step_1.cpp:744 > > This app is thread enabled via the suitable configure option. It is > linked with the 'audiere' sound playback library. However, as I am > building up a bunch of features just for this prototype, I have > alternate builds of this code that don't link against audiere, > but crash the same way, so I don't think this is the problem. > > The 'HandleAlarmFindPacket()' frame /is/ called as a signal > handler for SIGALRM on a periodic basis. > > This happens pretty often, randomly, about once every ....... > runs, seconds, whatever, hard to predict. > > I am a fairly proficient coder, and have a clean build of my code; > valgrind does not report any real issues on my side of the fence in > terms of leaks. I don't /think/ I am doing anything too out of > bounds, but FL_Output::value() calls, when called a lot, seem to > bug outthe FLTK stack..... > > Any thoughts on where to go with this?
Yes, you ought to replace the SIGALARM timer with a FLTK timer. This gives you the advantage of more portable code and is easy to do. You can use Fl::add_timeout() and Fl::repeat_timeout() to achieve what your SIGALARM timers do. What happens in your program is that you are accessing FLTK (and X11) structures without proper synchronizing. I can't see if you're using threads (you only wrote that your code is thread enabled), but even if you were using threads you would _have_to_ synchronize the access of FLTK structures with Fl::lock(), Fl::awake(), Fl::unlock() and such. The somewhat strange thing is that your crash hits FLTK in its event loop in a wait state. I can only guess that in this case something in the window context isn't set up correctly, while it is (accidently ;-) in other cases, and that's why the crash happens only now and then. But it's not worth thinking about it, because your signal could hit your application at completely different points, and maybe the damage has happened some time before the crash. A second way to synchronize in a proper way would be to use threads and use a worker thread to do the timing and access FLTK functions with proper Fl::lock() calls, but IMHO this would be much more complicated. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
