Summary: | games-strategy/wesnoth-1.8.5 scrolling breaks with sys-libs/glibc-2.13 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Seerp <roaldkoudenburg> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | tdalman, wtt6 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gna.org/bugs/index.php?17573 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 357687 | ||
Bug Blocks: | |||
Attachments: | Valgrind log |
Description
Seerp
2011-02-09 00:04:36 UTC
My guess is, that Wesnoth (or any of its dependencies) has tripped over recent memcpy() optimizations in glibc. Some applications wrongly call this function on overlapping memory areas, which in turn yields in undefined behaviour. Can you provide a debug report, i.e. have you tried calling wesnoth with valgrind ? I would also recommend to report this bug directly at wesnoth.org. Created attachment 262247 [details]
Valgrind log
Thanks for your reply Tolga.
Following your suggestion I just ran valgrind on wesnoth. In that case the problem doesn't occur, but valgrind does give an error message involving mem_cpy:
"==11400== Source and destination overlap in memcpy(0xd414000, 0xd4140c8, 3328)
==11400== at 0x4C2A236: memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11400== by 0x4E46810: ??? (in /usr/lib64/libSDL-1.2.so.0.11.3)
==11400== by 0x4E46765: ??? (in /usr/lib64/libSDL-1.2.so.0.11.3)
==11400== by 0x4E5C0EB: SDL_LowerBlit (in /usr/lib64/libSDL-1.2.so.0.11.3)
==11400== by 0x4E5C31B: SDL_UpperBlit (in /usr/lib64/libSDL-1.2.so.0.11.3)
==11400== by 0xCCF2E4: display::scroll(int, int) (in /usr/games/bin/wesnoth)
==11400== by 0x85336C: controller_base::handle_scroll(CKey&, int, int, int) (in /usr/games/bin/wesnoth)
==11400== by 0x853822: controller_base::play_slice(bool) (in /usr/games/bin/wesnoth)
==11400== by 0xB7DC5C: playsingle_controller::play_human_turn() (in /usr/games/bin/wesnoth)
==11400== by 0xB7D1F4: playsingle_controller::play_side(unsigned int, bool) (in /usr/games/bin/wesnoth)
==11400== by 0xB7C4D3: playsingle_controller::play_turn(bool) (in /usr/games/bin/wesnoth)
==11400== by 0xB83D5F: playsingle_controller::play_scenario(std::pair<config::const_child_iterator, config::const_child_iterator> const&, bool) (in /usr/games/bin/wesnoth)"
This was triggered by scrolling to the right. Before doing so, I tried scrolling in the three other directions, none of which gave the same error.
Is this enough information for the people of wesnoth? I don't have much experience in doing these things -- until now I had never heard of valgrind before.
Nice :-) The bug seems to be triggered within libSDL. However reporting this issue to the Wesnoth developers seems to be the right way. Perhaps you can just point them to this bug report ? Thanks & good luck! Thanks again Tolga. I found a wesnoth bug report on this problem and added the valgrind error message to that, as well as a link to this report. https://gna.org/bugs/index.php?17573 Great! Hopefully the bug is fixed quickly then. Thanks! Looks like there's now an upstream bug report at libSDL: http://bugzilla.libsdl.org/show_bug.cgi?id=1090 maybe somebody can help us out with a ebuild for a new version of libsdl? this bug is fix in CMS but its no patch in portage tree (In reply to comment #7) > maybe somebody can help us out with a ebuild for a new version of libsdl? > > this bug is fix in CMS but its no patch in portage tree > That is up to the package maintainer. I have filed a bug #357687 for the libsdl maintainer. In the meantime, people affected by this can apply the patch themselves. If you are running Gentoo stable, run the following commands as root: ebuild $(equery which media-libs/libsdl-1.2.13-r1) prepare cd /var/tmp/portage/media-libs/libsdl-1.2.13-r1/work/SDL-1.2.13 wget -O - http://bugzilla.libsdl.org/attachment.cgi?id=574 | patch -p1 ebuild $(equery which media-libs/libsdl-1.2.13-r1) merge If you are running Gentoo unstable, run the following commands as root: ebuild $(equery which media-libs/libsdl-1.2.14-r5) prepare cd /var/tmp/portage/media-libs/libsdl-1.2.14-r5/work/SDL-1.2.14 wget -O - http://bugzilla.libsdl.org/attachment.cgi?id=574 | patch -p1 ebuild $(equery which media-libs/libsdl-1.2.14-r5) merge Doing that will patch the package on your system. The patch will be lost if you re-emerge the package (e.g. as part of emerge -ave @world). People who want something that will not be lost when re-emerging the package could put the ebuild and patch into the local overlay. I expect that this will suffice until the package maintainer patches the portage tree; after which, none of this will be necessary anymore. I just noticed that sys-libs/glibc-2.13-r1 is keyworded, so anyone affected by this is likely using the unstable tree. Please disregard the instructions I posted for users of the stable tree. As long as they do not unkeyword glibc, they will likely not need to worry about this. fixed in libsdl-1.2.14-r6 |