PDA

View Full Version : Linux Dedicated Server Segfault



Milde
15th April 2006, 21:36
My server apparently segfaulted with b2a. Here's a backtrace:

#0 0xb2bc6c46 in CGrabController::AttachEntity () from hidden//bin/server_i486.so
#1 0xb2bc9628 in CPlayerPickupController::Init () from hidden//bin/server_i486.so
#2 0xb2bc96f6 in PlayerPickupObject () from hidden//bin/server_i486.so
#3 0xb299bbf5 in CBaseEntity::InputUse () from hidden//bin/server_i486.so
#4 0xb299e86c in CBaseEntity::AcceptInput () from hidden//bin/server_i486.so
#5 0xb2bbeaba in CSDKPlayer::PlayerUse () from hidden//bin/server_i486.so
#6 0xb280ccad in CBasePlayer::ItemPreFrame () from hidden//bin/server_i486.so
#7 0xb2aaae2a in CBasePlayer::PreThink () from hidden//bin/server_i486.so
#8 0xb2bbc643 in CSDKPlayer::PreThink () from hidden//bin/server_i486.so
#9 0xb2ab2ec7 in CPlayerMove::RunPreThink () from hidden//bin/server_i486.so
#10 0xb2ab33d8 in CPlayerMove::RunCommand () from hidden//bin/server_i486.so
#11 0xb2aa0603 in CBasePlayer::PlayerRunCommand () from hidden//bin/server_i486.so
#12 0xb2aaaa6d in CBasePlayer::PhysicsSimulate () from hidden//bin/server_i486.so
#13 0xb2a89dc8 in Physics_SimulateEntity () from hidden//bin/server_i486.so
#14 0xb2a8a12b in Physics_RunThinkFunctions () from hidden//bin/server_i486.so
#15 0xb2a17404 in CServerGameDLL::GameFrame () from hidden//bin/server_i486.so
#16 0xb73ecef0 in SV_Frame () from bin/engine_amd.so
#17 0xb73a7e51 in _Host_RunFrame_Server () from bin/engine_amd.so
#18 0xb73a8269 in _Host_RunFrame () from bin/engine_amd.so

Unfortunately, I don't have the core file anymore. Don't ask why. But anyway, you guys might want to look into what you're doing in that function!

Ging
15th April 2006, 22:38
It's from the hidden picking up an object, possibly dying when carrying a corpse or similar - the pick up code is fairly solid in that respect but it does sometimes fall over about corpses.

Must be a bad pointer, as that call trace ends in a core engine function (engine_amd.so)

RaideR
15th April 2006, 23:54
LMAO that was leet developer speak :)

So much for Unix being "more stable" :) hehehehe

MiasmicAnomie
16th April 2006, 00:01
So much for Unix being "more stable" :) hehehehe

A pointer being bad says nothing about Unix stability. :p

Apps can crash themselves all they like, on both Unix and Windows. The difference /used/ to lie in whether that app would take the rest of the system down as well.

I haven't really seen a hard crash on a Win box in a while that wasn't hardware related (same w/ *nix) - so i don't know if the difference still exists.

M_C
16th April 2006, 01:38
Bad SW can still do bad stuff to windows but even some *nix's are more stable than others as netcraft's longest uptime stats prove. I've had some amazing uptimes in winboxes but not many. FreeBSD on the other hand is really stable. I've had web servers with 700+ days of uptime on FBSD. So, while windows is getting better it's got a ways to go but, then again, so does linsux. ;)

I hear Vista is REALLY stable but I haven't tried it yet. *shrug*

MiasmicAnomie
16th April 2006, 02:17
but even some *nix's are more stable than others as netcraft's longest uptime stats prove.

That really says nothing about stability. Unless netcraft say 'this host was down because of a kernel crash', which as far as I know, it doesn't.

FWIW, I had a linux box up for 2 years - and it only went down because the MB fried (it was a 10 year old 486).

M_C
16th April 2006, 02:26
Heh...mine ws a p133 that only died because of a power outage that lasted longer than the UPS. The difference is, a 2 month old linsux kernel is exploitable remotely, if it's on the net. Used to be weekly. ;)

MiasmicAnomie
16th April 2006, 02:32
Heh...mine ws a p133 that only died because of a power outage that lasted longer than the UPS. The difference is, a 2 month old linsux kernel is exploitable remotely, if it's on the net. Used to be weekly. ;)

True, that - but you can't tell me that *BSD isn't remotely exploitable, either.

FreeBSD had at least one kernel exploit I'm aware of for roughly a year and a half before it was fixed.

