This function extracts and computes the query.keypoints:
// extract features
analyzer->analyze(query);
like this:
bool Analyzer::analyze(Query &query) {
// detect keypoints
query.keypoints.clear();
assert(query.keypoints.empty());
detector->detect(query.grayImage, query.keypoints);
// no keypoints detected!
if (query.keypoints.empty()) {
cout << "no keypoints detected!" << endl;
return false;
}
// compute descriptors
query.descriptors.release();
assert(query.descriptors.empty());
extractor->compute(query.grayImage, query.keypoints, query.descriptors);
// note: keypoints for which a descriptor cannot be computed are removed
if (query.keypoints.empty()) {
cout << "cannot compute keypoints!" << endl;
return false;
}
}
after this i match the query.keypoints with the pattern/training keypoints:
// if analyze() is ok, match descriptors
analyzer->match(query);
Like this:
void Analyzer::match(Query &query) {
assert(!query.descriptors.empty());
// query.matches.clear();
matcher->match(query.descriptors, query.matches);
}
Now i want to analyze the matching set:
double max_dist = 200; double min_dist = 100;
//-- Quick calculation of max and min distances between keypoints
for( int i = 0; i < pattern->descriptors.rows; i++ ) {
double dist = query.matches[i].distance;
if( dist < min_dist ) min_dist = dist;
if( dist > max_dist ) max_dist = dist;
}
//-- Localize the object
std::vector<cv::Point2f> obj;
std::vector<cv::Point2f> scene;
for( int i = 0; i < pattern->descriptors.rows; i++ ) {
if( query.matches[i].distance <= max(2*min_dist, 0.02) ) {
// get keypoints from good matches
// SEGMENTATION FAULT HERE!
// query.matches[i].queryIdx seems to be negative? possible?
cout << query.keypoints[query.matches[i].queryIdx].pt <<endl;
// BASICALLY THIS FAILS
// obj.push_back( pattern->keypoints[ query.matches[i].queryIdx ].pt );
// scene.push_back( query.keypoints[ query.matches[i].trainIdx ].pt );
}
}
But each time i try, i get a Segmentation Fault in the code above on line
// SEGMENTATION FAULT HERE!
// query.matches[i].queryIdx seems to be negative? possible?
cout << query.keypoints[query.matches[i].queryIdx].pt <<endl;
i think that there are missing keypoints. so i am not able to retrieve query.keypoints by queryID.
cv::DMatch match = query.matches[i];
cout << match.queryIdx << endl;
cout << query.matches.size() << endl;
int queryID = match.queryIdx;
cv::KeyPoint test = query.keypoints[queryID]; // FAILS
cout << test.pt << endl;
What i am doing wrong?? I am stucked..! Please enlight me.. ;)
--- EDIT ---
Here is the Valgrind Memcheck output:
[Result] Features: 420; Matches: 181; Time(ms): 757.842
Creating Query instance..
-- Max dist : 224,000000
-- Min dist : 0,000000
==11770== Invalid read of size 4
==11770== at 0x41759C: cv::Point_<float>::Point_(cv::Point_<float> const&) (operations.hpp:1623)
==11770== by 0x41A166: cv::KeyPoint::KeyPoint(cv::KeyPoint const&) (features2d.hpp:69)
==11770== by 0x41AFA2: Controller::detectObject(om::Query&) (Controller.cpp:169)
==11770== by 0x41B9B7: Controller::displayFunction(cv::Mat&, cv::Mat&) (Controller.cpp:261)
==11770== by 0x414909: processVideo() (App.cpp:109)
==11770== by 0x414C4F: main (App.cpp:144)
==11770== Address 0x2c9d9620 is not stack'd, malloc'd or (recently) free'd
==11770==
==11770==
==11770== Process terminating with default action of signal 11 (SIGSEGV)
==11770== Access not within mapped region at address 0x2C9D9620
==11770== at 0x41759C: cv::Point_<float>::Point_(cv::Point_<float> const&) (operations.hpp:1623)
==11770== by 0x41A166: cv::KeyPoint::KeyPoint(cv::KeyPoint const&) (features2d.hpp:69)
==11770== by 0x41AFA2: Controller::detectObject(om::Query&) (Controller.cpp:169)
==11770== by 0x41B9B7: Controller::displayFunction(cv::Mat&, cv::Mat&) (Controller.cpp:261)
==11770== by 0x414909: processVideo() (App.cpp:109)
==11770== by 0x414C4F: main (App.cpp:144)
==11770== If you believe this happened as a result of a stack
==11770== overflow in your program's main thread (unlikely but
==11770== possible), you can try to increase the size of the
==11770== main thread stack using the --main-stacksize= flag.
==11770== The main thread stack size used in this run was 8388608.
==11770==
==11770== HEAP SUMMARY:
==11770== in use at exit: 37,488,211 bytes in 27,473 blocks
==11770== total heap usage: 121,456 allocs, 93,983 frees, 60,575,106 bytes allocated
==11770==
==11770== LEAK SUMMARY:
==11770== definitely lost: 16,496 bytes in 35 blocks
==11770== indirectly lost: 2,140,260 bytes in 623 blocks
==11770== possibly lost: 22,477,384 bytes in 1,566 blocks
==11770== still reachable: 12,635,159 bytes in 24,368 blocks
==11770== suppressed: 0 bytes in 0 blocks
==11770== Rerun with --leak-check=full to see details of leaked memory
==11770==
==11770== For counts of detected and suppressed errors, rerun with: -v
==11770== Use --track-origins=yes to see where uninitialised values come from
==11770== ERROR SUMMARY: 1502 errors from 47 contexts (suppressed: 0 from 0)
Killed
with --leak-check=full
==11938== Process terminating with default action of signal 11 (SIGSEGV)
==11938== Access not within mapped region at address 0x2C774CA4
==11938== at 0x41759C: cv::Point_<float>::Point_(cv::Point_<float> const&) (operations.hpp:1623)
==11938== by 0x41A166: cv::KeyPoint::KeyPoint(cv::KeyPoint const&) (features2d.hpp:69)
==11938== by 0x41AFA2: Controller::detectObject(om::Query&) (Controller.cpp:169)
==11938== by 0x41B9B7: Controller::displayFunction(cv::Mat&, cv::Mat&) (Controller.cpp:261)
==11938== by 0x414909: processVideo() (App.cpp:109)
==11938== by 0x414C4F: main (App.cpp:144)
==11938== If you believe this happened as a result of a stack
==11938== overflow in your program's main thread (unlikely but
==11938== possible), you can try to increase the size of the
==11938== main thread stack using the --main-stacksize= flag.
==11938== The main thread stack size used in this run was 8388608.
==11938==
==11938== HEAP SUMMARY:
==11938== in use at exit: 35,574,636 bytes in 27,138 blocks
==11938== total heap usage: 97,784 allocs, 70,646 frees, 58,484,719 bytes allocated
Related
I'm new to C++ and I'm trying to write an enigma machine simulator. I know I've done something funky with my pointers and I've run it through Valgrind, but I'm not sure what the error messages mean and where to begin fixing it? (What does suppressed mean in the leak summary?)
Here's part of the code where each component is created and where the error occurs.
Enigma::Enigma(int argc, char** argv){
errorCode = NO_ERROR;
plugboard = NULL;
*rotor = NULL; //WHERE THE ERROR OCCURS
reflector = NULL;
rotorCount = 0;
//first check how many rotors there are
if (argc >= 5)
rotorCount = argc - 4;
if (argc <= 4)
errorCode = INSUFFICIENT_NUMBER_OF_PARAMETERS;
//pass files into each component and check if well-formed
if (errorCode == NO_ERROR){
plugboard = new Plugboard(argv[1]);
errorCode = plugboard -> errorCode;
if (errorCode == NO_ERROR){
cout << "Plugboard configuration loaded successfully" << endl;
reflector = new Reflector(argv[2]);
errorCode = reflector -> errorCode;
if (errorCode == NO_ERROR){
cout << "Reflector configuration loaded successfully" << endl;
rotor = new Rotor*[rotorCount];
size_t i = 0;
while (i < rotorCount && errorCode == NO_ERROR) {
rotor[i] = new Rotor (argv[i+3]);
i++;
errorCode = rotor[i]-> errorCode;
//destructor if rotor loading was unsuccessful
if (errorCode != NO_ERROR){
for (int j=0; j<=i; j++)
delete rotor[j];
delete [] rotor;
Here's the Valgrind error message:
reflectors/I.rf rotors/I.rot rotors/II.rot rotors/III.rot rotors/I.pos
==68943== Memcheck, a memory error detector
==68943== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==68943== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==68943== Command: ./enigma plugboards/I.pb reflectors/I.rf rotors/I.rot rotors/II.rot rotors/III.rot rotors/I.pos
==68943==
--68943-- run: /usr/bin/dsymutil "./enigma"
==68943== Use of uninitialised value of size 8
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== Uninitialised value was created by a stack allocation
==68943== at 0x1000007D4: main (main.cpp:11)
==68943==
==68943== Invalid write of size 8
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==68943==
==68943==
==68943== Process terminating with default action of signal 11 (SIGSEGV)
==68943== Access not within mapped region at address 0x0
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== If you believe this happened as a result of a stack
==68943== overflow in your program's main thread (unlikely but
==68943== possible), you can try to increase the size of the
==68943== main thread stack using the --main-stacksize= flag.
==68943== The main thread stack size used in this run was 10022912.
==68943==
==68943== HEAP SUMMARY:
==68943== in use at exit: 18,685 bytes in 166 blocks
==68943== total heap usage: 187 allocs, 21 frees, 27,133 bytes allocated
==68943==
==68943== LEAK SUMMARY:
==68943== definitely lost: 0 bytes in 0 blocks
==68943== indirectly lost: 0 bytes in 0 blocks
==68943== possibly lost: 72 bytes in 3 blocks
==68943== still reachable: 200 bytes in 6 blocks
==68943== suppressed: 18,413 bytes in 157 blocks
==68943== Rerun with --leak-check=full to see details of leaked memory
==68943==
==68943== For counts of detected and suppressed errors, rerun with: -v
==68943== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1 from 1)
Segmentation fault: 11
Thanks
Maybe you should take a look at: How do pointer to pointers work in C?
Basically, I see that rotor is a pointer to pointer or possibly an array of pointers (since you initialize *rotor to NULL and later also set rotor[i] = new Rotor).
Make sure you've initialized rotor properly. Is it pointing to a valid object? If not, you cannot expect *rotort = NULL /* or whatever value */; to work.
Basically suppressed means the memory leaks outside of your code in shared libraries.And *rotor = NULL,but it doesn't point to any valid object..
I use doubly linked list to implement Deque in C++.
Destructor:
Deque::~Deque()
{
while (this->left_p)
{
node *temp = this->left_p;
this->left_p = this->left_p->next;
delete temp;
}
this->right_p = NULL;
}
when i use valgrind --leak-check=full ./a.out to check memory leak just to test my destructor` I got the following output:
==2636==
==2636== HEAP SUMMARY:
==2636== in use at exit: 72,704 bytes in 1 blocks
==2636== total heap usage: 1,003 allocs, 1,002 frees, 97,760 bytes allocated
==2636==
==2636== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==2636== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2636== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==2636== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==2636== by 0x40107CA: call_init (dl-init.c:30)
==2636== by 0x40107CA: _dl_init (dl-init.c:120)
==2636== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2636==
==2636== LEAK SUMMARY:
==2636== definitely lost: 0 bytes in 0 blocks
==2636== indirectly lost: 0 bytes in 0 blocks
==2636== possibly lost: 0 bytes in 0 blocks
==2636== still reachable: 72,704 bytes in 1 blocks
==2636== suppressed: 0 bytes in 0 blocks
==2636==
==2636== For counts of detected and suppressed errors, rerun with: -v
==2636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I can't figure out why there is still ONE out of 1003 allocs not being free.
Why do i have one memory leak? what is wrong with my destructor?
Test code here:
/* Deque Test Program 6 */
#include <cstring>
#include <iostream>
#include "Deque.h"
using namespace std ;
int main (int argc, char * const argv[]) {
cout << "\n\nDeque Class Test Program 6 - START\n\n";
// Make a Deque
Deque * dq1 = new Deque();
for( int i = 0 ; i<1 ; i++ ){
dq1->push_left(1);
// dq1->display();
}
cout << "Size=" << dq1->size() << endl ;
// The destructor should delete all the nodes.
delete dq1 ;
cout << "\n\nDeque Class Test Program 6 - DONE\n\n";
return 0;
}
edit: remove implementation code.
Essentially, it's not your code's fault, it's valgrind's.
Check this other question that has had the same problem:
Valgrind: Memory still reachable with trivial program using <iostream>
Quoting from the post:
First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit of the program cause Valgrind to report this memory as still reachable. The behaviour not to free pools at the exit could be called a bug of the library though.
Hope that helps :)
The memory leak reported by valgrind does not appear to be in your code:
==2636== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==2636== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2636== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==2636== by 0x40106B9: call_init.part.0 (dl-init.c:72)
==2636== by 0x40107CA: call_init (dl-init.c:30)
==2636== by 0x40107CA: _dl_init (dl-init.c:120)
This appears to be a heap allocation from within a constructor of a global object. (In theory, it could still come from your code if operator new is called as a tail call, so that it does not show up in the backtrace, but I don't see such an object declaration in your cdoe.)
It is also not an actual leak, it is just some data allocated on the heap at program start. If you install debugging information for libstdc++, then you might get a hint of what is actually being allocated. Then you could also set a breakpoint on call_init and step through the early process initialization, to see the constructors that are called.
I have implemented multitask application in c++. Producer push on queue, and consumer get elements from queue. Sometimes my application crashed. Could someone help me with this problem. sf
Valgrind output:
==10769== Memcheck, a memory error detector
==10769== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10769== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==10769== Command: ./tachyon -s /HOME_ann/BII/biidurgak/test_new_tachyon/Tachyon_v5_improvedQueryTime/settings_smallNR
==10769==
==10769== Thread 5:
==10769== Invalid read of size 4
==10769== at 0x342669C9DE: std::string::assign(std::string const&) (in /usr/lib64/libstdc++.so.6.0.8)
==10769== by 0x42E01A: std::pair::operator=(std::pair const&) (stl_pair.h:152)
==10769== by 0x42B27A: boost::lockfree::detail::ringbuffer_base >::pop(std::pair&, std::pair*, unsigned
long) (spsc_queue.hpp:154)
==10769== by 0x428719: boost::lockfree::detail::compile_time_sized_ringbuffer, 2ul>::pop(std::pair&) (spsc_queue.hpp:305)
==10769== by 0x425DEA: boost::lockfree::spsc_queue, boost::lockfree::capacity, boost::parameter::void_>::pop(std::pair&) (spsc_queue.hpp:572)
==10769== by 0x41BE16: findInDatabase() (Tachyon.cpp:103)
==10769== by 0x4351D4: boost::detail::thread_data::run() (thread.hpp:117)
==10769== by 0x4E53D01: thread_proxy (in /HOME_ann/BII/biidurgak/test_new_tachyon/boost_install/boost_1_55_0/lib/libboost_thread.so.1.55.0)
==10769== by 0x342120673C: start_thread (in /lib64/libpthread-2.5.so)
==10769== by 0x34206D3D1C: clone (in /lib64/libc-2.5.so)
==10769== Address 0xfffffffffffffff8 is not stack'd, malloc'd or (recently) free'd
==10769==
==10769==
==10769== Process terminating with default action of signal 11 (SIGSEGV)
==10769== Access not within mapped region at address 0xFFFFFFFFFFFFFFF8
==10769== at 0x342669C9DE: std::string::assign(std::string const&) (in /usr/lib64/libstdc++.so.6.0.8)
==10769== by 0x42E01A: std::pair::operator=(std::pair const&) (stl_pair.h:152)
==10769== by 0x42B27A: boost::lockfree::detail::ringbuffer_base >::pop(std::pair&, std::pair*, unsigned long) (spsc_queue.hpp:154)
==10769== by 0x428719: boost::lockfree::detail::compile_time_sized_ringbuffer, 2ul>::pop(std::pair&) (spsc_queue.hpp:305)
==10769== by 0x425DEA: boost::lockfree::spsc_queue, boost::lockfree::capacity, boost::parameter::void_>::pop(std::pair&) (spsc_queue.hpp:572)
==10769== by 0x41BE16: findInDatabase() (Tachyon.cpp:103)
==10769== by 0x4351D4: boost::detail::thread_data::run() (thread.hpp:117)
==10769== by 0x4E53D01: thread_proxy (in /HOME_ann/BII/biidurgak/test_new_tachyon/boost_install/boost_1_55_0/lib/libboost_thread.so.1.55.0)
==10769== by 0x342120673C: start_thread (in /lib64/libpthread-2.5.so)
==10769== by 0x34206D3D1C: clone (in /lib64/libc-2.5.so)
==10769== If you believe this happened as a result of a stack
==10769== overflow in your program's main thread (unlikely but
==10769== possible), you can try to increase the size of the
==10769== main thread stack using the --main-stacksize= flag.
==10769== The main thread stack size used in this run was 10485760.
==10769==
==10769== HEAP SUMMARY:
==10769== in use at exit: 219,895,341 bytes in 4,598,508 blocks
==10769== total heap usage: 36,680,650 allocs, 32,082,142 frees, 1,474,244,383 bytes allocated
==10769==
==10769== LEAK SUMMARY:
==10769== definitely lost: 1,904 bytes in 2 blocks
==10769== indirectly lost: 0 bytes in 0 blocks
==10769== possibly lost: 184,232,229 bytes in 4,598,462 blocks
==10769== still reachable: 35,661,208 bytes in 44 blocks
==10769== suppressed: 0 bytes in 0 blocks
==10769== Rerun with --leak-check=full to see details of leaked memory
==10769==
==10769== For counts of detected and suppressed errors, rerun with: -v
Producer:
void producer(string file) {
ifstream query(file.c_str());
string description = "";
string sequence = "";
string line;
while (getline(query, line)) {
//read description
if (line == "") continue;
if (line.at(0) == '>') {
if (sequence != "") {
pair<string, string> a = make_pair(description, sequence);
while (!queue.push(a))
;
sequence = "";
}
description = line.substr(1);
} else {
sequence += line;
}
}
if (sequence != "" && description != "") {
pair<string, string> a = make_pair(description, sequence);
while (!queue.push(a))
;
}
}
In the consumer I have this:
void Consumer(void) {
pair<string, string>element;
//part of code
while(queue.pop(element)){ //Line 103 in Tachyon.cpp
string queryDescription = element.first;
string sequence = element.second;
//Part of code
}
}
Queue is the global variable:
boost::lockfree::spsc_queue<pair<string, string>, boost::lockfree::capacity<2> > queue;
Global variables, multiple threads (I assume), one reading and another thread writing - you need a synchronization object like mutex or critical section.
Pseudocode:
// Consumer
loop-begin;
Lock();
get-item-into-local-variable
Unlock();
process-local-variable-item;
loop-end
// Producer
void AddItem(item)
{
Lock();
Add-item-into-queue
Unlock();
}
The following code is to move the "non-overlapping" TablePath from vector v to vector u. I am encountering segmentaion fault at the line "u.push_back(*it1);". I didn't copy the object(but instead only copy the pointer of the object) so I believe the problem doesn't lie in copying constructor. Can you give some hints on why segfault is occuring ?
#include <iostream>
#include <vector>
using namespace std;
class TablePath
{
private:
int source;
int destination;
public:
TablePath(int,int);
~TablePath();
int overlap(TablePath*);
void toString();
TablePath(const TablePath& that) : source(that.source), destination(that.destination)
{
}
};
TablePath::TablePath(int source=0,int destination=0)
{
this->source = source;
this->destination = destination;
}
int TablePath::overlap(TablePath* thatTablePath)
{
if (this->source >= thatTablePath->source and this->source <= thatTablePath->destination)
return 1;
else if (this->destination >= thatTablePath->source and this->destination <= thatTablePath->destination)
return 1;
else if (thatTablePath->source >= this->source and thatTablePath->source <= this->destination)
return 1;
else if (thatTablePath->destination >= this->source and thatTablePath->destination <= this->destination)
return 1;
else
return 0;
}
void TablePath::toString()
{
cout << this->source << " " << this->destination << endl;
}
int main()
{
int numofTests;
cin >> numofTests;
while(numofTests > 0)
{
int numofMoves;
vector<TablePath *> v;
cin >> numofMoves;
for (int i=0;i<numofMoves;i++)
{
int source,destination;
cin >> source >> destination;
TablePath* MyTablePath = new TablePath(source,destination);
v.push_back(MyTablePath);
}
vector<TablePath *> u;
vector<TablePath *>::iterator it1 = v.begin();
u.push_back(*it1);
v.erase(v.begin());
for(vector<TablePath *>::iterator it1 = v.begin(); it1 != v.end(); ++it1)
{
for(vector<TablePath *>::iterator it2 = u.begin(); it2 != u.end(); ++it2)
{
if ((*it1)->overlap((*it2)))
{
u.push_back(*it1);
}
}
}
cout << u.size() * 10;
v.erase(v.begin(),v.end());
u.erase(u.begin(),u.end());
numofTests--;
}
}
The following is the output I get from valgrind:
frank#frank-vm:~$ valgrind --tool=memcheck ./tablepath
==6172== Memcheck, a memory error detector
==6172== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6172== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6172== Command: ./tablepath
==6172==
1
3
10
20
15 30
20 50
==6172== Invalid read of size 4
==6172== at 0x8048BB0: main (in /home/frank/tablepath)
==6172== Address 0x4320184 is 0 bytes after a block of size 4 free'd
==6172== at 0x402ACFC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==6172== by 0x8049616: __gnu_cxx::new_allocator<TablePath*>::deallocate(TablePath**, unsigned int) (in /home/frank/tablepath)
==6172== by 0x80493E8: std::_Vector_base<TablePath*, std::allocator<TablePath*> >::_M_deallocate(TablePath**, unsigned int) (in /home/frank/tablepath)
==6172== by 0x8049230: std::vector<TablePath*, std::allocator<TablePath*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<TablePath**, std::vector<TablePath*, std::allocator<TablePath*> > >, TablePath* const&) (in /home/frank/tablepath)
==6172== by 0x8048E00: std::vector<TablePath*, std::allocator<TablePath*> >::push_back(TablePath* const&) (in /home/frank/tablepath)
==6172== by 0x8048BED: main (in /home/frank/tablepath)
==6172==
==6172== Invalid read of size 4
==6172== at 0x8048965: TablePath::overlap(TablePath*) (in /home/frank/tablepath)
==6172== by 0x8048BCA: main (in /home/frank/tablepath)
==6172== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6172==
==6172==
==6172== Process terminating with default action of signal 11 (SIGSEGV)
==6172== Access not within mapped region at address 0x0
==6172== at 0x8048965: TablePath::overlap(TablePath*) (in /home/frank/tablepath)
==6172== by 0x8048BCA: main (in /home/frank/tablepath)
==6172== If you believe this happened as a result of a stack
==6172== overflow in your program's main thread (unlikely but
==6172== possible), you can try to increase the size of the
==6172== main thread stack using the --main-stacksize= flag.
==6172== The main thread stack size used in this run was 8388608.
==6172==
==6172== HEAP SUMMARY:
==6172== in use at exit: 48 bytes in 5 blocks
==6172== total heap usage: 8 allocs, 3 frees, 64 bytes allocated
==6172==
==6172== LEAK SUMMARY:
==6172== definitely lost: 0 bytes in 0 blocks
==6172== indirectly lost: 0 bytes in 0 blocks
==6172== possibly lost: 0 bytes in 0 blocks
==6172== still reachable: 48 bytes in 5 blocks
==6172== suppressed: 0 bytes in 0 blocks
==6172== Rerun with --leak-check=full to see details of leaked memory
==6172==
==6172== For counts of detected and suppressed errors, rerun with: -v
==6172== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
std::vector<T>::push_back is (usually) allowed to invalidate all iterators associated with the vector object. So after you do:
u.push_back(*it1);
it is not safe to continue the inner for loop with ++it2.
You could use an index for the inner loop instead. Or, break out of the inner loop right after doing the push_back, if you don't really want multiple copies of the same TablePath* pointer in u.
I would like to use ITK for a simple color-ratio program, but I get a segfault after the return 0; of the main function.
here is my code.
#include "itkImage.h"
#include "itkImageFileReader.h"
#include "itkImageFileWriter.h"
#include <iostream>
#include <string>
#include <vector>
#include "itkRGBPixel.h"
const unsigned int Dimension = 2;
typedef itk::RGBPixel< unsigned char > PixelType;
typedef itk::Image< PixelType, Dimension > ImageType;
typedef itk::ImageFileReader< ImageType > ReaderType;
typedef itk::ImageFileWriter< ImageType > WriterType;
int main(int argc, char** argv)
{
std::string input=argv[1], output=argv[2];
//allocation of the image data
ReaderType::Pointer reader = ReaderType::New();
WriterType::Pointer writer = WriterType::New();
reader->SetFileName(input);
writer->SetFileName(output);
reader->Update();
//access image
ImageType::Pointer image = reader->GetOutput();
ImageType::Pointer output_img;
//apparently providing the spacing and origin in ITK is mandatory
ImageType::SpacingType spacing;
spacing[0] = 0.33;
spacing[1] = 0.33;
image->SetSpacing(spacing);
ImageType::PointType origin;
origin[0] = 0.0;
origin[1] = 0.0;
image->SetOrigin(origin);
writer->SetInput( reader->GetOutput() );
writer->Update();
return EXIT_SUCCESS;
}
It compiles and links without any error messages but I have a segfault during execution.
By executing the program line by line using gdb, I pinpionted the segfault to the last line of the program: after return 0;
Here is the backtrace
Program received signal SIGSEGV, Segmentation fault.
0xb79099bc in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0xb79099bc in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1 0xb7909a4e in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/i386-linux-gnu/libstdc++.so.6
#2 0x08065369 in main (argc=3, argv=0xbffff1b4) at /home/thibault/workspace/OU/MachineLearning/Project1/src/itkTry1.cpp:221
(gdb)
and when checking with valgrind:
==16671== Memcheck, a memory error detector
==16671== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==16671== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==16671== Command: ./ColorRatio clouds2.jpeg coucou.jpeg --track-origins=yes
==16671==
==16671== Conditional jump or move depends on uninitialised value(s)
==16671== at 0x4B28DD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==16671== by 0x4B28EC7: inflateInit2_ (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==16671== by 0x4C87E58: ??? (in /usr/lib/libITKniftiio.so.3.20.1)
==16671==
==16671== Conditional jump or move depends on uninitialised value(s)
==16671== at 0x4B28DD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==16671== by 0x4B28EC7: inflateInit2_ (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==16671==
==16671== Invalid read of size 4
==16671== at 0x47429BC: ??? (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16671== by 0x47CE4D2: (below main) (libc-start.c:226)
==16671== Address 0xfffffffc is not stack'd, malloc'd or (recently) free'd
==16671==
==16671==
==16671== Process terminating with default action of signal 11 (SIGSEGV)
==16671== Access not within mapped region at address 0xFFFFFFFC
==16671== at 0x47429BC: ??? (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16671== by 0x47CE4D2: (below main) (libc-start.c:226)
==16671== If you believe this happened as a result of a stack
==16671== overflow in your program's main thread (unlikely but
==16671== possible), you can try to increase the size of the
==16671== main thread stack using the --main-stacksize= flag.
==16671== The main thread stack size used in this run was 8388608.
==16671==
==16671== HEAP SUMMARY:
==16671== in use at exit: 2,352,658 bytes in 63,532 blocks
==16671== total heap usage: 74,071 allocs, 10,539 frees, 14,082,941 bytes allocated
==16671==
==16671== LEAK SUMMARY:
==16671== definitely lost: 49 bytes in 2 blocks
==16671== indirectly lost: 0 bytes in 0 blocks
==16671== possibly lost: 1,309,540 bytes in 42,156 blocks
==16671== still reachable: 1,043,069 bytes in 21,374 blocks
==16671== suppressed: 0 bytes in 0 blocks
==16671== Rerun with --leak-check=full to see details of leaked memory
==16671==
==16671== For counts of detected and suppressed errors, rerun with: -v
==16671== Use --track-origins=yes to see where uninitialised values come from
==16671== ERROR SUMMARY: 5 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
Even with 36000 useless try/catch statments, I still get that same segmentation fault after the main.
Can anyone please help me?
Thank you in advance
This code works for me:
#include <iostream>
#include <string>
#include <vector>
#include "itkImage.h"
#include "itkImageFileReader.h"
#include "itkImageFileWriter.h"
#include "itkRGBPixel.h"
int main(int argc, char** argv)
{
std::string input = "/home/doriad/temp/test.png";
std::string output= "output.png";
const unsigned int Dimension = 2;
typedef itk::RGBPixel< unsigned char > PixelType;
typedef itk::Image< PixelType, Dimension > ImageType;
typedef itk::ImageFileReader< ImageType > ReaderType;
typedef itk::ImageFileWriter< ImageType > WriterType;
//allocation of the reader
ReaderType::Pointer reader = ReaderType::New();
reader->SetFileName(input);
reader->Update();
//access image
ImageType::Pointer image = reader->GetOutput();
// ImageType::Pointer output_img;// This line does nothing
//apparently providing the spacing and origin in ITK is mandatory
// The spacing and origin are read from the file.
// ImageType::SpacingType spacing;
// spacing[0] = 0.33;
// spacing[1] = 0.33;
// image->SetSpacing(spacing);
// ImageType::PointType origin;
// origin[0] = 0.0;
// origin[1] = 0.0;
// image->SetOrigin(origin);
WriterType::Pointer writer = WriterType::New();
writer->SetFileName(output);
writer->SetInput( reader->GetOutput() );
writer->Update();
return EXIT_SUCCESS;
}
Of course, you have to change the 'input' string to a file you actually have.