l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
November 4: Social gathering
Next Installfest:
TBD
Latest News:
Oct. 24: LUGOD election season has begun!
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?



I don't know, I am guessing, but it is an educated guess, for reasons explained in other email replies by Ken and Brian.

I don't know any details about Solaris compilers or debuggers, but object allocators usually keep a pointer around to memory used for keeping track of unallocated blocks of memory. It is an utter guess that 0xba7bff is at the root of your problem, but if it is then the memory it was loaded from was corrupted earlier in the execution of the program, and you need to find out where/when using some debugging or anti-bugging tools. I have used assembly-level debugging and memory watchpoints in the past, but there are a variety of memory corruption tools out there that might be available to you.

If my guess is wrong, well, the price was right.

"Hai Yi" <yihai2004@gmail.com> 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@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
>vox-tech@lists.lugod.org
>http://lists.lugod.org/mailman/listinfo/vox-tech

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.