SortVertices memcpy source and destination overlap

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

SortVertices memcpy source and destination overlap

Postby Boost113 » Thu Nov 20, 2014 9:32 am

Running valgrind memcheck on my program which uses Newton yields the following error:
Code: Select all
==16443== Source and destination overlap in memcpy(0x110fec70, 0x110fec70, 48)
==16443==    at 0x4C2B403: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16443==    by 0x54CF63E: SortVertices(double*, int, int, int, double) (dgTypes.cpp:229)
==16443==    by 0x54D02DC: dgVertexListToIndexList(double*, int, int, int, int*, double) (dgTypes.cpp:415)
==16443==    by 0x54D0496: dgVertexListToIndexList(float*, int, int, int, int, int*, float) (dgTypes.cpp:460)
==16443==    by 0x55C1D22: dgCollisionSphere::Init(float, dgMemoryAllocator*) (dgCollisionSphere.cpp:99)
==16443==    by 0x55C1F07: dgCollisionSphere::dgCollisionSphere(dgMemoryAllocator*, unsigned int, float) (dgCollisionSphere.cpp:45)
==16443==    by 0x5544181: dgWorld::dgWorld(dgMemoryAllocator*) (dgCollisionSphere.h:84)
==16443==    by 0x560C830: Newton::Newton(float, dgMemoryAllocator*) (NewtonClass.cpp:89)
==16443==    by 0x56020DD: NewtonCreate (Newton.cpp:181)
==16443==    by 0x5072576: Leviathan::PhysicalWorld::PhysicalWorld(Leviathan::GameWorld*) (PhysicalWorld.cpp:15)
==16443==    by 0x50723D1: Leviathan::NewtonManager::CreateWorld(Leviathan::GameWorld*) (NewtonManager.cpp:41)
==16443==    by 0x4FBDEEF: Leviathan::GameWorld::Init(Leviathan::GraphicalInputEntity*, Ogre::Root*) (GameWorld.cpp:235)
==16443==
==16443== Source and destination overlap in memcpy(0x110fe650, 0x110fe650, 32)
==16443==    at 0x4C2B403: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16443==    by 0x54CF5AF: SortVertices(double*, int, int, int, double) (dgTypes.cpp:295)
==16443==    by 0x54D02DC: dgVertexListToIndexList(double*, int, int, int, int*, double) (dgTypes.cpp:415)
==16443==    by 0x54D0496: dgVertexListToIndexList(float*, int, int, int, int, int*, float) (dgTypes.cpp:460)
==16443==    by 0x55C1D22: dgCollisionSphere::Init(float, dgMemoryAllocator*) (dgCollisionSphere.cpp:99)
==16443==    by 0x55C1F07: dgCollisionSphere::dgCollisionSphere(dgMemoryAllocator*, unsigned int, float) (dgCollisionSphere.cpp:45)
==16443==    by 0x5544181: dgWorld::dgWorld(dgMemoryAllocator*) (dgCollisionSphere.h:84)
==16443==    by 0x560C830: Newton::Newton(float, dgMemoryAllocator*) (NewtonClass.cpp:89)
==16443==    by 0x56020DD: NewtonCreate (Newton.cpp:181)
==16443==    by 0x5072576: Leviathan::PhysicalWorld::PhysicalWorld(Leviathan::GameWorld*) (PhysicalWorld.cpp:15)
==16443==    by 0x50723D1: Leviathan::NewtonManager::CreateWorld(Leviathan::GameWorld*) (NewtonManager.cpp:41)
==16443==    by 0x4FBDEEF: Leviathan::GameWorld::Init(Leviathan::GraphicalInputEntity*, Ogre::Root*) (GameWorld.cpp:235)


Changing the memcpy to memmove could fix the issue.

Here's an article related to this topic: http://lwn.net/Articles/414467/
Boost113
 
Posts: 26
Joined: Thu Oct 23, 2014 3:24 am

Re: SortVertices memcpy source and destination overlap

Postby Julio Jerez » Thu Nov 20, 2014 11:59 am

