Gareth, I sent a quick note to the autoconf mailing list about the use of __USE_UNIX98 in the openslp source code. The answer I got back was "don't do that". Instead I'm to use an autoconf macro AC_USE_SYSTEM_EXTENSIONS, which enables __USE_UNIX98 (when it works) in config.h.
I don't care as much for this approach, as it pollutes preprocessor symbol space with lots of extra system extensions (GNU_SOURCE, POSIX+, etc) that openslp developers may now inadvertently use, but it is the recommended way. I'm copying the list with this note to let the other openslp developers know about this choice. This has been committed in revision 1639. Regards, John On 8/23/2010 1:18 PM, Gareth Lowe wrote: > John, > > Thank you for your prompt response! > > This problem has been discovered at a late stage in our development and > having a fix now should help us keep disruption to a minimum. > > Thanks > > Gareth. > > On 23 Aug 2010, at 18:10, John Calcote wrote: > >> Hi Gareth, >> >> I believe I've fixed your properties issue. You were spot-on, of course, >> in your analysis (thank you very much). Property reinit was intended for >> the server-side only . It's caused by a SIGHUP being sent (manually) to >> slpd, but SIGHUP is probably being caught in the application that >> includes the client library also. This is likely unintentionally >> reloading properties in client apps as well. It will take a bit longer >> to work out this one. >> >> In the mean time - please try SVN rev 1638. I added lock/unlock calls >> around the reinit function in slp_properties.c. I also added a check for >> null on the scope list in the SLPFindSrvs call. >> >> IMPORTANT NOTE TO OPENSLP DEVELOPERS: I needed to add recursion to the >> POSIX mutex implementation in the SLPMutex wrapper (slp_threads.c). This >> would normally not be an issue - it just brings the POSIX implementation >> of SLP mutexes into alignment with the Windows side (CRITICAL_SECTION is >> recursive by default). The potential problem is that I had to make use >> of pthreads constructs that are only available in UNIX98 - thus, I had >> to #define __USE_UNIX98 around the inclusion of pthread.h in slp_types.h. >> >> THIS MAY BREAK CERTAIN OLDER PLATFORMS. >> >> Please keep an eye on things and let me know if this was a dumb thing to >> do. I think UNIX98 is old enough now that we can safely rely on it, but >> you never know... In any case, if we find we're unable to use UNIX98 >> functionality, we can always implement recursion manually in the mutex >> wrapper. >> >> John >> >> On 8/23/2010 1:49 AM, Gareth Lowe wrote: >>> Code base is 2.0.0 and we are currently using Rev 1620 >>> >>> On 23 Aug 2010, at 05:19, John Calcote wrote: >>> >>>> Thanks Gareth - what code base are you using? 2.0? 1.x? The property >>>> code was rewritten between these two versions, so it's important. And >>>> thanks again for the bug report. >>>> >>>> John >>>> >>>> On 8/22/2010 2:18 PM, Gareth Lowe wrote: >>>>> I have submitted a bug: >>>>> https://sourceforge.net/tracker/?func=detail&aid=3050990&group_id=1730&atid=101730 >>>>> >>>>> We have had several crashes when calling SLPFindSrvs. >>>>> >>>>> We are passing a null scope list and the problem occurs in the following >>>>> section of code: >>>>> /* Get a scope list if not supplied. */ >>>>> if (pcScopeList == 0 || *pcScopeList == 0) >>>>> pcScopeList = SLPPropertyGet("net.slp.useScopes", 0, 0); >>>>> >>>>> If pcScopeList is NULL or empty string SLPPropertyGet returns the value >>>>> from the slp.conf file. Sometimes, however, this call returns NULL which >>>>> is unchecked and later on when strlen() is called on the NULL string the >>>>> application will crash. >>>>> >>>>> The first issue is the code assumes the get property will always >>>>> successfully return a string even though it is possible that it can >>>>> return NULL. >>>>> The biggest issue however is why the SLPPropertyGet for >>>>> "net.slp.useScopes" returns NULL when thousands of times previously it >>>>> has returned the correct value. >>>>> >>>>> I believe this is caused by a race condition in the property access. >>>>> Periodically libslp refreshes its properties by first clearing them and >>>>> then reloading them. Modifications and accesses to the property list are >>>>> protected by MUTEXes but clearing and reloading the property list is not >>>>> an atomic action, it is two actions, clearing and reloading. If >>>>> SLPFindSrvs is unlucky enough to be called between these two actions the >>>>> call will crash. >>>>> >>>>> Gareth >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by >>>>> >>>>> Make an app they can't live without >>>>> Enter the BlackBerry Developer Challenge >>>>> http://p.sf.net/sfu/RIM-dev2dev >>>>> _______________________________________________ >>>>> Openslp-devel mailing list >>>>> Openslp-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel >>>>> > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
