Program crashes in release build

Hey.

I’m having an issue with my program where it crashes upon exiting in the release build. Funnily enough, this is the program:

#include “sdl.h”

int main(int argc, char* args[])
{
return 0;
}

Rather than post stuff that I’ve posted elsewhere, I’ll post the links to the sites that I posted to about this problem:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

I’m completely dumbfounded… I don’t have any idea what to do about this. It works fine in the debug build…

Cheers._________________________________________________________________
Find out what?s new with your friends Download the new Windows Live Messenger
http://download.live.com/

Just a bit of a guess here (in wrong place to test this) but SDL relies on argc and argv, which you’ve called args. Try changing the name.— On Mon, 3/23/09, mitch curtis wrote:

From: mitch curtis
Subject: [SDL] Program crashes in release build
To: sdl at lists.libsdl.org
Date: Monday, March 23, 2009, 4:18 AM
Hey.

I’m having an issue with my program where it crashes
upon exiting in the release build. Funnily enough, this is
the program:

#include “sdl.h”

int main(int argc, char* args[])
{
return 0;
}

Rather than post stuff that I’ve posted elsewhere,
I’ll post the links to the sites that I posted to about
this problem:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

I’m completely dumbfounded… I don’t have any idea
what to do about this. It works fine in the debug build…

Cheers.


Find out what?s new with your friends Download the new
Windows Live Messenger
http://download.live.com/_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey. Thanks for the reply, but unfortunately it’s still throwing the exception.

I dunno how to reply to this list haha…

Just a bit of a guess here (in wrong place to test this) but SDL relies on argc and argv,
which you’ve called args. Try changing the name.— On Mon, 3/23/09, mitch curtis <@mitch_curtis> wrote:

From: mitch curtis <@mitch_curtis>
Subject: [SDL] Program crashes in release build
To: sdl at lists.libsdl.org
Date: Monday, March 23, 2009, 4:18 AM
Hey.

I’m having an issue with my program where it crashes
upon exiting in the release build. Funnily enough, this is
the program:

#include “sdl.h”

int main(int argc, char* args[])
{
return 0;
}

Rather than post stuff that I’ve posted elsewhere,
I’ll post the links to the sites that I posted to about
this problem:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

I’m completely dumbfounded… I don’t have any idea
what to do about this. It works fine in the debug build…

Cheers.


View photos of singles in your area. Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating.ninemsn.com.au%2Fchannel%2Findex.aspx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=EXT

As long as he refers to it as args in the body of main, the name change
doesn’t matter.

JeffOn Monday 23 March 2009 04:03, Paul Duffy wrote:

Just a bit of a guess here (in wrong place to test this) but SDL relies on
argc and argv, which you’ve called args. Try changing the name.

This is what happens when someone ‘reply alls’ to a mailing list. I’ll send this again.

That’s all very well so long as only he’s referring to args, but there are parts of SDL which also refer to the arguments and expect them to be called argv. This is something which has caused problems before when people have tried to leave argc and argv out when working with SDL.— On Mon, 3/23/09, Jeff Post <j_post at pacbell.net> wrote:

From: Jeff Post <j_post at pacbell.net>
Subject: Re: [SDL] Program crashes in release build
To: @Paul_Duffy, “A list for developers using the SDL library. (includes SDL-announce)”
Date: Monday, March 23, 2009, 12:35 PM
On Monday 23 March 2009 04:03, Paul Duffy wrote:

Just a bit of a guess here (in wrong place to test
this) but SDL relies on
argc and argv, which you’ve called args. Try
changing the name.

As long as he refers to it as args in the body of main, the
name change
doesn’t matter.

Jeff

argv is not global. As long as he passes “args” from main to any SDL function
that expects argv, all will be well.

JeffOn Monday 23 March 2009 06:53, Paul Duffy wrote:

That’s all very well so long as only he’s referring to args, but there are
parts of SDL which also refer to the arguments and expect them to be called
argv. This is something which has caused problems before when people have
tried to leave argc and argv out when working with SDL.

You need to read through the header files sometime.

sdl.h includes sdl_main.h which has a specific #define which substitutes ‘main’ with ‘SDL_main’ and a function prototype for SDL_main.

