OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

memory corruption when using ref_ptr on osg objects


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Build system [build]
View previous topic :: View next topic  
Author Message
nicow
Newbie


Joined: 27 Jul 2014
Posts: 5

PostPosted: Sun Jul 27, 2014 7:02 pm    Post subject:
memory corruption when using ref_ptr on osg objects
Reply with quote

Hi,

I have been using OSG for a month now, and everything was fine. Recently I had to recompile the sources to include a new plugin, and since then I get a crash everytime I use an object with a ref_ptr.

I am running a 64 bits debian with OSG 3.0.1. I am using two different builds of OSG : one with dynamic libraries, one with static ones. This should not matter much (since my programs crash with both) except that they are both compiled with the extra option fPIC for position independent code (this seems mandatory for using static libraries one amd64 architectures). The static build has a few adjustments, but except for the above mentioned fPIC the dynamic one has no modification.

The problem started so : I needed the TrueTypeFont plugin to work, so I installed a few dev packages (freeglut-dev and one or two ohter ones) and built from the sources using the exact same process I had used before. From then on, my programs compiled with the new libraries (both dynamic and static) crash with the following error :
Code:

*** glibc detected *** ./a.out: malloc(): memory corruption: 0x00000000014f9cc0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76e46)[0x7f3c83ffee46]
/lib/x86_64-linux-gnu/libc.so.6(+0x79eb3)[0x7f3c84001eb3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f3c84003cd0]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1d)[0x7f3c83a8507d]
./a.out[0x6281c0]
./a.out[0x41e30b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f3c83fa6eed]
./a.out[0x41e1e9]
======= Memory map: ========
...
...
...
Aborted




Here is the (part of) the output of valgrind :

Code:

==4240== Memcheck, a memory error detector
==4240== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4240== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4240== Command: ./a.out
==4240==
==4240== Invalid write of size 8
==4240==    at 0x62A8AE: osg::ref_ptr<osg::Camera::DrawCallback>::ref_ptr() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x627FF3: osg::Camera::Camera() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x41E2E6: main (test.cpp:10)
==4240==  Address 0x84602b8 is 0 bytes after a block of size 824 alloc'd
==4240==    at 0x4C286E7: operator new(unsigned long) (vg_replace_malloc.c:287)
==4240==    by 0x41E2DB: main (test.cpp:10)
==4240==
==4240== Invalid write of size 8
==4240==    at 0x62A8AE: osg::ref_ptr<osg::Camera::DrawCallback>::ref_ptr() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x628005: osg::Camera::Camera() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x41E2E6: main (test.cpp:10)
==4240==  Address 0x84602c0 is 8 bytes after a block of size 824 alloc'd
==4240==    at 0x4C286E7: operator new(unsigned long) (vg_replace_malloc.c:287)
==4240==    by 0x41E2DB: main (test.cpp:10)


and here is the code it was ran on:

Code:

#include <osgViewer/Viewer>
#include <osg/ref_ptr>
#include <osg/Referenced>
#include <osg/Camera>
USE_GRAPHICSWINDOW()
int main( int argc, char** argv )
{

osg::ref_ptr<osgViewer::Viewer> viewer = new osgViewer::Viewer();
osg::ref_ptr<osg::Camera> cam = new osg::Camera();

return viewer->run();
}



What is weird is that only the objects from the osg:: namespace seem to crash the program. The ref_ptr on the osgViewer in the code above does just fine. I tried to understand the invalid writes, but most of them look absolutely alright. One that particularly puzzled me was thrown from accessing the elements of indices 0,1,2 of a static array of size 3, i.e. (not from this code example, but just to give a flavor) :

Code:

// from osg/include/vec3d, lines 39 and 48
double _v[3];
...
_v[0] = x; _v[1] = y; _v[2] = z;


I tried recompiling from scratch a few times, always leading to the same results when I try to run a program. I recently discovered Valgrind, so I could be missing/misunderstanding something very easy or fundamental. What throws me off is that the only thing that happened between the working and crashing periods that I think is related to the compiling behavior is the install of a few packages, so that OSG could compile the TTF plugin.

If anyone has an idea as to what can be causing the problem, it is very welcome! (and please feel free to ask for information)


Thank you,
Nicolas[/quote][/code]
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12127

PostPosted: Mon Jul 28, 2014 9:55 am    Post subject:
memory corruption when using ref_ptr on osg objects
Reply with quote

Hi Nicolas,

The OSG ref_ptr<>/Reference counting has been well tested over many years and is very robust, it's been a very long time since memory errors could be traced back to problems here.


The most likely causing of problems you are seeing is mixing OSG libs at compile time vs. runtime.  It's not possible to pinpoint where error you have made with the details provided so we can only provided guesses at this stage and pointers at what to look at.


If you are compiling the OSG locally and compiling against your application against this version, but at runtime the path are setup so that other libraries are linked to then you could have errors.  The OSG libs are versioned to avoid this issue and this avoids most issues, but sometimes users are able to force the wrong libs, or a rebuild is done with different options but the same code base so the version are the same - this is particular problem under Windows as debug/release rebulds or other compile options can render libs incompatible, however, Linux doesn't usually represent this problem so you must be doing something unusual to force this error.


