[Bf-committers] 2.36 status...

Kester Maddock Christopher.Maddock.1 at uni.massey.ac.nz
Tue Dec 14 10:30:36 CET 2004


Hi Jacques,

That is what the assert is supposed to check for - I guess no one compiles 
debug builds.

If this works for most people, commit it and send it to Gino for help.

Kester


On Monday 15 November 2004 16:10, Jacques Beaurain wrote:
> Hi,
>
> Tried it over here on Windows XP (Visual Studio build) and managed to
> crash using #2006 instructions. The call stack is below for those that
> knows the game engine a bit better than I do (I don't at all, but would
> like to). It is kind of hard to figure out what went wrong (although the
> routine does look a bit unsafe to me; also explained below). I stop in
> the SumoPhysicsController destructor a couple of times after hitting
> escape and then crash here because I am inside a member function of an
> invalid BP_Endpoint object.
>
>     blender.exe!BP_Endpoint::getType()  Line 69 + 0x3 bytes    C++
>      blender.exe!BP_EndpointList::stab(const BP_Endpoint & pos={...},
> BP_ProxyList & proxies={...})  Line 44 + 0x8 bytes    C++
>      blender.exe!BP_EndpointList::range(const BP_Endpoint & min={...},
> const BP_Endpoint & max={...}, unsigned short & first=7, unsigned short
> & last=62, BP_ProxyList & proxies={...})  Line 86 + 0x10 bytes    C++
>      blender.exe!BP_EndpointList::removeInterval(unsigned short first=7,
> unsigned short last=62, BP_ProxyList & proxies={...})  Line 155    C++
>      blender.exe!BP_Proxy::remove(BP_ProxyList & proxies={...})  Line 63
> + 0x37 bytes    C++
>      blender.exe!BP_Scene::destroyProxy(BP_Proxy * proxy=0x04dd0648)
> Line 55    C++
>      blender.exe!BP_DestroyProxy(BP_SceneHandle__ * scene=0x0367e398,
> BP_ProxyHandle__ * proxy=0x04dd0648)  Line 56    C++
>      blender.exe!DT_Scene::removeObject(DT_Object & object={...})  Line
> 129 + 0x17 bytes    C++
>      blender.exe!DT_RemoveObject(DT_SceneHandle__ * scene=0x0465d3d0,
> DT_ObjectHandle__ * object=0x04dd0518)  Line 310    C++
>      blender.exe!SM_Scene::remove(SM_Object & object={...})  Line 150 +
> 0x14 bytes    C++
>      blender.exe!SumoPhysicsController::~SumoPhysicsController()  Line
> 71    C++
>      blender.exe!KX_SumoPhysicsController::~KX_SumoPhysicsController()
> Line 217 + 0x20 bytes    C++
>      blender.exe!KX_SumoPhysicsController::`scalar deleting
> destructor'()  + 0x14 bytes    C++
>      blender.exe!SG_IObject::~SG_IObject()  Line 165 + 0x27 bytes    C++
>      blender.exe!SG_Spatial::~SG_Spatial()  Line 91 + 0x24 bytes    C++
>      blender.exe!SG_Node::~SG_Node()  Line 66 + 0x1d bytes    C++
>      blender.exe!SG_Node::`scalar deleting destructor'()  + 0x14
> bytes    C++
>      blender.exe!KX_Scene::RemoveNodeDestructObject(SG_IObject *
> node=0x035c4208, CValue * gameobj=0x03670958)  Line 357 + 0x20 bytes    C++
>      blender.exe!KX_SceneDestructionFunc(SG_IObject * node=0x035c4208,
> void * gameobj=0x03670958, void * scene=0x0466ff78)  Line 91    C++
>      blender.exe!SG_IObject::ActivateDestructionCallback()  Line 129 +
> 0x1a bytes    C++
>      blender.exe!SG_Node::Destruct()  Line 128    C++
>      blender.exe!KX_Scene::RemoveObject(CValue * gameobj=0x03670958)
> Line 644    C++
>      blender.exe!KX_Scene::~KX_Scene()  Line 174    C++
>      blender.exe!KX_Scene::`scalar deleting destructor'()  + 0x14
> bytes    C++
>      blender.exe!KX_KetsjiEngine::StopEngine()  Line 836 + 0x21 bytes   
> C++ blender.exe!StartKetsjiShell(ScrArea * area=0x046956dc, char *
> scenename=0x046a00c6, Main * maggie=0x046899bc, int
> always_use_expand_framing=1)  Line 335    C++
>      blender.exe!start_game()  Line 473 + 0x1b bytes    C
>      blender.exe!do_view3d_buttons(short event=152)  Line 3570    C
>      blender.exe!do_headerbuttons(short event=152)  Line 2072 + 0x15
> bytes    C
>      blender.exe!scrarea_dispatch_header_events(ScrArea *
> sa=0x04693634)  Line 488 + 0xa bytes    C
>      blender.exe!screen_dispatch_events()  Line 963 + 0x9 bytes    C
>      blender.exe!screenmain()  Line 1216    C
>      blender.exe!main(int argc=1, unsigned char * * argv=0x01082da0)
> Line 604    C
>      blender.exe!mainCRTStartup()  Line 283 + 0x12 bytes    C
>      kernel32.dll!7c816d4f()
>      kernel32.dll!7c8399f3()
>
> Looking  at  BP_EndpointList::stab, it  i (unsigned short) has been
> decremented from 0 and now points to an invalid location (65535) in the
> endpoint list. However count is still 1 and the loop continued which
> caused the crash. With limited knowledge and time to investigate this at
> the moment a quick fix seems to just do what I did in the patch
> attached, I compiled with it and it seemed to resolve the problem, but I
> did not try the other issues though. I did not look into this because of
> time constraints right now and with my limited knowledge I expect that
> something elsewhere is wrong, but hopefully someone can find this
> information useful.
>
> Cheers,
> Jacques
>
> BTW, the game seems to start okay, but then the screen goes grey after I
> move around a bit (fall through the floor?) and when I hit escape the
> abort happens.
>
> Ton Roosendaal wrote:
> > Hi,
> >
> > Went with Kester today over engine status. He advised to release,
> > since  for him the engine runs better than ever. :)
> >
> > The unsolved issue is still why we get crashes... the version running
> > at Kester's survives bug #2006 and the conveyorbelt.blend without
> > issues. All other tests done until now give crashes for it in release
> > candidates built for Linux, OSX and Windows.
> >
> > Kester tried both building with scons and make, both run fine. CVS is
> > on same level, no files forgotten to commit, no weird options for
> > compiling. In short, a mystery still.
> >
> > If people have time to help, try to collect clues. Like is Solid
> > really  compiled OK? Is the intern/moto/ really OK? Full clean
> > recompile done?  No cvs sticky tags sneaked in?
> >
> > Kester; had no time to ask (darn timezones!) but can you upload your
> > binary build?
> >
> > Clueless in Amsterdam,
> >
> > -Ton-
> >
> > ------------------------------------------------------------------------
> > --
> > Ton Roosendaal  Blender Foundation ton at blender.org
> > http://www.blender.org
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers

-- 
The rule on staying alive as a program manager is to give 'em a number or 
give 'em a date, but never give 'em both at once.


More information about the Bf-committers mailing list