While it’s true that the name in the prototype does not have to be the same as in the function proper according to the standards, compilers and their optimisation routines can do some very unstandard things.

So, like I said, SDL expects the main function to have a certani format. This is because it does things to the main function in the preprocessor which doesn’t care if something’s global or not.

The problem this guy is having looks very much like an over-optimisation issue. It’s entirely possible that as the compiler isn’t seeing anything properly used from sdl.h and all the included files that it’s optimising this right out. It may be something to do with the mismatch, it may be something else.

Just because something has not been a problem before doesn’t mean it’s not going to bite you sometime.

/* The application’s main() function must be called with C linkage,
and should be declared like this:
#ifdef __cplusplus
extern “C”
#endif
int main(int argc, char *argv[])
{
}
*/
#define main SDL_main

/* The prototype for the application’s main() function */
extern C_LINKAGE int SDL_main(int argc, char *argv[]);— On Mon, 3/23/09, Jeff Post <j_post at pacbell.net> wrote:

From: Jeff Post <j_post at pacbell.net>
Subject: Re: [SDL] Program crashes in release build
To: @Paul_Duffy, “A list for developers using the SDL library. (includes SDL-announce)”
Date: Monday, March 23, 2009, 2:53 PM
On Monday 23 March 2009 06:53, Paul Duffy wrote:

That’s all very well so long as only he’s
referring to args, but there are
parts of SDL which also refer to the arguments and
expect them to be called
argv. This is something which has caused problems
before when people have
tried to leave argc and argv out when working with
SDL.

argv is not global. As long as he passes "args"
from main to any SDL function
that expects argv, all will be well.

Jeff

I tried what you suggested but it’s still giving me the exception… did you take a look at my project settings in the other links and also where the exception took me to? I’m hoping that might prove indicative of the problem.

#include “sdl.h”

#ifdef __cplusplus
extern “C”
#endif

int main(int argc, char* argv[])
{
return 0;
}_________________________________________________________________
View photos of singles in your area. Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating.ninemsn.com.au%2Fchannel%2Findex.aspx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=EXT

Hiyyya, it will be clear as day if you try to duplicate the issue on another compiler and the another computer. You don’t know what your functions are doing so you can release everything, your compiler settings, or what is returning what and why…did I forget anything? lol lol lol no I’m just giving you the rasberry.

Just start with a known good program and add/replace one part at a time (with full rebuilds) till the error happens then you know where to look. Enjoy--------------------------

---- mitch curtis wrote:

=============

I tried what you suggested but it’s still giving me the exception… did you take a look at my project settings in the other links and also where the exception took me to? I’m hoping that might prove indicative of the problem.

#include “sdl.h”

#ifdef __cplusplus
extern “C”
#endif

int main(int argc, char* argv[])
{
return 0;
}


View photos of singles in your area. Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating.ninemsn.com.au%2Fchannel%2Findex.aspx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=EXT

Hey. Not really sure what you mean, as I am not calling any functions. All I have is main, and I #include “SDL.h”.
Trying it on another computer sounds like a good idea, but what would it prove?-----------

Hiyyya, it will be clear as day if you try to duplicate the issue on another compiler and the another computer.
You don’t know what your functions are doing so you can release everything, your compiler settings,
or what is returning what and why…did I forget anything? lol lol lol no I’m just giving you the rasberry.

Just start with a known good program and add/replace one part at a time (with full rebuilds)
till the error happens then you know where to look. Enjoy


Find out what?s new with your friends Download the new Windows Live Messenger
http://download.live.com/

OK, now that I’m properly awake again.

I’m not sure exactly which example you’re wanting the help with at the exact moment. There’s the checkers example (I’m not seeing any use of destructors, this isn’t ObjC is it?) and the base example you’ve copied here.

Usually when I see an error like this, it’s down to going only slightly out of the allocated memory elsewhere in the program. If, for example, you accidently write one cell beyond the end of an array it’ll be a small enough error when it happens it can still be within program memory, not spilling into system memory, and it won’t immediately crash the program but when you go to free memory (any memory, not just the memory you’ve misused) the whole thing just keels over. When you exit, the O/S attempts to free any memory cleanly and deallocate resources which is why this happens here.

