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 <[email protected]> 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<[email protected]> wrote: >>> ---------- Forwarded message ---------- >>> From: Bill Broadley<[email protected]> >>> Date: Tue, Aug 24, 2010 at 3:44 AM >>> Subject: Re: [vox-tech] a "Bus Error" C++ issue, platform, compiler or STL? >>> To: [email protected] >>> >>> >>> 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 >>> [email protected] >>> http://lists.lugod.org/mailman/listinfo/vox-tech >>> >> _______________________________________________ >> vox-tech mailing list >> [email protected] >> http://lists.lugod.org/mailman/listinfo/vox-tech > > _______________________________________________ > vox-tech mailing list > [email protected] > http://lists.lugod.org/mailman/listinfo/vox-tech > _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
