SFML community forums

Help => Graphics => Topic started by: timesqueezer on November 07, 2010, 02:51:20 am

Title: segfault while saving to png
Post 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.
Title: segfault while saving to png
Post by: Laurent on November 07, 2010, 10:23:32 am
Quote
it fails also on other systems

All 64 bits?
Title: segfault while saving to png
Post by: timesqueezer on November 07, 2010, 01:55:02 pm
Yes they're all 64bit.
Title: segfault while saving to png
Post by: Xorlium on November 07, 2010, 04:56:31 pm
I can confirm this. I had actually posted this some time ago:
http://www.sfml-dev.org/forum/viewtopic.php?t=3390

Xorlium
Title: segfault while saving to png
Post by: Svenstaro on November 07, 2010, 05:13:52 pm
Confirming as well. Arch Linux x86_64 here.
Title: segfault while saving to png
Post by: Laurent on November 07, 2010, 05:43:16 pm
I've sent an e-mail to the author of stb_image, hopefully he can do something about it.
Title: segfault while saving to png
Post by: Svenstaro on November 07, 2010, 05:48:10 pm
Laurent, can you replicate the problem at all?
Title: segfault while saving to png
Post by: Laurent on November 07, 2010, 05:59:50 pm
I haven't tried yet.

Anyway, here is his answer:
Quote
For the crashes, I don't know for sure, but try -fno-strict-aliasing
Title: segfault while saving to png
Post by: Svenstaro on November 08, 2010, 07:27:25 pm
Doesn't work here. I recompiled my whole project with that setting but no dice.
Title: segfault while saving to png
Post by: Laurent on November 08, 2010, 08:08:09 pm
I think SFML has to be recompiled with this option.
Title: segfault while saving to png
Post by: Svenstaro on November 08, 2010, 08:27:00 pm
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.
Title: segfault while saving to png
Post by: Laurent on November 08, 2010, 08:34:25 pm
I agree. I'll see what the author can do.
Title: segfault while saving to png
Post by: Laurent on November 08, 2010, 11:23:57 pm
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? :)
Title: segfault while saving to png
Post by: Xorlium on November 09, 2010, 07:56:56 am
Works well for me now.

Thanks Laurent!

Xorlium
Title: segfault while saving to png
Post by: Silvah on November 09, 2010, 02:18:23 pm
Quote from: "Laurent"
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.
Title: segfault while saving to png
Post by: Laurent on November 09, 2010, 02:26:51 pm
Here it is
Quote
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