If course, it’d be easy to say something like this must be the problem if it was just one program, calling a destructor on any object would have a similar effect in the right place. This might be worth trying anyway to see if there’s any effect.

Still, try it on another computer if you can. There are a range of issues that can be cause by flagging hardware and SDL is particularly likely to highlight such issues as it pokes itself into a lot of areas most software (like a word processor) just doesn’t need.

As for the debugging/release issue. This is something of a common problem. Debugging compiles have a lot of padding and don’t optimise (some optimisations can cause problems with debugging) nearly as much. Sometimes it’s a case of the compiler over-optimising, sometimes the compiler uses tricks in more optimised compiling that it doesn’t employ otherwise and people have found that this can be affected by hardware faults (another reason to check it on another computer).— On Tue, 3/24/09, mitch curtis wrote:

From: mitch curtis
Subject: [SDL] Program crashes in release build
To: sdl at lists.libsdl.org
Date: Tuesday, March 24, 2009, 7:38 AM
Hey. Not really sure what you mean, as I am not calling any
functions. All I have is main, and I #include
"SDL.h".
Trying it on another computer sounds like a good idea, but
what would it prove?


Hiyyya, it will be clear as day if you try to duplicate the
issue on another compiler and the another computer.
You don’t know what your functions are doing so you can
release everything, your compiler settings,
or what is returning what and why…did I forget anything?
lol lol lol no I’m just giving you the rasberry.

Just start with a known good program and add/replace one
part at a time (with full rebuilds)
till the error happens then you know where to look. Enjoy


Find out what?s new with your friends Download the new
Windows Live Messenger
http://download.live.com/_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey thanks for that Paul.

I tried it on my laptop and it throws an exception in the same place. It still runs fine in debug mode.

What else do you suggest? I think I am literally out of all options… I’ve been trying to share this game around for ages and it’s so discouraging to encounter this problem each time I get excited about it…

Any advice is appreciated.

Thanks.------------------------

OK, now that I’m properly awake again.

I’m not sure exactly which example you’re wanting the help with at the exact moment.
There’s the checkers example (I’m not seeing any use of destructors, this isn’t ObjC is it?) and the base example you’ve copied here.

Usually when I see an error like this, it’s down to going only slightly out of the allocated memory
elsewhere in the program. If, for example, you accidently write one cell beyond the end of an
array it’ll be a small enough error when it happens it can still be within program memory, not
spilling into system memory, and it won’t immediately crash the program but when you go to
free memory (any memory, not just the memory you’ve misused) the whole thing just keels over.
When you exit, the O/S attempts to free any memory cleanly and deallocate resources which is why this happens here.

If course, it’d be easy to say something like this must be the problem if it was just one program,
calling a destructor on any object would have a similar effect in the right place.
This might be worth trying anyway to see if there’s any effect.

Still, try it on another computer if you can. There are a range of issues that can be cause
by flagging hardware and SDL is particularly likely to highlight such issues as it pokes itself
into a lot of areas most software (like a word processor) just doesn’t need.

As for the debugging/release issue. This is something of a common problem. Debugging
compiles have a lot of padding and don’t optimise (some optimisations can cause problems
with debugging) nearly as much. Sometimes it’s a case of the compiler over-optimising,
sometimes the compiler uses tricks in more optimised compiling that it doesn’t employ otherwise
and people have found that this can be affected by hardware faults (another reason to check it on another computer).


View photos of singles in your area Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating.ninemsn.com.au%2Fchannel%2Findex.aspx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=EXT

Mybowlcut wrote:

Hey.

I’m having an issue with my program where it crashes upon exiting in the
release build. Funnily enough, this is the program:

#include “sdl.h”

int main(int argc, char* args[])
{
return 0;
}

Rather than post stuff that I’ve posted elsewhere, I’ll post the links to
the sites that I posted to about this problem:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

I’m completely dumbfounded… I don’t have any idea what to do about this.
It works fine in the debug build…

Cheers.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I have not had any luck with this problem…
http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/214f4813-6ba7-4940-94d3-eedc5bd18870/
this thread discusses an error that occurs in the same place as mine,
though.

