bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ost::String class release 1.1.1


From: David Sugar
Subject: Re: ost::String class release 1.1.1
Date: Mon, 5 Apr 2004 02:09:37 -0400
User-agent: KMail/1.5.3

The idx[slot] list is a link list sorted by size.  The place to start is first 
to confirm if the slot[idx] is being correctly initialized to NULL, and, in 
the separate place where strings are being deleted, if they are being added 
to the linked list correctly.  This may also be an alignment issue, depending 
on the architecture.  What cpu architecture is this being built on?

On Monday 05 April 2004 01:48 pm, address@hidden wrote:
> David,
>  635 char *String::getSpace(unsigned size)
>  636 {
>  637     unsigned        slot;
>  638     char*           text = NULL;
>  639     char**          next;
>  640
>  641     if(size > slotlimit)
>  642         return new char[size];
>  643
>  644     slot = size / slotsize;
>  645     mutex.enterMutex();
>  646     if(!pager)
>  647     {
>  648         pager = new MemPager(pagesize);
>  649         idx = (char **)pager->alloc(sizeof(char *) * slots);
>  650         memset(idx, 0, sizeof(char *) * slots);
>  651     }
>  652     text = idx[slot];
>  653     if(text)
>  654     {
>  655         next = (char **)text;
>  656         idx[slot] = *next;
>  657     }
>  658     else
>  659         text = (char *)pager->alloc(++slot * slotsize);
>  660     mutex.leaveMutex();
>  661     return text;
>  662 }
>
> Right on line 656.
> slot = 1
> text = 0x32353964 <Address 0x32353964 out of bounds>
> size = 1076041732
>
> I think that size must be way off (duh).  OK, so where'd that come from?
>
>  407 void String::copy(const String &original)
>  408 {
>  409     char *ptr;
>  410     content = original.content;
>  411
>  412     if(!isBig())
>  413         return;
>  414
>  415     if(getLength() < minsize)
>  416     {
>  417         content.ministring.length = getLength();
>  418         memcpy(content.ministring.text, getText(), getLength() + 1);
>  419         content.ministring.big = false;
>  420         return;
>  421     }
>  422
>  423     ptr = getText();
>  424     content.bigstring.size = setSize(content.bigstring.length + 1);
>  425     content.bigstring.text = getSpace(getSize());
>  426     memcpy(content.bigstring.text, ptr, getLength() + 1);
>  427 }
>
> at line 425
> getLength() = 8
> ptr is pointing to a valid string of text.
> content.bigstring.size = 32
>
> Hmm.  Hope that this helps, I'm afraid that I've not studied this String
> class sufficiently to diagnose this at the moment.  Perhaps you'l ahve some
> insights?
>
>       Thanks,
>               Erik.
>
> > -----Original Message-----
> > From: David Sugar [mailto:address@hidden
> > Sent: Monday, April 05, 2004 1:27 AM
> > To: Ohrnberger, Erik; address@hidden
> > Subject: Re: ost::String class release 1.1.1
> >
> >
> > Hmm...
> >
> > text is either assigned from a slot list (linked list) or
> > from mempager
> > alloc'd memory.  If the linked list is messed up, that is one
> > possibility.
> > However, the other option is if the string is too large, a
> > simple new is
> > used, and text is never modified.  Text is not initialized
> > because it does
> > not need a value until it needs to be assigned from the list or from
> > mempager.  Hence, it would help to know more about where
> > precisely this
> > segfault occurs.  One thing you can do is initially set text
> > to NULL at the
> > start of getSpace, as that would make it easier to determine
> > what the real
> > state of text is at the time it happens; whether its before
> > or after it has
> > been assigned by something.
> >
> > On Monday 05 April 2004 12:15 pm, address@hidden wrote:
> > > Everyone,
> > >   I'm noticing instances of seg faults in the
> >
> > ost::String::getSpace()
> >
> > > method, where the *text variable is assigned what appears
> >
> > to be random
> >
> > > garbage, and is yet used as a pointer into some data structure.
> > >
> > >   Has anyone else experienced a similar failure?
> > >
> > >   Is there a patch to the ost::String class that needs to
> >
> > be applied?
> >
> > >   Thanks,
> > >           Erik.
> > >
> > >
> > > _______________________________________________
> > > Bug-commoncpp mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp





reply via email to

[Prev in Thread] Current Thread [Next in Thread]