Crystal Space
Welcome, Guest. Please login or register.
September 25, 2017, 10:56:47 am

Login with username, password and session length
Search:     Advanced search
9054 Posts in 2047 Topics by 74517 Members
Latest Member: Gurshalanyin644
* 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.
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.

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:

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

export CVS_CRYSTAL=:ext:$
export CVS_CEL=:ext:$

export CCORE_DATA_URL=''
export CCORE_DATA=""
export CCORE_LEVELS=""

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

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

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

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

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

# Check for updates in all three packages
# Returns to starting directory.
function csupdates() {
  pushd $CRYSTAL
  echo "[CRYSTAL]:"
  pushd $CEL
  echo "[CEL]"
  pushd $CCORE
  echo "[CCORE]"
} # 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.
  //// 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 5.143 seconds with 17 queries.