Anyone have any ideas as to what this might be? I have tried it on my laptop
like was suggested but it does the same thing.–
View this message in context: http://www.nabble.com/Program-crashes-in-release-build-tp22654119p23057544.html
Sent from the SDL mailing list archive at Nabble.com.

Mybowlcut wrote:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

It works fine in the debug build…

What compiler, and what exact version of the compiler, are you using
to build this? What runtime library is being used? What are all the
compiler settings? Try changing settings and runtime libraries
between the debug and release build configurations to identify which
setting or runtime, or combination of the two, is triggering the
crash. Check to see if there are any updates available for your build
system and install them, see if the problem still occurs. Try with an
earlier release of your build system, see if the problem still occurs.

Run the code in the debugger, and examine the local variables right
before the exception is thrown. Is *onexitend the pointer that
contains 0x10 rather than a valid value? If so, set a memory
breakpoint on the address in onexitend (which could require examining
and understanding the source of the _decode_pointer function to do
properly) and identify when and why it is set to 0x10.

If it is not, then step through the assembly
instruction-by-instruction (rather than the code line-by-line),
watching the values of the registers, to identify when 0x10 is
actually dereferenced. Once you know where exactly the 0x10 is
happening, you can trace back in the assembly where in the code or in
memory the 0x10 came from, and set an appropriate breakpoint. Perhaps
*onexitend is a valid pointer but does not point to valid code – then
you would still want to set a memory breakpoint to see where onexitend
is set or reset, and if it is never properly set. There may be
something going screwy with a call to atexit() in SDL code.

It would be easier to deal with your issue if the relevant information
had been distilled and compiled into your post on the mailing list –
diving through the linked forum posts makes working out a hard problem
even harder, hence my late response. I am not the best person to
resolve this anyway, though, as I do not work with the microsoft sdk
and am rather new to SDL!

fuzzyTew wrote:

Mybowlcut wrote:

http://www.codeguru.com/forum/showthread.php?threadid=472394

http://www.gamedev.net/community/forums/topic.asp?topic_id=527261

It works fine in the debug build…

What compiler, and what exact version of the compiler, are you using
to build this? What runtime library is being used? What are all the
compiler settings? Try changing settings and runtime libraries
between the debug and release build configurations to identify which
setting or runtime, or combination of the two, is triggering the
crash. Check to see if there are any updates available for your build
system and install them, see if the problem still occurs. Try with an
earlier release of your build system, see if the problem still occurs.

Run the code in the debugger, and examine the local variables right
before the exception is thrown. Is *onexitend the pointer that
contains 0x10 rather than a valid value? If so, set a memory
breakpoint on the address in onexitend (which could require examining
and understanding the source of the _decode_pointer function to do
properly) and identify when and why it is set to 0x10.

If it is not, then step through the assembly
instruction-by-instruction (rather than the code line-by-line),
watching the values of the registers, to identify when 0x10 is
actually dereferenced. Once you know where exactly the 0x10 is
happening, you can trace back in the assembly where in the code or in
memory the 0x10 came from, and set an appropriate breakpoint. Perhaps
*onexitend is a valid pointer but does not point to valid code – then
you would still want to set a memory breakpoint to see where onexitend
is set or reset, and if it is never properly set. There may be
something going screwy with a call to atexit() in SDL code.

It would be easier to deal with your issue if the relevant information
had been distilled and compiled into your post on the mailing list –
diving through the linked forum posts makes working out a hard problem
even harder, hence my late response. I am not the best person to
resolve this anyway, though, as I do not work with the microsoft sdk
and am rather new to SDL!


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey thanks for the reply.

I was just experimenting then, and I found that excluding all the other
source files except main and bringing main down to this fixes the problem:

#include “sdl.h”

int main(int argc, char* argv[])
{
return 0;
}

Unfortunately, this leaves me with no Checkers game to play. I’ve been
deleting folders and files and rebuilding for almost an hour now… please
someone tell me I don’t have to do this for each source/header file in my
project. :)–
View this message in context: http://www.nabble.com/Program-crashes-in-release-build-tp22654119p23059506.html
Sent from the SDL mailing list archive at Nabble.com.

