Programming Forums > Application Development > C++

Jessehk · Feb 9th, 2008, 8:50 PM

I don't expect people to look through the complicated code that is the problem. I'm mostly looking for some debugging advice because I'm obviously doing something wrong, but at a loss of where to look.

When I compile my code with debugging on, there are no memory errors (checked with valgrind) and everything runs perfectly.

When I compile a "release" mode which includes -O3 and -DNDEBUG, the code segfaults almost immediately. However, when I insert a single output statement in one area of code,

ie,

 c++ Syntax (Toggle Plain Text) 
std::cout << "Fine" << std::endl;
std::cout << "Fine" << std::endl;

and recompile (with the same optimizations), everything runs perfectly once again.
Does anyone recognize any symptoms here or have any advice on what class of errors might be causing this bizarre behavior?

Thanks in advance.

grumpy · Feb 9th, 2008, 9:03 PM

There are many possible causes but, if I had to guess, you're probably falling off the end of an array and clobbering a variable that happens to be located at the end of that array. Some other code then comes along and uses that variable (eg as an index into another array) and dies horribly.

Valgrind is not guaranteed to find such things, and changing optimisation settings just changes what is getting clobbered by changing how data/code/etc are laid out in memory. An output statement (particularly one that doesn't output any variables) can appear to fix such problems, as it (depending on how the compiler works) has a small side-effect of changing how things are laid out in memory.

Jessehk · Feb 9th, 2008, 10:00 PM

After about an hour of review, I couldn't find anything obvious. However, there was one spot in my code where I was using a boost::shared_ptr where a pointer of any kind wasn't necessary. I got rid of it, and the code runs fine. I'm not exactly sure why, but everything seems to be fine now. Thanks grumpy.

Jessehk · Feb 10th, 2008, 10:33 AM

Just a bit of an update. It turns out that the fact that the code was working before was just a fluke.
It was just a lucky coincidence like before.

The real culprit was Boost.Foreach.
For some reason, something like this:

 c++ Syntax (Toggle Plain Text) 
const char LETTERS[] = { 'A', 'B' };
 
BOOST_FOREACH( char letter, LETTERS ) {
    // ...
}
const char LETTERS[] = { 'A', 'B' };

BOOST_FOREACH( char letter, LETTERS ) {
    // ...
}

was not iterating the correct number of times and that was the result of the segfault. I'm trying to figure out if it was a bug in my code (which ATM seems unlikely) or a bug with Boost.Foreach and arrays.

In any case, your suspicion that the code was falling off the end of an array was correct.

Sane · Feb 10th, 2008, 12:23 PM

Boost Foreach needs to know how long the sequence is. Currently there's no way of telling where your LETTERS array ends.

It can iterate over C-style strings. However, your { 'A', 'B' } is not null-terminated. So the following should also work, since it now knows how large your array is:

(Toggle Plain Text)

const char LETTERS[] = { 'A', 'B', '\0' };

BOOST_FOREACH( char letter, LETTERS ) {
    // ...
}

This should also work:

(Toggle Plain Text)

std::string LETTERS( "AB" );

BOOST_FOREACH( char letter, LETTERS ) {
    // ...
}

Jessehk · Feb 10th, 2008, 12:30 PM

I believe you're wrong, Sane.

 c++ Syntax (Toggle Plain Text) 
#include <iostream>
 
#include <boost/foreach.hpp>
 
int main() {
    const int numbs[] = { 1, 2, 3, 4, 5 };
 
    BOOST_FOREACH ( int n, numbs ) {
        std::cout << n << std::endl;
    }
}
#include <iostream>

#include <boost/foreach.hpp>

int main() {
    const int numbs[] = { 1, 2, 3, 4, 5 };

    BOOST_FOREACH ( int n, numbs ) {
        std::cout << n << std::endl;
    }
}

(Toggle Plain Text)

$ valgrind ./example
==11578== Memcheck, a memory error detector.
==11578== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==11578== Using LibVEX rev 1804, a library for dynamic binary translation.
==11578== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11578== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==11578== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==11578== For more details, rerun with: -v
==11578== 
1
2
3
4
5
==11578== 
==11578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==11578== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11578== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==11578== For counts of detected errors, rerun with: -v
==11578== All heap blocks were freed -- no leaks are possible.

It is able to do this was some automagic templates of some kind.

I am also unable to reproduce the original bug when I test the specific conditions in a seperate file and compilation. I'm guessing the bug (if it exists) only occurs when very specific conditions are true.

Sane · Feb 10th, 2008, 12:33 PM

They say numbers are different. But for C-style strings, it has to know how long it is by the null-terminator.

http://www.boost.org/regression-logs...l/foreach.html

Jessehk · Feb 10th, 2008, 12:52 PM

Oops! Thanks for the correction. I guess that explains it.

Feb 9th, 2008, 8:50 PM	#1
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 644 Rep Power: 4	Code Segfaults when compiled with optimizations, doesn't in arbitrary situations I don't expect people to look through the complicated code that is the problem. I'm mostly looking for some debugging advice because I'm obviously doing something wrong, but at a loss of where to look. When I compile my code with debugging on, there are no memory errors (checked with valgrind) and everything runs perfectly. When I compile a "release" mode which includes -O3 and -DNDEBUG, the code segfaults almost immediately. However, when I insert a single output statement in one area of code, ie, c++ Syntax (Toggle Plain Text) std::cout << "Fine" << std::endl; std::cout << "Fine" << std::endl; and recompile (with the same optimizations), everything runs perfectly once again. Does anyone recognize any symptoms here or have any advice on what class of errors might be causing this bizarre behavior? Thanks in advance. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Feb 9th, 2008, 9:03 PM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,223 Rep Power: 5	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations There are many possible causes but, if I had to guess, you're probably falling off the end of an array and clobbering a variable that happens to be located at the end of that array. Some other code then comes along and uses that variable (eg as an index into another array) and dies horribly. Valgrind is not guaranteed to find such things, and changing optimisation settings just changes what is getting clobbered by changing how data/code/etc are laid out in memory. An output statement (particularly one that doesn't output any variables) can appear to fix such problems, as it (depending on how the compiler works) has a small side-effect of changing how things are laid out in memory.

