Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
hi, now that heroes3 is in portage and can be upgraded to 1.3.1a i want to file a bug-report against it. i was looking for a solution to the problem described below for over a year now - and i finally figured out how to fix it :)) so, here's the bug description: 1. if you try playing a network-game the game segfaults. 2. the whole game doesn't run very stable at all (random crashes) steps to reproduce: 1. click "new game" -> "multiplayer" -> "tcp/ip" in the main-menu. 2. play the game on a cold winter weekend and count the crashes ;) tested arch: x86 over the last year i read everything locatable on the web concerning this issues and didn't find a proper solution, but alot of helpful suggestions. so i read the game's strace to see what might cause the segfault and tracked the problem down to be an issue related to glibc. i remember that the game worked perfectly on a slackware-8.1 box which comes with glibc-2.2.5, while i've got glibc-2.3.4.20040808-r1 installed on my gentoo box right now. heroes3 itself reports to have been built with glibc-2.1 and i guess with loki games out of buisness there won't be a new binary ever. so, the "solution" i figured out maybe worth considering in order to make heroes3 "just work" - although it is just a hack... through strace i recognized open-calls like these: open("libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libnss_files.so.2", O_RDONLY) = 16 open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 16 my solution to this issue is based on the observation that the necessary libraries are first looked up in CWD. i took the official slackware glibc-2.2.5-i386-4.tgz package (such an old version of glibc isn't in portage anymore), got the needed libs out of it and created proper symlinks in /opt/heroes3 (which is, thanks to the wrapper in /usr/games/bin/, the CWD): lrwxrwxrwx 1 root root 15 Nov 12 23:36 ld-linux.so.2 -> lib/ld-2.2.5.so* lrwxrwxrwx 1 root root 17 Nov 12 23:36 libc.so.6 -> lib/libc-2.2.5.so* lrwxrwxrwx 1 root root 25 Nov 12 23:36 libnss_files.so.2 -> lib/libnss_files-2.2.5.so* lib: total 5.5M -rwxr-xr-x 1 root root 425K Nov 12 23:35 ld-2.2.5.so* -rwxr-xr-x 1 root root 4.8M Nov 12 23:35 libc-2.2.5.so* -rwxr-xr-x 1 root root 228K Nov 12 23:35 libnss_files-2.2.5.so* tracing heroes3 again, that results in: open("libnss_files.so.2", O_RDONLY) = 16 open("libc.so.6", O_RDONLY) = 16 open("ld-linux.so.2", O_RDONLY) = 16 so heroes3 is able to use the symlinked libs from CWD and is independent from the system's glibc which makes the game network playable again. i haven't had the time for much testing yet, but i guess this approach could be given a try: i played a network game for about one hour yesterday without any trouble, errors or crashes. the only backdraw i see right now is that the additional libs enlarge the diskspace needed for heroes3 by about 5.5 mb (unstripped). i guess through this approach it is even possible to gain alot more stability in heroes3 in general, but, as i said before, i haven't had the time for testing yet. i updated the ebuild for those who are willing to test/try it. any suggestions/experiences? have a nice day, alex p.s.: cause "heroes3.xpm" wasn't proper installed to /usr/share/pixmaps, i fixed that in the updated ebuild, too - didn't want to open a new bug report for this trivial problem. hope that's allright ;)
Created an attachment (id=43854) [edit] heroes3-1.3.1a.ebuild
I have an x86 architecture. I had also noticed the icon issue, but didn't look at how it could be fixed. I copied the attached ebuild (dated 2004-11-13) to the /usr/portage/games-strategy/heroes3 directory, but called it heroes3-1.3.1a-r1.ebuild. I did a USE="ppc" emerge -f heroes3 to get the ppc patch (so the ebuild heroes3-1.3.1a-r1.ebuild digest command would work). Redigest the directory (which downloaded the build patch, the libraries and, the ppc patch -- I already had the x86 patch in /usr/portage/distfiles). I then emerged heroes3. Everyting seemed to work fine. I noticed the gnome icon reappeared. I started the program, and selected multi-player (tcp/ip) -- no crash. I don't know any specific IP to ask someone else to play at this time, and didn't try to host (I'd have to unblock some ports and didn't want to bother at this time), but no crash. Looks good. I'd say it could be shipped.
The ebuild worked for me! I replaced my current ebuild with this one, and then ran: ACCEPT_KEYWORDS="ppc" emerge -f heroes3 ebuild /usr/portage/games-strategy/heroes3/heroes3-1.3.1a.ebuild digest emerge heroes3 And it worked perfectly! =) Hope this ebuild becomes the official one...
I am working on a solution that isn't using a bunch of pre-compiled biaries to cause this to work. In fact, I kept from adding heroes3 into portage for a *long* time until I could get loki_patch into portage. Translation: This will not go into portage. Hvae you looked instead at the libraries provided by the lib-compat package, which is already in portage and using those instead? Also, Forest, you're on PPC, so this ebuild is no different for you. If you notice, all the hackery is done only if "${ARCH}" = "x86".
Forest, Can you verify if network issues occur on the ppc arch?
I guess Forest is on x86 too and has just run "ACCEPT_KEYWORDS="ppc" emerge -f heroes3" to get all files together for the digest building... However, sure the solution I suggested is just a hack and in fact, I didn't check if it's possible to resolve the network issue with lib-compat, because it doesn't provide libnss_files.so - so I guessed that it wouldn't work... Chris, what solution to this issue do you think of? Through compiling a whole old libc it would maybe be possible to cover network issues on ppc, too (are there any at all?!), but wouldn't that be overkill? I'm definitely willing to help out getting the hacked part out of the solution ;)
If libnss_files.so is all lib-compat is missing, it may be possible to have libnss_files.so added to lib-compat. I was trying to find info on lib-compat. It lists the default homepage as www.gentoo.org. Which makes me believe this may be a distribution specific type of package. When I read lib-compat's changelog it states that lib 'such-n-such' was added to version 1.x, and lib 'something-else' was added to version 1.y . I googled +"lib-compat" +howto but found a void of directly/immediately useful information. I noticed I have lib-compat installed, and plan to learn from the source soon. A question I still have: If the library-version necessary for heroes3 were build from some source as Alex suggested and I was thinking about, what effects would this have on other future compiled programs? Chris, is this a workable solution? Why/Why-not?
There is really only one solution that I would accept, and that is using lib-compat to get the library versions that we need and getting heroes3 to use specifically those versions. Otherwise, I would just as well remove the thing from the tree before adding *any* binary libraries that are not shipped with the game itself. As for the effects on future-compiled programs, there would be none. The versions required would have unique filenames and would only be referenced by the applications requiring them. I would also bet that the only documentation for lib-compat is the lib-compat ebuild itself.
I tried using the libs provides by lib-compat and libnss_files.so in addition: lrwxrwxrwx 1 root root 23 Nov 25 08:56 ld-linux.so.2 -> /lib/ld-linux.so.1.9.11* lrwxrwxrwx 1 root root 18 Nov 25 08:56 libc.so.6 -> /usr/lib/libc.so.5* lrwxrwxrwx 1 root root 25 Nov 18 08:55 libnss_files.so.2 -> lib/libnss_files-2.2.5.so* That results in the following messages during heroes3-startup: sh: libc.so.6: no version information available (required by sh) sh: libc.so.6: no version information available (required by sh) sh: libc.so.6: no version information available (required by sh) sh: libc.so.6: no version information available (required by sh) sh: libc.so.6: no version information available (required by /lib/libdl.so.2) sh: libc.so.6: no version information available (required by /lib/libdl.so.2) sh: libc.so.6: no version information available (required by /lib/libdl.so.2) sh: libc.so.6: no version information available (required by /lib/libdl.so.2) sh: libc.so.6: no version information available (required by /lib/libdl.so.2) sh: relocation error: /lib/libdl.so.2: symbol _libc_intl_domainname, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Heroes3 starts up and no segfault on TCP/IP happens, but I guess the game will become more unstable through this. I mean, pretending libc.so.5 to be libc.so.6 seems to be no good solution to me. Shall we ignore the errors above? So, I guess the libs from lib-compat are already too old. I tried to just use the old version of libnss_files.so and therefore removed the symlinks ld-linux.so.2 and libc.so.6: now the game segfaults on TCP/IP again. It seems to need at least a real libc.so.2.[12].* and libnss_files.so... As far as I could see from lib-compat's ebuild and the lib-compat-1.4.tar.bz2, lib-compat uses arch-specific precompiled libraries, too. So I guess it would be possible to just add the libs heroes3 needs to lib-compat - but this would enlarge the space needed for every user of one of the progs listed on http://www.gentoo-portage.com/sys-libs/lib-compat/rdep (e.g. mozilla*-bin/netscape-*) by about 5.5 MB, even if they aren't interested in heroes3 at all. I guess that isn't a good solution either. What do you think? My suggestion would be the following: - write a new ebuild like 'sys-libs/lib-compat-loki' - make it provide the libs heroes3 needs (and maybe other loki games, too) - make it install the libs to /usr/lib/ - make heroes3's ebuild RDEPEND on 'sys-libs/lib-compat-loki' (on x86 only first) - make heroes3's ebuild link the libs provided by 'lib-compat-loki' to '/opt/heroes3' So it would be possible to add the libs needed for heroes3 on PPC to 'lib-compat-loki' if necessary at all and only those who are interested in heroes3/loki-games would have to install the libs this issue is depending on. Btw, can anybody confirm that there are issues on PPC at all? If and only if the errors from above shall be just ignored, the ebuild for 'sys-libs/lib-compat-loki' could itself RDEPEND on 'sys-libs/lib-compat' to use the provided libc.so.5 instead of libc.so.6. Chris, would that be a solution? Have a nice day,
I'd just like to add that one of the reasons I began using gentoo, was that some loki packages were "easily" installed, while still difficult to use on other newer distributions. I hoped that gentoo would slowly add more commercial game titles, and planed to get involved *sometime soon*. I'm finally getting involved. IMHO, removing heroes3 from portage is not a good solution. Personally I don't care which library is used where, as long as it works. I can see what gets installed, and the magic of portage can remove the unused library when/if I ever unemerge heroes3. In the meantime, I'd be happy getting the proposed or modified (to compile a library OR with a lib-compat-loki) attached heroes3 ebuild setting up heroes3 with binary or compiled old-libraries and then setting it up as M+ stable / hard masked for x86; with no special code for ppc. This would allow us and others to unmask and play/test the solution. And also allow others to see, learn, and suggest newer/better methods. Chris, your the moderator/expert here. Please continue to let us know your thoughts. Thanks, and Happy Thanksgiving !!!
Created an attachment (id=44727) [edit] lib-compat-loki-0.1.ebuild I attached this ebuild to this bug instead of filing a new (ebuild) bug report, because it's unsure if the concept it follows is wanted at all. I suggest 'sys-libs/lib-compat-loki'...
Created an attachment (id=44728) [edit] heroes3-1.3.1a-r1.ebuild This new version RDEPENDS on 'sys-libs/lib-compat-loki'.
the lib-compat-loki solution possability still seems to work for me.
Sorry everyone for not replying sooner... I am on x86, and I would *really* like to see the new ebuild go into portage. I think I like the idea best of having a seperate lib-compat-loki library, if it applies to other games also. But just using the slackware stuff and having it directly attached to the heroes3 ebuild isn't so bad... I just want to be able to easily emerge heroes3!
I just finished a short game against the computer. My highscores were not captured because the /opt/heroes3/data/hiscore.dat file should/could be modified for games group writeable. I was trying to figure out where the highscores were untared to during installation, and get the one line necessary into the ebuild, but I didn't see the files after the untar command appear in /var/tmp/portage/heroes3-1.3.1a-r1/image/ ljkopen@turtle heroes3 $ pwd /opt/heroes3 ljkopen@turtle heroes3 $ ls -la data total 115065 drwxr-x--- 3 root games 232 Nov 25 20:41 . drwxr-x--- 5 root games 456 Nov 25 20:41 .. -r--r----- 1 root games 42369064 Nov 25 20:41 h3bitmap.lod -r--r----- 1 root games 52633380 Nov 25 20:41 h3sprite.lod -r--r----- 1 root games 13772884 Nov 25 20:41 heroes3.snd -r--r----- 1 root games 8928600 Nov 25 20:41 heroes3cd.snd -r--r----- 1 root games 0 Nov 25 20:41 hiscore.dat drwxr-x--- 2 root games 1840 Nov 25 20:41 video
Created an attachment (id=44958) [edit] heroes3-1.3.1a-r1.ebuild I updated the ebuild: * 'data/hiscore.dat' is now writeable for games-group members * fixed some messages
This new ebuild still functions for me.
Chris, what do you think of the "lib-compat-loki"-approach? I've been testing heroes3 for a while now with this configuration and didn't run into any problems. Do you consider this approach to be a hack, too? And if so, wouldn't it be possible to merge at least the fixes for the icon- and hiscore.dat-issues? Have a nice day,
I'll be honest... I haven't even looked at this bug in a while, since I've been really busy with real life work coupled with having to spend my limited time working on Gentoo doing more critical bugs. I'll get around to this one as soon as I get a chance. I would really like to avoid having to use the lib-compat-loki seeing as how we've only demonstrated its usefulness on this one application. Personally, the heroes3 ebuild has been a serious PITA sice the day it was introduced. Due to the ebuild, I had to add and maintain 3 other "loki" ebuilds that aren't used elsewhere. I've started converting anything using loki-patch to using these ebuilds, simply to ensure future compatability, but adding one more set of garbage just to support these aging games is starting to make it not worthwhile for me. Like I said, I'll get to this as soon as I get a chance, but it isn't a high priority.
Ok. As you describe it, I could think of the following possibilities to come to a solution: 1. add some of the other nice loki-games to portage that might have issues like heroes3, too (I think Civ3 had a similar TCP/IP-crash issue, too) - so having lib-compat-loki around would be more useful. 2. add libnss_files.so to lib-compat and use the libs provides by lib-compat in general, ignore the errors I reported, skip lib-compat-loki, merge a new ebuild as -r1, mark it unstable (~x86) for testing - maybe it turns out that the errors aren't that heavy at all. 3. remove heroes3 from portage and get rid of the other loki_*-stuff I submitted, too. 4. merge the two bugfixes (icon,hiscore.dat) and keep the rest as it was, ignoring the TCP/IP-crash-issue. 5. add a new USE flag to the current heroes3 ebuild, i.e. 'tcpip_hack', that puts the slackware binaries in place, if and only if the user desires so and wants the hack to enlarge the diskspace needed etc. in order to use TCP/IP network games again. I would prefer 1. or 2. - I'm still interested in having a working heroes3-ebuild in portage, so removing heroes3 wouldn't be a good solution from my point of view as a user. Chris, if you think adding libnss_files.so to lib-compat would be possible, than I would update the ebuild again, so that there would be the possibility to test how acceptable this solution really is. If it turns out that this approach doesn't work as desired, solution 3. or 4. could be chosen. (Or even 1. if you don't want skip to lib-compat-loki in general) Even if 5. is a hack, it doesn't pretend to be none and gives the user the choice wheter he wants it applied or not instead of applying it anyway. I hope these suggestions are helpful...
Hi, I also would like to have heroes3 in portage, cause this is still one of my favorite games ever. I have it now running with the lib-compat-loki ebuild playing it in my network with friends. The tcp/ip-crashes were not that good for me, so I go back to woody for playing. Now it is possible to stay in gentoo. :-) I mirrored the lib-combat-loki.tar.bz2 for Alex, because there are sometimes serverproblems there he offer it. The mirror is at: http://www.blfh.de/gentoo/distfiles/lib-combat-loki.tar.bz2 Because I like to play other games from loki, like Alpha Centauri and Civilization: Call to power, I would prefer to have solution 1. as Alex stated. Maybe you can thing about it an give it a try. Cheers, Karsten
Sorry, wrong file name, right url is: http://www.blfh.de/gentoo/distfiles/lib-combat-loki-0.1.tar.bz2 cheers, Karsten
Don't know, something is wrong with me. ;-( Right url: http://www.blfh.de/gentoo/distfiles/lib-compat-loki-0.1.tar.bz2 Cheers, Karsten
Added to portage... hopefully the lib-compat-loki stuff ends up being useful for more than this one game...
Sory to spoil the party , but this does not look fixed. I am using 1.3.1a-r1. Any idea of what is happening ? obelix@home ~ $ heroes3 /etc/host.conf: line 24: bad command `mdns off' heroes3: dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed. BUG! Exception triggered, cleaning up. Heroes of Might & Magic III 1.3.1a Built with glibc-2.1 on x86 Stack dump: { [0x82062d3] [0x820645b] [0xffffe420] [0x82f93d3] [0x82f5b9e] [0x8336947] [0x83372e1] [0x8338328] [0x831c309] [0x831bfdb] [0x831c474] [0x831939f] [0x831bfdb] [0x8318c22] [0x83192a0] [0x831a048] [0x8319ba2] [0x82057d3] [0x814c873] [0x814c914] [0x814b2fd] [0x81fa321] [0x814b3bd] [0x81fa909] [0x81fa035] [0x81fbb4c] [0x81f9fa8] [0x812fa51] [0x812f5ed] [0x812e7b7] [0x8137e5c] [0x82f5abd] [0x8048111] } Please send the text of the failed assertion, along with the contents of autosave to: support@lokigames.com Unable to execute loki_qagent - exiting obelix@home ~ $ /opt/heroes3/heroes3.dynamic Segmentation fault
Ivan, Your error appears to be related to you /etc/host.conf file. Are you able to post your /etc/host.conf file here. The answer may be hidden in there. I personally don't have an /etc/host.conf file and am not immediately familar with it, or what a "mdns off" could be used for. But we can look into it. I started by running heroes3 from an xterm. I hit <ALT-Enter> after the game started, so I could view the output debug on the command line. I selected *new game* I selected *multi-player* . I selected *TCP/IP* I selected *host* I did not enter a password - I selected *ok* I selected *back* --> at this point everything was ok <-- I selected *multi-player* I selected *TCP/IP* I selected *join* I typed in an arbitrary IP --> 10.33.15.195 I typed in an arbitrary Password --> Junk I clicked a check box. After a minute or two the game returned with "Game was not found. Please try again." I clicked on the check box. I selected *back* So then as root I did the following to simulate your environment: turtle ~ # touch /etc/host.conf turtle ~ # echo "mdns off" >> /etc/host.conf turtle ~ # cat /etc/host.conf mdns off turtle ~ # As a user I did the following: I started by running heroes3 from an xterm. I hit <ALT-Enter> after the game started, so I could view the output debug on the command line. I selected *new game* I selected *multi-player* . I selected *TCP/IP* NOTE: at this point the following debug message appeared, but did not cause a core dump: /etc/host.conf: line 1: bad command `mdns off' I selected *host* I did not enter a password - I selected *ok* I selected *back* I selected *multi-player* I selected *TCP/IP* I selected *join* I typed in an arbitrary IP --> 10.33.15.195 I typed in an arbitrary Password --> Junk I clicked a check box. After a minute or two the game returned with "Game was not found. Please try again." I clicked on the check box. I selected *back*. If while the game was searching for a game to join at the IP address and password entered; I close the heroes3 window using the X11 X(close) button on the upper right of my display, I get a dump exactly like yours: BUG! (Segmentation Fault) Going down hard... Heroes of Might & Magic III 1.3.1a Built with glibc-2.1 on x86 Stack dump: { [0x82062d3] [0x82064bb] [0xffffe420] [0x830ba73] [0x82733cd] [0x8253235] [0x824d741] [0x82430e8] [0x8243123] [0x8132e40] [0x8138007] [0x816ac5a] [0x814c7ed] [0x814c859] [0x814b339] [0x81fa321] [0x814b3bd] [0x81fa909] [0x81fa035] [0x81fbb4c] [0x81f9fa8] [0x812fa51] [0x812f5ed] [0x812e7b7] [0x8137e5c] [0x82f5abd] [0x8048111] } Please send a full bug report, along with the contents of autosave to: support@lokigames.com I would guess something didn't like me killing the window... Is this what you did?
I have a GeForce4 MX 440 with AGP8X, am using nvidia nvidia-kernel-1.0.6629-r3 , nvidia-glx-1.0.6629-r5. While using the nvidia driver the fullscreen image is severely distorted , so I run the game in window mode. The fullscreen image is fine on the nv driver. obelix@home ~ $ qpkg -f /etc/host.conf sys-libs/glibc * So the host.conf comes from the glibc , which is glibc-2.3.4.20050125. I will attach the file. When I start the game I choose 'New Game' -> 'Multiplayer' -> 'TCP/IP' , as soon as I click the 'TCP/IP' the game crashes. I suppose the the '/etc/host.conf: line 24: bad command `mdns off'' comes from the loki_libc complaining that it does not understand the file. This is normal , I guess , loki_libc is quite old. The line 'heroes3: dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed.' looks more like a problem.
Created an attachment (id=52225) [edit] host.conf This is my /etc/host.conf. I tried commenting the mdns line , but it did not make any difference.
Well... I don't know what changed since 2 mounts ago ( actually I do - several hundred merges of "unreleated" stuff :) ) , but the game has magically stopped crashing and misbehaving for me. Thanks to everyone who made this happen :)
Hi! Sorry for my question, because I am using Fedora Core 3, not Gentoo. But I can not get Heroes 3 working :( (It worked perfectly ot Fedora Core 1) I have searched with Google and have not found working solution for Fedora 3. I hoped that alex`s solution will help me, but it did not... Can you please help me, or direct me to some origin of inforamtion on how to overcme that problem with Fedora Core 3 and Heroes 3: [peter@hst-1-98 ~]$ heroes3 BUG! (Segmentation Fault) Going down hard... Heroes of Might & Magic III 1.3.1a Built with glibc-2.1 on x86 Stack dump: { [0x82062d3] [0x82064bb] [0x420] [0x827fe7e] [0x825f1a4] [0x825f00b] [0x825953d] [0x82596be] [0x824bcdf] [0x8242f69] [0x8243048] [0x8137d37] [0x82f5abd] [0x8048111] } Please send a full bug report, along with the contents of autosave to: support@lokigames.com Unable to execute loki_qagent - exiting Meanwhile I have tried all available patches/updates for Heroes 2 with no success. Running heroes3 as root resulted in a message: video memory protecting Thanks in advance, Peter
Perhaps you should ask on a Fedora list or in a Fedora bug report. Anyway, you said you got "video memory protecting" when running as root? That would make me think it might be something with SELinux. Try turning it off and see if you still have problems. Otherwise, well... I'm not a Fedora developer and have never used it, so couldn't be of much more help.
I have turned Selinux off, but unfortunately that did not helped:( Anyway, thanks for your attention! P.S. there is at this moment nothing about Heroes 3 on the Fedora list, but I will ask... It is maybe somehow related to SDL...