I was just experimenting then, and I found that excluding all the other
source files except main and bringing main down to this fixes the problem:

#include “sdl.h”

int main(int argc, char* argv[])
{
? ? ? ?return 0;
}

Unfortunately, this leaves me with no Checkers game to play. I’ve been
deleting folders and files and rebuilding for almost an hour now… please
someone tell me I don’t have to do this for each source/header file in my
project until I find the offending file. :slight_smile:

Ah, so it is indeed something outside main being linked in. Don’t
worry about header files. The problem is probably from the destructor
of an object defined statically or at file scope. Stepping through in
a debugger should help a lot. If that is not an option for some
reason, you’re stuck with either inspection of your source or adding
and removing .cpp files until you find which one causes it.

From the little I see, it really looks like one of your singletons
fails to initialise a pointer in its constructor. This singleton
probably defines a static instance of itself to save you from
initialising it, so it doesn’t matter whether main references it or
not. Do you have no backtrace of the exception?On Wed, Apr 15, 2009 at 9:57 AM, Mybowlcut wrote:

fuzzyTew wrote:

I was just experimenting then, and I found that excluding all the other
source files except main and bringing main down to this fixes the
problem:

#include “sdl.h”

int main(int argc, char* argv[])
{
? ? ? ?return 0;
}

Unfortunately, this leaves me with no Checkers game to play. I’ve been
deleting folders and files and rebuilding for almost an hour now…
please
someone tell me I don’t have to do this for each source/header file in my
project until I find the offending file. :slight_smile:

Ah, so it is indeed something outside main being linked in. Don’t
worry about header files. The problem is probably from the destructor
of an object defined statically or at file scope. Stepping through in
a debugger should help a lot. If that is not an option for some
reason, you’re stuck with either inspection of your source or adding
and removing .cpp files until you find which one causes it.

From the little I see, it really looks like one of your singletons
fails to initialise a pointer in its constructor. This singleton
probably defines a static instance of itself to save you from
initialising it, so it doesn’t matter whether main references it or
not. Do you have no backtrace of the exception?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Found it. The reason I’m not excited is because I am SCARED. Here is the
offending header file:

#ifndef SDL_TOOLS_H
#define SDL_TOOLS_H

#include “include_ticpp.h”

#include “SDL.h”

namespace SDL_Tools
{
// A readable/writeable SDL_Rect.
struct RW_SDL_Rect : public SDL_Rect//, public ticpp::Element_RW
{
RW_SDL_Rect();
RW_SDL_Rect(Sint16 x, Sint16 y, Uint16 w, Uint16 h);

	virtual void Read(ticpp::Element* element);
	virtual void Write(ticpp::Element* element) const;
};

}

#endif

Here is the offending source file:

#include “SDL_Tools.h”

SDL_Tools::RW_SDL_Rect::RW_SDL_Rect()
{
}

SDL_Tools::RW_SDL_Rect::RW_SDL_Rect(Sint16 x, Sint16 y, Uint16 w, Uint16 h)
{
this->x = x;
this->y = y;
this->w = w;
this->h = h;
}

void SDL_Tools::RW_SDL_Rect::Read(ticpp::Element* element)
{
// TODO: Uncomment! Is temp until release crash bug is found!
//ticpp::throw_on_bad_element(element, FILE);

x = element->GetAttribute<Sint16>("x");
y = element->GetAttribute<Sint16>("y");
w = element->GetAttribute<Uint16>("w");
h = element->GetAttribute<Uint16>("h");

}

void SDL_Tools::RW_SDL_Rect::Write(ticpp::Element* element) const
{
// TODO: Uncomment! Is temp until release crash bug is found!
//ticpp::throw_on_bad_element(element, FILE);

element->SetAttribute("x", x);
element->SetAttribute("y", y);
element->SetAttribute("w", w);
element->SetAttribute("h", h);

}
SDL_Tools::RW_SDL_Rect::RW_SDL_Rect(Sint16 x, Sint16 y, Uint16 w, Uint16 h)
{
this->x = x;
this->y = y;
this->w = w;
this->h = h;
}

