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

[Hai Yi]

thanks to all:

This is the update. My project is depending on a few home grown
libraries in the company, some were released many yrs ago. Basically,
most if not all libs are built on the top a distributed framework
underlied by tibco RV5 /RV7 tranport layer. These libs have their own
auto generated code from this framework, which is similar to RMI; also
these systems are built and versioned, something like CVS repo.
Anyway, I noticed that my project and the libs that I suppose have
such a auto generated class with same name but different namespace;
the system picks up the first one it encounter and mistakenly use the
api in the second. Still, this is only my best guess.

I made some change accordingly, and the bus error is gone.

This is problem of working on a project which has too many
dependencies which are not well tested - you try to debug your code
but end up hacking into other system, :-(

Thanks again for all interest,
Hai


On Wed, Aug 25, 2010 at 3:22 AM, Bill Broadley <bill at broadley.org> wrote:
> On 08/24/2010 07:17 PM, 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?
>
> You are the one with the strange compiler and over 10 year old OS.  I'd
> suggest debugging a known working code and check out the mapping
> yourself.  Debug a working program, look at the stack before and faster
> function calls, track the function parameters, dereference some pointers.
>
> Bus errors, segmentation faults, core dumps and the like are usually
> memory errors, I'd check all of the following:
> * Return values, especially on any allocation
> * Make sure memory is free once, and exactly once.  (double frees are
>   common)
> * Make sure you are using STL allocation and resize functions correctly,
>   at least some of the time they depend on the user doing the memory
>   allocation.
> * Learn to recognize pointers, look at a few 1000, you didn't mention
>   if the OS was 64 bit or 32 bit.
>
> Keep in mind corruptions can propagate, memory protection is on the page
> boundaries.  So you can have quite a few corruptions before you cross a
> boundary.  You might have trashed the stack and not notice
> till later.
>
> Again I'd suggest running it in a different environment, try a newer g++
> with -Wall -pedantic it might well just point to something that you are
> doing is illegal, ill advised, or undefined.
>
>
>
>
>>
>> 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
>
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>