Playing an Internet Onslaught game, game suddenly exited to shell prompt and
following error was above the prompt:
--------------------------------------------
RecvFrom returned SOCKET_ERROR 111
FailCode NEEDSTATS
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
aAssertion failed: p->model1 [File:KFarfield.cpp] [Line: 937]
History:
Exiting due to error
--------------------------------------------
I have experienced this same bug at least 5 to 10 times in just one afternoons
play. It's very irritating - occured in deathmatch; ctf and bombing run and
maybe others.
Comment 6Thomas R. (TRauMa)
2004-03-19 19:44:22 EST
Created attachment 234[details]
full UT2004.log from a KFarfield assertion failed crash..
Played a few Onslaught, then this occurred in the first CTF game.
Specs:
AMD 2x2600MP
Nvidia FX5900
1GB ECC Mem
Suse 9.0 Pro
Anything else you need, ask..
Created attachment 238[details]
full TU2004.log from SIGSEGV [segmentation fault] crash
Attached my full UT2004.log from the SIGSEGV [segmentation fault] type crash.
System specs are:
2x AMD 2800+ MP
2gb Ram
Nvidia FX 5900
Suse 9.0 Pro
Willing to test any possible fixes.
I am also getting the KFarfield assertaion failed crashes from time to time as
well.
Ok, the KIntersect crash and the p-model1 assertion appear to be two
manifestations of the same bug (which appears to be due to an uninitialized
block of memory inside the Karma physics library).
I'm about to flag a bunch of bugs as duplicates of this bug report, so sorry
about all the mail you might get CC'd on...
--ryan.
Please try these binaries and see if they help:
http://icculus.org/~icculus/tmp/ut2004-linux-x86-03222004.tar.bz2
Download them, unpack them in the retail game's System directory so they
overwrite ut2004-bin and ucc-bin, and go to town.
There's a few other fixes in there, too, but once we know they're better I'll
announce them publically. In the meantime, try not to spread them around too much.
--ryan.
Created attachment 247[details]
Crash from 03222004 binaries
Thank you for addressing this so quickly. Unfortunately, I got a KIntersect
error with the new binaries as well. Log file attached.
Seems to work for me. I played for a 1/2 hour. My original bug # was 1423, so
maybe these errors are different. I'll keep posting if I have an problems
here, but so far so good.
Created attachment 249[details]
Another log of a 03222004 crash
Here's a second crash log, if that helps.
My test case is to load 32 bots up at instant action onslaught at maximum
display settings and spectate. Only the demo has ever made it a full hour.
Created attachment 250[details]
Yet another 03222004 crash log
Okay, one more log, and then I'll stop CC spamming everyone. This one's
interesting because it mentions p->model1 again.
Here's an amd64 build (the crash is apparently still there but maybe reduced in
frequency, and there's a lot of other AMD64-specific fixes, like net
compatibility and no segfault when using webadmin, etc).
http://icculus.org/~icculus/tmp/ut2004-linux-amd64-03222004.tar.bz2
--ryan.
Created attachment 254[details]
log for SIGSEGV crash using 03222004 binaries
Took about 5 minutes for it to happen while playing ONS-Dawn. Thanks for the
speedy response to the problems.
Gentoo Linux
2.6.3-rc3-gentoo
XFree 4.3.0
Nvidia Drivers v1.0.4496
2500 Barton
Epox 8RDA+
512MB(256x2 Dual-Channeled) DDR3200 Corsair XMS
GeForce4 TI4600
SB Live! 5.1
Created attachment 255[details]
crash log for latest version
uhmmm... i'm out 1600c for challenging another team and the game crashing FOUR
POINTS from victory. heh.
Comment 40Kristopher Kersey
2004-03-22 21:53:18 EST
Created attachment 257[details]
Log file from crash on new AMD64 bin.
Got these on the console:
FailCode NEEDPW
Error, overrun: -32, trying to recover.
Error, overrun: -32, trying to recover.
Error, overrun: -32, trying to recover.
Error, overrun: -32, trying to recover.
Error, overrun: -32, trying to recover.
.
.
.
Error, overrun: -32, trying to recover.
Signal: SIGSEGV [segmentation fault]
Aborting.
I've got a couple of logs with the KIntersect crash in them that I could add,
but it looks like you've got plenty :) Let me know if you want them. I cannot
reproduce the crash reliably.
Comment 44Thomas R. (TRauMa)
2004-03-23 20:33:09 EST
Created attachment 262[details]
KIntersect w/ 03222004
On console it said:
Press any key to attempt to continue. Or make an offering to The Unholy Lord
Satan to get your game back.
With the new patch I am no longer receiving the Kintersect issue. I am however
getting a SIGSEGV crash (which also happened on the retail GOLD). Do you want a
seperate issue opened for the SIGSEGV? I think comment #42 is identical to the
log I have. The back trace is the same... just the libraries are a bit different
and some of the values.
I would like to leave this one open until the SIGSEGV is cleared just to make
sure that I have a long enough test run to say it is fixed.
Comment 48Sebastien Chaumat
2004-03-24 12:14:30 EST
I noticed that the crash occured often when the program is under heavy input
load (cliking on 2 mouse buttons plus 1 key or 2 on the keyboard).
Do the other in CC also noticed that ? Maybe this is relevant...maybe not.
SEb
Created attachment 264[details]
Another crash in
Another crash log, just to join the frey...
I know a lot of people who have a very unstable Linux version of ut2004.
FWIW, I got a crash with the new binaries as well. This time, however, I had
"Log: KIntersect had a null p->model1" right before the backtrace information. I
didn't have that with the original binaries.
Additional comment to Sebastien's, #48:
It's indeed more likely with much action on the screen. = many people/bots dying
-> many death animations, which is probably triggering the bug more often? I've
played ONS-Icarus a lot lately and it never crashed. In non-onslaught maps a
crash is certain, though.
I can't really confirm the "high input load" theory. It also happens if you load
up a small map with 32 bots and spectate for a while.
Comment 52Bryan "Brain Murders" Meredith
2004-03-24 19:35:15 EST
This game is definitely borked at the moment - with retail or the patch release in this
thread, I have trouble getting to the end of a map.
Is there _anything_ else we can do to help you find the bug(s) in the karma engine
Icculus???
Created attachment 273[details]
Crash Log
crashed again but with something new on the command line...
Assertion failed: type1 > kMcdGeometryTypeNull && type1 <
kMcdGeometryBuiltInTypes [File:KFarfield.cpp] [Line: 963]
Judging by the log this could possibly be a different bug?
I'm running the original binaries on linux 2.4.24 with a Geforce 2 mx
*** Bug 1497 has been marked as a duplicate of this bug. ***
Comment 57Matthias Klostermann
2004-03-28 04:38:08 EST
Created attachment 289[details]
Yet another AMD64 ut2004 crash with unofficial patch.
If there ist any way we could help you with this bug, please, please, please
tell us.
This may be coincidental, but....
If I have the "Physics Detail" setting set to High, I'm lucky to make it to
the end of map. Last night, I changed to "Low" and was able to play for
several hours. It may be something for people to try as a temporary
workaround. I have no idea what affect it has on game play. I didn't really
notice much other than it not crashing.
Hm, maybe something did go wrong while installing ut?
I can remember at least two messages in console, but I'm not really sure...
When I'm back in my appartment I can check that out.
PS: I had all three mentioned errors several times now. Seems to be really
random, cause sometimes I can play for hours, but I had a crash after few
seconds on a server, too.
I'm running the unofficial binaries. My graphics details are set mostly to
middle.
Just my two cents worth. I am running Gentoo Linux 2.4.25, P4 3.2GHz, nVidia GeForce FX 5900 XT,
768MB DDR266 RAM, Intel 865 Chipset, Intel ICH5 sound. I am sure the hardware is stable.
I get two kinds of crashes randomly.
1) (Signal: SIGSEGV)
Log: [ 1] ./ut2004-bin [0x86c915c]
Log: [ 2] /lib/libpthread.so.0 [0x4003f335]
Log: [ 3] /lib/libc.so.6 [0x40139fb8]
Log: [ 4] ./ut2004-bin [0x81d30b0]
Log: [ 5] ./ut2004-bin(KHandleCollisions__FP22_McdModelPairContainerP6ULevel+0xdd) [0x81d31f9]
Log: [ 6] ./ut2004-bin(KUpdateContacts__FRt6TArray1ZP6AActorP6ULeveli+0x74f) [0x81d11c3]
Log: [ 7] ./ut2004-bin(KTickLevelKarma__FP6ULevelf+0x234) [0x8603028]
Log: [ 8] ./ut2004-bin(Tick__6ULevel10ELevelTickf+0x35b) [0x82df03b]
Log: [ 9] ./ut2004-bin(Tick__11UGameEnginef+0x3cf) [0x82889b7]
Log: [10] ./ut2004-bin(SDL_SetVideoMode+0x83f) [0x814dac3]
Log: [11] ./ut2004-bin(main+0x69bc) [0x815849c]
Log: [12] /lib/libc.so.6(__libc_start_main+0xbf) [0x40126adf]
Log: [13] ./ut2004-bin(getlogin+0xad) [0x814d361]
Log: Unreal Call Stack: KIntersect <- KIntersectEach <- KHandleCollisions <- KUpdateContacts <-
KTickLevelKarma <- TickAllActors <- ULevel::Tick <- TickLevel <- UGameEngine::Tick <- UpdateWorld
<- MainLoop
2) The famous
Assertion failed: p->model1 [File:KFarfield.cpp] [Line: 937]
This happens sometimes immediately, sometimes after 3 hours of play. I am sure it is not hardware
related as I stress tested my machine for 10 hours using cpuburn and it worked fine - also UT2003
works flawlessly.
I tried the patch released on here, but it only changed the pointer p->model1 to have a null value, and
not check the assertion, that is why I would get the "p->model1 is null" exception. So I rolled back...
Any ETA on a fix?
Thanks so much for all your hard work.
Just a very silly suggestion - I have absolutely no idea what exactly the Karma code does (apart from
the fact that it has something to do with the physics), but I would *much* more prefer me dying/
graphical glitch/stray bullet than the game crashing.
Therefore a suggestion for an interim solution is to (if at all possible) patch the code so that the
assertion p->model1 != null does not fail, but that if it is null (which is obviously wrong), it does some
graceful handling of the problem - such as skipping the request and resetting it as if it had performed
the request.
This will only be a temporary solution, but will make the game playable.
Comment 74Lars Hugentobler
2004-04-01 04:31:07 EST
i apologize for producing two dupes, but i'd like to point out that the binaries
linked in comment 27 worked really well for me after switching to my system's
libSDL.
After play with the patched version for a bit (from additional comment #27), I
noticed that this one doesn't detect "lock on's" correctly. My vehical will get
a lock on and then I can doc for cover and avoid the hit... and the lock on
will remain. I can get out of the vehical, run around for ages (in ut time :)
and jump in and lock on will come on immedately... even though no ememies are in
the area and I wait and no boom. This didn't seem to happen with the retail
version.
After reading comment #74 I thought I'd try my own SDL library too (with
patch). Seems to be the best yet! I even managed to play a single player
assault match all the way through!
Created attachment 293[details]
Crash log with new binaries and system libSDL
I've been playing with the new binaries (32 bit) and my own libSDL
(libSDL-1.2.so.0.7.0). I'm still crashing, but the stack trace is different.
It's similar now to attachment #263[details], 'mcdcontactsimplify'.
Thanks for all your work, and please keep us posted...
Crashiness is low on my box with 03222004 binaries and symlinked libSDL 1.2.7
and openal 20040303, physics detail set to low. Kernel 2.6.3, if that's relevant.
Okay, I have been torturing the new binaries for the last several hours under a
variety of conditions, and I have yet to see a single crash. At a minimum, the
latest patch is a tremendous improvement over the previous two versions. Thank
you, Ryan.
To the people actually having crashes, could you please post the entire log
file, system specifications, and perhaps the game conditions (gametype. number
of players. etc.) when the crash occurred?
I've been playing using the binaries in comment #83 for several hours this
evening and not a single crash - previously I'd be seeing 8 or 10 in the same
time. (still using my own libSDL though.)
Great improvement for me at least (fingers crossed, touch wood). Thanks a lot.
Kernel 2.6.4
libSDL 1.2.7
XFree86-4.4
nVidia binary drivers 5336
I just put a couple of hours with the new amd64 binaries into an online
20-player ons-severance match without a single crash... woohoo! My system libSDL
is identical to the one in the kit (amd64 gentoo running 2.6.4-bk4). Thanks so
much for all your hard work on this, Ryan.
I just had a crash with the most recent binaries, exactly the same as
described in comment #91. They are still a huge improvement though - perhaps
we are now talking about a different bug?
Comment 94Kristopher Kersey
2004-04-03 10:52:22 EST
Worked 100% on AMD64 last night over several hours. No crashes at all. Seems
like the new crash is fairly rare.
FWIW, I played for several hours last night on a variety of maps using the new
x86 binaries with the physics set on "high" and never crashed. I especially used
maps that involve a lot of rag-dolling when you die (like on BR-Anubis). The new
binaries seem to have lessened this bug's severity at least. I'm using a heavily
modified version of Slackware 9.0 with the 2.6.3 kernel and an NVIDIA GeForce FX
5700 Ultra with the 5336 drivers. I'm using the game's libSDL and openal.so.
Russell, to post an entire log file, create a new attachment. Although I think
you included enough.
It's disappointing that some people are still crashing. It might possibly help
to purge your ~/.ut2004 directory and try again.
Comment 98Sebastien Chaumat
2004-04-03 15:42:11 EST
Created attachment 299[details]
log of a crash with the new binary "kintersect-fix"
Crash with new binary (not exactly the same as before)
Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect
Look at his log : there is a strange constantly repeating warning (the log is
300k!) :
Log: Octree Warning (AddActor): ONSManualGunPawn Outside World.
Log: Octree Warning (RemoveActor): ONSManualGunPawn moved without proper
hashing
----
Kernel 2.4.24
debian sid SDL 1.2
sblive OSS
athlon 2500 512Mo
"
Log: Octree Warning (AddActor): ONSManualGunPawn Outside World.
Log: Octree Warning (RemoveActor): ONSManualGunPawn moved without proper
hashing
"
I saw that in some of my crashes with the retail build as well.
Just an fyi.
-Ryan N.
Created attachment 300[details]
Crash with KIntersect-fix binaries
I finally got a crash with the newest binaries. Once in a dozen hours of play
is still a much better ratio, though.
I was getting the same error that originally started bug 1413, but when I
applied the patches I also get the same log file as <a
href="https://bugzilla.icculus.org/show_bug.cgi?id=1413#c96">Comment #96</a> .
The stability seems to be better with the retail version. The patches that I
applied seem to be more unstable and the error in #96 seems to occur more
frequently than the original bug.
I'm currently of the opinion that the x86 build box didn't pick up all of the
source changes, or at least didn't recompile everything, thus reducing the
frequency but not erradicating the bug...human error.
This is just a guess, though. I'm rebuilding x86 to see if this helps.
amd64 was built by hand from scratch, which might be why no one has reported any
crashes, but that might just be a matter of less testers.
--ryan.
Created attachment 302[details]
Another Crash log with Newest Binaries
Seems to crash more often for me with the new binaries. About every 3 minutes.
Doesn't seem like it was like the old crashes though, as it isn't when people
around me are dying. This is kind of more random I guess. Created an
attachment, and here's the output from the console.
<console>
WARNING: ALC_EXT_capture is subject to change!
Resolved ut2004master2.epicgames.com -> 207.135.145.7
Connection established.
Resolved ut2004master2.epicgames.com -> 207.135.145.7
Connection established.
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
SendTo: 67.167.43.130:7778 returned -1: 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
SendTo: 65.39.83.116:7778 returned -1: 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
RecvFrom returned SOCKET_ERROR 111
Signal: SIGSEGV [segmentation fault]
Aborting.
Crash information will be saved to your logfile.
</console>
This is a sanity-check complete rebuild to make sure the build box didn't screw
up. This is x86 only; amd64 users should have a sane build already.
My stress test, which crashed reliably in minutes, has been running for over an
hour (but the last build, which people had trouble with, ran all night here, so
take it for what it's worth).
http://icculus.org/~icculus/tmp/ut2004-kintersect-fix-2-x86.tar.bz2
--ryan.
Tested the AMD64 build with 32 Bots (Godlike) on ONS-Icarus for some hours. No
crash yet, unlikely to see one. I would say AMD64 build ist stable now, thx. Ryan :)
Created attachment 306[details]
Another Crash log with KIntersect-fix-2
Game crashed 10min after it was first started with the new binaries
OS here is Gentoo Linux
Created attachment 307[details]
This is the latest utlog file for new binaries.
Played the new binaries here is the crash log for Fix 2 as an atachment.
Russell
Created attachment 313[details]
Kintersect crash with fix-2
about 30 minutes of play. Even with fix-2. ( Linux DEMO never crashed )
System:
Distro: Mandrake Linux 9.2
Kernel: 2.4.22-10mdksmp #1 SMP
P4 3.0Ghz ( Hyperthreading enabled )
512MB Ram
GeForce2 GTS/Pro ( 64MB )
Comments:
Bug seems to trigger faster on servers with more players. I can
typically play for several hours on servers with less then 16 players. Over 18
in about 30 min. 32+ 10 min max.
I've hit this on pretty much every map.
Created attachment 316[details]
Crash log with new patch
I've crashed twice in an hour while testing the new patch in Onslaught mode
online. Here's my log file for the 2nd crash.
Created attachment 317[details]
Crashed as soon soon as I joined a game
This time UT2004 crashed as soon as I joined the game, with a much messier
variant on the KIntersect bug. Could it have something to do with me just
installing the Anti-TCC stuff? Log is attached.
Created attachment 319[details]
Several logs of crashes with the ut2004-kintersect-fix-2 on x86
Three crash logs with the ut2004-kintersect-fix-2 version on x86. RedHat 9
system, with locally built SDL-1.2.7-1 from SRPM. GeForce4 Ti4400. AthlonXP
1800+, 1GB ram. Locally-built 2.4.20-30.9 kernel.
In two of them, I was able to play for a while before crashing. In the instant
one, it crashed as soon as the map loaded. Still very hard to isolate, I
played several rounds yesterday without a crash but crashed multiple times
today. All were in onslaught.
I've been playing quite a bit with the fix-2 binaries since they were released
and I have not yet gotten a crash, even with the physics set on "high". FWIW,
I'm using the stock libSDL and openal.so.
I too have been playing with the fix-2 and no problems tonight with onslaught
online. So far no crashes!
Thanks for the help Ryan. Ill keep you posted.
Have been playing with fix-2 since monday. Crashes are less frequent, and occur
with a different signature.
Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect <- ...
My machine has recompiled libSDL and openal.
Created attachment 340[details]
MdcContactSimplify logfile
Logfile for crash with "Unreal Call Stack: McdContactSimplify <- ..."
Log is using ut2004-kinsersect-fix2. Replaced locally-compiled openal and
libSDL with original shipping versions (i.e. reverted to original); this
improved reliability somewhat, but game still crashes about once every half an
hour.
I get this problem ver often
The first report was made more than one month ago
Is there any chance that we have a patch some day ?
It's not like it is not reproductible : many people have this bug.
I can be a bit patient, but understand that it's a bit annoying when we can't
finish a game because a bug occurs in the middle of it :/
Created attachment 346[details]
Online McdContactSimplify crash with fix-2 binaries
I've beaten these fix-2 binaries to death in single player ever since they came
out and never got a single crash. I decided to go online and spectate a couple
of Onslaught maps. It made it through the first map fine. The second map
crashed and produced this log. Is this now a multiplayer-only thing?
Created attachment 347[details]
UT2004 Crash Log
This is a crash log using the jesus-h patch. The other patches also do not fix
this problem for me.
Just as the previous poster said, this seems to be a multiplayer-only bug.
I've played many single player matches and I cannot get this bug to show up
while in SP. However, while playing Onslaught multiplayer, it's often hard to
finish a single match without the game crashing. Speaking of onslaught, is it
the only game mode that this bug pops up in? I played a few matches of
Invasion and it worked flawlessly for the few maps I tested online. Maybe I
was just lucky?
I have yet to find a pattern for when the game crashes. Sometimes it will
crash immediately after the map loads and other times it will crash randomly
during the game.
Anyways, it'd be real nice to have a patch for this soon. :-/
Created attachment 348[details]
UT2k4 Seg fault
This log was done on a P4 2.8E w/hyper-threading. Nvidia Ti4200 with
"NVIDIA-Linux-x86-1.0-5336-pkg1.run". Installed fresh again from the UT2k4 5-
disk cd set. Current OS distro is Mandrake 10.
There is mention of corrupted texture, but even with clean install(s) this
remains. Copied from W2k- problem exists even. Wondering if this is an isolated
incident?
Anyway crash is very annoying. No mp game lasts longer than 2h30m long .
I think that is all. Thank you.
If the bug occurs are you playing MP on the internet or LAN? I'm mostly playing
on LAN and with the kintersect-fix-2 patch I've never experienced this crash
anymore. It used to trigger very easily in crowded DM maps, but even those now
run for hours and never crash on me.
I have yet to play this game on a LAN, so I have to say that this bug only
shows up when I'm playing on the internet. It'd be interesting to hear
feedback from more users that have played many LAN games. Maybe it is an
internet-only bug after all...
BTW, I forgot to mention my setup in my comment yesterday:
Gentoo Linux w/ 2.6.5-mm5
Audigy 2 ZS using ALSA
Geforce2 pro GTS 64mb using nvagp and driver release 5336
xfree 4.3.0
I've tried both the original sdl and openal libraries in addition to ones
compiled on my own. This doesn't seem to have any effect.
Let me know if more info is needed.
With regard to "internet only" speculation - I watched my friend crash out of
a single-player onslaught game (fix-2 binaries) last night. He restarted
immediately and the log was lost, but it *looked* like the McdContactSimplify
bug. This is the only cause of crashes that I ever get now.
Does anyone know if there is a fix being worked on?
McdContactSimplify definately seems to be vehicle-related. I played assault on
a map with 15-25 people for about 3 hours before finally getting a crash. Crash
occurred while I was getting run over by a Hellbender.
Can anyone determine if crashes are specifically related to being run over (or
running over with) vehicles?
Sorry, hadn't quite figured out attachement creation yet.
My above attachment is an McdContactSimplify crash that has occured on
ONS-Icarus online twice within a short period of time each. These are using the
fix-2 binaries on x86.
Just as a thought - It should be noted that a lot of my McdContactSimplify
crashes appear when I'm online, on ONS (tho I don't play much else) and in a
Tank. Not sure what I'm doing in the Tank when it crashes (i.e. getting hit,
running over, firing), but it seems to be that. Don't take my word on that, however.
System:
Gentoo Linux, kernel 2.6.5 (vanilla)
Nvidia GeForce Ti4600 w/ 4496 drivers
1024MB RAM
Pentium 4, 2.53GHz
XFree 4.3.0
libsdl 1.2.7
Gnome 2.6.0
I don't think it's vehicles. It may just seem that way because most of the
time in Onslaught you're, well... in a vehicle. I just got an
McdContactSimplify crash while running around Dawn with a lightning gun. No
vehicles in sight.
Well I decided to do an unofficial test, I played a few hours in assualt, deathmatch, and
I did not encounter the bug, it only seems to happen in onslaught. I have not tried all
the other game types, maybe someone can venture their experience.
The longer they wait, the more people will be upset, at this rate they might as well
withdrawl their Linux support of the product. How many people bought this game just
for Linux support? I know I did, and having it not work in Linux is very up setting. As
others have stated, in the Gnu/linux community their are plenty of knowledgeable
people who probably could be consulted, hired to work on this project. Here is to
hoping on a fast fix, or a fix for that matter.
Russell
I think we need to cut back on the hyperbole. Saying that the client "doesn't
work" is overstating the problem. You yourself said that you can play everything
except Onslaught without any problems. I can play any game type in single player
with the fix-2 binaries and not have a single crash (this is with at least 50
hours of gameplay). With the original binaries I'd be lucky to make it through
an hour. I'd like to see it fixed completely too, but taking cheap shots at
icculus isn't going to help.
I've certainly had it happen to Assault a few times, normally on robotfactory &
glacier - the ones with vechiles in them. I don't have to be in the vechiles or
close to them for it to happen tho.
Invasion seems to work fine without it.
I appericate Ryan's work on this, and I get the impression that it is proving
difficult to take down. As a coder myself, I can appericate this!
The thing I do find odd is that the demo had no such problems, I played ONS for
hours without issue.
Comment 156Jason D. Clinton
2004-04-24 19:52:27 EDT
I just finished an eight-hour non-stop testing spree in single player. Single
player is completely unaffected by this bug. This leads me to believe the bug
lies is the position prediction code for network play. I'm guessing that objects
are occasionally predicted to exist beyond logical collision space.
I have been playing on a lan for several hours. The ONLY time I crash is during
Onslaught. I am using the fix2 binaries under Fedora Core1. I can play any other
type of game ( mutant, DM, etc) all night without problems.
Can someone confirm that this bug happens when playing a network game on a dedicated server with
the fixed binaries? It's possible the crashes are happening because the Linux dedicated servers out
there don't have the fix (which would be most of the public ones, including the Atari Official servers),
and transmit bogus data to the client.
Thanks,
--ryan.
I've installed the dedicated server (there is only one release floating around,
right) on a LAN server and played with that. Two players connected, one Linux
machine, one Windos. In about two hours of ONS-Redplanet it didn't crash. I
didn't test very much though, because the system was quite underpowered to
handle the load (600 MHz). Will test a bit more.
Hm, can the kintersect-2-fix binaries be used with the dedicated server install?
Ah, indeed. I've been running the dedicated server with the non-fixed binaries then.
$ md5sum ucc-bin
458e8050afd5302e8d5f419cb023fa65 ucc-bin
You want tested: patched client (kintersect-2) + unpatched dedicated server, right?
Hm, here it is
Log: [ 1] ./ut2004-bin [0x86c932c]
Log: [ 2] /lib/libpthread.so.0 [0x4003858d]
Log: [ 3] /lib/libc.so.6 [0x400fb458]
Log: [ 4]
./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x301) [0x81d2fe1]
[...] and so on.
Same as posted by many others. This was on LAN with a _unpatched_ dedicated
server. ONS-Torlan right at the very beginning while spawning all players (2sec
into the game). An hour worth of DM maps run fine before that.
The server still runs, only the client crashed. I'll copy the kintersect-2
binary over to the dedicated server and try again.
At least your theory patched client + unpatched server = crash seems to be not
that far off. We always played with a listen server on the LAN and since your
latest patch all crashes were gone.
So far so good. Copied the kintersect-2 ucc-bin to the dedicated server and
ONS-Torlan ran without a crash until now. Maybe it's time to release an official
hotfix/patch for client and server? Then this gets more widespread testing.
I can reproduce this bug 95% of the time by either:
dying in a vehicle
watching someone else be hit by a vehicle
I've only actually tested with Onslaught.
If I play maps with no vehicles I can play for hours.
Although rare, I'm almost certain I've had a crash or two with both the client
and server patched. The KIntersect-2 fix is on the server, while I've tried
both KIntersect-2 and the jesus-h-christ binaries on the client. Unfortunately,
I haven't saved any logs, but I'll post one if it happens again.
The jesus-h-christ binaries seem more stable than the KIntersect-2 ones. I'd
like to try it server side, but there's no ucc-bin in it.
Created attachment 353[details]
Client crash with patched server and client
Here's a crash from a jesus-h-christ client when connected to a
kintersect-fix-2 server.
I don't like hyperbole either, but the fact is that if you bought this game to
play Onslaught on Linux, it is practically useless. You certainly can't make it
through a match with these binaries. Yesterday I crashed 5 times in a single
45-minute match.
It may be fun to play squash-the-boogs with free software, but when you lay out
$30 for the game you have a right to expect quality out of the box and timely
updates afterwards. The quality of feedback demonstrated here is more than
Atari has any right to expect. I hope to see a fix for this issue soon.
I've been playing single player onslaught with no crashes (+kintersect-2 fix).
So it could be possible that network interaction is causing the crash.
This shouldn't be the case by principle though since the windows client doesn't
crash when connected to any server. Why would the server matter if only the
linux client is crashing?
Added crashlog found here:
https://bugzilla.icculus.org/attachment.cgi?id=354&action=view
My system stats:
Shuttle SB75G2
Pentium 4 2.8Ghz
512MB Cas3 Crucial RAM
80 GB SATA drive
ATI 9800 PRO 128MB
ATI 3.7.6 Linux Drivers
Gentoo 2004.0
Kernel 2.6.4
OpenAL 20040303
libSDL 1.2.7
SDL-GFX 2.0.10
The error this time was just simply a crash/segfault when playing UT2004 for
about 15 or 20 mins. I was playing on-line. Playing single user never seems to
have a problem though, I can verify this if I see feedback here regarding any
steps I can take to provide better feedback.
I would like to register my complaint though, that I didn't expect to have to
submit a bug about this one thing that so many others have submitted about, but
I don't know how else any of us will ever get what we paid for. I only make this
remark that I hope someone from the company reads this and helps Ryan take some
action if he needs the help. Ryan, I'm glad you've done what you have so far,
and I hope you find a fix soon.
Austin
Some patterens with the bug I have noticed which may help someone somewhere:
1) it only affects online play, single player does not crash
2) it only affects onslaught, other game styles do no crash
3) dropping the 'physics detail' option reduceses the frequency of the crashes
4) the number of people on the server is related to the frequency of the
crashes. (perhaps due to some block of code being invoked more often)
<10 I can play forever
10-14 Will crash in the next hr
14+ Will crash in the next 10 minutes
5) crashes often occur during vehicles + death + projectiles (may explain #4)
6) spectating online,onslaught,14+ players does not crash
7) demo does not crash.
I've been playing online by sticking to servers with max 12 people. I have bug
free sessions. But half the fun of this game is when there are 12 ppl a team!!!!!
client movement prediction?
Well been testing the fix 2, it seems ut2004 is much more stable if u play at
patched dedicated servers. When i played with my fix-2 patches ut2004 on a non-
patched dedicated server i had lots of crashes, then i patched the server to
fix-2 and i was able to play for hours without it crashing, i had 8 people in
the game, tried ons ctf br and it kept going on fine, also the client didnt
crash anymore. So i think they should send out the patch officially for
dedicated servers.
I have noticed that I have never had a crash playing 1v1 online. This maybe
just due to that fact most 1v1 matches are less then 15 min.
I see lots of crashes on any "team play mode" with a lot of players. ( more
than 8 ) It seems to be a player interaction problem.. It's kinda pointless
for us to speculate on what wrong.. We can kinda see causes, but with out
knowing how the game opperates it's a fruitless operation to dig any farther.
Eh^Biovore
biovore@covad.net
Created attachment 357[details]
Crash Log
My fastest crash yet. 40 seconds :)
I assume this is the Karma bug. I did a query on "RecvFrom returned
SOCKET_ERROR 111", and this seemed to be the relevant bug.
Created attachment 360[details]
Crash Log
Its *almost* repeatable in that if a change is made to the config, then its a
lot more likely to bomb. For example here I had switched from 1600x1200 to
1024x768 and then joined. Like I say, it doesn't do it every time, but does
make it more likely to crash.
Created attachment 361[details]
Crash Log
DevKarma nonsupression gives a little more detail in this crash log. This is
with kintersect-fix-2 (I find the jesus-h one less stable!)
The output of my crashes are exactly the same as the ones listed, so I don't
need to post it, but what was kinda neat is three of us Linux players got
together for a LAN game. All systems had the fix-2 patches.
One person hosted and myself and another guy connected. We were in an Onslaught
game (the usual typical crash game). He was next to me where I could see his
screen. We were in totally different parts of the map then all of a sudden, we
both crashed at the exact same time. Our logs revealed the same crash. The
person hosting the game didn't crash though. Just kinda strange.
Ken
Once we had the same problem.
5 clients connected to my dedicated server in our company -> ONS Map -> Crash
All 5 clients crashed at the exact same time. But the server was still running *puh*
all clients had fix-2.
Created attachment 364[details]
Crash Log
3204 beta patched now and I'd say it crashes more than the kintersect-2-fix
patch. "Nice" to see its happing in Windows too as that should help narrow
things down. Am willing to help test stuff if it aids degubbing.
Seems a lot more unstable switching screen resolutions now as well. Have had it
bomb out several times just changing res from the settings page.
Created attachment 365[details]
Latest crash UT2004.log with KIntersect-fix-2 binaries (long)
map was ONS-JUNKARD
Last sound I heard was the explosion of the vehicle's turret weapon that I was
controlling.
Sorry for the huge attachment, but I didn't want to take out anyhting that
might help. The crash is at the end, naturally.
Okay
So it's been over 2 months since the first report in this thread.
2 months of not being able to play a single game reliably because of a major bug.
A bug that has been meticulously reported by the users, in more details and
willing cooperation than any software company could ever hope to be offered.
A couple of patches were posted; mostly useless.
Should we even bother waiting/hoping for a fix ? Is anyone working on fixing
this ? Or should linux users just reclaim the 5+ GIGS of hard disk space
occupied by this behemoth and count their losses ?
Ok, I have agree with the previous post whole completly. It is very frustrating
and I have found MY solution.
First of all, I appreciate the effort and at least the possibility of adding
another Linux game to my collection, but this game should not have even been
released for linux. It is totally UNplayable and I basically have given up even
trying to play this game after tonight. I will put in on the back burner and
play it when the real patch comes out to fix the problem.
Secondly, I think it is 100% total BS that I pay for a game and after 2 months
NOTHING has been fixed.
The basic scenerio:
Here ya go, buy the game but don't expect to play it more than 5 minutes w/o a
crash. Furthermore, we don't really think it is important enough to fix the
problem, so p%$^^ off customer. We don't need your business anyway and if you
you got a problem with that we probably will not make another Linux version anyway.
Does that sum it up?
People...calm down. I'm sure everyone here and at Epic is working on a fix.
Actually, the people at epic HAVE come up with a fix (aparently)[?]. I've been
playing on the new Epic binaries for a while now and no crash YET. I bet this
has got all of you pretty fired up by now eh? Ok, no more procrastination. First
let me just say that this is the linux version of the Newly released 3204. It's
still a BETA patch but it is official by EPIC. Go get it at:
ftp://ukftp.multiplay.co.uk/pub/games/fps/unrealtournament2004/patches/linux/ut2004-lnxpatch3204BETA.tar.bz2
Yep, it's the linux 3204. Looks a little different while starting up. Go Have a
look at the changelog that comes with the patch (Help/ReadMePatch.int.txt)...I
really hope this one won't crash at all. Best of luck, hope it helped. =)
Created attachment 367[details]
3204 Beta Crash log
Please give an update on this. You've gotten more crash data than any developer
could ever hope to get.
Here's another attachment. Let's see if we can make it to 500 :-(
You crashed? With 3204? Hmm.. Actually there's a little theory I wanted to throw
down on the table. We pretty much know this crash has to do with vehicles. The
crashes only happen in Onslaught and AS-JunkYard where there is a HellBender.
Apart from that, DM, CTF, DDOM don't really crash. Not that I've experienced.
But that's not really my theory. My theory relies on Epic's inconsistency with
binary releases. We have the following facts!:
1) Linux UT2004 Demo NEVER crashed.
2) Linux Retail build Crashes.
3) Windows Retail build NEVER crashes. [At least not from Karma KIntersect]
4) Windows Patch 3204 crashes.
This leads me to believe that Code in the Linux Retail BINs is more recent than
code in Windows Retail BINs. A logical drawing to eliminate code for epic would
be to grab changelogs and see what has been modified in certain combinations.
Given the above facts we can draw this out:
Linux Demo = Windows Demo [No Crash]
Windows Retail = Windows Demo [No Crash]
Linux Retail = Windows 3204 [Crash]
I really hope Epic keeps changelogs =). It may be wild-eyed...but it's a hunch
i've had for a while.
I hate to get greedy, but can we get an AMD64 patch as well? Also, can we get
some info on who you are Tom and where this new patch came from? I'm not into
just downloading patches from just any source. Thanks.
Kristopher, the file does contain AMD64 binaries. They've been renamed to
ucc-bin-linux-amd64 and ut2004-bin-linux-amd64. So just rename them by taking
off the -linux-amd64 and it should work for you.
Just for information I get this as the MD5SUM for the file
632416236513bbebca0d34327ebc7bc5 ut2004-lnxpatch3204BETA.tar.bz2
Just to add info: I was on an official Atari server for attachment #367[details] crash.
It's possible they were still running an older version, although it still
_shouldn't_ make a fixed client crash in theory :)
Alright, Instead of putting the game up until it was fixed, I tried the beta
patch first.
Well I was able to play for about 2 minutes on the first ONS game and less than
1 minute the secord go around. It is still broken and probably will remain that
way for awhile. My suggestion is to forget about playing for a few months until
all the bugs are worked out.
In response to the theory that this crash is vehicle related, it happens in BR,
so that is definately not the whole kit and caboodle.
In response to the frustration, obviously I am frustrated too. On the one hand
we are very pleased that we got the game ported to linux and had it in the box,
but since it is unstable we are frustrated, as we should be. I think one thing
that would help would be some more updates about progress on this bug.
Thanks again for your help
-Sam
Here's an update:
- We're still working on it (no, we really are, I swear!)
- I have gone over Karma with a fine tooth comb, and it's now valgrind clean
in the 3204 patch. There's 10-15 significant memory access fixes over 3186
in Karma and the surrounding code. Some of these were crashbugs that
hadn't been a pesk yet, others were related bugs. To my chagrin, none of them
fixed the KIntersect issue.
- Win32 clients are seeing this in 3204, too, many with as much frequency
as Linux users are accustomed to. As someone predicted, the retail Linux
build is a few revisions ahead of the retail win32, so it's possible this bug
sneaked in between the Win32 binaries going gold, and the Linux
binaries going gold. However, the Mac client hasn't ever experienced
this crash, to my knowledge, and it's a later build by several days...this
is noteworthy, since the bug has dug in so deep that the win32 client
is now triggering it months after 3186 went gold.
- Obviously, we've got a better grasp on the problem, thanks to the
win32 client misfortune. We don't, however, have a fix yet, but now
there's more developers at Epic directly interested in fixing this bug,
fwiw.
I'll report back when there's more information. Sorry to everyone
that's getting burned by this bug; I'm as displeased with this
scenario as you are, and hopefully we'll get you guys fixed up soon.
--ryan.
Well yes it is very frustrating because the game is basically useless now. As it
appears after this patch - beta 3204 - the game has become even less stable. I
am not sure which patch - kintersect-fix2, jesus-h-christ, or beta 3204- has
caused the game to seg-fault now. I was getting the - KFarfield.cpp] [Line: 937]
- error. Now it doesn't show at all. I simple get the segfault crash variety.
So, I am lost as to what the real problem on my system is now. The Karma deal
was a little better understandable as to where the problem existed.
No log attached as plenty have been attached so far. If you need one, I will
post it if you like (as soon as I can find it :).
Ryan, thanks for the status report. As long as you're still working on a fix
I'm happy to wait as long as it takes, but I think we all needed some
reassurance that we hadn't been abandoned.
Come on, I bet everyone was wondering: what framerates did you see under
valgrind? Anything playable?
Ryan,
This may have fixed the problem, as I played for about 1 hour without incident.
I will further test this tonight, but it does seem ok.
It is definately better than 5-10 minutes of gameplay.
A sincere thank you is in order.
PS. Could you possibly gives the guys at Redhat a hand with the p4p800, FC2
reboot issue? :)
Yup. Been hitting at as hard as I could. Physics Detail on "high", 32 players,
Max carnage. Hours of play (hands now numb). Much positive karma to Ryan!
I think we can all pause for a moment of silence while I put this bug report in
the grave.
THANK YOU to everyone that patiently waited for a good fix for this. All of the
detailed reports and research were very appreciated. Still, let's try to _not_
do this again, okay? :)
Resolving bug #1413 as "FIXED". w00t!
--ryan.
I experienced the same crash. Although, if you revert back to the patch before
3236, you can still play online and it will not crash (in my experience).
Granted, I haven't played tons with 3236.1, but I haven't experienced the
KIntersect bug yet. I played enough online last night that the bug would have
triggered with the original retail version.
Playing an Internet Onslaught game, game suddenly exited to shell prompt and following error was above the prompt: -------------------------------------------- RecvFrom returned SOCKET_ERROR 111 FailCode NEEDSTATS RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 aAssertion failed: p->model1 [File:KFarfield.cpp] [Line: 937] History: Exiting due to error --------------------------------------------Created attachment 234 [details] full UT2004.log from a KFarfield assertion failed crash.. Played a few Onslaught, then this occurred in the first CTF game. Specs: AMD 2x2600MP Nvidia FX5900 1GB ECC Mem Suse 9.0 Pro Anything else you need, ask..Created attachment 238 [details] full TU2004.log from SIGSEGV [segmentation fault] crash Attached my full UT2004.log from the SIGSEGV [segmentation fault] type crash. System specs are: 2x AMD 2800+ MP 2gb Ram Nvidia FX 5900 Suse 9.0 Pro Willing to test any possible fixes. I am also getting the KFarfield assertaion failed crashes from time to time as well.Created attachment 247 [details] Crash from 03222004 binaries Thank you for addressing this so quickly. Unfortunately, I got a KIntersect error with the new binaries as well. Log file attached.Created attachment 249 [details] Another log of a 03222004 crash Here's a second crash log, if that helps. My test case is to load 32 bots up at instant action onslaught at maximum display settings and spectate. Only the demo has ever made it a full hour.Created attachment 250 [details] Yet another 03222004 crash log Okay, one more log, and then I'll stop CC spamming everyone. This one's interesting because it mentions p->model1 again.Created attachment 252 [details] Yet another 03222004 crash log Whoops, wrong log. Here it is.Created attachment 253 [details] and64-03222004 crash log As one might have guessed, the 64-bit version crashes as well. Here's a log.Created attachment 254 [details] log for SIGSEGV crash using 03222004 binaries Took about 5 minutes for it to happen while playing ONS-Dawn. Thanks for the speedy response to the problems. Gentoo Linux 2.6.3-rc3-gentoo XFree 4.3.0 Nvidia Drivers v1.0.4496 2500 Barton Epox 8RDA+ 512MB(256x2 Dual-Channeled) DDR3200 Corsair XMS GeForce4 TI4600 SB Live! 5.1Comment on attachment 254 [details] log for SIGSEGV crash using 03222004 binaries Changed mimetypeCreated attachment 255 [details] crash log for latest version uhmmm... i'm out 1600c for challenging another team and the game crashing FOUR POINTS from victory. heh.Created attachment 257 [details] Log file from crash on new AMD64 bin. Got these on the console: FailCode NEEDPW Error, overrun: -32, trying to recover. Error, overrun: -32, trying to recover. Error, overrun: -32, trying to recover. Error, overrun: -32, trying to recover. Error, overrun: -32, trying to recover. . . . Error, overrun: -32, trying to recover. Signal: SIGSEGV [segmentation fault] Aborting.Created attachment 262 [details] KIntersect w/ 03222004 On console it said: Press any key to attempt to continue. Or make an offering to The Unholy Lord Satan to get your game back.Created attachment 263 [details] New crash, mcdcontactsimplify This one seems new to me.Created attachment 264 [details] Another crash in Another crash log, just to join the frey... I know a lot of people who have a very unstable Linux version of ut2004.Created attachment 267 [details] Another KIntersect crash Man I hope this gets worked out.. =c(Created attachment 271 [details] Kintersect/Karma Crash LogCreated attachment 273 [details] Crash Log crashed again but with something new on the command line... Assertion failed: type1 > kMcdGeometryTypeNull && type1 < kMcdGeometryBuiltInTypes [File:KFarfield.cpp] [Line: 963] Judging by the log this could possibly be a different bug? I'm running the original binaries on linux 2.4.24 with a Geforce 2 mxCreated attachment 289 [details] Yet another AMD64 ut2004 crash with unofficial patch. If there ist any way we could help you with this bug, please, please, please tell us.Created attachment 292 [details] Yet another AMD64 log from the crash. :)Created attachment 298 [details] Crash on new Bins Crash on new Bins.. as of 4/2/2003 Developer Backtrace: Log: [ 1] ./ut2004-bin [0x86c932c] Log: [ 2] /lib/libpthread.so.0 [0x40037d69] Log: [ 3] /lib/libc.so.6 [0x40143bf8] Log: [ 4] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x301) [0x81d2fe1] Log: [ 5] ./ut2004-bin [0x81d2a1e] Log: [ 6] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x274) [0x81d2f54] Log: [ 7] ./ut2004-bin [0x81d2a1e] Log: [ 8] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x274) [0x81d2f54] Log: [ 9] ./ut2004-bin(KHandleCollisions__FP22_McdModelPairContainerP6ULevel+0x178) [0x81d31bc] Log: [10] ./ut2004-bin(KUpdateContacts__FRt6TArray1ZP6AActorP6ULeveli+0x74f) [0x81d1243] Log: [11] ./ut2004-bin(KTickLevelKarma__FP6ULevelf+0x3cb) [0x860324f] Log: [12] ./ut2004-bin(Tick__6ULevel10ELevelTickf+0x35b) [0x82df05b] Log: [13] ./ut2004-bin(Tick__11UGameEnginef+0x3cf) [0x82889d7] Log: [14] ./ut2004-bin(SDL_SetVideoMode+0x83b) [0x814db43] Log: [15] ./ut2004-bin(main+0x69bc) [0x815851c] Log: [16] /lib/libc.so.6(__libc_start_main+0xcc) [0x40130c3c] Log: [17] ./ut2004-bin(readdir+0x99) [0x814d3e1] Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KIntersectEach <- KHandleCollisions <- KUpdateContacts <- KTickLevelKarma <- TickAllActors <- ULevel::Tick <- TickLevel <- UGameEngine::Tick <- UpdateWorld <- MainLoop Exit: Exiting. Log: FileManager: Reading 0 GByte 274 MByte 452 KByte 214 Bytes from HD took 41.435196 seconds (20.176291 reading, 21.258905 seeking). Log: FileManager: 0.000000 seconds spent with misc. duties Uninitialized: Name subsystem shut down Uninitialized: Allocation checking disabled Uninitialized: Log file closed, Sat Apr 3 00:46:42 2004 Took a while for the crash to happen at lest.. P4 3.2Ghz/512MB Gentoo 2004.0 Nvidia GeforeFx5700 ultra libSDL 1.2.7 (CVS as of 3-29-2004) Running Kde 3.2 in background.This is the full log that was requested due to crashing with the new bins. Bugzilla says I cannot post whole log file, so will shorten it a bit. Still cannot post whole log file. I get this from bugzillz "Comments cannot be longer than 65,535 characters". System$ cat UT2004.log Log: Log file open, Fri Apr 2 16:06:25 2004 Init: Name subsystem initialized Log: Your locale: [ANSI_X3.4-1968]. Init: Version: 3186 (127.29) Init: Compiled: Apr 2 2004 09:17:44 Init: Command line: Init: (This is Linux patch version 3186.1) Init: Character set: Unicode Init: Base directory: /usr/local/games/ut2004/System/ Init: Ini:UT2004.ini UserIni:User.ini Init: Build label: UT2004 Build UT2004_Build_[2004-03-03_02.42] Init: Object subsystem initialized Warning: Missing Class Class Editor.TransBuffer Log: Initializing OpenGLDrv... Log: binding libGL.so.1 Log: Global MD5: [3986c4774f86cab155ff9f5432b89282] Log: Game class is 'GameInfo' Log: Bringing Level Entry.myLevel up for play (0) appSeconds: 7.987421... ScriptLog: GameInfo::InitGame : bEnableStatLogging False Log: Browse: NvidiaLogo.ut2?Name=_Claudent_?Class=Engine.Pawn?Character=Kane?tea m=255?Sex=M Log: Collecting garbage Log: Purging garbage Log: Garbage: objects: 32782->32781; refs: 339619 Log: Game class is 'CinematicGame' Log: Bringing Level NvidiaLogo.myLevel up for play (0) appSeconds: 9.815889... ScriptLog: GameInfo::InitGame : bEnableStatLogging False Log: Created and initialized a new SDL viewport. Log: ALAudio: Using ALC_EXT_capture to record audio. Log: SET PLAYER! ScriptLog: New Player _Claudent_ id=7b8a5d30559948d0b9c932185793d2fd Log: TTS: No output filename specified. Log: Enter SetRes: 800x600 Fullscreen 0 Log: OpenGL Log: GL_VENDOR : NVIDIA Corporation Log: GL_RENDERER : GeForce FX 5600 Ultra/AGP/SSE/3DNOW! Log: GL_VERSION : 1.4.1 NVIDIA 53.36 Log: OpenGL: Device supports: GL Log: OpenGL: Device supports: GL_EXT_bgra Log: OpenGL: Device supports: GL_ARB_texture_compression Log: OpenGL: Device supports: GL_EXT_texture_compression_s3tc Log: OpenGL: Device supports: GL_ARB_texture_cube_map Log: OpenGL: Device supports: GL_ARB_texture_env_combine Log: OpenGL: Device supports: GL_NV_texture_env_combine4 Log: OpenGL: Device supports: GL_EXT_texture_lod_bias Log: OpenGL: Device supports: GL_ARB_multitexture Log: OpenGL: Device supports: GL_NV_vertex_array_range Log: OpenGL: Device supports: GL_NV_vertex_array_range2 Log: OpenGL: Device supports: GL_ARB_multisample Log: OpenGL: Device supports: GL_NV_multisample_filter_hint Log: OpenGL: Device supports: GL_EXT_texture_filter_anisotropic Log: OpenGL: Device supports: GL_ARB_vertex_buffer_object Log: OpenGL: C32 RGB888 Z24 S8 Log: OpenGL: Level of anisotropy is 1.000000 (max 8.000000). Log: OpenGL: Have 0 multisamples buffers, 0 samples. Log: OpenGL: Failed to get a multisample GL context Log: OpenGL: allocated 32 MByte of AGP memory Log: Startup time: 11.675080 seconds Log: Precaching: NvidiaLogo.LevelInfo0 Log: Static mesh batches: 508608 vertex bytes, 110460 index bytes Log: Allocating 32768 byte dynamic index buffer. Log: Allocating 65536 byte dynamic vertex buffer. Log: Finished precaching geometry in 0.145 seconds Log: Finished precaching textures in 0.140 seconds Log: URL: Adding default option Name=_Claudent_ Log: URL: Adding default option Class=Engine.Pawn Log: URL: Adding default option Character=Kane Log: URL: Adding default option team=255 Log: Browse: Index.ut2?disconnect?Name=_Claudent_?Class=Engine.Pawn?Character=Ka ne?team=255 Log: Failed; returning to Entry Log: GP=FALSE Log: Spawning new actor for Viewport SDLViewport Log: SET PLAYER! ScriptLog: New Player _Claudent_ id=7b8a5d30559948d0b9c932185793d2fd Log: MatchViewportsToActors: GUI2K4.UT2K4MainMenu Debug: Option(0): disconnect Debug: Option(1): Name=_Claudent_ Debug: Option(2): Class=Engine.Pawn Debug: Option(3): Character=Kane Debug: Option(4): team=255 Debug: UT2k4MainMenu.Opened() Sender:Package.UT2k4MainMenu Log: Static mesh batches: 0 vertex bytes, 0 index bytes IRC: 2 Servers 1 Channels ScriptLog: UT2k4Browser_ServerListPageFavorites Spawned new ServerQueryClient 'E ntry.ServerQueryClient' Log: Resolving ut2004master1.epicgames.com... Log: Resolved ut2004master1.epicgames.com -> 207.135.145.6 Log: Connection established. Debug: Received Response APPROVED Debug: Sending GlobalMD5 of 3986c4774f86cab155ff9f5432b89282 Log: Allocating 92880 byte dynamic vertex buffer. Log: Resolving ut2004master2.epicgames.com... Log: Allocating 94608 byte dynamic vertex buffer. Log: Resolved ut2004master2.epicgames.com -> 207.135.145.7 Log: Connection established. Debug: Received Response APPROVED Debug: Sending GlobalMD5 of 3986c4774f86cab155ff9f5432b89282 D Debug: #### Received server Data UT2004 Server ONSOnslaughtGame Log: ALAudio: AL_INVALID_NAME in PlaySound END Debug: UT2k4MainMenu.Opened() Sender:None ScriptLog: PreClientTravel Log: URL: Adding default option Name=_Claudent_ Log: URL: Adding default option Class=Engine.Pawn Log: URL: Adding default option Character=Kane Log: URL: Adding default option team=255 Log: Browse: 67.18.8.154/Index.ut2?Name=_Claudent_?Class=Engine.Pawn?Character=K ane?team=255 ScriptLog: UT2k4Browser_ServerListPageFavorites Destroying ServerQueryClient 'Se rverQueryClient' Log: NetMode now NM_Client Log: Collecting garbage Log: Purging garbage Log: (Karma): Level Karma Terminated. Log: Garbage: objects: 47498->46950; refs: 620024 Log: Bringing Level ONS-Severance.myLevel up for play (90) appSeconds: 113.10355 3... Log: Spawning new actor for Viewport SDLViewport Log: SET PLAYER! ScriptLog: New Player _Claudent_ id=7b8a5d30559948d0b9c932185793d2fd Log: Collecting garbage Log: Purging garbage Log: Garbage: objects: 47727->47727; refs: 629421 Log: SET PLAYER! Log: AntiTCCSecurePlayer setplayer SDLViewport Warning: ONSPRV ONS-Severance.ONSPRV (Function Onslaught.ONSPRV.DrivingStatusCha nged:0023) Accessed None 'PlayerReplicationInfo' Log: Precaching: ONS-Severance.LevelInfo0 Log: Static mesh batches: 11898972 vertex bytes, 1078176 index bytes Log: Allocating 32768 byte dynamic index buffer. Log: Allocating 694656 byte dynamic index buffer. Log: Allocating 65536 byte dynamic vertex buffer. Log: Allocating 68096 byte dynamic vertex buffer. Log: Allocating 101388 byte dynamic vertex buffer. Log: Allocating 104720 byte dynamic vertex buffer. Log: Allocating 105196 byte dynamic vertex buffer. Log: Finished precaching geometry in 2.015 seconds Log: Finished precaching textures in 1.704 seconds Log: Opening user log ../UserLogs/AntiTCC_ClientConsoleLog.log AntiTCC: AntiTCC: ================================================== AntiTCC: Anti TCC v1.12Lite build 2004-03-27 12:43 AntiTCC: Copyright (c) 2003-2004 Wormbo AntiTCC: ================================================== AntiTCC: AntiTCC: * Your unique ID is [ 7b8a5d30-559948d0-b9c93218-5793d2fd ] AntiTCC: * Player ID logging is enabled AntiTCC: Use 'Whois' to view other players' alias names. AntiTCC: * Check Timeout: 60 seconds AntiTCC: * Reaction to insecurities: Kick AntiTCC: * Integrity check passed AntiTCC: * Verified map ONS-Severance AntiTCC: * Verified package HumanMaleA AntiTCC: * Verified package HumanFemaleA AntiTCC: * Verified package Jugg AntiTCC: * Verified package Aliens AntiTCC: * Verified package Bot AntiTCC: * Verified package SkaarjAnims AntiTCC: * Verified package XanRobots AntiTCC: * Verified package ThunderCrash AntiTCC: * Verified package Hellions AntiTCC: * Verified package NewNightmare AntiTCC: * Verified package PlayerSkins AntiTCC: * Verified package UT2004PlayerSkins AntiTCC: * Verified package DemoPlayerSkins AntiTCC: * Verified package BrightPlayerSkins AntiTCC: * Verified file AntiTCC112Lite.u AntiTCC: * Verifying skins... Log: Octree Warning (AddActor): ONSManualGunPawn Outside World. AntiTCC: [INSECURE CLIENT] PCPManiac [ daabdd50-be64d9b9-1aa579f9-a1d449eb ] has a modified Anti TCC package Log: Developer Backtrace: Log: [ 1] ./ut2004-bin [0x86c932c] Log: [ 2] /lib/libpthread.so.0 [0x4002e815] Log: [ 3] /lib/libc.so.6 [0x4012b4a8] Log: [ 4] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x30 1) [0x81d2fe1] Log: [ 5] ./ut2004-bin [0x81d2a1e] Log: [ 6] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x27 4) [0x81d2f54] Log: [ 7] ./ut2004-bin [0x81d2a1e] Log: [ 8] ./ut2004-bin(KIntersect__FP13_McdModelPairP19_McdIntersectResult+0x27 4) [0x81d2f54] Log: [ 9] ./ut2004-bin(KHandleCollisions__FP22_McdModelPairContainerP6ULevel+0x 178) [0x81d31bc] Log: [10] ./ut2004-bin(KUpdateContacts__FRt6TArray1ZP6AActorP6ULeveli+0x74f) [0 x81d1243] Log: [11] ./ut2004-bin(KTickLevelKarma__FP6ULevelf+0x3cb) [0x860324f] Log: [12] ./ut2004-bin(Tick__6ULevel10ELevelTickf+0x35b) [0x82df05b] Log: [13] ./ut2004-bin(Tick__11UGameEnginef+0x3cf) [0x82889d7] Log: [14] ./ut2004-bin(SDL_SetVideoMode+0x83b) [0x814db43] Log: [15] ./ut2004-bin(main+0x69bc) [0x815851c] Log: [16] /lib/libc.so.6(__libc_start_main+0xc6) [0x40117dc6] Log: [17] ./ut2004-bin(readdir+0x99) [0x814d3e1] Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect <- KAggregateG enericIntersect <- Intersect Function <- Types <- KIntersect <- KAggregateGeneri cIntersect <- Intersect Function <- Types <- KIntersect <- KIntersectEach <- KHa ndleCollisions <- KUpdateContacts <- KTickLevelKarma <- TickAllActors <- ULevel: :Tick <- TickLevel <- UGameEngine::Tick <- UpdateWorld <- MainLoop Exit: Exiting. Log: FileManager: Reading 0 GByte 170 MByte 430 KByte 689 Bytes from HD took 12. 168933 seconds (4.870482 reading, 7.298451 seeking). Log: FileManager: 0.000000 seconds spent with misc. duties Uninitialized: Name subsystem shut down Uninitialized: Allocation checking disabled Uninitialized: Log file closed, Fri Apr 2 16:11:27 2004 rcall@Raiz_mpx:~/.ut2004/System$ This crashed 5 minutes after installing the new bins, then I restarted the game and ran about 15 minutes before the next crash. I am using kernel 2.4.25 have a Geforce 5600 ultra on a dual smp system with 1.2 gig Athlon MPs. RussellCreated attachment 299 [details] log of a crash with the new binary "kintersect-fix" Crash with new binary (not exactly the same as before) Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect Look at his log : there is a strange constantly repeating warning (the log is 300k!) : Log: Octree Warning (AddActor): ONSManualGunPawn Outside World. Log: Octree Warning (RemoveActor): ONSManualGunPawn moved without proper hashing ---- Kernel 2.4.24 debian sid SDL 1.2 sblive OSS athlon 2500 512MoCreated attachment 300 [details] Crash with KIntersect-fix binaries I finally got a crash with the newest binaries. Once in a dozen hours of play is still a much better ratio, though.Created attachment 302 [details] Another Crash log with Newest Binaries Seems to crash more often for me with the new binaries. About every 3 minutes. Doesn't seem like it was like the old crashes though, as it isn't when people around me are dying. This is kind of more random I guess. Created an attachment, and here's the output from the console. <console> WARNING: ALC_EXT_capture is subject to change! Resolved ut2004master2.epicgames.com -> 207.135.145.7 Connection established. Resolved ut2004master2.epicgames.com -> 207.135.145.7 Connection established. RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 SendTo: 67.167.43.130:7778 returned -1: 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 SendTo: 65.39.83.116:7778 returned -1: 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 RecvFrom returned SOCKET_ERROR 111 Signal: SIGSEGV [segmentation fault] Aborting. Crash information will be saved to your logfile. </console>Created attachment 305 [details] Crash log with KIntersect-fix-2Created attachment 306 [details] Another Crash log with KIntersect-fix-2 Game crashed 10min after it was first started with the new binaries OS here is Gentoo LinuxCreated attachment 307 [details] This is the latest utlog file for new binaries. Played the new binaries here is the crash log for Fix 2 as an atachment. RussellCreated attachment 308 [details] crash with fix2 Crash with fix2. VARSize was 64. Lots of GL_OUT_OF_MEMORY and other errors in the log.Created attachment 310 [details] log file net-play and single, some errorsCreated attachment 311 [details] duplicate:IgnoreCreated attachment 313 [details] Kintersect crash with fix-2 about 30 minutes of play. Even with fix-2. ( Linux DEMO never crashed ) System: Distro: Mandrake Linux 9.2 Kernel: 2.4.22-10mdksmp #1 SMP P4 3.0Ghz ( Hyperthreading enabled ) 512MB Ram GeForce2 GTS/Pro ( 64MB ) Comments: Bug seems to trigger faster on servers with more players. I can typically play for several hours on servers with less then 16 players. Over 18 in about 30 min. 32+ 10 min max. I've hit this on pretty much every map.Created attachment 314 [details] Another KIntersect crash logCreated attachment 315 [details] Crash from Kintersect with Fix-2. Cleared the system folder completely out of the .ut2004 folder. No difference. Crash from Kintersect with Fix-2. Log: Unreal Call Stack: McdContactSimplify <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KIntersectEach <- KHandleCollisions <- KUpdateContacts <- KTickLevelKarma <- TickAllActors <- ULevel::Tick <- TickLevel <- UGameEngine::Tick <- UpdateWorld <- MainLoopCreated attachment 316 [details] Crash log with new patch I've crashed twice in an hour while testing the new patch in Onslaught mode online. Here's my log file for the 2nd crash.Created attachment 317 [details] Crashed as soon soon as I joined a game This time UT2004 crashed as soon as I joined the game, with a much messier variant on the KIntersect bug. Could it have something to do with me just installing the Anti-TCC stuff? Log is attached.Created attachment 319 [details] Several logs of crashes with the ut2004-kintersect-fix-2 on x86 Three crash logs with the ut2004-kintersect-fix-2 version on x86. RedHat 9 system, with locally built SDL-1.2.7-1 from SRPM. GeForce4 Ti4400. AthlonXP 1800+, 1GB ram. Locally-built 2.4.20-30.9 kernel. In two of them, I was able to play for a while before crashing. In the instant one, it crashed as soon as the map loaded. Still very hard to isolate, I played several rounds yesterday without a crash but crashed multiple times today. All were in onslaught.Created attachment 320 [details] Crash Log Onslaught. Crashed in under 5 minutes. Very few players online. Stock SDL. Slackware 9.1, 2.4.25 kernel.Created attachment 339 [details] another report if I can help more, tell me a patch soon ? it crashes really often hereCreated attachment 340 [details] MdcContactSimplify logfile Logfile for crash with "Unreal Call Stack: McdContactSimplify <- ..." Log is using ut2004-kinsersect-fix2. Replaced locally-compiled openal and libSDL with original shipping versions (i.e. reverted to original); this improved reliability somewhat, but game still crashes about once every half an hour.Created attachment 346 [details] Online McdContactSimplify crash with fix-2 binaries I've beaten these fix-2 binaries to death in single player ever since they came out and never got a single crash. I decided to go online and spectate a couple of Onslaught maps. It made it through the first map fine. The second map crashed and produced this log. Is this now a multiplayer-only thing?Created attachment 347 [details] UT2004 Crash Log This is a crash log using the jesus-h patch. The other patches also do not fix this problem for me. Just as the previous poster said, this seems to be a multiplayer-only bug. I've played many single player matches and I cannot get this bug to show up while in SP. However, while playing Onslaught multiplayer, it's often hard to finish a single match without the game crashing. Speaking of onslaught, is it the only game mode that this bug pops up in? I played a few matches of Invasion and it worked flawlessly for the few maps I tested online. Maybe I was just lucky? I have yet to find a pattern for when the game crashes. Sometimes it will crash immediately after the map loads and other times it will crash randomly during the game. Anyways, it'd be real nice to have a patch for this soon. :-/Created attachment 348 [details] UT2k4 Seg fault This log was done on a P4 2.8E w/hyper-threading. Nvidia Ti4200 with "NVIDIA-Linux-x86-1.0-5336-pkg1.run". Installed fresh again from the UT2k4 5- disk cd set. Current OS distro is Mandrake 10. There is mention of corrupted texture, but even with clean install(s) this remains. Copied from W2k- problem exists even. Wondering if this is an isolated incident? Anyway crash is very annoying. No mp game lasts longer than 2h30m long . I think that is all. Thank you.Created attachment 350 [details] UT2004 McdContactSimplify crash logCreated attachment 353 [details] Client crash with patched server and client Here's a crash from a jesus-h-christ client when connected to a kintersect-fix-2 server.Created attachment 354 [details] Appears to be a Karma Kintersect crash. Was playing for about 15 mins, then it blew up.Created attachment 357 [details] Crash Log My fastest crash yet. 40 seconds :) I assume this is the Karma bug. I did a query on "RecvFrom returned SOCKET_ERROR 111", and this seemed to be the relevant bug.Created attachment 360 [details] Crash Log Its *almost* repeatable in that if a change is made to the config, then its a lot more likely to bomb. For example here I had switched from 1600x1200 to 1024x768 and then joined. Like I say, it doesn't do it every time, but does make it more likely to crash.Created attachment 361 [details] Crash Log DevKarma nonsupression gives a little more detail in this crash log. This is with kintersect-fix-2 (I find the jesus-h one less stable!)Created attachment 363 [details] It rears it's ugly head in 3204 beta patch. P4 2.80E Hyper-threading enabled. Intel D875PBZ mainboard 2x 256MB Corsair XMS Xtreme Memory Speed Logitech MX510 optical mouse Audigy sound card Nvidia Ti 4200 64MB Leadtek 5336 Driver Gentoo 2004.1 Stage 1 ck-sources 2.6.4-r2 XFree86 4.3.0-r5 (to be xorg X11R6.7.0) I'm getting the messages using the 3204 beta patch in both unpatched and patched servers. McdContactSimplify <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KAggregateGenericIntersect <- Intersect Function <- Types <- KIntersect <- KIntersectEach <- KHandleCollisions <- KUpdateContacts <- KTickLevelKarma <- TickAllActors <- ULevel::Tick <- TickLevel <- UGameEngine::Tick <- UpdateWorld <- MainLoop This problem should be fixed.Created attachment 364 [details] Crash Log 3204 beta patched now and I'd say it crashes more than the kintersect-2-fix patch. "Nice" to see its happing in Windows too as that should help narrow things down. Am willing to help test stuff if it aids degubbing. Seems a lot more unstable switching screen resolutions now as well. Have had it bomb out several times just changing res from the settings page.Created attachment 365 [details] Latest crash UT2004.log with KIntersect-fix-2 binaries (long) map was ONS-JUNKARD Last sound I heard was the explosion of the vehicle's turret weapon that I was controlling. Sorry for the huge attachment, but I didn't want to take out anyhting that might help. The crash is at the end, naturally.Created attachment 367 [details] 3204 Beta Crash log Please give an update on this. You've gotten more crash data than any developer could ever hope to get. Here's another attachment. Let's see if we can make it to 500 :-(Just to add info: I was on an official Atari server for attachment #367 [details] crash. It's possible they were still running an older version, although it still _shouldn't_ make a fixed client crash in theory :)