Try removing other versions the OSG that are intalled and make sure that your application goes through a clean build against remaining version of the OSG that is installed.


As general note, this issue isn't an OSG specific issue, it's dynamic library issue that C++ programmers just have to disciplined about to avoid potentially problem.  On the OSG we've done as much as we can to avoid these issues, but users can still find ways of tripping things up.  


Robert.



On 27 July 2014 20:02, Nicolas Mattia < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi,

I have been using OSG for a month now, and everything was fine. Recently I had to recompile the sources to include a new plugin, and since then I get a crash everytime I use an object with a ref_ptr.

I am running a 64 bits debian with OSG 3.0.1. I am using two different builds of OSG : one with dynamic libraries, one with static ones. This should not matter much (since my programs crash with both) except that they are both compiled with the extra option fPIC for position independent code (this seems mandatory for using static libraries one amd64 architectures). The static build has a few adjustments, but except for the above mentioned fPIC the dynamic one has no modification.

The problem started so : I needed the TrueTypeFont plugin to work, so I installed a few dev packages (freeglut-dev and one or two ohter ones) and built from the sources using the exact same process I had used before. From then on, my programs compiled with the new libraries (both dynamic and static) crash with the following error :

Code:

*** glibc detected *** ./a.out: malloc(): memory corruption: 0x00000000014f9cc0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76e46)[0x7f3c83ffee46]
/lib/x86_64-linux-gnu/libc.so.6(+0x79eb3)[0x7f3c84001eb3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f3c84003cd0]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1d)[0x7f3c83a8507d]
./a.out[0x6281c0]
./a.out[0x41e30b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f3c83fa6eed]
./a.out[0x41e1e9]
======= Memory map: ========
...
...
...
Aborted






Here is the (part of) the output of valgrind :


Code:

==4240== Memcheck, a memory error detector
==4240== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4240== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4240== Command: ./a.out
==4240==
==4240== Invalid write of size 8
==4240==    at 0x62A8AE: osg::ref_ptr<osg::Camera::DrawCallback>::ref_ptr() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x627FF3: osg::Camera::Camera() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x41E2E6: main (test.cpp:10)
==4240==  Address 0x84602b8 is 0 bytes after a block of size 824 alloc'd
==4240==    at 0x4C286E7: operator new(unsigned long) (vg_replace_malloc.c:287)
==4240==    by 0x41E2DB: main (test.cpp:10)
==4240==
==4240== Invalid write of size 8
==4240==    at 0x62A8AE: osg::ref_ptr<osg::Camera::DrawCallback>::ref_ptr() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x628005: osg::Camera::Camera() (in /home/cowcow/Documents/Projects/Programming/C_Cpp/OSG/a.out)
==4240==    by 0x41E2E6: main (test.cpp:10)
==4240==  Address 0x84602c0 is 8 bytes after a block of size 824 alloc'd
==4240==    at 0x4C286E7: operator new(unsigned long) (vg_replace_malloc.c:287)
==4240==    by 0x41E2DB: main (test.cpp:10)




and here is the code it was ran on:


Code:

#include <osgViewer/Viewer>
#include <osg/ref_ptr>
#include <osg/Referenced>
#include <osg/Camera>
USE_GRAPHICSWINDOW()
int main( int argc, char** argv )
{

osg::ref_ptr<osgViewer::Viewer> viewer = new osgViewer::Viewer();
osg::ref_ptr<osg::Camera> cam = new osg::Camera();

return viewer->run();
}





What is weird is that only the objects from the osg:: namespace seem to crash the program. The ref_ptr on the osgViewer in the code above does just fine. I tried to understand the invalid writes, but most of them look absolutely alright. One that particularly puzzled me was thrown from accessing the elements of indices 0,1,2 of a static array of size 3, i.e. (not from this code example, but just to give a flavor) :


Code:

// from osg/include/vec3d, lines 39 and 48
double _v[3];
...
_v[0] = x; _v[1] = y; _v[2] = z;




I tried recompiling from scratch a few times, always leading to the same results when I try to run a program. I recently discovered Valgrind, so I could be missing/misunderstanding something very easy or fundamental. What throws me off is that the only thing that happened between the working and crashing periods that I think is related to the compiling behavior is the install of a few packages, so that OSG could compile the TTF plugin.

If anyone has an idea as to what can be causing the problem, it is very welcome! (and please feel free to ask for information)


Thank you,
Nicolas
[/code]

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60473#60473





_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[/quote]

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
nicow
Newbie


Joined: 27 Jul 2014
Posts: 5

PostPosted: Mon Jul 28, 2014 10:29 am    Post subject:
Reply with quote

Hello Robert,

Thank you for your reply. I am indeed not pointing the finger at OSG; you did an awesome job. As I mentioned, before rebuilding, I could use OSG with no problem, and rather painlessly! I would rather suspect an error in the way I am building the core library.