Feb 9th, 2008, 10:00 PM	#3
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 644 Rep Power: 4	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations After about an hour of review, I couldn't find anything obvious. However, there was one spot in my code where I was using a boost::shared_ptr where a pointer of any kind wasn't necessary. I got rid of it, and the code runs fine. I'm not exactly sure why, but everything seems to be fine now. Thanks grumpy. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Feb 10th, 2008, 10:33 AM	#4
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 644 Rep Power: 4	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations Just a bit of an update. It turns out that the fact that the code was working before was just a fluke. It was just a lucky coincidence like before. The real culprit was Boost.Foreach. For some reason, something like this: c++ Syntax (Toggle Plain Text) const char LETTERS[] = { 'A', 'B' }; BOOST_FOREACH( char letter, LETTERS ) { // ... } const char LETTERS[] = { 'A', 'B' }; BOOST_FOREACH( char letter, LETTERS ) { // ... } was not iterating the correct number of times and that was the result of the segfault. I'm trying to figure out if it was a bug in my code (which ATM seems unlikely) or a bug with Boost.Foreach and arrays. In any case, your suspicion that the code was falling off the end of an array was correct. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Feb 10th, 2008, 12:23 PM	#5
Sane Programming Guru Join Date: Apr 2005 Location: Waterloo, Ontario Posts: 1,885 Rep Power: 5	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations Boost Foreach needs to know how long the sequence is. Currently there's no way of telling where your LETTERS array ends. It can iterate over C-style strings. However, your { 'A', 'B' } is not null-terminated. So the following should also work, since it now knows how large your array is: (Toggle Plain Text) const char LETTERS[] = { 'A', 'B', '\0' }; BOOST_FOREACH( char letter, LETTERS ) { // ... } const char LETTERS[] = { 'A', 'B', '\0' }; BOOST_FOREACH( char letter, LETTERS ) { // ... } This should also work: (Toggle Plain Text) std::string LETTERS( "AB" ); BOOST_FOREACH( char letter, LETTERS ) { // ... } std::string LETTERS( "AB" ); BOOST_FOREACH( char letter, LETTERS ) { // ... }

Feb 10th, 2008, 12:30 PM	#6
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 644 Rep Power: 4	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations I believe you're wrong, Sane. c++ Syntax (Toggle Plain Text) #include <iostream> #include <boost/foreach.hpp> int main() { const int numbs[] = { 1, 2, 3, 4, 5 }; BOOST_FOREACH ( int n, numbs ) { std::cout << n << std::endl; } } #include <iostream> #include <boost/foreach.hpp> int main() { const int numbs[] = { 1, 2, 3, 4, 5 }; BOOST_FOREACH ( int n, numbs ) { std::cout << n << std::endl; } } (Toggle Plain Text) $ valgrind ./example ==11578== Memcheck, a memory error detector. ==11578== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11578== Using LibVEX rev 1804, a library for dynamic binary translation. ==11578== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11578== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==11578== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11578== For more details, rerun with: -v ==11578== 1 2 3 4 5 ==11578== ==11578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1) ==11578== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11578== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==11578== For counts of detected errors, rerun with: -v ==11578== All heap blocks were freed -- no leaks are possible. $ valgrind ./example ==11578== Memcheck, a memory error detector. ==11578== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11578== Using LibVEX rev 1804, a library for dynamic binary translation. ==11578== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11578== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==11578== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11578== For more details, rerun with: -v ==11578== 1 2 3 4 5 ==11578== ==11578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1) ==11578== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11578== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==11578== For counts of detected errors, rerun with: -v ==11578== All heap blocks were freed -- no leaks are possible. It is able to do this was some automagic templates of some kind. I am also unable to reproduce the original bug when I test the specific conditions in a seperate file and compilation. I'm guessing the bug (if it exists) only occurs when very specific conditions are true. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Feb 10th, 2008, 12:33 PM	#7
Sane Programming Guru Join Date: Apr 2005 Location: Waterloo, Ontario Posts: 1,885 Rep Power: 5	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations They say numbers are different. But for C-style strings, it has to know how long it is by the null-terminator. http://www.boost.org/regression-logs...l/foreach.html

Feb 10th, 2008, 12:52 PM	#8
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 644 Rep Power: 4	Re: Code Segfaults when compiled with optimizations, doesn't in arbitrary situations Oops! Thanks for the correction. I guess that explains it. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Incorporating javascript code into java application	csrocker101	Java	1	Feb 11th, 2008 6:36 AM
Code compiled without error, but gets the wrong answer; Calculating Volume	Fall Back Son	C	15	Oct 21st, 2006 6:51 PM
Compiled Python code dependencies	titaniumdecoy	Python	12	Jun 23rd, 2006 7:04 AM
Viewing VB's Automated code	john Wesley	Visual Basic .NET	3	Jun 8th, 2006 5:37 AM
FTP and return code fetching	Serinth	C	2	May 28th, 2006 11:05 PM

Programming Forums > Application Development > C++

Code Segfaults when compiled with optimizations, doesn't in arbitrary situations