the code fragment is this
Code: Select all
            if (i <= j)   {
               if (i < j) {
                  dgFloat64 tmp[64];
                  memcpy (tmp, &vertexList[i * stride], stride * sizeof (dgFloat64));
                  memcpy (&vertexList[i * stride], &vertexList[j * stride], stride * sizeof (dgFloat64));
                  memcpy (&vertexList[j * stride], tmp, stride * sizeof (dgFloat64));
               }
               i++;
               j--;


I fixed by adding a check that I is less that j
using memmove is no a good idea because that function need to be as fast as it can be, and remove does not resolve to a fats version.
the array are always different with the exception when I == J in which copy the array to itself.
so a check is sufficient.

please sync to github,
thank you
Julio Jerez
Moderator
Moderator
 
Posts: 11040
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SortVertices memcpy source and destination overlap

Postby Boost113 » Thu Nov 20, 2014 1:28 pm

I pulled from github and tested again. This time it seems that the first error is now gone, but the other error is still there (the one on line 297)

Code: Select all
==28675== Source and destination overlap in memcpy(0x2e958450, 0x2e958450, 32)
==28675==    at 0x4C2B403: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28675==    by 0x54CF507: SortVertices(double*, int, int, int, double) (dgTypes.cpp:297)
==28675==    by 0x54D023C: dgVertexListToIndexList(double*, int, int, int, int*, double) (dgTypes.cpp:417)
==28675==    by 0x54D03F6: dgVertexListToIndexList(float*, int, int, int, int, int*, float) (dgTypes.cpp:462)
==28675==    by 0x55C0282: dgCollisionSphere::Init(float, dgMemoryAllocator*) (dgCollisionSphere.cpp:99)
==28675==    by 0x55C0467: dgCollisionSphere::dgCollisionSphere(dgMemoryAllocator*, unsigned int, float) (dgCollisionSphere.cpp:45)
==28675==    by 0x5544301: dgWorld::dgWorld(dgMemoryAllocator*) (dgCollisionSphere.h:84)
==28675==    by 0x560AD90: Newton::Newton(float, dgMemoryAllocator*) (NewtonClass.cpp:89)
==28675==    by 0x560063D: NewtonCreate (Newton.cpp:181)
==28675==    by 0x50726F6: Leviathan::PhysicalWorld::PhysicalWorld(Leviathan::GameWorld*) (PhysicalWorld.cpp:15)
==28675==    by 0x5072551: Leviathan::NewtonManager::CreateWorld(Leviathan::GameWorld*) (NewtonManager.cpp:41)
==28675==    by 0x4FBE0BF: Leviathan::GameWorld::Init(Leviathan::GraphicalInputEntity*, Ogre::Root*) (GameWorld.cpp:235)

The same fix would probably work here, too.
Boost113
 
Posts: 26
Joined: Thu Oct 23, 2014 3:24 am

Re: SortVertices memcpy source and destination overlap

Postby Julio Jerez » Thu Nov 20, 2014 1:43 pm

yes is the same, can you try until I do it tonight? I am at work now.
Julio Jerez
Moderator
Moderator
 
Posts: 11040
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SortVertices memcpy source and destination overlap

Postby Boost113 » Thu Nov 20, 2014 1:49 pm

There's no hurry to fix this as this error has been there for a while and everything seems to work fine. I only reported this now because a guy recommended reporting the issue.
Boost113
 
Posts: 26
Joined: Thu Oct 23, 2014 3:24 am

Re: SortVertices memcpy source and destination overlap

Postby Julio Jerez » Thu Nov 20, 2014 4:05 pm

ok I had a lithe time now, It is check in, please try again.
Let us keep Valgrin happy. :D
Julio Jerez
Moderator
Moderator
 
Posts: 11040
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SortVertices memcpy source and destination overlap

Postby manny » Thu Nov 20, 2014 4:23 pm

Julio Jerez wrote:ok I had a lithe time now, It is check in, please try again.
Let us keep Valgrin happy. :D

I've got vs2013 ultimate at work, I'll run it's static analyzer tomorrow if I get some free minutes.
http://www.instaLOD.io - InstaLOD - State of the art 3D optimization
manny
Site Admin
Site Admin
 
Posts: 131
Joined: Tue Feb 11, 2014 6:49 pm

Re: SortVertices memcpy source and destination overlap

Postby Boost113 » Fri Nov 21, 2014 11:09 am

Okay, so it seems that the errors I posted about are gone. But I just noticed another error, which I originally thought to be part of an Ogre error. Valgrind complains about an unitialized variable:
Code: Select all
==8072== Thread 31:
==8072== Conditional jump or move depends on uninitialised value(s)
==8072==    at 0x55B2B68: dgWorldDynamicUpdate::UpdateDynamics(float) (dgWorldDynamicUpdate.cpp:169)
==8072==    by 0x5542F6C: dgWorld::StepDynamics(float) (dgWorld.cpp:989)
==8072==    by 0x55430D0: dgWorld::TickCallback(int) (dgWorld.cpp:1030)
==8072==    by 0x54D8993: dgMutexThread::Execute(int) (dgMutexThread.cpp:62)
==8072==    by 0x54CDF04: dgThread::dgThreadSystemCallback(void*) (dgThread.cpp:245)
==8072==    by 0x8247EE4: start_thread (pthread_create.c:309)
==8072==    by 0xA843B8C: clone (clone.S:111)

I split the line in two and it seems that
Code: Select all
world->m_amp
is the one which is uninitialized.
Boost113
 
Posts: 26
Joined: Thu Oct 23, 2014 3:24 am

Re: SortVertices memcpy source and destination overlap

Postby Julio Jerez » Fri Nov 21, 2014 12:20 pm

yes, fixed.
Julio Jerez
Moderator
Moderator
 
Posts: 11040
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SortVertices memcpy source and destination overlap

Postby Boost113 » Sat Nov 22, 2014 9:07 am

Valgrind no longer complains about anything so everything's fixed now.
Thanks for taking the time to fix this
Boost113
 
Posts: 26
Joined: Thu Oct 23, 2014 3:24 am


Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 2 guests