swordlegend / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

Crashes inside dtNavMesh::getTileAt #190

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Unknown

What version of the product are you using? On what operating system?
Rev 254 on *nix

Please provide any additional information below.

dtNavMesh::getTileAt is sometimes returning overflowed integers, probably 
caused by the floorf 
(http://pubs.opengroup.org/onlinepubs/009604499/functions/floor.html). 
According to my crash log are the choords valid until they return from this 
function.

Example:

    int tx;
    int ty;
    float point[3] = {74.771492f, -22.0912132f, -184.045013f};
    calcTileLoc(point, &tx, &ty);
->
0x0000000001331389 in dtNavMesh::getTileAt (this=0x2aaadcc10160, x=-1, 
y=-2147483648) at dep/recastnavigation/Detour/DetourNavMesh.cpp:826
826             dtMeshTile* tile = m_posLookup[h];

Notice the -2147483648 == -HUGE_VAL, obvious overflow...
Is this because of my code or problems inside getTileAt?

Thanks

Original issue reported on code.google.com by jesper.m...@gmail.com on 29 Dec 2011 at 11:53

GoogleCodeExporter commented 9 years ago
Hi,
If you can repro the crash, can you tell the values of : m_orig[0], m_orig[1], 
m_tileWidth and m_tileHeight?
Are you intentionally using negative tile coordinates?

Also, what is the value of h when it crashes?

--mikko

Original comment by memono...@gmail.com on 29 Dec 2011 at 12:13

GoogleCodeExporter commented 9 years ago
Do we have any updates on this issue? i guess it only happens with negative 
tile coordinates (wich on my case and the OP case, are intended).

Original comment by rubenmu...@hotmail.com on 20 Jul 2012 at 2:40