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
