Re: [Flightgear-devel] Re: fix for exit crash
On Tue, 7 Mar 2006 08:07:00 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Martin Spott -- Monday 06 March 2006 15:17: FreeBSD-5.3: Assertion failed: (status == 0), function ~SGMutex, file /opt/FlightGear/include/simgear/threads/SGThread.hxx, line 227. Abort (core dumped) OK, that's enough proof. This definitely needs to be fixed. If it can't be done cleanly before the release, then we can still comment out the destructors again for a *very* short period. This is a crude hack that mustn't prevail for years again. Less offensive (while still bad) would be to only comment out the triggering ASSERT. What about my solution? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp5PX6oHItb1.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Tue, 7 Mar 2006 09:39:31 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Jean-Yves Lefort -- Tuesday 07 March 2006 09:30: Melchior FRANZ [EMAIL PROTECTED] wrote: If it can'tbe done cleanly before the release, then we can still [...] What about my solution? Oh, true. Still an ugly workaround, but the best of all so far. It's not an ugly workaround, it's the only clean way to ensure portability. According to the test page, no standard requires the C++ stack to be unrolled after a cancellation is received. You can see that the cancellation_exception test is reported to fail on LinuxThreads, OS X, HP-UX, FreeBSD, Solaris and cygwin. BTW: what about the other thread using subsystems (voice, tilemanager)? No problems there? FGVoiceMgr would crash on destruction if you didn't leak _thread (FGVoiceThread::_mutex would then be destroyed while it is still locked by wait_for_jobs()). FGTileLoader would crash if FGGlobals::tile_mgr was destroyed. PS: Can you *please* finally stop to send a CC of everything? I mean, is it not obvious that I'm subscribed here and follow the thread? Netiquette may vary. In the other technical mailing lists I hang on, people copy eachother. I'll try to remember to make an exception for you (please do copy me, btw). -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpK6qhl0qKCd.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ wrote: * Jean-Yves Lefort -- Sunday 05 March 2006 03:06: The attached patch fixes a crash which occurs on exit. Anyone else seeing this crash (which really is a deliberate abort())? Or is it a BSD feature? I've seen this assertion failure at least once on IRIX. I'm not all that certain I has all packages in sync though. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator http://www.cafepress.com/fgfs_flightsim FlightGear Art --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ I'm also getting the very annoying ... leaving my airspace ... crash, which looks very similar. Can you post a backtrace for that? It doesn't happen every time, and it isn't happening right now. The next time it does, I'll try to get a bt. V. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 08:01:54 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: In the FGMetarEnvironmentCtrl destructor, thread-cancel() causes the following thread-join() call to return without actually waiting on the thread (btw, thread-cancel() does not cause the thread to exit). It causes the thread to to be left at the next cancellation point, that would be the wait() in the SGBlockingQueue::pop. So the guarded mutex should automatically be unlocked and the thread left. That's according to the documentation and works here. My initial assumption is wrong. Here's another one: pthread_cancel() does cause the thread to exit, but the C++ destructors are not invoked. The SGGuard destructor can therefore not unlock the mutex. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpBI1B734S1V.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 11:37:21 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Jean-Yves Lefort -- Monday 06 March 2006 11:28: pthread_cancel() does cause the thread to exit, but the C++ destructors are not invoked. The SGGuard destructor can therefore not unlock the mutex. Which destructor is not invoked (apart from the SGGuard one)? ~FGEnvironmentCtrl()? That would be very strange. Are you sure you have SimGear CVS/HEAD? No sticky tags/dates or something? Especially on simgear/structure/subsystem_mgr.cxx, where SGSubsystemGroup::Member::~Member() (line 227) didn't delete the subsystem in past version, but now does. The C++ stack of the cancelled thread is not unrolled. See http://www.slamb.org/projects/cancellation_tests/ -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpQEMCJKnPZ9.pgp Description: PGP signature
