You are not logged in.
EDIT: It seems this is a more general problem than I first suspected. Thanks to the feedback below it has been traced to a commit in zlib.
--- Original Post Below ---
Original Title: zlib 1.2.11 incompatability with sdl game (manaplus)
This morning I found one of my guilty pleasures manaplus completely failed to work. It is an SDL MMORPG. In normal use, the game downloads sprite files as png data compressed in zip archives to ~/.local/share/mana/ and uses those to render scenes and characters for game play. With the zlib 1.2.11 upgrade, manaplus is completely unable to use any of the zipped png data.
I confirmed by downgrading zlib to 1.2.8 which was sufficient to restore normal functioning. I've repeated the downgrade-upgrade cycle many times with both the manaplus package from community as well as manaplus-git from the AUR. Every version works fine with zlib 1.2.8 but they all fail with zlib 1.2.11.
I've been talking to the manaplus developer (4144) who has helped gather some logs, but to the best of his ability to assess, the problem lies with a dependency of manaplus that needs to be rebuilt against the new zlib. Manaplus is an SDL game using sdl_image, physfs, and libpng as the most likely candidate problems. It seems none of these have been rebuilt since the zlib upgrade. 4144 pushed better physfs logging to git to diagnose this further. I rebuilt manaplus and got a new log file, but the physfs logging didn't provide any new information and - based on 4144's interpretation - may have ruled out physfs as the problem.
I rebuilt curl, sdl_image, libxml2, physfs, and libpng from the ABS against the new zlib, but I have still been unable to restore functionality to manaplus with zlib 1.2.11.
It seems someone just flagged the manaplus package in the repo out of date - so at least one other user has noticed a problem. Unfortunately they don't know what "out of date" means as that is not the problem - a git build has the same problem. Instead there is a bug somewhere.
I'd like help assembling a better bug report. Specifically, should this be a manaplus bug, or is it downstream in sdl, sdl_image, physfs, libpng, or another in the dependency chain. I don't have any other software on my system that depends on sdl tools. If anyone can check whether other sdl software is having problems with compressed png data that would be a valuable data point.
EDIT: As I don't recall the order of rebuilding the above listed packages I'm retesting sdl_image as sdl_image depends on both zlib directly and on libpng which depends on zlib. I'm now ensuring I build libpng against the new zlib then sdl_image against the new zlib *and* the rebuild libpng in case this would have an effect. (no luck)
WORKAROUND: I've gotten as far as I can get in tracking this, and the upstream developer does not use a current zlib so it will likely be quite a while until they face this issue. So for now I just copied the libz.so.1.2.8 from the old zlib into my home directory, and I just launch this game with `LD_PRELOAD=/path/to/old/libz.so.1.2.8 manaplus ...` While I'd rather have it work properly, this works quite well as it doesn't require holding back upgrades or rebuilding countless packages hoping one of them might fix the problem.
Last edited by Trilby (2017-01-19 21:35:23)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I also found a problem with the recent zlib and reverted to 1.2.8. My problem is in the Erlang dialyzer program which is in the community/erlang package. After the zlib update it can no longer read its PLT (sort of like a database) files and can no longer extract the data used to create them from pre-existing code modules. I submitted this report to the erlang bugs list but it is moderated and has not posted yet.
I have just installed the old package from my cache and added it to the IgnorePkg key for now in my pacman.conf.
I'm an Arch Linux user and picked up an update a few days ago that broke dialyzer. I bisected the last few days of updates and then narrowed the problem to zlib 1.2.10, which was released January 2nd. 1.2.11 was released on the 15th as an emergency bug fix and does not fix the problem. Reverting my system back to 1.2.8 (the previous version packaged for Arch) did resolve the issue.
It seems doubtful this is an Erlang problem, but I doubt I'm going to write a test program to demonstrate the problem to them. I thought I should at least report the issue in case others encounter it.
To reproduce, one would need only install zlib 1.2.10 and then run:
dialyzer --verbose --build_plt --apps erts --output_plt test.plt
Output would be along the lines of:
dialyzer: Could not get abstract code for file: /usr/lib/erlang/lib/erts-8.2/ebin/erlang.beam (please recompile it with +debug_info)
There are also errors when simply trying to do success typing analysis *using* any pre-existing PLT file, along lines of "this isn't a PLT file". The errors are not dependent upon the version of Erlang installed - at least anything I tried that was released on Arch in the 19.x branch will reproduce the problem.
Anyway, I hope this report helps someone and I would be curious if anyone else reproduces it, or especially if they fail to reproduce it.
Offline
Both packages depend on zlib via glu->libgl->mesa via llvm-libs, libelf, and wayland->libxml2.
I only had rebuilt libxml2 as that seemed a likely candidate as manaplus also stores a lot of data in xml files. But if these two problems are connected, perhaps anything in this shared dependency chain could need a rebuild. Unfortunately that would be *a lot* of compiling that would take far longer than reasonable on my old laptop.
I suspect several permutations of rebuilding different branches of the dependency tree would be necessary to pinpoint which package(s) in the repos currently really need the rebuild. Without knowing which packages need the rebuild it's hard to submit an actionable bug report.
EDIT: I suppose the shared libgl dependency might be a red-herring as the erlang symptoms don't seem to have anything to do with graphics handling: certainly not compressed png data which was the problem with manaplus.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I suspected it is a bug in zlib itself as they had an emergency fix in 1.2.11 for a bug introduced in 1.2.10, but looking at the changelog for 1.2.9 I see there were macro changes, define changes, etc. If it is not binary compatible I think they should have bumped to 1.3 but you may be right that a rebuild is necessary since everything was built against 1.2.8. If that is the issue then the only library requiring rebuild should be those that actually import zlib headers.
Last edited by jeremyjh (2017-01-19 11:53:20)
Offline
Michel Boaventura sent this to the Erlang-bugs list after reporting the same error I had.
I've done the bisect and find the culprit: https://github.com/madler/zlib/commit/b … 9014f7b282. Before this commit term_to_binary works and stop doing so afterwards. I will have a look at the changes and see if I can figure out what happened.
Cheers
Offline
Thanks for the follow up. Good to know it's been pinpointed. I'll build zlib from before and after that commit and confirm that this is indeed the same problem I'm facing. If/when I confirm that I'll revise the title of this thread to more accurately capture the scope of the issue.
I was skeptical at first that this could be a zlib issue. Zlib is so widely used that I'd expect a bug in decompressing data in general would have wide-spread effects and would have been caught already.
EDIT: confirmed. A build from immediately before that commit works fine while that commit causes the SDL game to fail due to an inability to properly decompress png sprite data.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
The plot thickens! Based on feedback from the zlib maintainer, an Erlang maintainer confirmed the zlib change exposed a latent bug that's been in Erlang for several years. The zlib change performs an additional check of its internal state, which is invalid due to Erlang doing a shallow memcopy.
Offline
Thanks, I subscribed to that issue now. It sounds like a similar latent bug may be present in sdl_image. (edit, physfs is again looking like the suspect).
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Hello,
I am developer of manaplus.
This is issue in libphysfs.
Here is small code for reproduce issue: http://download.evolonline.org/manaplus/bug/bug.zip
Here is patch to fix issue: http://download.evolonline.org/manaplus … _seek.diff
physfs mail list look like dead. This mean probably patch will be not added to physfs in near future.
Offline
Thanks. I've already applied your patch to my own physfs and it works great.
I'll see if we can get this applied to the physfs in our repos, and if not I'll submit a patched physfs to the AUR (the AUR serves a similar function as *buntu's PPAs if I understand PPAs correctly).
EDIT: xref [extra]/physfs bug report to apply the patch to our repo package: https://bugs.archlinux.org/task/52719
Last edited by Trilby (2017-01-26 14:25:47)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Trilby, I've assigned your ticket, but the maintainer has been totally inactive since May last year. Nobody else has touched the package, so there's not even anyone else I can add. Not a good situation, so don't expect much.
Edit: I also thought to add the manaplus maintainer, since this bug breaks it, but he's a TU and physfs is in Extra. No go.
Last edited by Scimmia (2017-01-26 16:37:45)
Offline
Thanks for the update. In that case I'll submit a physfs-patched (alternative name suggestions welcome) for the AUR which provides/replaces physfs.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Erlang 19.2.3 was released for Arch on 2/17 and fixes this issue.
Offline
ManaPlus in git now not using physfs by default. All should works, but it not tested very long time.
This mean package manaplus-git should works without issues.
Next manaplus release will be by default without physfs support too.
Offline
Thanks. I just built from git and tested without physfs and all is well.
I just updated our AUR package (PKGBUILD) for manaplus-git to remove the physfs depdency. I also switched that PKGBUILD to sdl2 dependencies.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
ManaPlus without physfs was released today
Offline