My static build (for instance) is installed in OSG/installs/linux64stat/. Everytime I build it I wipe that directory first, set the CMAKE_INSTALL_PREFIX to OSG/installs/linux64stat/, and then make/make install. That means that all the libraries in OSG/installs/linux64stat/lib64 are supposed to be up to date (or at least all have the same version). Here's an example command I used today to build a.out and its output:

Code:

$gcc -g -Wl,--verbose -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused\
-DOSG_DEBUG_POSTFIX=d -DOSG_LIBRARY_STATIC \
-I/home/cowcow/OSG/installs/linux64stat/include/ test.cpp -L/home/cowcow/OSG/installs/linux64stat/lib64/ \
-lpthread -lm -lGLU -lSM -lICE -lX11 -lXext -losgUtil -losgText -losgViewer -losgUtil -losgGA -losgDB -losg -lOpenThreads\
| grep "succeeded" | grep "osg"

attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgUtil.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgText.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgViewer.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgUtil.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgGA.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgDB.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosg.a succeeded


The last part is the linker's output concerning osg. From my understanding, all the OSG libraries that are linked at compile time come from OSG/installs/linux64stat/lib64/ and should thus all have the same version. Now, the command
Code:

nm -u a.out | grep osg


does not output anything, so there should be no osg libraries needed at runtime (no osg symbol left undefined after compilation). If I am correct, all the osg libraries come from the same (faulty) build. If there is anything I could provide that could lead to a solution, please let me know. And once again, I am pretty sure the problem does not come from OSG itself, but probably rather from the way I built it.

Greetings,
Nicolas
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12127

PostPosted: Mon Jul 28, 2014 10:35 am    Post subject:
memory corruption when using ref_ptr on osg objects
Reply with quote

Hi Nicolas,

What happens is you run one of the OSG example like osgstaticviewer?


What happens when you using a dynamic library build of the OSG?


As a general note, I'd suggest using the recently released OSG-3.2.1 as a base as it has a range of bug fixes and improvements over 3.0.1.  There aren't any fixes relevant to the issue you are having as I suspect this isn't an OSG one but a compile/linking issue.


Robert.



On 28 July 2014 11:29, Nicolas Mattia < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hello Robert,

Thank you for your reply. I am indeed not pointing the finger at OSG; you did an awesome job. As I mentioned, before rebuilding, I could use OSG with no problem, and rather painlessly! I would rather suspect an error in the way I am building the core library.

My static build (for instance) is installed in OSG/installs/linux64stat/. Everytime I build it I wipe that directory first, set the CMAKE_INSTALL_PREFIX to OSG/installs/linux64stat/, and then make/make install. That means that all the libraries in OSG/installs/linux64stat/lib64 are supposed to be up to date (or at least all have the same version). Here's an example command I used today to build a.out and its output:


Code:

$gcc -g -Wl,--verbose -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused
-DOSG_DEBUG_POSTFIX=d -DOSG_LIBRARY_STATIC
-I/home/cowcow/OSG/installs/linux64stat/include/ test.cpp -L/home/cowcow/OSG/installs/linux64stat/lib64/
-lpthread -lm -lGLU -lSM -lICE -lX11 -lXext -losgUtil -losgText -losgViewer -losgUtil -losgGA -losgDB -losg -lOpenThreads
| grep "succeeded" | grep "osg"

attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgUtil.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgText.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgViewer.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgUtil.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgGA.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosgDB.a succeeded
attempt to open /home/cowcow/OSG/installs/linux64stat/lib64//libosg.a succeeded




The last part is the linker's output concerning osg. From my understanding, all the OSG libraries that are linked at compile time come from OSG/installs/linux64stat/lib64/ and should thus all have the same version. Now, the command

Code:

nm -u a.out | grep osg




does not output anything, so there should be no osg libraries needed at runtime (no osg symbol left undefined after compilation). If I am correct, all the osg libraries come from the same (faulty) build. If there is anything I could provide that could lead to a solution, please let me know. And once again, I am pretty sure the problem does not come from OSG itself, but probably rather from the way I built it.

Greetings,
Nicolas

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=60477#60477





_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
nicow
Newbie


Joined: 27 Jul 2014
Posts: 5

PostPosted: Mon Jul 28, 2014 12:58 pm    Post subject:
Reply with quote

Hello Robert,

I built the latest OSG version as you suggested (3.2.1) and everything is back to normal. I used the exact same process to build and compile the programs, so maybe a bug that was still present in 3.0.1 along with my system led to this one.

Thanks a lot for your time!

Greetings,
Nicolas
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Build system [build] All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts How to track down memory leaks? OmegaDoom General 9 Wed Jul 11, 2018 1:07 pm View latest post
No new posts Leaking memory on node removal Tini General 1 Fri May 25, 2018 6:48 pm View latest post
No new posts Leaking memory on node removal Tini General 0 Fri May 25, 2018 6:39 pm View latest post
No new posts Leaking memory on node removal Tini General 0 Fri May 25, 2018 6:30 pm View latest post
No new posts Leaking memory on node removal Tini General 0 Fri May 25, 2018 6:27 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP