Page 1 of 5 123 ... LastLast
Results 1 to 10 of 41

Thread: Linux Dedicated Server Segfault

  1. #1
    Milde Guest

    Default Linux Dedicated Server Segfault

    My server apparently segfaulted with b2a. Here's a backtrace:
    Code:
    #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!

  2. #2
    Join Date
    Mar 2005
    Location
    UK
    Posts
    3,495

    Default

    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)


    "The enemy gate is down"

    The Hidden - Source
    Calibre Studios
    Developicus Videogameos (Dev Blog)

  3. #3
    Join Date
    May 2005
    Location
    Coventry Uk
    Posts
    212

    Default

    LMAO that was leet developer speak

    So much for Unix being "more stable" hehehehe
    Statistically Mad Development Team Leader
    Coder / Server Administrator
    Hidden Stats | http://www.baxters.me.uk

  4. #4
    Join Date
    Jan 2006
    Location
    The hippest town in Texas.
    Posts
    534

    Default

    Quote Originally Posted by RaideR
    So much for Unix being "more stable" hehehehe
    A pointer being bad says nothing about Unix stability.

    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.


    One thing was certain, that the white kitten had had nothing to do with it - it was the black kitten's fault entirely.

  5. #5
    M_C Guest

    Default

    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*

  6. #6
    Join Date
    Jan 2006
    Location
    The hippest town in Texas.
    Posts
    534

    Default

    Quote Originally Posted by M_C
    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).


    One thing was certain, that the white kitten had had nothing to do with it - it was the black kitten's fault entirely.

  7. #7
    M_C Guest

    Default

    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.

  8. #8
    Join Date
    Jan 2006
    Location
    The hippest town in Texas.
    Posts
    534

    Default

    Quote Originally Posted by M_C
    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.


    One thing was certain, that the white kitten had had nothing to do with it - it was the black kitten's fault entirely.

  9. #9
    M_C Guest

    Default

    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.

  10. #10
    Join Date
    Jan 2006
    Location
    The hippest town in Texas.
    Posts
    534

    Default

    Quote Originally Posted by M_C
    I've been running fbsd since 94, there's never been a fbsd kernel exploit that wasn't patched sooner than that.
    Oh Really?

    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.
    Last edited by MiasmicAnomie; 16th April 2006 at 04:20.


    One thing was certain, that the white kitten had had nothing to do with it - it was the black kitten's fault entirely.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •