While we are on the discussion, i noticed that my slpd daemon configured as SA is taking registrations from outside (there are DAs in the n/w). That sounds wrong! I think SA should not take registrations from DA's right?
Regards, Varun On Wednesday, August 03, 2011 02:58:57 pm Hird Matthew wrote: > Varun > > How many nodes do you have in your system? also, how long are your scope > names? I've found a bug in slpd_process.c which is related to these areas > and causes the daemon to segfault. As soon as we hit 50 DAs, all the SLP > daemons seg faulted at the same time. I have a fix which I'll submit shortly > but you could just up that buffer to 8192 as a temporary test. > > What happens is that when a search is performed on a node, the slptool asks > the daemon for a list of it's known scopes via a 'backdoor'. the daemon > builds up a list of known DAs from it's database and returns them all in the > form of a DAAdvert. This will vary in size according to your scope name and > IP address but each advert is in the order of 70-100 bytes, assuming a scope > name of less than 10 chars. It puts it's own local loopback address in at > the start of the list and a terminating DAAdvert at the end so you're down > to ~3936 bytes straight off. Assuming a DAAdvert size of ~80 bytes, means > you can only fit 49/50 DAs in the list. Obviously, if you have a very scope > name, even less. > > could this be the problem you're seeing? > > Like I said, I'll fix the code to dynamically size the buffer to something > appropriate and submit the patch soon. > > cheers > Matt > > > _____ > > From: Nick Wagner [mailto:ne...@wingedbeast.org] > Sent: 02 August 2011 03:29 > To: Richard Morrell > Cc: openslp-devel@lists.sourceforge.net > Subject: Re: [Openslp-devel] Segfault Seen In Latest Openslp > > > Yes, I didn't spot what you were doing until after I sent the email. I've > never done that trick inside of a union -- I wouldn't think so, but is it > possible some compiler optimization is getting in the way? Varun, what kind > of compiler/environment are you using? > > --Nick > > > On Mon, Aug 1, 2011 at 1:51 PM, Richard Morrell <r.morr...@hotmail.com > <mailto:r.morr...@hotmail.com> > wrote: > > > This seems to be in the code I added while at Thales. > > I left there recently, and am just getting myself set back up to have access > to > the source and mailing lists from home rather than work. > > Any further information on this ? > > > > See comments below. > > > > >On 07/28/2011 03:40 AM, Varun Chandramohan wrote: > >> On Thursday, July 28, 2011 12:51:47 am Nick Wagner wrote: > >>> The SLPDPredicateTreeNode structure does seem to have a problem. If we > left > > > >>> the larger-sized array, guards should still be added to ensure that > neither > >>> strncpy will step off the end of the member 'storage'. Others may have > >>> differing opinions, but I'd change storage to be a char* and alloc it to > the > > > >>> right size (tag_len + value_len + terminating nulls), as long as we make > >>> sure that it's freed appropriately. We're allocating all the nodes in > the > >>> tree anyway. > >>> > > > >>> --Nick > >>> > >> I think we can do that. If all are ok with it, can we make this change? > >It seems that the extra space for the attributes is already taken care > >of in allocating the memory for ppNode (slpd_predicate:1645). So Nick's > > > >proposed change shouldn't be necessary. But we still need to find out > >why it doesn't work properly yet... > > > Agreed. The assumption was that "storage" was allocated as the last > structure > > > member at the end of the structure, and is initially two bytes long to allow > for > the trailing NUL characters at the end of each of the tag and value strings. > The > space allocated is increased by lhs_len+rhs_len to allow for the storage of > the > > > strings. This is so that you don't need to worry about separately allocating > and > de-allocating storage for the (usually short) tag and value strings. > > It works fine for me using the latest trunk source built on Linux Mint 7 > > > x86_64. Can we get any more information from the failure ? How repeatable > is > it ? Can you generate a core file and get information like the values of > lhs_len > and rhs_len, operator, and *ppNode at the point of failure using gdb ? > > > > >Can we be certain that the 'storage' field is actually exactly at the > >end of the SLPPredicateTreeNode structure? > Even if it wasn't, it shouldn't cause a segmentation fault, although it > would > > > overwrite any structure members allocated following it. > > > > > >BR, > > Roel > >> > >> - Varun > >> > >>> On Wed, Jul 27, 2011 at 1:27 AM, Varun Chandramohan< > > >>> varunc@...> wrote: > >>> > >>>> ** > >>>> > >>>> Hi Folks, > >>>> > >>>> The test team reported a bug. Iam pasting the bug analysis. They seem > to > > > >>>> have found the problem as well with a temporary fix. However i they > want our > >>>> opinion on the fix. Please advice. > >>>> > >>>> Using the following command: > > > >>>> > >>>> slptool findsrvs service:test$ID "(foo=value1)" > >>>> > >>>> this will generat the overflow in createPredicateParseTree doing an > strncpy - > >>>> > > > >>>> line 1656 slpd_predicate.c > >>>> > >>>> When reading the comments around "operator" it appears it is using > the operator > >>>> > >>>> 2 characters as a place to copy the attribute name. The attribute name > can be > > > >>>> > >>>> very large. This is the code: > >>>> > >>>> /* Finished with "operator" now - just use as temporary pointer > to assist > >>>> > > > >>>> with copying the > >>>> > >>>> * attribute name (lhs) and required value (rhs) into the node > >>>> > >>>> */ > >>>> > >>>> operator = (*ppNode)->nodeBody.comparison.storage; > > > >>>> > >>>> strncpy(operator, lhs, lhs_len); > >>>> > >>>> operator[lhs_len] = '\0'; > >>>> > >>>> operator is now the pointer of "storage" in: > > > >>>> > >>>> slpd_predicate.h > >>>> > >>>> typedef struct __SLPDPredicateTreeNode > >>>> > >>>> { > >>>> > >>>> SLPDPredicateTreeNodeType nodeType; > > > >>>> > >>>> struct __SLPDPredicateTreeNode *next; /* next node in a > combination */ > >>>> > >>>> union { > >>>> > >>>> struct __SLPDPredicateLogicalBody > > > >>>> > >>>> { > >>>> > >>>> struct __SLPDPredicateTreeNode *first; > >>>> > >>>> } logical; > >>>> > >>>> struct __SLPDPredicateComparisonBody > > > >>>> > >>>> { > >>>> > >>>> size_t tag_len; > >>>> > >>>> char *tag_str; > >>>> > >>>> size_t value_len; > > > >>>> > >>>> char *value_str; > >>>> > >>>> char storage[2]; > >>>> > >>>> } comparison; > >>>> > >>>> } nodeBody; > > > >>>> > >>>> } SLPDPredicateTreeNode; > >>>> > >>>> Copying of attributes onto 2char array fails though doesn't fail in > older > >>>> > >>>> builds so I am not sure if build options or strictness has changed. > > > >>>> > >>>> Since there were no cleanup routines if the pointer was malloced, I > just > >>>> > >>>> increased --> storage[200] and the testcase runs without fail and the > area will > > > >>>> > >>>> get freed with the structure. > >>>> > >>>> Is this the best way out? > >>>> > >>>> Regards, > >>>> > > >>>> Varun > >>>> > >>>> > >>>> > >>>> > ---------------------------------------------------------------------------- > -- > >>>> Got Input? Slashdot Needs You. > > > >>>> Take our quick survey online. Come on, we don't ask for help often. > >>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek. > >>>> http://p.sf.net/sfu/slashdot-survey > <http://p.sf.net/sfu/slashdot-survey> > > > >>>> _______________________________________________ > >>>> Openslp-devel mailing list > >>>> Openslp-devel@... > > >>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel > <https://lists.sourceforge.net/lists/listinfo/openslp-devel> > > > >>>> > >>>> > >> > ---------------------------------------------------------------------------- > -- > >> Got Input? Slashdot Needs You. > >> Take our quick survey online. Come on, we don't ask for help often. > > > >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. > >> http://p.sf.net/sfu/slashdot-survey <http://p.sf.net/sfu/slashdot-survey> > > >> _______________________________________________ > > > >> Openslp-devel mailing list > >> Openslp-devel@... > > >> https://lists.sourceforge.net/lists/listinfo/openslp-devel > <https://lists.sourceforge.net/lists/listinfo/openslp-devel> > > > ---------------------------------------------------------------------------- > -- > BlackBerry(r) DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 <http://p.sf.net/sfu/rim-blackberry-1> > _______________________________________________ > Openslp-devel mailing list > Openslp-devel@lists.sourceforge.net > <mailto:Openslp-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/openslp-devel > <https://lists.sourceforge.net/lists/listinfo/openslp-devel> > > > > > > This email, including any attachment, is a confidential communication > intended solely for the use of the individual or entity to whom it is > addressed. It contains information which is private and may be proprietary > or covered by legal professional privilege. If you have received this email > in error, please notify the sender upon receipt, and immediately delete it > from your system. > > Anything contained in this email that is not connected with the businesses > of this company is neither endorsed by nor is the liability of this company. > > Whilst we have taken reasonable precautions to ensure that any attachment to > this email has been swept for viruses, we cannot accept liability for any > damage sustained as a result of software viruses, and would advise that you > carry out your own virus checks before opening any attachment. > > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
