Re: [tuxracer-main] Trouble getting tuxracer to start.
Status: Beta
Brought to you by:
jfpatry
From: David G. W. <dgw...@ke...> - 2000-05-02 23:13:35
|
I can personally vouch that this is a problem on a K6-233. I have one of those, and by the time I figured out that the problem was my CPU, the warranty was up. I have to run this CPU at 200, because it will die very quickly at 233 (no, heat is not a problem - it's cool to the touch). And it seems to be working OK at 200 with 32MB RAM, but anything more causes major messups. Windows would crash much more than usual (every 20 minutes or so), and Linux would die after 3 days with very weird kernel problems. And GCC would give me internal compiler errors. Fortunately I'm not using that machine any more, but my brother is :). On Tue, 02 May 2000, you wrote: > Oh - I feel <sick> - something very nasty just happened. > > OK - it's been a while since this thread fizzled out - so I'll quickly > recap: > > Ryan wrote: > > Ive installed the data in /usr/local/share/tuxracer and compiled (and > > installed) tuxracer-0.12 with no errors (maybe just a few warnings) and > > when i type 'tuxracer' from, say an xterm, I get... > > > > root@scrumpy:~# tuxracer > > BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: > > Assertion `needed != ((void *)0)' failed! > > I expressed doubt that it could be a problem with tuxracer - and indeed, > just doing an 'ldd' on the tuxracer executable was enough to produce > the exact same message. > > I wondered whether Ryan's older 1.9.11 linker was maybe not playing > nicely with his ultra-modern 2.2.14 kernel - or whatever compiler > revision came with his Debian Linux. > > There was also this strange compiler error: > > Ryan said: > > c++ -DHAVE_CONFIG_H -I. -I. -I.. -Wall -pedantic -O2 -c > > course_quad.cpp > > In file included from tuxracer.h:46, > > from course_quad.cpp:2: > > /usr/local/include/GL/glut.h:202: warning: declaration of `exit(int)' > > throws different exceptions > > Finally, Ryan said: > > OK, well yes I have Debian potato which is the latest stable (I belive) > > but I have never had any problems with it before with the dynamic linker. > > Basicaly I installed the base system and then in a more slackware like > > fashion did everything else as tarballs. The compiler is the latest > > stable of gcc (which of the top of my head is 2.9.75 or something like > > that) and my glibc is i belive 2.2 or 2.1 and my kernel is 2.2.14 > > now the only one of those things that actually came with the debian > > install was the glibc. At any rate, is it possible to update my ld.so > > and not have major library dependancy errors? I can see how it would be a > > problem, but that's just me. Hmm also I think I will need to take a > > look a GLUT perhaps. > > OK - so that brings us up to date. > > Now, I've just upgraded both of my PC's to SuSE 6.4 - which uses 2.2.14 > kernel (same as Ryan's) and ldd version 2.1.3. > > My PC's are called 'batcave' and 'waynemanor': > > batcave: 450MHz AMD with a GeForce card and 64Mb RAM. > waynemanor: 266MHz AMD with a Voodoo-3 and 64Mb RAM. > > They are running more or less identical SuSE 6.4 loads - installed off > the same CD-ROMs. > > Now, I compiled a program of my own (an early version of my upcoming > 'tuxkart' game) on batcave - and it ran *perfectly*. When I tried > to run it on waynemanor (without recompiling it - the two machines > share disk space via NFS) I got the EXACT SAME LINKER ERROR AS RYAN. > > On batcave: > > batcave% ldd /u/tuxkart/src/tuxkart > libglut.so.3 => /usr/lib/libglut.so.3 (0x40015000) > libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40048000) > libGL.so => /usr/lib/libGL.so (0x40065000) > .... > > But on waynemanor: > > waynamanor% ldd /u/tuxkart/src/tuxkart > BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: > _dl_check_map_versions: Assertion `needed != ((void *)0)' > failed! > > So: > > 1) We can definitely eliminate a bug in tuxracer - since tuxracer > and tuxkart don't share any code. (I suspected as much before) > > 2) We can eliminate Ryan's strange GLUT problem and the old version > of ldd he seems to have - although both are 'fishy'. My machines > are both running the exact same (and bang up to date) GLUT and > ldd. > > 3) Actually, we can eliminate everything except the CPU types I have > in my two PC's - they are virtually identical machines with virtually > identical software loads. > > What I now suspect is the little-know (but bloody annoying) bug in > some AMD K6-2 CPU's. I've never seen it impact ldd before - but > it regularly causes peculiar and intermittant compilation errors. > You run a 'make', the compiler dies with some internal error message, > you re-run it and it 'goes away'. > > However, the nature of the glitch in the CPU is such that in principal, > almost any program could fall foul of it - although it's an astronomically > rare problem (no Windoze program has ever been reported to fail for this > reason - and the only Linux program that ever reported a bug is the > gcc compiler). > > Oh - and the problem only shows up when you have >32Mb RAM. > > Well, perhaps this problem is showing up with the linker under > 2.2.14 kernels - and perhaps it's not intermittant for some programs. > > So - the big question is - what CPU does Ryan have - and at what > clock rate - and with how much RAM? > > If it turns out that this is indeed the problem, there are only > three possible fixes (AFAIK): > > 1) Change your CPU chip. AMD did promise to replace affected > CPU's at no charge - but when I tried to take them up on > that offer, they claimed that the bug only affects old > CPU's running at 133MHz and that they'd fixed it in 233MHz > parts. There are a couple of web sites out there where > people claim they see it on 233 and 266MHz parts - but AMD > won't play ball. > > 2) Downgrade your memory to 32Mb. Uck! > > 3) There is a kernel patch (for 2.1 series kernels I believe) > that does a *DISGUSTING* kludge to try to reduce the > probability of the bug. I don't know if that works with > 2.2.14 - and it seemed to me that the kludge had the possibility > of slowing memory allocation down noticably. |