Inconsistent results on two F9 boxes when running a trivial c++ program

Roopnarine, Peter proopnarine at calacademy.org
Fri Sep 26 23:14:11 UTC 2008


Do the boxes have identical g++ installations? Seems like you've encountered
a small bug in the library, which sometimes seem to creep in between minor
revisions.

Peter D. Roopnarine, Assoc. Curator
Dept. of Invertebrate Zoology & Geology
California Academy of Sciences
55 Music Concourse Drive
San Francisco CA 94118
USA

http://zeus.calacademy.org/roopnarine/peter.html
http://www.calacademy.org/blogs
Tel. (415)379-5271
"There's a thing about Americans. We're not very good occupiers." Judgement
at Nuremberg



-----Original Message-----
From: fedora-list-bounces at redhat.com on behalf of Agile Aspect
Sent: Fri 9/26/2008 4:14 PM
To: Community assistance, encouragement,and advice for using Fedora.
Subject: Re: Inconsistent results on two F9 boxes when running a trivial c++
program
 
Steve Searle wrote:
> Can anyone help. Through debugging a program I have created this trivial
> C++ program.
>
>
> #include <iostream>
>
> //int main(int argc, char *argv[]) {
> int main() {
> 	return 0;
> }
>
>
> I have two F9 boxes, both mounting an NFS partition.  When testing the
> program using valgrind, on one box there is no problem.  On the other
> box, it reports an error (full output at the end of this email).  This
> happens regardless of which box the program is compiled on.
>
> If the include line is removed, the error does not happen.
>
> Can anyone give me any pointers as to what the problem could be?
>
> Thanks
>
> Steve
>
> Valgrind output:
>
> $ valgrind ./a.out
> ==12095== Memcheck, a memory error detector.
> ==12095== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==12095== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==12095== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==12095== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
> ==12095== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==12095== For more details, rerun with: -v
> ==12095== 
> ==12095== Invalid free() / delete / delete[]
> ==12095==    at 0x40052EA: operator delete(void*, std::nothrow_t const&)
(vg_replace_malloc.c:354)
> ==12095==    by 0x4215118: std::__verify_grouping(char const*, unsigned,
std::string const&) (locale_facets.cc:108)
> ==12095==    by 0x421604C: std::locale::_Impl::_Impl(char const*, unsigned)
(localename.cc:218)
> ==12095==    by 0x42160CC: std::locale::_Impl::_Impl(char const*, unsigned)
(localename.cc:206)
> ==12095==    by 0x42171F7: std::locale::locale() (basic_string.h:2189)
> ==12095==    by 0x42121CC: std::locale::_Impl::_Impl(std::locale::_Impl
const&, unsigned) (locale.cc:249)
> ==12095==    by 0x804857D: __static_initialization_and_destruction_0(int,
int) (in /tmp/a.out)
> ==12095==    by 0x80485B6: _GLOBAL__I_main (in /tmp/a.out)
> ==12095==    by 0x804864C: (within /tmp/a.out)
> ==12095==    by 0x8048413: (within /tmp/a.out)
> ==12095==    by 0x80485E8: __libc_csu_init (in /tmp/a.out)
> ==12095==    by 0x65F570: (below main) (libc-start.c:179)
> ==12095==  Address 0x42ae188 is not stack'd, malloc'd or (recently) free'd
> ==12095== 
> ==12095== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1)
> ==12095== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==12095== malloc/free: 0 allocs, 1 frees, 0 bytes allocated.
> ==12095== For counts of detected errors, rerun with: -v
> ==12095== All heap blocks were freed -- no leaks are possible.
>
>   

Isn't an invalid free() an error in the following sense that:

       "Address 0x42ae188 is not stack'd, malloc'd or (recently) free'd"

-- 
Article. VI. Clause 3 of the constitution of the United States states: 

"The Senators and Representatives before mentioned, and the Members of 
the several State Legislatures, and all executive and judicial Officers, 
both of the United States and of the several States, shall be bound by 
Oath or Affirmation, to support this Constitution; but no religious Test 
shall ever be required as a Qualification to any Office or public Trust 
under the United States." 


-- 
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5180 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080926/1019f7af/attachment-0001.bin>


More information about the fedora-list mailing list