The scary part is that include_ticpp.h is excluded from my build completely.
The calls to throw_on_bad_element produce linker errors if I uncomment them,
yet my code is happy to use ticpp::Element… can anyone please explain this
before my head explodes?

Cheers.> On Wed, Apr 15, 2009 at 9:57 AM, Mybowlcut <@mitch_curtis> wrote:

View this message in context: http://www.nabble.com/Program-crashes-in-release-build-tp22654119p23069172.html
Sent from the SDL mailing list archive at Nabble.com.

The scary part is that include_ticpp.h is excluded from my build completely.
The calls to throw_on_bad_element produce linker errors if I uncomment them,
yet my code is happy to use ticpp::Element… can anyone please explain this
before my head explodes?

It’s excluded from the build completely, as in from the project file?
If it’s still in the right location, it might get included nonetheless
(otherwise, the #include statement would probably cause a compilation
error, actually).

But it’s source file probably did get excluded from the build, hence
the linking errors. I suspect that the methods called that do work
fine are defined in the header file (so no need for the source file),
but I can’t tell for sure, since that header wasn’t posted.

That’d be another case where Valgrind might point you right at the
culprit, but you’d have to run your code on Linux to use that (Purify
would do too, but that’s US$870).On Wed, Apr 15, 2009 at 8:14 PM, Mybowlcut wrote:


http://pphaneuf.livejournal.com/

Pierre Phaneuf wrote:

It’s excluded from the build completely, as in from the project file?
If it’s still in the right location, it might get included nonetheless
(otherwise, the #include statement would probably cause a compilation
error, actually).

But it’s source file probably did get excluded from the build, hence
the linking errors. I suspect that the methods called that do work
fine are defined in the header file (so no need for the source file),
but I can’t tell for sure, since that header wasn’t posted.

That’d be another case where Valgrind might point you right at the
culprit, but you’d have to run your code on Linux to use that (Purify
would do too, but that’s US$870).


http://pphaneuf.livejournal.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey.

Both include_ticpp.h and include_ticpp.cpp are excluded (via right clicking
on them and excluding them from the build). All the files are still added in
the project and exist in the physical folder.

throw_on_bad_element is declared in the header and defined in the source
(not declared & defined in header). When I uncomment the call to it, I get
the link error. I thought that it should be a compile error too, since it
shouldn’t have any function declaration matching that name.

What kind of problem do you think this is though? I don’t use this structure
at all so I don’t understand why it would be crashing.

Any help is appreciated!–
View this message in context: http://www.nabble.com/Program-crashes-in-release-build-tp22654119p23095349.html
Sent from the SDL mailing list archive at Nabble.com.

Both include_ticpp.h and include_ticpp.cpp are excluded (via right clicking
on them and excluding them from the build). All the files are still added in
the project and exist in the physical folder.

I suspect that excluding a header file only does something like skip
any dependency analysis done on the file, or something of that nature.

From what you describe, the header file does indeed get included
successfully, otherwise the ‘#include “include_ticpp.h”’ line would
cause a fatal compilation error.

throw_on_bad_element is declared in the header and defined in the source
(not declared & defined in header). When I uncomment the call to it, I get
the link error. I thought that it should be a compile error too, since it
shouldn’t have any function declaration matching that name.

And the GetElement templated method is, of course, declared and
defined in the header, so when that one is used in your source file,
it works fine.

The compilation passes because the header file is indeed included,
despite what you think might happen when you “excluded” it. So it sees
the function declaration just fine, but then, at link time, can’t find
its implementation, since its missing the source file that defines it.

What kind of problem do you think this is though? I don’t use this structure
at all so I don’t understand why it would be crashing.

A further tip on the crash you’re getting: having an invalid access at
0x10 is probably a NULL pointer getting dereferenced, where the
pointer is expected to be at some structure or array, and the access
is to some member that’s 16 bytes into the structure (say, “int* foo =
NULL; foo[4]”). Why it’s happening in the libc atexit handler, that’s
a good question. Looking for uses of atexit in your program (including
the libraries) might be a start.On Fri, Apr 17, 2009 at 6:51 AM, Mybowlcut wrote:


http://pphaneuf.livejournal.com/