l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2010 Aug 25 00:23

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] a "Bus Error" C++ issue, platform, compiler or STL?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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!

On Tue, Aug 24, 2010 at 7:05 AM, Hai Yi <yihai2004@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Bill Broadley <bill@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@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@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.