Hi Scott,

I have added some code to Image.cc:
          if (fifmt == FIF_PNG)
          {
            std::cerr<<"Before crash"<<std::endl;
this->bitmap = FreeImage_Load(fifmt, fullName.c_str(), PNG_DEFAULT);
            std::cerr<<"After crash"<<std::endl;
          }
Looks like you're right, second call to FreeImage_Load ends with crash, so there's no second 'After crash' message. Funny thing, I compiled code from the same FreeImage3131.zip on both Gentoo and Fedora 8, and I don't have such a problem on Fedora 8!
My freeimage.pc file looks like this:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include

Name: freeimage
Description: Freeimage
Version: 3.13.1
Requires:
Libs: -L${libdir} -lfreeimage
Cflags: -I${includedir}

From FreeImage/Dist I copied only FreeImage.h to /usr/local/include and libfreeimage.a to /usr/local/lib (even if this path is listed in /etc/ld.so.conf, I'm keeping only static libs there, that's my inside policy).

PNGstat.perl script did not find anything suspicious in grey_play_button.png and gqview shows this file properly. Both blue (loaded correctly) and grey image have transparent background so I don't think it is the source of this problem.

For some reason Gentoo developers removed this library from distribution with "...and don't come back"-like comment as for their standards it is too buggy. I guess, newer version of glibc (in Gentoo) than the one I have in Fedora 8 is more sensible for this kind of bugs and that's the source of my problems. For now, I have to wait for newer version of FreeImage which hopefully will have this issue fixed.

Paul

On Thu, 29 Apr 2010, Scott Biddlestone wrote:

Hi Paul,

I don't think I have ever seen this particular segfault.  A quick grep
for grey_play_button takes you to server/gui/Toolbar.cc and then into
server/rendering/Image.cc.  Image.cc is doing the stat64 and then a
Freeimage_Load is probably where you are crashing.  This is
interesting since blue_play_button succeeded on the same path right
before that.  Since your mmap2 call after the read ( buried in
Freeimage_Load ) is asking for really big chunk of memory ( 4290834432
bytes ) this is probably a freeimage issue.

As a shot in the dark, did you somehow happen to get gazebo to
dynamically link to freeimage?  The Freeimage_Initiailise() call in
the Image constructor seems to only be required for a static link, so
maybe it does something strange when dynamically linked.  I believe
you mentioned making a .pc for Freeimage. I did not make a pkg-config
file, I just symlinked FreeImage.h and the libs in /usr/include and
/use/lib to where ever I had freeimage installed at the time.

Hope that helps,
 Scott


2010/4/29 Paul Osmialowski <[email protected]>:
Hi Scott,

This helped me to move forward, still I have problems. Gazebo gets killed by
SIGSEGV right after start. I tried to track down this using valgdind, to my
surprise, it works fine started with valgrind! (unfrotunately, this is not
an workaround: everything works slower with valgrind). I started this with
strace and it says:
stat64("~/psg3/share/gazebo/Media/materials/textures/grey_play_button.png",
{st_mode=S_IFREG|0644, st_size=1182, ...}) = 0
open("~/psg3/share/gazebo/Media/materials/textures/grey_play_button.png",
O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=1182, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7843000
read(7,
"\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\24\0\0\0\27\10\6\0\0\0\v\35o"..., 4096)
= 1182
mmap2(NULL, 4290834432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 4290965504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1,
0) = 0xb1d8e000
munmap(0xb1d8e000, 466944)              = 0
munmap(0xb1f00000, 581632)              = 0
mprotect(0xb1e00000, 135168, PROT_READ|PROT_WRITE) = 0
mmap2(NULL, 4290834432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Looks like check for NULL pointer is missing somewhere.

Paul

On Wed, 28 Apr 2010, Scott Biddlestone wrote:

Edit your ~/.gazeborc file and set orgePath to "/usr/lib/OGRE".  You
will need to do this every time you reinstall gazebo.
This only happens on my Gentoo box, never tried to hunt in down though.

-Scott

On Wed, Apr 28, 2010 at 6:45 PM, Paul Osmialowski <[email protected]>
wrote:


On Tue, 27 Apr 2010, Scott Biddlestone wrote:

Hi Paul,

To get rid of the recursive_mutex problem remove the "threads" use
flag from ogre and reemerge ( apparently I hit this a long time ago
and forgot a about, but its in my notes ).  You have to do an emerge
-aC ogre before emerging again, during my reemerge it sometimes tries
to link to the previous ogre install.  Since this ebuild uses DeViL
and not Freeimage, some of my textures do not load correctly.  I
typically use an overlay of ogre 1.7 with freeimage for gazebo stuff.

Hi Scott,

Setting -threads for ogre did the trick and problem with assertions is
now gone, unfortunately, still I cannot run Gazebo on that Gentoo box.

I compiled freeimage and installed globally in /usr/local/lib. Then I
unmerged ogre and emerged it again like that:
EXTRA_ECONF="--enable-freeimage" emerge ogre

This configure option enables freeimage which results in disabling DevIL.
Then I compiled gazebo once again. Result is:

Gazebo multi-robot simulator, version 0.10.0

Part of the Player/Stage Project [http://playerstage.sourceforge.net].
Copyright (C) 2003 Nate Koenig, Andrew Howard, and contributors.
Released under the GNU General Public License.

Error Loading Gazebo
/root/psg3/src/gazebo-20100428/server/rendering/OgreAdaptor.cc:452 :
Exception: unable to find rendering system

Any suggestions for that?

Paul


------------------------------------------------------------------------------
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo



------------------------------------------------------------------------------
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo

------------------------------------------------------------------------------

_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo



------------------------------------------------------------------------------
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
------------------------------------------------------------------------------
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo

Reply via email to