SFML community forums
Help => Graphics => Topic started by: timesqueezer on November 07, 2010, 02:51:20 am
-
It seems that stbi_zlib_compress causes this segfault while saving an image as png. When I use jpg it works fine.
Here's the gdb trace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79601cf in stbi_zlib_compress(unsigned char*, int, int*, int) ()
from /usr/lib/libsfml2-graphics.so
(gdb) bt
#0 0x00007ffff79601cf in stbi_zlib_compress(unsigned char*, int, int*, int) ()
from /usr/lib/libsfml2-graphics.so
#1 0x00007ffff79612f9 in stbi_write_png_to_mem(unsigned char*, int, int, int, int, int*) ()
from /usr/lib/libsfml2-graphics.so
#2 0x00007ffff7961592 in stbi_write_png () from /usr/lib/libsfml2-graphics.so
#3 0x00007ffff7961c4b in sf::priv::ImageLoader::SaveImageToFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, unsigned int, unsigned int) () from /usr/lib/libsfml2-graphics.so
I'm working on a 64bit Arch Linux Laptop but it fails also on other systems.
-
it fails also on other systems
All 64 bits?
-
Yes they're all 64bit.
-
I can confirm this. I had actually posted this some time ago:
http://www.sfml-dev.org/forum/viewtopic.php?t=3390
Xorlium
-
Confirming as well. Arch Linux x86_64 here.
-
I've sent an e-mail to the author of stb_image, hopefully he can do something about it.
-
Laurent, can you replicate the problem at all?
-
I haven't tried yet.
Anyway, here is his answer:
For the crashes, I don't know for sure, but try -fno-strict-aliasing
-
Doesn't work here. I recompiled my whole project with that setting but no dice.
-
I think SFML has to be recompiled with this option.
-
That worked indeed. Stupid me, of course, recompiling my project with that option effectively didn't do anything. So, what are we going to do? Make -fno-strict-aliasing a compile option for SFML2 or should this still be delegated to the image library?
EDIT: From a few quick searches it appears as using that options is undesirable. The issue should be fixed in the image library.
-
I agree. I'll see what the author can do.
-
I can apply -fno-strict-aliasing to stb_image only, which is fair enough. The author made the choice to stop fixing code related to strict aliasing (I can show his answer to people who are interested).
I updated the makefiles, can everybody test it again please? :)
-
Works well for me now.
Thanks Laurent!
Xorlium
-
The author made the choice to stop fixing code related to strict aliasing (I can show his answer to people who are interested).
Sure, there's nothing wrong in depending upon undefined behavior, after all. I really wonder why he chose to leave the code broken.
-
Here it is
I've decided not to fix bugs involving strict-aliasing, because it's just
too much of a hassle. I'll take patches from other people, but I can't
guarantee that I won't break them again, because strict-aliasing
optimizations break too many traditional C programming practices
and in fact make one standard technique I use impossible (I think;
I posted some suggestions on molly rocket for how it might be tackled
in the image writing library, but I don't know if they'll actually work--based
on past experience probably not).
Anyway, I can't test it myself because I don't have a gcc install set up
right now and it's only gcc that does this, and I don't really want to put
effort into setting it up and testing it, because:
I think the gcc developers made a mistake with this; it is allowed
by the C spec, but this is because the C specification is being
developed by people who don't realize the consequences of
this (those people are mostly compiler writers like the gcc authors)
on the ability to write robust C code. No compilers other than gcc do
this (and supposedly Apple turned it off in the gcc that ships with
their OS).
A summary of issues with strict aliasing explaining why we don't
use it at the place where I work:
http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.html
Linus Torvalds explaining why they use -fno-strict-aliasing in the
Linux kernel:
http://lkml.org/lkml/2003/2/26/158
A more general analysis of the problem with compilers gong too far:
http://www.securecoding.cert.org/confluence/download/attachments/26017980/SD+West+Dangerous+Optimizations.pdf?version=1