[vox-tech] a "Bus Error" C++ issue, platform, compiler or STL?

[Brian Lavender]

Well f == 1111 1111 in binary, so that's an odd number.

0xba7bfff == 195543039

I believe it's like putting your foot into a shoe and forcing your toes
through the end. It just doesn't make sense.  I imagine that you need
to be on a modulus of 4 boundary or depending upon your datatype some
other even modulus. It looks like that memory address you have there
would only work if you were storing a char (1 8bit datatype).

Unless, you made memory with a decoder that would just lay it over 
wherever you wanted it! 

brian

On Tue, Aug 24, 2010 at 10:17:16PM -0400, Hai Yi wrote:
> Thanks Jeff and Bill.
> Jeff, how do you know that the value,0xba7bfff, is corrupted? Because
> it's only 3.5 bytes? Could it be possible a value with zero stripped?
> Also, what's the mapping of the argument list b/w the code and that in
> the stack?
> 
> Thanks again!
> Hai
> 
> 
> On Tue, Aug 24, 2010 at 7:05 AM, Hai Yi <yihai2004 at gmail.com> wrote:
> > ---------- Forwarded message ----------
> > From: Bill Broadley <bill at broadley.org>
> > Date: Tue, Aug 24, 2010 at 3:44 AM
> > Subject: Re: [vox-tech] a "Bus Error" C++ issue, platform, compiler or STL?
> > To: vox-tech at lists.lugod.org
> >
> >
> > On 08/23/2010 05:43 PM, Hai Yi wrote:
> >> Hello All:
> >>
> >> I'm on a C++ project and have been strugling with an "Bus Error" issue
> >> for a couple of weeks. I used dbx to debug the code and here is the
> >> stack:
> >> ...
> >> ficc_trade_leg::set_trailer1(const string&  arg)
> >> df_string_tuple::df_string_tuple(0x1ae5180, 0xffbea53c, 0xfd578ac0,
> >> 0x0, 0x18, 0x0)
> >> basic_string,allocator>::basic_string,allocator>(0x1ae518c,
> >> 0xfd578ac0, 0xffbea540, 0xff3de7a8, 0x0, 0x5)
> >> string_ref,allocator>::references(0xba7bfff, 0x0, 0x8, 0xfb9c1e54, 0x0, 0x0)
> >>
> >>
> >> set_trailer1 is creating an instance of df_string_tuple, whose
> >> constructor looks like
> >>
> >> df_string_tuple::df_string_tuple(const df_tag&  Tag, const string&
> >> Value): df_tuple(Tag), Value_(Value)
> >> {}
> >>
> >> It seems to me that debugger nailed down to the 2nd parameter of the
> >> above constructor. Isn't it more likely an issue of Solaris patch, C++
> >> compiler or STL lib rather than a coding issue?
> >
> > Most of the bugs I've seen with STL code have been of the variety of
> > assuming that when you resize something, say a vector, that the
> > programmer assumes STL is doing the memory allocation for the new array,
> > and the STL lib of course is assuming the programmer is doing the memory
> > allocation.  Resulting in usually a segmentation fault.  It's been a
> > very long time since I've tried anything on SunOS or the embarrassing
> > excuse of a compiler that sun ships.  Most of the open source I played
> > with back when 5.8 was somewhat new said something along the lines of:
> > * Do not use solaris tar it's buggy
> > * Do not use solaris make it's buggy
> > * Do not use solaris compiler it's buggy (here's binaries to bootstrap
> >   gcc).
> >
> > Not sure if the solaris bus error is the equivalent of the linux segfault.
> >
> >> My platform is SunOS 5.8, not sure about the STL lib or CC compiler.
> >
> > If possible I'd recommend trying the same code in a standard linux
> > environment.  The newer gcc compilers seem to have improvement C++ error
> > messages quite a bit.
> >
> > I suspect if you asked someone could set you up with a linux account if
> > need be.
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech at lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox-tech
> >
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

-- 
Brian Lavender
http://www.brie.com/brian/

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."

Professor C. A. R. Hoare
The 1980 Turing award lecture