[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