M_C
16th April 2006, 02:42
I've been running fbsd since 94, there's never been a fbsd kernel exploit that wasn't patched sooner than that. Even linsux patches theirs quicker than that, they just used to get them every week. While fbsd has had a few, no where near the numer of remotes that linsux has had. ;)

MiasmicAnomie
16th April 2006, 04:14
I've been running fbsd since 94, there's never been a fbsd kernel exploit that wasn't patched sooner than that.

Oh Really? (http://www.ciac.org/ciac/bulletins/l-036.shtml)

The procfs exploit existed in the FreeBSD kernels for at least a year and a half. I'm not talking about time to patch - I'm talking about how long it was there, from the time it was introduced until it was fixed. You can't pretend it wasn't there, just because nobody honest had found it yet.

Both Linux and the *BSDs are quick to patch known vulnerabilities. It's the ones that are unknown (or even worse, known only to the black hats) that are troubling - and there's not an OS on the planet that can make a valid claim that none exist in that operating system.

M_C
16th April 2006, 04:20
[I'm not talking about time to patch - I'm talking about how long it was there.
IF it was there for that long it wasn't known that long. Wow an unknown bug. Nobody cares how old unknown bugs are it's the time from known to patched that counts. :D

It wasn't even remote, it was local. ;)

MiasmicAnomie
16th April 2006, 04:29
Wow an unknown bug. Nobody cares how old unknown bugs are it's the time from known to patched that counts. :D

In the meantime, while the bugs are "unkown", and "Nobody cares", people exploit them.

Like I said - all "unknown" means is that no one who is honest knows about it. It doesn't mean you're invulnerable, and it doesn't mean no one is actually using it.

If a bug being unknown is such a panacea, why bother firewalling? Why bother shutting off unneeded network services? Why harden at all?

Because people do care.

M_C
16th April 2006, 04:42
You can't exploit unknown bugs, that's whythey call them unknown and THAT unknow bug still needed local access once it was known. :D

MiasmicAnomie
16th April 2006, 05:02
You can't exploit unknown bugs, that's whythey call them unknown

No, they call them unknown because they've not been reported or found by someone who will fix them.

That does not mean that no one knows about them.

M_C
16th April 2006, 05:08
Exploits don't stay secret for any real length of time. I know the asshole that wrote and released the smurf attack code, back in the day. :(

MiasmicAnomie
16th April 2006, 05:18
Exploits don't stay secret for any real length of time.

They often stay secret long enough.

M_C
16th April 2006, 06:50
A few days a or a week isn't that long. smurf.c stayed secret 3 whole days. :D

MiasmicAnomie
16th April 2006, 11:02
A few days a or a week isn't that long. smurf.c stayed secret 3 whole days. :D

Aye, but there have been other bugs that were secret for far, far longer. Not so much any more, maybe, or maybe the black hats have gotten better at keeping quiet how /long/ they knew about it, when it does come to light.

I would not be surprised at all to find that there's an exploit that's "unknown" but has been exploited for a long time. It's happened before - it'll probably happen again.

M_C
16th April 2006, 17:14
I'd be very surprised, exploits just don't stay secret in the wild. I can't think of any that made it any real length of time. It's not just blackhats that find these exploits. People use honeypots and intrusion detection tools, etc, to find them too. I'm just not buying the secret hole that was never-patched-and-nobody-ever-found-out theory. ;)

MiasmicAnomie
16th April 2006, 20:02
I'd be very surprised, exploits just don't stay secret in the wild. I can't think of any that made it any real length of time. It's not just blackhats that find these exploits. People use honeypots and intrusion detection tools, etc, to find them too. I'm just not buying the secret hole that was never-patched-and-nobody-ever-found-out theory. ;)

I know all that. Most breakins that you see are script-kid exploits, and the author released it for the credit / scene reputation / whatever. And if they try to keep it a secret the exploit gets found through a honeypot and good reverse engineering.

That's all well and good, but pretending that there cannot and never will be anyone that finds an exploit and keeps it secret, so they can use it for specifically targeted attacks (rather than breaking into everything they can find, the way the script-kids do) is naive at best. There are people with interests other than their reputation in the "scene". (Now, they're not particularly likely to attack you, because they've probably got no interest in what you've got on your box. That, however, is beside the point).

We're where we're at because a lot of code was written with what most people do in mind, rather than what could actually be done. Your view is simply a subcase of that.

M_C
16th April 2006, 20:27
I never said can not or never will be, I just said there hasn't been any that lasted very long because of the various reasons. That said, local still isn't the same as remote. ;)

MiasmicAnomie
16th April 2006, 20:59
That said, local still isn't the same as remote. ;)

