Stripped PDBs for debugging?

[benpye]

Windows includes stripped pdbs for debugging, so you can see roughly where a crash occurs. Would this not be possible for the Source engine too, since it could help know where the crash has occurred, even for the sections where we don't have source access. These pdbs can be generated either directly from visual studio with the /PDBSTRIPPED argument ( http://msdn.microsoft.com/en-us/library/y87kw2fd(v=vs.100).aspx ) or with pdbcopy ( http://msdn.microsoft.com/en-us/library/ff560131%28VS.85%29.aspx ).

[alanedwardes]

We'd find this extremely useful too. Crashes that occur in engine.dll, materialsystem.dll etc are basically a dead end - there's no way to debug aside from trial and error, caveman and rock style.

[HenryDorsett]

Yeah, having this would be really very handy. It would have made a great many things I've tried in the past significantly easier.

[neico]

Still no response regarding this? is it really that hard to provide these?

I got a pretty good example for why this is useful: I've been spending 2 whole days now on a crash that seems to be related to my code but has not client.dll/server.dll function calls at all, just in engine.dll and tier0.dll. (and still haven't found out what's causing it)
It's so god damn hard to even find the line of code causing it as you have no idea which function exactly is causing it.

You can't expect people to know ASM just to decipher what the debugger is trying to tell you...

[benpye]

No reason that this can't be done?

[bruced-valve]

There were a lot of concerns about symbols being used to make cheating and unwanted reverse engineering easier. Sorry -- I know it's annoying not having symbols.

[alanedwardes]

Ok, thanks for explaining why.

Would it be appropriate to post crash dumps as issues in this repo if we're stuck with a re-creatable crash happening inside Source that we can't debug ourselves?

[KyleSanderson]

@bruced-valve can you ship a separate server.dll for Windows that isn't stripped; like how Linux is currently shipped?

[bruced-valve]

Posting occasional crash dumps and asking for analysis is not a bad idea. We can't promise to look at them, but we have done that in the past.

[KyleSanderson]

@monokrome VAC2 was well documented years ago. The claim this helps prevent cheating is unfortunately based on pure ignorance. There's an internal disconnected sect that's hell bent on trying to weaken the community, that's all this is. No one can stop it externally; it's purely political.

[monokrome]

@KyleSanderson I deleted my comment, because it slightly misrepresented my point.

Security through obscurity in the engine code itself (as is being leveraged here) is not really representative of ignorance. It actually exists primarily as a form of protection against accidentally exposing potential artifacts of ignorance as potentially exploitable artifacts, design patterns, etcetera - which could be used as an attack vector in the final product. Windows isn't a very good example of what to do here, because it is often regarded as a product which does not provide realistic security concerns for it's goals and is therefore often exploited.

As for shipping server.dll itself with symbols, there's not really much point. You can build it yourself however you want it, anyway. I would think that those symbols probably only exist in Linux binaries due to a technical caveat or a lack of optimization in the build configuration for Source on Linux...

Although I am not personally a fan of security through obscurity, I don't see that there are any outlandishly any ignorant decisions made here.

[KyleSanderson]

@monokrome okay.

Security through obscurity in the engine code itself (as is being leveraged here) is not really representative of ignorance. Most of the code has been shipped in earlier versions of SDKs. There's game specific defines that are added seemingly at random to support the server binaries (the Source Engine is more of a game template, not an actual engine). What's being effectively hidden is nothing, the reason outlined by Bruce is apparently they're worried about cheaters, which works out to ignorance (if you're familiar with the products), or a lie.

As for shipping server.dll itself with symbols, there's not really much point. It's clear you don't run servers, there's a bunch of hacks that go on in both the engine and server that don't need to be there. Commonly arrays are mis-sized, lots of uninitialized data (my goodness, the Steam library itself is a hornets nest) in the engine and server (usermessages/sound/ai), horrible horrible casting pointers to int and vice-versa, dlopening without closing, I believe server addons still unload backwards... The list goes on for why this would be extraordinarily helpful. Simply running Valgrind or any C++ checking tool would render tons of real errors (and actually does).

I'm not asking for client bins to be unstripped. My only ultimate goal here is for servers to have some sort of stability. When I have to use memory patching just to prevent crashes... The game is pretty much lost. I'm lucky Linux intentionally has symbols (yes; it's intentional), and there's no one trying to poison that platform yet.

EDIT PS: No one supports their current breakpad platform, the dumps that are uploaded are clearly never reviewed.

[monokrome]

Eh, maybe you're approaching the problem the wrong way if you're mad about server stability.