Crystal Space
Welcome, Guest. Please login or register.
October 22, 2014, 05:47:14 am

Login with username, password and session length
Search:     Advanced search
9010 Posts in 2044 Topics by 8784 Members
Latest Member: Beaburleson
* Home Help Search Login Register
  Show Posts
Pages: [1]
1  Crystal Space Project Development / Bug Reports / Re: CVS Mac OS X (10.4.2) - Segmentation Fault on demo apps on: November 15, 2005, 04:35:58 am
This is because gcc 4.0 has problems with CS, using gcc 3, or newer gcc 4.0 is the solution to this problem.


Yes, XCode 2.2 (gcc 4.0.1) works.
2  Crystal Space Project Development / Development Discussion / CVS Tutorial/Recipe Book for Group Projects on: November 14, 2005, 08:20:46 pm
I just posted this on another site. Probably won't be useful to the old hands but may help developers new to SoureForge/CVS. The examples may look familiar.

http://www.astahost.com/cvs-basics-t9134.html
3  Crystal Space Project Development / Development Discussion / Re: non-virtual destructors in pure-virtual base classes, TIME-BOMB on: November 14, 2005, 07:25:57 pm
The simplest solution is to simply allocate the iPolygonMesh implementations from the heap. That should resolve the issue nicely.

On the other hand, I was looking for a solution which would avoid these extra heap allocations (which might get expensive when a lot of meshes are in play), but had difficulty discovering a workable solution.

(I did, by the way, in my partial solution remove the capability to perform that long-deprecated SCF query.)


I would recommend the heap allocation. If it becomes a performance issue, we can implement a custom allocator (not fun, but effective).
4  Crystal Space Project Development / Development Discussion / Re: non-virtual destructors in pure-virtual base classes, TIME-BOMB on: November 14, 2005, 07:24:12 pm
There are a couple related issues:

(1) Many of the meshes have iPolygonMesh implementations embedded within them, yet the iPolygonMesh implementations are not marked as SCF embedded objects. This means that the reference counts on these embedded objects are independent of the reference counts of the objects in which they are embedded. This can lead to really awful situations where either the embedded and/or the embedding object are destroyed independently of the other. In fact, this is what happens with Thing. The Thing mesh object is destroyed while its csObjectModel is still holding references to the iPolygonMesh embedded in the Thing object. Later, when the csObjectModel releases those references, the embedded iPolygonMeshes are destroyed a second time. This bug occurs *all* the time so it is not caused by having virtual destructors; virtual destructors merely allow the bug (which is constantly occurring) to manifest as an actual crash. This situation *must* be fixed in all meshes. Having embedded objects with independent reference counts is about the biggest NO-NO one can imagine. Also, this design flaw isn't limited just to iPolygonMesh implementations. The same problem is repeated in the meshes for some of the implementations of the shader-related interfaces.
<snip>

So what is happening is that when you destruct an already destructed object, its memory may have already been reused and the D/VMT pointer is bad (or arbitrary) which leads to calling random virtual methods and a messy crash. I can look at some of this, but, not understanding the history and design, it will take me a bit (though this discussion is helping). Two possibilities spring to mind, one is to reorganize the references. It sounds like you are already deprecating/ removing some old methods which will make this easier; the second is to add indirection to avoid the double-death. Basically, bury the iPolygonMesh implementation deeper so that 'destroying it' just destroys a wrapper (which decrements a reference) and the second destruction actually does the job. Double-indirection may be a good immediate solution with the reorg happening  a little slower. The double-indirection can be modified to add some assertions to help check that the solution works.

One thing I have found to greatly help in other projects is gratuitous mutilation: visibly damage an object when it is destructed in a way which can be tested by an assertion. Thus the program will fail on the first illegal access after destruction rather than when the memory is reclaimed. It cannot protect every instance but detects 99% of them. Have an inlinable 'checkvalid()' method in the base class which can be called from major operations. It will not generally affect performance and assertions can be macroed out.
5  Crystal Space Project Development / Development Discussion / useful shell script - automating build, cvs tasks on: November 14, 2005, 08:35:57 am
This is a bash shell script I am using while working on Crystal Core. It may be a little over-the-top, but I like automation. It keeps me from making (as many) stupid mistakes. It sets up my (project specific) cvs enviroment, automates configuration of the projects, sets up my run environment and downloads the crystal core data files (using wget). Also, by setting cdable vars in my shell, the variables make tree navigation easier. I put it in my project directory just above my checkouts and dot it in when starting work.

