[Top][All Lists]

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

Re: Question

From: Chuck Robey
Subject: Re: Question
Date: Fri, 15 May 1998 23:51:39 -0400 (EDT)

On Fri, 15 May 1998, John W. Eaton wrote:

> On 15-May-1998, Chuck Robey <address@hidden> wrote:
> | On Fri, 15 May 1998, John W. Eaton wrote:
> | 
> | > The compiler is supposed to insert the string constructor
> | > automatically.  I'd suspect that at least that part is correct.
> | 
> | When I ran gdb, and tried to read the passed variable, it told me
> | incomplete type.  That's why I thought maybe it had been constructed
> | wrong, and the ref value was wrong (it might be trying to free a class
> | instance that hadn't been created).  The constructor is NOT called,
> | according to gdb.
> What version of gdb are you using?
> When gdb says incomplete type, it usually means that for some reason
> it doesn't have enough information.  Was your libstdc++ compiled with
> debugging symbols?

I recompiled libstdc++ with debugging symbols, and I have gotten much
further.  First, my libstdc++ is in sync, I checked.  I don't load these
things myself, I run a full cvs archive of FreeBSD-current here, and I
was able to verify via cvs-log that it was a virgin import from the gnu
sources, with no patches.

FreeBSD is (historically and notoriously) slow to upgrade the compiler,
until new versions have a good track record.  My guess is that the
upgrade to 2.8.x is at least 3 months away, and I would not be surprised
to find it happens early next year, because the furious pace of locally
inspired changes will not allow too much other instability in the tree
right away.

I've done more investigation.  The SIGBUS occurs in line 198 of
octave.cc (ddd cut'n'paste):

    196 #endif
    198   Vprogram_invocation_name = name;
    199   size_t pos = Vprogram_invocation_name.rfind ('/');
    200   Vprogram_name = (pos == NPOS)

This calls, indirectly, to libstdc++/std/bastring.cc line 147:

    146 // _lib.string.cons_ construct/copy/destroy:
    147   basic_string& operator= (const basic_string& str)
    148     {
    149       if (&str != this) { rep ()->release (); dat = str.rep()->grab (); 
    150       return *this;
    151     }

The release function is in bastring.h line 69:

     67   charT& operator[] (size_t s) { return data () [s]; }
     68   charT* grab () { if (selfish) return clone (); ++ref; return data 
     69   void release () { if (--ref == 0) delete this; }
     71   inline static void * operator new (size_t, size_t);

I'm not sure about this, but on entering the function, ref is 1, and
that's the value of this.ref, right?  (understand please that I could be
stronger perhaps in C++, sorry).  It _looks_ like "this" is being
deleted, then immediately referenced, which would sure cause the SIGBUS.

Does this make sense?

Chuck Robey                 | Interests include any kind of voice or data 
address@hidden         | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770         | I run Journey2 and picnic (FreeBSD-current)
(301) 220-2114              | and jaunt (NetBSD).

reply via email to

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