a) I did not say the exploit was remote. What I said exactly was "FreeBSD had at least one kernel exploit I'm aware of for roughly a year and a half before it was fixed." Nothing about /remote/, and the example was to show that it had been there a long time, not remote vs. local.

b) You put way too much faith in 'oh that exploit wasn't remote'. Sure, that one wasn't, but that says nothing about whether they exist, or have existed. The line between 'this kernel bug is remotely exploitable' and 'this kernel bug is only locally exploitable' is simply a matter of 'Can I get the network code to hit this somehow?'.

c) In fact, there have been remote kernel exploits in FreeBSD.

M_C
16th April 2006, 22:26
A) Yes but we were talking about remotes right before that.
B) That was the one you gave as an example though. ;)
C) Of course there have been, I even said there've been far fewer fbsd remotes than linsux. That stipulates that fbsd has had some, just not as many. ;)

The whole thing started when we wer talking about uptime as a judge of stability and security. The reason you virtually never see linsux in the top 50 longest uptimes is because of the "exploit of the week" which has now slowed down a little, as we discussed. Since linsux has a new remote kernel exploit so often, they never make it that far in the rankings. They either get rebooted for a new kernel or they get hacked. ;)

Milde
16th April 2006, 22:28
I've been getting a bunch more crashes:

#0 0xb2a66420 in CBasePlayer::Weapon_Drop () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
(gdb) bt
#0 0xb2a66420 in CBasePlayer::Weapon_Drop () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#1 0xb29552a2 in CBaseCombatCharacter::Event_Killed () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#2 0xb2a70dea in CBasePlayer::Event_Killed () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#3 0xb2b8184e in CSDKPlayer::Event_Killed () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#4 0xb2952616 in CBaseCombatCharacter::OnTakeDamage () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#5 0xb2a6bfaf in CBasePlayer::OnTakeDamage () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#6 0xb295b38f in CBaseEntity::TakeDamage () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#7 0xb2853f41 in ApplyMultiDamage () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#8 0xb28906b5 in CTriggerTraceEnum::EnumEntity () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#9 0xb73673fd in CEnumerationFilter::EnumElement () from /home/srcds/usr/srcds/bin/engine_amd.so
#10 0x08b917fc in ?? ()
#11 0xb73f6e6a in CSpatialPartitionHash::EnumerateElementsAlongRay_R ay () from /home/srcds/usr/srcds/bin/engine_amd.so
#12 0xb73f7381 in CSpatialPartitionHash::EnumerateElementsAlongRay () from /home/srcds/usr/srcds/bin/engine_amd.so
#13 0xb7366b0d in CEngineTrace::EnumerateEntities () from /home/srcds/usr/srcds/bin/engine_amd.so
#14 0xb28705ac in CBaseEntity::TraceAttackToTriggers () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#15 0xb2b748c7 in CSDKPlayer::FireBullet () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#16 0xb2b6cb06 in FX_FireBullets () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#17 0xb2b91759 in CWeaponP90::PrimaryAttack () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#18 0xb27c5077 in CBaseCombatWeapon::ItemPostFrame () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#19 0xb27d0e71 in CBasePlayer::ItemPostFrame () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#20 0xb2a7364b in CBasePlayer::PostThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#21 0xb2b80103 in CSDKPlayer::PostThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#22 0xb2a764cd in CPlayerMove::RunCommand () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#23 0xb2a63603 in CBasePlayer::PlayerRunCommand () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#24 0xb2a6da6d in CBasePlayer::PhysicsSimulate () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#25 0xb2a4cdc8 in Physics_SimulateEntity () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#26 0xb2a4d12b in Physics_RunThinkFunctions () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#27 0xb29da404 in CServerGameDLL::GameFrame () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#28 0xb73afef0 in SV_Frame () from /home/srcds/usr/srcds/bin/engine_amd.so
#29 0xb736ae51 in _Host_RunFrame_Server () from /home/srcds/usr/srcds/bin/engine_amd.so
#30 0xb736b269 in _Host_RunFrame () from /home/srcds/usr/srcds/bin/engine_amd.so


#0 0xb29f7420 in CFuncAreaPortalWindow::UpdateVisibility () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
(gdb) bt
#0 0xb29f7420 in CFuncAreaPortalWindow::UpdateVisibility () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#1 0xb28e62a2 in CAI_StandoffBehavior::BeginScheduleSelection () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#2 0x00000000 in ?? ()