'cvscheck' (which this uses) is a shell function in my profile:

function cvscheck() {
    cvs -f -qn update -d |grep -v '^?'
}

Anywho, if anyone finds it useful, they are free to play with it. Building/rebuilding cs is a bit of a pain; this makes it a bit easier.

# Environment settings for crystal space work.
# Dot this in before working (. ./dotme)

# Functions:
# For configuring packages: configure-cs, configure-cel, configure-ccore
# dlcoredata: downloads CrystalCore data from support website to correct dirs
#   (needs wget)
# csupdates: checks for available updates in cvs (all three project trees)
# NOTE: these functions, except csupdate all leave you in their working
#   directory when done.

# Change options for configuring here:
#_____________________________________
private_inst_dir=/Users/evought/local
fink_dir=/sw
sourceforge_user=ericvought

export AUTOCONF_PREFIX=$private_inst_dir
export WHERE_JPEG=$fink_dir
export WHERE_PNG=$fink_dir
export WHERE_CPP_UNIT=$private_inst_dir
export WHERE_ODE=$private_inst_dir

#_____________________________________
# Project locations
# suggest: "shopt -s cdable_vars" in your bash startup script
export CRYSTAL=$PWD/cs
export CEL=$PWD/cel
export CCORE=$PWD/crystalcore
export CSTREE=$PWD

# CVS ROOTs
export CVS_CRYSTAL=:ext:$sourceforge_user@cvs.sourceforge.net:/cvsroot/crystal
export CVS_CEL=:ext:$sourceforge_user@cvs.sourceforge.net:/cvsroot/cel

export CCORE_DATA_URL='http://www.crystalspace3d.org/support/crystalcore'
export CCORE_DATA="entities.zip models.zip game_textures.zip"
export CCORE_LEVELS="textures.zip cc_comcenter_in.zip cc_ground.zip cc_ground_terr.zip cc_lab.zip"

#_____________________________________
# Shell functions to configure packages
function configure-cs() {
  cd $CRYSTAL
  ./configure \
    --prefix=$AUTOCONF_PREFIX \
    --with-jpeg=$WHERE_JPEG --with-png=$WHERE_PNG \
    --with-ode=$WHERE_ODE \
    --with-cppunit=$WHERE_CPP_UNIT
} # configure-cs

function configure-cel() {
  cd $CEL
  ./configure \
    --prefix=$AUTOCONF_PREFIX \
    --with-cppunit=$WHERE_CPP_UNIT
} # configure-cel

function configure-ccore() {
  cd $CCORE
  ./configure \
    --prefix=$AUTOCONF_PREFIX \
    --with-cppunit=$WHERE_CPP_UNIT
} # configure-ccore

#_______________________________________
# Downloads game files from cs support site to correct ccore directories
function dlcoredata() {
  cd $CCORE/data
  for archive in $CCORE_DATA
  do
    wget -nc $CCORE_DATA_URL/$archive
  done

  cd levels
  for archive in $CCORE_LEVELS
  do
    wget -nc $CCORE_DATA_URL/$archive
  done
} # dlcoredata

#_____________________________________
# Check for updates in all three packages
# Returns to starting directory.
function csupdates() {
  pushd $CRYSTAL
  echo
  echo "[CRYSTAL]:"
  echo
  cvscheck
  popd
  pushd $CEL
  echo
  echo "[CEL]"
  echo
  popd
  pushd $CCORE
  echo
  echo "[CCORE]"
  echo
  popd
} # csupdates

