error when return 0; in int main()w

This is a discussion on error when return 0; in int main()w within the C++ Programming forums, part of the General Programming Boards category; Here is the report from valgrind: Code: ==9371== Invalid read of size 4 ==9371== at 0x8050C4A: main (entropy.cpp:105) ==9371== Address ...

  1. #16
    Registered User
    Join Date
    Jun 2008
    Posts
    106
    Here is the report from valgrind:

    Code:
    ==9371== Invalid read of size 4
    ==9371==    at 0x8050C4A: main (entropy.cpp:105)
    ==9371==  Address 0x4a150f4 is 0 bytes after a block of size 396 alloc'd
    ==9371==    at 0x4024025: operator new(unsigned) (vg_replace_malloc.c:224)
    ==9371==    by 0x8055723: std::vector<int, std::allocator<int> >::_M_fill_insert(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, unsigned, int const&) (new_allocator.h:91)
    ==9371==    by 0x8050B09: main (stl_vector.h:653)
    k = 29
    k = 30
    k = 31
    k = 32
    k = 33
    k = 34
    k = 35
    k = 36
    k = 37
    k = 38
    k = 39
    k = 40
    k = 41
    k = 42
    k = 43
    k = 44
    k = 45
    k = 46
    k = 47
    k = 48
    k = 49
    k = 50
    k = 51
    k = 52
    OK
    P(F,C) done
    ==9371== 
    ==9371== ERROR SUMMARY: 224 errors from 1 contexts (suppressed: 28 from 1)
    ==9371== malloc/free: in use at exit: 0 bytes in 0 blocks.
    ==9371== malloc/free: 707,923 allocs, 707,923 frees, 2,107,823,781 bytes allocated.
    ==9371== For counts of detected errors, rerun with: -v
    ==9371== All heap blocks were freed -- no leaks are possible.
    mockset # 
    mockset # valgrind --leak-check=yes entropy spec.json x3-truth-map.txt *h5 -v
    ==9374== Memcheck, a memory error detector.
    ==9374== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
    ==9374== Using LibVEX rev 1854, a library for dynamic binary translation.
    ==9374== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
    ==9374== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
    ==9374== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
    ==9374== For more details, rerun with: -v
    ==9374== 
    ... Indexing truthmap ... OK
    terminate called after throwing an instance of 'std::length_error'
      what():  basic_string::resize
    ... Indexing filenames ... ==9374== 
    ==9374== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1)
    ==9374== malloc/free: in use at exit: 791,127 bytes in 21,938 blocks.
    ==9374== malloc/free: 133,693 allocs, 111,755 frees, 9,435,638 bytes allocated.
    ==9374== For counts of detected errors, rerun with: -v
    ==9374== searching for pointers to 21,938 not-freed blocks.
    ==9374== checked 988,264 bytes.
    ==9374== 
    ==9374== 5,820 bytes in 116 blocks are possibly lost in loss record 26 of 31
    ==9374==    at 0x40237F9: malloc (vg_replace_malloc.c:207)
    ==9374==    by 0x40F6474: H5FL_malloc (in /prog/lib/hdf5-1.8.1/hdf5/lib/libhdf5.so.5.0.1)
    ==9374== 
    ==9374== 
    ==9374== 386,444 bytes in 9,887 blocks are possibly lost in loss record 31 of 31
    ==9374==    at 0x4024025: operator new(unsigned) (vg_replace_malloc.c:224)
    ==9374==    by 0x43519F0: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.9)
    ==9374==    by 0x4352CF4: (within /usr/lib/libstdc++.so.6.0.9)
    ==9374==    by 0x4352EA6: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.9)
    ==9374==    by 0x808449C: __static_initialization_and_destruction_0(int, int) (in /prog/igor/src/entropy/entropy)
    ==9374==    by 0x8084504: _GLOBAL__I__ZN2H59Exception11DEFAULT_MSGE (in /prog/igor/src/entropy/entropy)
    ==9374==    by 0x80A2DB4: (within /prog/igor/src/entropy/entropy)
    ==9374==    by 0x804E24B: (within /prog/igor/src/entropy/entropy)
    ==9374==    by 0x80A2D58: __libc_csu_init (in /prog/igor/src/entropy/entropy)
    ==9374==    by 0x4446330: (below main) (in /lib/libc-2.7.so)
    ==9374== 
    ==9374== LEAK SUMMARY:
    ==9374==    definitely lost: 0 bytes in 0 blocks.
    ==9374==      possibly lost: 392,264 bytes in 10,003 blocks.
    ==9374==    still reachable: 398,863 bytes in 11,935 blocks.
    ==9374==         suppressed: 0 bytes in 0 blocks.
    ==9374== Reachable blocks (those to which a pointer was found) are not shown.
    ==9374== To see them, rerun with: --leak-check=full --show-reachable=yes

  2. #17
    Registered User
    Join Date
    Jun 2008
    Posts
    106
    Quote Originally Posted by elninio View Post
    Code:
    map<string, int> Fmap;
    vector<map<string,int> > kFmap;
    
    cout << "... Indexing feature-values ... ";
    for (unsigned int k = 0; k < spec.features.size(); k++){
      //Fmap.resize(spec.features.size());
      for (int i = 3; i <= argc; i++){
        dataset_loader loader(argv[i]);
        Fmap[namesmap[i]] = spec.features[k].load(loader);
      }
      kFmap[k] = Fmap;
      Fmap.empty();
    }
    cout << "OK" << endl;
    this one gave a seg fault

    have also tried:

    Code:
    map<string, int> Fmap;
    vector<map<string,int> > kFmap;
    
    cout << "... Indexing feature-values ... ";
    for (unsigned int k = 0; k < spec.features.size(); k++){
      //Fmap.resize(spec.features.size());
      for (int i = 3; i <= argc; i++){
        dataset_loader loader(argv[i]);
        Fmap[namesmap[i]] = spec.features[k].load(loader);
      }
      kFmap.push_back(Fmap);
      Fmap.empty();
    }
    cout << "OK" << endl;
    this one worked, but I'm afraid it has been done incorrectly, because after I execute a similar loop following this, my program breaks RIGHT AFTER the "cout << "OK" << endl; of the 2nd block of code posted ABOVE. Here is the THIRD block of code that follows the SECOND (the FIRST is no longer in the picture):

    [
    Code:
    // Index P(F) matrices
    cout << "... Indexing P(F) matrices ...";
    vector<vector<int> > kF;
    vector<int> F;
    for (unsigned int k = 0; k < spec.features.size(); k++){
      F.resize(spec.features[k].max_val());
      for (int i = 3; i <= argc; i++){ 
        F[kFmap[k][namesmap[i]]]++;
      }
      kF.push_back(F);
      F.clear();
      cout << "k = " << k << endl;
    }
    cout << "OK" << endl;
    	
    for (unsigned int i = 0; i < kF.size(); i++){
      for (unsigned int j = 0; j < kF[i].size(); j++){
        cout << kF[i][j] << " ";
      }
      cout << endl;
    }
    for this part of code, the program runs all of this code, but then gives me the *** glibc detected *** entropy: free(): invalid next size (normal): 0x0875ccb0 *** error. When i remove

    Code:
    for (unsigned int i = 0; i < kF.size(); i++){
      for (unsigned int j = 0; j < kF[i].size(); j++){
        cout << kF[i][j] << " ";
      }
      cout << endl;
    }
    from code the third code block, it runs about halfway (k = 32, but k=53 normally), and gives *** glibc detected *** entropy: munmap_chunk(): invalid pointer: 0x08752d88 ***
    could this be the problem right here: F[kFmap[k][namesmap[i]]]++; (this is in the 3rd block of code i posted)

    I'm assuming that when a vector is resized, its entries are initialized to zero? Is this not the case

  3. #18
    Registered User
    Join Date
    Jun 2008
    Posts
    106
    AHHHH! *throws chair*

    ok this was the problem:

    F.resize(spec.features[k].max_val()); i changed it to ...max_val() + 1)

    i guess its true, off by one errors are the most common!

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,401
    Quote Originally Posted by elninio
    wouldn't this not process the last file I pass as parameter? thats what i was refering to in my reply.
    No, the last filename would be at argv[argc-1], assuming argc > 3 (argc <= 3 implies no filenames were provided).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Fmap.empty();
    This function doesn't do what you think it does. You're looking for clear().
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How can I make this code more elegant?
    By ejohns85 in forum C++ Programming
    Replies: 3
    Last Post: 04-02-2009, 08:55 AM
  2. can some one please tell me the cause of the error ?
    By broli86 in forum C Programming
    Replies: 8
    Last Post: 06-26-2008, 08:36 PM
  3. Debug Error Really Quick Question
    By GCNDoug in forum C Programming
    Replies: 1
    Last Post: 04-23-2007, 12:05 PM
  4. Working with random like dice
    By SebastionV3 in forum C++ Programming
    Replies: 10
    Last Post: 05-26-2006, 09:16 PM
  5. Half-life SDK, where are the constants?
    By bennyandthejets in forum Game Programming
    Replies: 29
    Last Post: 08-25-2003, 11:58 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21