Just wanted to say: nice analysis! I'd not have found that stuff - really sounds like that could be the basis for the problem...
> Peeter: can you make an STR for this so we can track it? > I think I can confirm it's something we need to fix > in Fl_cocoa.mm. > > This way you'll be notified of fixes as they happen. > > In the mean time, a little investigation: > > Peeter, I'm guessing your app uses the fltk method add_fd(), > as this triggers FLTK to internally use the DataReady class, > which starts a child thread running the DataReadyThread() > method to: > > a) monitor the fd with select(2) > b) send the custom event when data is ready > to wake up FLTK to run the add_fd() callback. > > I wrote that code a long time ago (2004), and some years > later Manolo ported it to cocoa/objective C, so probably > the two of us needs to look at it. > > Afraid I don't know objective C myself, but given your > stack dump, looks like it's something to do with one of > the objective C memory allocation calls, probably "NSAutoReleasePool". > > Could be some issue with that call not being thread safe > or something is missing in the use of it. > > Manolo: perhaps you can weigh in on this? > > The code for the method DataReady::DataReadyThread() (in Fl_cocoa.mm) > runs entirely in the context of a child thread. So anything we do > in that method has to be thread safe. > > I looked at the docs for 'NSAutoReleasePool' and it has a section > on "Threads" which has a special note about POSIX threads (which we use): > > Note: If you are creating secondary threads using the POSIX thread > APIs instead of NSThread objects, you cannot use Cocoa, including > NSAutoreleasePool, unless Cocoa is in multithreading mode. > Cocoa enters multithreading mode only after detaching its first > NSThread object. To use Cocoa on secondary POSIX threads, your > application must first detach at least one NSThread object, > which can immediately exit. You can test whether Cocoa is > in multithreading mode with the NSThread class method isMultiThreaded. > > I'm guessing we need to take this advice, either: > > 1) Use NSThread instead of pthreads() > > - OR - > > 2) Do what the above docs advise, and just start a quick > NSThread() during the first use of Add_FD() so that our > use of posix threads will work properly, given the above warning. > > I'm pretty sure that's the issue. > > Peeter: as a quick workaround, can I advise that at the top of your main() > function, before doing anything else, create a simple thread using > NSThread() > that does nothing (simply returns). > > I think by doing this, it will do as the above recommends, triggering > whatever internal bookkeeping OSX wants to prevent the leak. > > Doing this should be safe to do, even when we eventually fix the > problem. > > Please open the STR with just your initial post, and I'll follow up > with the above details, and me and Manolo will chime in when we have > a fix to the code. I want you to open the STR so that you'll receive > emails as the fixes progress. > SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