(gdb) bt
#0 0xb29cd420 in global constructors keyed to _ZN9CBubbling9m_DataMapE () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#1 0xb28bc2a2 in CAI_BaseNPC::NPCInit () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#2 0xb29d7dea in CEntityParticleTrail::Create () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#3 0xb2ae884e in CScriptedTarget::DrawDebugGeometryOverlays () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#4 0xb28b9616 in DataMapInit<AIExtendedSaveHeader_t> () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#5 0xb29d2faf in CGlobalEntityList::FindEntityByClassname () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#6 0xb28c238f in CAI_BaseNPC::ValidateNavGoal () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#7 0xb27baf41 in ?? () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#8 0xb27f76b5 in CBaseEntity::ComputeTracerStartPosition () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#9 0xb72ce3fd in ?? () from /home/srcds/usr/srcds/bin/engine_amd.so

I've got the core dumps for these if you want them.

Also: apparently the ovr_ maps are causing crashes, according to the players on my server.

MiasmicAnomie
17th April 2006, 01:16
Since linsux has a new remote kernel exploit so often, they never make it that far in the rankings. They either get rebooted for a new kernel or they get hacked. ;)


"a new remote kernel exploit so often" <- when was the last one, M_C?

How many *BSD boxen have been up for a three years that you would be willing to say /shouldn't/ have had their kernels fixed?

M_C
17th April 2006, 01:32
"a new remote kernel exploit so often" <- when was the last one, M_C?

How many *BSD boxen have been up for a three years that you would be willing to say /shouldn't/ have had their kernels fixed?
I remember reading about one in the last few months but since linsux kernels don't affect me, I didn't really pay attention. 6 at the most. I'd trust a 3 year old fbsd kernel over anything else, including solaris, but I'd prefer to have one more up to date than that, personally.

MiasmicAnomie
17th April 2006, 01:38
I remember reading about one in the last few months

I'm doing searches like mad, and the most recent remote root exploit I can find in Linux was from December of 2003-ish (and the patch had been available for months - the main kernel tree had been patched for months - but Red Hat didn't patch it) - the brk() exploit.

Bring a newer one if you've got it. If you can't, then your argument is basically orthogonal to someone complaining about an exploit found in FreeBSD 3.x or 4.x.

M_C
17th April 2006, 01:48
OK, I'll get right on that. :D

OK, I'm done. 1-06

http://www.securiteam.com/exploits/5WP0J1FHFS.html

;)

Milde
17th April 2006, 03:17
And another:
#0 0xb275aac8 in CCollisionProperty::MarkPartitionHandleDirty () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
(gdb) bt
#0 0xb275aac8 in CCollisionProperty::MarkPartitionHandleDirty () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#1 0xb272d025 in CBaseEntity::InvalidatePhysicsRecursive () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#2 0xb28c9676 in CBaseEntity::SetLocalOrigin () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#3 0xb2ae483e in CSDKPlayer::PreThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#4 0xb29daec7 in CPlayerMove::RunPreThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#5 0xb29db3d8 in CPlayerMove::RunCommand () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#6 0xb29c8603 in CBasePlayer::PlayerRunCommand () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#7 0xb29d2a6d in CBasePlayer::PhysicsSimulate () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#8 0xb29b1dc8 in Physics_SimulateEntity () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#9 0xb29b212b in Physics_RunThinkFunctions () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#10 0xb293f404 in CServerGameDLL::GameFrame () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#11 0xb7314ef0 in SV_Frame () from /home/srcds/usr/srcds/bin/engine_amd.so
#12 0xb72cfe51 in _Host_RunFrame_Server () from /home/srcds/usr/srcds/bin/engine_amd.so
#13 0xb72d0269 in _Host_RunFrame () from /home/srcds/usr/srcds/bin/engine_amd.so
#14 0x00000000 in ?? ()
(gdb)

MiasmicAnomie
17th April 2006, 03:29
OK, I'll get right on that. :D

OK, I'm done. 1-06

http://www.securiteam.com/exploits/5WP0J1FHFS.html

;)


That's local. I asked for remote, because you had said
a new remote kernel exploit so often.

E.G., you yourself specified remote explicitly. Your argument has no basis if you can't find a recent remote root exploit in linux. If they're so common, how come the most recent I can find is close to three years old?

M_C
17th April 2006, 03:30
That's local. I asked for remote, because you had said .

E.G., you yourself specified remote explicitly. Try again.
Oops, my bad, here you go, all remotes:

http://secunia.com/advisories/16355/ (8-05)
http://secunia.com/advisories/16494/ (8-05)
http://secunia.com/advisories/18482/ (1-06)
http://secunia.com/advisories/18766/ (2-06)
http://secunia.com/advisories/19402/ (3-06)

;)

MiasmicAnomie
17th April 2006, 03:42
Oops, my bad, here you go, all remotes:

http://secunia.com/advisories/16355/ (8-05)
http://secunia.com/advisories/16494/ (8-05)
http://secunia.com/advisories/18482/ (1-06)
http://secunia.com/advisories/18766/ (2-06)
http://secunia.com/advisories/19402/ (3-06)

;)


Every single one of those is a DOS, except the last, which is an info leak.

/ Link broken, just search on google for 'FreeBSD remote kernel DOS' /

I really don't have the time to go point for point right now. However, you've got a whole month on Linux without a reported remote kernel DOS exploit - I suppose that does somehow prove FreeBSD's superiority :p

M_C
17th April 2006, 03:48
I suppose that does somehow prove FreeBSD's superiority :p
Now you're making sense. 5-1 and a WHOLE month. :D

MiasmicAnomie
17th April 2006, 03:51
Now you're making sense. 5-1 and a WHOLE month. :D


The difference is, a 2 month old linsux kernel is exploitable remotely


A one month old FreeBSD kernel is exploitable remotely. Check and mate.

M_C
17th April 2006, 04:00
A one month old FreeBSD kernel is exploitable remotely. Check and mate.
Better check your clicky, it doesn't click and the linsux hole is newer. ;)

MiasmicAnomie
17th April 2006, 04:05
Better check your clicky, it doesn't click and the linsux hole is newer. ;)

If you don't realize how you've contradicted yourself, you never will. Tomorrow it could flip flop, if an exploit were found in FreeBSD. I'm not arguing one is better than the other - I'm a 'use what you'd like' guy, they all have people fixing what's coming up. If we'd had this argument in Feb of 2006, FreeBSD would have had the newer exploit. It's just not a valid argument.

(for some reason I can't get the link to work, it's just a google search for 'FreeBSD remote kernel DOS')

Anyway, we're going nowhere. I'll continue to think that every OS has exploits pop up, and you'll continue to think that a one-month gap is somehow magically better. So I'm out. ;)

M_C
17th April 2006, 04:14
http://www.linuxsecurity.com/content/view/103878/103
That one? :confused:

MiasmicAnomie
17th April 2006, 04:15
http://www.linuxsecurity.com/content/view/103878/103
That one? :confused:

No. The remote FreeBSD kernel panic via carefully crafted NFS packets, which didn't have a fix as of Feb 2006. (oops - I'd forgotten it was april, so your two-month-old FreeBSD kernel is remotely exploitable, not one-month).

You should probably switch to OpenBSD. ;)

(Edit: and now I really am out, because I know you're going to bring up what I would consider distinctions-without-a-difference. You get the last word ;) )

M_C
17th April 2006, 04:19
No. The remote FreeBSD kernel panic via carefully crafted NFS packets, which didn't have a fix as of Feb 2006.
Oh, http://secunia.com/advisories/19017/ that one, that you have to be running NFSD (which is disabled by default) to exploit, that was patched March 1st?
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:10.nfs.asc that you want to compare to http://secunia.com/advisories/19402/ which was reported 3-28-06 which states: "Secunia is currently not aware of any official patches for the 2.4 kernel." and "which can be exploited by malicious people to disclose certain system information and potentially to bypass certain security restrictions."

Milde
17th April 2006, 13:17
Another one!
#0 0xb2a8d029 in CSprayCan::Think () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#1 0xb2a7345d in CBaseEntity::PhysicsDispatchThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#2 0xb2844354 in CBaseEntity::PhysicsRunSpecificThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#3 0xb28445be in CBaseEntity::PhysicsRunThink () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#4 0xb2a74412 in CBaseEntity::PhysicsNone () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#5 0xb284506c in CBaseEntity::PhysicsSimulate () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#6 0xb2a74dc8 in Physics_SimulateEntity () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#7 0xb2a7512b in Physics_RunThinkFunctions () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#8 0xb2a02404 in CServerGameDLL::GameFrame () from /home/srcds/usr/srcds/hidden//bin/server_i486.so
#9 0xb73d7ef0 in SV_Frame () from /home/srcds/usr/srcds/bin/engine_amd.so
#10 0xb7392e51 in _Host_RunFrame_Server () from /home/srcds/usr/srcds/bin/engine_amd.so
#11 0xb7393269 in _Host_RunFrame () from /home/srcds/usr/srcds/bin/engine_amd.so
#12 0x080eff70 in ?? ()

You guys should build the next beta with the gcc -g and -ggdb3 switches so we can give you line numbers for these crashes.

Ging
17th April 2006, 13:47
You guys should build the next beta with the gcc -g and -ggdb3 switches so we can give you line numbers for these crashes.

Issue with that is it nearly doubles the size of the .so file and makes it a whole lot slower than it needs to be...