[Bf-committers] 2.36 status...

Ton Roosendaal ton at blender.org
Tue Dec 14 14:05:21 CET 2004


Hi,

The conveyor file still crashes, Rob Haarsma noticed and I confirm  
here, but now a couple of seconds after Carstens head gets squished  
(like 15 seconds after start).

- I've committed a change in Makefile for solid to copy to correct  
locations. You have to run "make install" in extern/solid/ btw.

The status of Solid make is *higly* confusing, and definitely worth to  
be included in Sirdudes project :)

Status of regression files overview:

- clown.blend: gives errors on rotate (left/right arrow), displaying  
all grey
- eskimogame.blend: same as for clown
- mech-interactive.blend: same as for clown, but only after walking to  
edge
- MG1.blend doesnt show planes anymore

These errors didn't happen in 2.35 release. However,  
conveyor-head.blend crashes in 2.35 on same issue.

-Ton-




On 14 Dec, 2004, at 13:35, Ton Roosendaal wrote:

> Hi,
>
> I am not familiar with asserts, but i regular compile debug builds  
> with "-g", I suppose you mean something else? Do we have to compile  
> solid with asserts on or so? (N00b alert!)
>
> Remaining issues;
> - why did it run OK at your machine? Any clue we can learn from?
> - Gino likely won't respond - did he ever for you? - so maybe we could  
> check if DT_Count can better become signed int everywhere?
> - is, with this patch, the engine OK for release for you?
>
> Thanks,
>
> -Ton-
>
>
> On 14 Dec, 2004, at 10:30, Kester Maddock wrote:
>
>> 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.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
>>
>>
> ----------------------------------------------------------------------- 
> ---
> 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
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org



More information about the Bf-committers mailing list