6  Crystal Space Project Development / Development Discussion / non-virtual destructors in pure-virtual base classes, TIME-BOMB on: November 14, 2005, 07:06:27 am
I am looking at the spew of warnings in CEL about non-virtual destructors. The CS psuedo-stable has the same warnings, but it has been turned off via a compiler option in the recent cvs versions. In the code, (e.g.: cs/include/csutil/scf_interface.h, I see:

  // Jorrit: removed the code below as it causes 'pure virtual' method
  // calls to happen upon destruction.
  //protected:
  //// Needed for GCC4. Otherwise emits a flood of "virtual functions but
  //// non-virtual destructor" warnings.
  //virtual ~iBase() {}

and this seems typical of about twenty gazillion files in the various codebases. What is going on here, is there a problem which needs solving? This is not a GCC 4.x problem. GCC gives the warning because the code is explosively dangerous without the virtual destructor. It can result in severe memory/resource leaks and segfaults.

What happens is that without the declared virtual destructor, the compiler is required (by the standard) to generate a destructor for you. The generated destructor is empty and non-virtual. Now, you have a pointer to a descendent of iBase held in an iBase pointer. The child class has its own destructor, which may, for instance, release critical OpenGL resources. When the pointer is deleted and the object is destructed, because the destructor is non-virtual, the reference is clipped: the auto-generated iBase destructor gets called instead of the subclass destructor. Not having a virtual destructor only makes sense if the class will *never* be subclassed, and since iBase (and many of these classes) have pure-virtual functions, this is obviously not the case. Aside from leakage, you can end up with really hairy problems because of objects not cleaning up state and lead to a core-dump several bounces down the road. If you use multiple inheritance anywhere, you can end up with nasty memory corruption.

I assume the calls were commented out for a reason. Jorrit refers to a 'pure virtual' call happening (presumably with subsequent core dump). This is usually caused by bad casts and is often fixable (or at least diagnosable) by using appropriate checked cast templates (static_cast<>(), dynamic_cast<>(), reinterpret_cast<>() and friends) and a bit of code reorg. Is this something you would like tracked down and fixed?
7  Crystal Space Development / Support / Re: Mac OS X (10.4.3 with XCode 2.2) breakage csInstallationPathsHelper::GetAppPath on: November 13, 2005, 08:55:28 am
Allrighty. To cap off this lovely conversation with myself:

I ended up putting getAppFilename(..) into its own module. The Mac implementation is different and correct. The UNIX Jamfile now pulls in the generic GetAppFIlename(..). Tested (on OS X) and committed changes. If this breaks anything, it will break the UNIX build.
8  Crystal Space Development / Support / Re: Mac OS X (10.4.3 with XCode 2.2) breakage csInstallationPathsHelper::GetAppPath on: November 13, 2005, 07:20:08 am
It looks like this change to OSXGetDirs.cpp was the culprit:

revision 1.6
date: 2005/11/06 21:30:19;  author: vknecht;  state: Exp;  lines: +11 -0
        - Vincent Knecht made the following changes:
          - Added a csInstallationPathsHelper::GetAppFilename() method which
            returns a native executable filename given a basename.
          - Modified 'startme' to read demos and star settings from its
            configuration file.

I do not know which version to keep yet. If Knecht's function is correct, then the generic apppath.cpp will need to be split so that GetAppFilename is available separately, otherwise 1.6 will need to be backed out again.
9  Crystal Space Development / Support / Mac OS X (10.4.3 with XCode 2.2) breakage csInstallationPathsHelper::GetAppPath on: November 13, 2005, 07:12:59 am
In the latest CVS, linker breaks on Mac OS X 10.4.3 with XCode 2.2 (GCC 4.0.1). The psuedo-stable builds fine.

The problem is with a multiple define of csInstallationPathsHelper::GetAppFilename(char const*). It is defined in both csutil/generic/apppath.cpp and in csutil/macosx/OSXGetDirs.cpp.

The Mac OS X Jamfile adds apppath.cpp to CSUTIL.GENERIC, which causes the conflict, but removing it causes the link to fail when GetAppPath(..) is undefined, so some rearrangement is necessary. I think the fix is to remove GetAppFilename(..) from OSXGetDirs.cpp, but I am not yet certain.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 4.197 seconds with 16 queries.