debug mode brokenness

[Holomorph]

I was having some crashes that I did not understand when linking my game with the debug build of gne.  I traced it to  a null pointer from
params->sConnPtr = SyncConnection::create( this_.lock() );
in ClientConnection.cpp and it dies a couple of more levels down because the this_.lock()  is, I think returning a null pointer.  

Anyway, I thought I was doing something wrong for a while, but eventually tried building the simplehello app and linked with -gned rather than -gne.  It crashed (segfault).  so it appears something is screwy with the debug build.

[Gillius]

If that really returns null, that is very bad.  The this_.lock() shouldn't be able to fail because that would mean the method was executing in an deleted object, or that this_ was never initialized.  But you say that none of the examples that I made work at all in debug mode?  That is very particular.

Boy I wish that there was a team supporting this.  Truthfully I have not examined GNE code at all for a year and a half.  I'll see if I have time tonight to take a peek at this and the assert issue that I forgot about earlier.

[Holomorph]

yea, I don't entirely trust the debugger on this one, and I wasn't able to understand why it was happening.  I'll keep my eye's out for any other bugs, and fixes if I can figure them out.  Of course now that I have things connecting and actually sending packets (linking with the release build), I sort of doubt I'll run into much more.  GNE certainly saves me a lot of work trying to write good network code, something I know very little about

Ok, so the example program I built and linked with the debug build of gne was a ever so slightly modified version of simplehello.  I basically removed the prompting for adress and port, and changed the game info so I could quickly test connecting a client to my game.  If I get a chance I'll try linking some of the other examples with libgned and see if they choke or not.

[takbal]

Perhaps the topic is a bit old, but I have almost the same problem here.

I simply define the DEBUGMODE symbol in the makefile, then compile GNE and run exhello. The server brokes with illegal instruction (SIGILL signal) when creating the server side part of a connection.

I use GNE 0.70 and 64-bit SUSE 10.1 Linux with gcc 4.1.0.

[takbal]

The problem could be traced back to a boost incompatibility with GNE.
Undefining the _DEBUG symbol while compiling solves the problem, or at least I am able to trace the function calls now.

[Gillius]

I'm a little confused here as to what is going on, but is this something I need to correct in GNE? Is it a flag conflict? The GNE in subversion uses a new build system -- is it still affected?

[takbal]

The problem was with the debug message printing functions, which could not take a boost smart pointer directly as an argument. Perhaps they could earlier. If you try to compile the code with debug enabled, gcc will complain during compilation at 3 lines in the code that the call will fail. Adding .get() to those references, for example, fixes everything.

[Gillius]

Oh, OK that definitely sounds like one of the many bugs/compiler issues I've fixed from 0.70 to the current (unreleased) version.

I noticed this in the changelog:

"Fixed crashing bug in SyncConnection when trying to print a SmartPtr with debugging macros."

Does that describe where you found the problem? If there are other places I need to call get can you point them out to me? It's hard to find them unless you actually run that portion of the code in debug. GNE used to use all raw pointers and in GNE 0.70 I had just converted to use smart pointers so I probably missed a few ".get()"s because they don't show as compile errors.