Pre-processor macros causing segfaults

[nempo]

Hello,

so, I'm playing around with pre-processor macros, and I've come across behaviour I can't quite figure out. I've written these macros to trace the execution path of my program, problem is, when I activate them, the program just seg-faults and I can't for the life of me figure out what is causing this, maybe anyone on here has a clue.

Here are the two main files:

#ifndef DEBUG_HPP__
#define DEBUG_HPP__

#define DEBUG

#ifdef DEBUG
	#include <fstream>

	#define LOCATION "(File: " << __FILE__ << ", Function: " << __FUNCTION__ << "(...), Line: " << __LINE__ << ")"
	#define SPACE std::string(lvl*2, ' ')

	#define BEGIN {															\
					extern unsigned int lvl;								\
					extern std::ofstream log;								\
																			\
					{														\
						log << SPACE << "--> "								\
							<< __FILE__ << "::"								\
							<< __FUNCTION__ << "(...)"						\
							<< std::endl;									\
						lvl++;												\
					}

	#define PING															\
					{														\
						log << SPACE										\
							<< "PING "										\
							<< LOCATION										\
							<< std::endl;									\
					}

	#define PRINT(x)														\
					{														\
						log << SPACE										\
							<< x << " "										\
							<< LOCATION										\
							<< std::endl;									\
					}

	#define RETURN(x)														\
					{														\
						lvl--;												\
						log << SPACE										\
							<< "<-- "										\
							<< __FILE__ << "::" << __FUNCTION__ << "(...)"	\
							<< std::endl;									\
					}														\
																			\
					return x;

	#define END																\
					{														\
						lvl--;												\
						log << SPACE										\
							<< "<-- "										\
							<< __FILE__ << "::" << __FUNCTION__ << "(...)"	\
							<< std::endl; lvl--;							\
					}														\
				}

#endif /*DEBUG*/

#ifndef DEBUG
	#define BEGIN {
	#define PING
	#define PRINT(x)
	#define RETURN(x) return x;
	#define END }
#endif /*DEBUG*/

#define DELETE(x) delete x; x = 0;

#endif /*DEBUG_HPP__*/

Ye, the indentation above sucks but hope you can understand it.

#include <fstream>
#include "Debug.hpp"

#ifdef DEBUG
unsigned int lvl = 0;
std::ofstream log("log.log");
#endif /*DEBUG*/

Here is a sample function which makes use of the macros.

void function(int arg)
BEGIN
PRINT(arg)
END

Thanks in advance, Jimmy.

[matsp]

Seems to work for me.

--> main.cpp::function(...)
  7 (File: main.cpp, Function: function(...), Line: 6)
<-- main.cpp::function(...)

--
Mats

[nempo]

Right, guess my example wasn't very error-prone, the problem might not lie in the macros them self I guess, but instead of something else interacting with the macros in some unexpected way. I need to do some more investigating here.

[nempo]

Half-figured it out, seems that I had used the BEGIN and END macros on class constructors. And this somehow caused a few problems.
Are the class constructors executed before the 'main' function starts executing?

There was also a small error in the END macro causing the 'lvl' variable to fall out of sync.

[CornedBee]

The constructors of global objects are executed before main() starts, yes. And the objects in different translation units are initialized in unspecified order, so it could easily be that you have some log output before the log file is opened.

[matsp]

Half-figured it out, seems that I had used the BEGIN and END macros on class constructors. And this somehow caused a few problems.
Are the class constructors executed before the 'main' function starts executing?

There was also a small error in the END macro causing the 'lvl' variable to fall out of sync.

Yes, class constructors for global/static objects are executed before YOUR CODE inside main. It may well be that the compiler adds a bit of compiler- generated code inside main() itself [gcc appears to call a function, and I think it's purpose is to call all global constructors].

As CornedBee says, global constructors are executed in an undefined order [most likely "first found first", but not guaranteed by any means].

You can probably solve this by using a singleton pattern for your logfile object.
http://en.wikipedia.org/wiki/Singleton_pattern

--
Mats

[nempo]

Cheers for the help and clearing things up.