DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
But if its a external program, you could do some deep memory digging and check the handle in use..
I understood nothing of your line 'Well the bogus value in dxdiag shows 2.5 in idle. If you add the 4 for crashed ns2 it does +- match what is in the log.' probably because we may not talk about the same. Be a bit more specific.
You talking about free memory, committed, paged, nonpaged, system wide or application only? (and yes that is a question on which id expect multiple answers)
What I ment is, do you still have the memory leak when you play on dx11?
What do you make of the .log's @ironhorse? I could not reproduce the same errors with verbose 3, so I assume they are part of the problem. Prediction world seems... off
Uhh.. on the dates he reported having issues (Feb 13th and 15th) you were using less than the default tick rate as well as a hacked executable to increase the maximum player count.... So how exactly is what I said false?
You have changed it since then, but not the hacked server executable. (or mods I'm assuming)
Unsurprisingly, your server consistently produces false positives for tech support related issues. Therefore, it cannot be used as a testing environment.
@IronHorse It is false because you are just guessing. Like Mephilles and another guy posted (whose post just got deleted) it happens on every server (and is mostly related to a bad network on the client side). I understand the fact that the tech support files may produce "false positives" values, it is still vague to claim it is only happen on servers with more than 24 slots.
The mods i am using are there to offer the people a good experience while playing ns2 (NS2+ and Shine Administration plus Custom Badges) which wouldn't be possible with vanilla. Also there are no gameplay changes made since the server is running.
And yes i am using a "hacked" executable and i am glad that this has not been changed. Else we would have many 24+ servers with bad performance.
Edit: If you check the current playerbase you will see that 1/4 - 1/6 Players playing on a Server with 24+ Slots. I always tell them to contact me first so i can try solve their problem since there is (still) no acceptance here. I understand the fact that such servers may produce extra work for the CDT, but how they (or most of them) represent their view will just split the community into two parts... (Which already happened)
any chance future patch update NS2 will have no longer after 1-2 map change it cash to destop and say "Fatal Error" or "Failed to allocate ##### bytes and now terminated" ?
developers should fix this and add game Match making like Insurgency ( they still have dedicated server , offical server is 6v6 for match making)
@wooza Yeah, I provided them with crashdumps on other servers too. No need to get defensive... It is impossible to find modless server nowadays anyway(I tried in Game vs Bots, but those basterds kick me out for being AFK Maybe I will try keyboard script to circumvent this later, if I get bored...). You and the deleted guy are saying something about bad network, what is that about (I mean, it's a network - packets gonna get dropped sooner or later, thats no reason for crash)?
@Perman12 That frequent for you, huh? Tough luck. Patience - that programming nonsense takes time, especially if you do more nonsense at the same time https://trello.com/b/91ApENY6/ns2-cdt-development-tracker for free (or are you getting someting for your work CDT?). You can try some things, to kill time(or do something else entirely, you know): reinstall (forums.unknownworlds.com/discussion/131428/obbys-full-nuke-ns2-guide-only-way-to-be-sure), mess around with game settings, update all your drivers, try more reliable network if you practically can(LAN cable), disable "Show hints"(that fixed it for one guy in previous thread, so who knows...), try uninstalling overlay software(Fraps, AMD Gaming evolved/raptr, NVidia Shadowplay, disable steam overlay too perhaps), check your disk for errors, post your tech_support zip (forums.unknownworlds.com/discussion/131384/how-to-make-a-good-tech-support-post). Maybe it can be reduced to less annoying frequency for you in the meantime... or if not this should get a laugh: dilbert.com/strip/2015-03-01
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
If you contact me I may find you a taw server without any mods.. We keep them on standby.
As long as the modded servers are not in use (and no indication of being used that day) I have no issues shutting one down and booting the vanilla one. Especially if you can test this within a reasonable timeframe. (note that I ment in a solo or 1 vs 1 enviroment, I do not have a modless pub available atm, they are all scrim servers.)
I am often pressed for time so your best attempt to do this is during the weekends.. (Note current weekend is a nono)
im search on forums , and there is many topics about "Failed allocate ### bytes" crash or "fatal error"
so i dont have to creat "more" of them , developers should consider go on techsupport forums and say more about these "frequently with many user crash"
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
edited March 2015
The previous topics are outdated and old.
This is just the remainder, and I assume from a different cause.
Yes, if you still have the error the cdt needs more info.. More info is always good.
>edit
I tried to find some info what went wrong with memory, in the .dmp.
I eventually found the heap (to my knowledge) which was close to max. namely:
Allocations statistics for
heap @ 08430000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
8703c 1 - 8703c (95.14)
I had hoped to pull the stack information out of it with -p -a, however when I enable Page Heap, ns2 simply crashes upon boot.
If the dump file isnt made with page heap on, I can not grab it out to my knowledge. (if it worked I mend to ask you to make one with heap on)
Now I never tried to lookup memory info in a dmp before, so I may be going about it the wrong way.. If I have more ideas ill get back to you.
Exactly. It was a many patches ago, also for clarity sake I started new thread (boy, this thread is getting long too without much added value! Maybe I should make thread summary in the OP?). Also a memory leak and the related error message are more of a symptom than an error in itself. The old thing could very well be fixed and this could be recent(well at least I was not getting errors last year I think).
Now I never tried to lookup memory info in a dmp before, so I may be going about it the wrong way.. If I have more ideas ill get back to you.
Good way to get into programming as any, though you won't see much in the dumps. You need source code to do anything useful. Well you can at least see the stack (where it crashed and what was immediately before that ), because for some reason we got *.pdb(symbol database) in our installations. You will see pretty much, what we already know(something or other wants memory at the end, but there is no more, so bam, crash!).
If you want to try, what you do is install Visual Studio(should be free). Then double click the *.dmp file. Then in VS click "Debug" (and wish that you are not broking some random EULA in the process ). Somewhere the stack should show up(bottom right?). If it's not legible(0xblahblah instead nice function names) you need to load the *.pdb files, but it should have been done automagically.
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
You are partially right mate.
Ive been using Windows debugger for well, quite some while now. Which is of course setup with a symbol path (and linked to ns'2 symbols also because why not.)
The .pdb are ment to be supplied with ns2.. They desided to do that some while ago and ive ran both symbol paths ever since. ^^ (ok I made a seperate workspace for ns2 as the 2nd path slows analyze -v down)
The odd part is, it does NOT supply the stack.. which is what I was digging for. I was hoping to read the stacks of the growing heap. I found several large heaps close to max %, (70%~ up to the 90%~ one I posted) and I wanted to see what their stacks contained. You know, get fresh ideas.
But it does not do so.
-p -a <UsrPtr> should give me a call stack, but it doesn't.
This is why:
The !heap -p command displays various forms of page heap information. Before using !heap -p, you must enable the page heap for the target process. This is done through the Global Flags (gflags.exe) utility. To do this, start the utility, fill in the name of the target application in the Image File Name text box, select Image File Options and Enable page heap, and click Apply. Alternatively, you can start the Global Flags utility from a Command Prompt window by typing gflags /i xxx.exe +hpa, where xxx.exe is the name of the target application.
Assuming I didnt screw up somewhere, its just not giving.
naah, I can not code. I barely understand code.. I do understand logic which usually gets me the info I need from a dmp, ironic right?
I mainly use the debugger to see what breaks (.dll, hardware etc) when I get some crashes somewhere in software. (because normal crash dumps from like windows do contain stacks thankfully)
Just hoped to expand the mind and see if I could dig up the leak in the dmp itself.
(hmm makes me wonder what stack you would see if you setup process explorer or a live debug session when it crashes)
@IronHorse It is false because you are just guessing. Like Mephilles and another guy posted (whose post just got deleted) it happens on every server (and is mostly related to a bad network on the client side). I understand the fact that the tech support files may produce "false positives" values, it is still vague to claim it is only happen on servers with more than 24 slots.
Re read the post you called "false".
Nothing I said in there was false, and never did I "claim it is only happen(ing) on servers with more than 24 slots".
I merely explain there is a chance, and that it is not a good testing environment due to bugs that we cannot test for because it is outside of what is intended for the game... something you already recognize in the quote above.
Lastly, I am not getting drawn into another discussion that you or your regulars derail in a misguided attempt to explain what good your historically poor performing servers have provided to new players. (not even mentioning the entirely unintended gameplay results.) I don't care what you think, frankly, as I've heard it all before. And that's really what I have a problem with : the technical support forums are not a place for discussion, but to aid players in resolving technical issues.
So, since you clearly agree with the CDT's assessment of your servers not being an adequate environment to diagnose problems with - Please refrain from responding to posts in these technical support forums that mention your servers if you have nothing productive to contribute or are just looking to save face - it is simply derailing and a waste of time for everyone.
@krOoze Still no news to update you with, but it seems like we definitely have an idea of why it is occurring, just might be more work than anticipated.
We will definitely need you though when we have a fix to test
@DC_Darkling :
IMHO pdb files are waste of space for end user. I am curious, do you know more about that decision?
"stacks of growing heap"??? Well I thought you ment THE stack. As in not heap.
Can't help you much with command line debug, I am not masochistic that way... that tool you describe is for debugging Windows itself and drivers, no?
Well I do wonder how would you interpret anything useful from dmp without source code. I mean the leak is probably NetworkMemory, but that name mean bat s*** to me without source codes...
(Un)fortunately I do not get the crashes frequently enough to sufficiently test much in any reasonable time. Sometimes it's week somtimes two consecutive gameplays. Maybe it's time to put @Perman12 to work Right now I am little paranoid about Fraps(and the like) incompatibility and still testing that...
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
Yeh well Windbg is, for me, most often used to find what dll or hardware breaks what. So yeh, mainly windows, drivers and windows programs. (and since ns2 is a windows program also.... ) :P
Meh, varied result I would guess in its use.. If most of the memory would have stacks calling upon NetworkMemory it would only be a stronger indication. (the failing area did say stuff about Networkmemory btw)
But yeh, its for me personally most useful debugging windows issues so I often hit a wall with program digging. :P
I actually got a bit further but hit a new wall as the symbols for the specific handle seemed either nonexistant, or off.
also about the pdb files, im the wrong person to ask.. ive spend to much time around these forums to remember every how and why, but I think it wasnt a mistake if I remember correct.
Yeah me too, it's probably the same thing. It probably fails to allocate memory for the text of the "Fatal memory" window in some cases.
Just make techsupport.exe report like you are told, before clicking OK to the message (described how here: forums.unknownworlds.com/discussion/131384/how-to-make-a-good-tech-support-post Go to the "C:\Program Files\Steam\SteamApps\common\Natural Selection 2" or whatever your installation is and run techsupport.exe, let it do its thing then click save). If the zip is less than 10 MB(doesn't contain minidump folder), then open task manager(ctrl-alt-esc) and right mouse click NS2.exe in it and click "Create dump file". It will tell you where it is saved. Compress it (it will be like 4GB. Best use 7zip with best compression - I get 400MB from it). Alternatively you can try Process Explorer from Windows Sysinternals instead and create mini-dump (~20 MB). Then post the report zip and the dump(if it needed to be done separately) here or in your new thread. And wait wait wait...
Good for you. But you still need to provide them with the data they asked you for. I gave you a step by step guide in previous post as to how. Do you have any trouble doing that? Do you need further help with it? Oh, you did just now provided the data in the thread... You should still make and post them a dump as I described in previous post.
There's some consistency errors in the logs you posted. You should check hard disk in Windows and do "Verify game cache integrity" in steam.
@DC_Darkling
1) It's what 99% people have in their PCs, if they have integrated LAN chip.
2) I don't even run over it and use wi-fi instead.
3) Even if it does bad stuff like dropping packets, why should that cause software to leak. The game still needs to get fixed.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
It's not so much about blaming hardware as it is about finding patterns to root out of the cause, be it software (NS2) that interacts poorly with hardware or drivers etc.
I even have that driver disabled... what would make you two satisfied? OK, I am updating it too.
I mentioned another similarity in the other thread. We both have lame CPUs (so maybe some ugly race-condition?).
Comments
I understood nothing of your line 'Well the bogus value in dxdiag shows 2.5 in idle. If you add the 4 for crashed ns2 it does +- match what is in the log.' probably because we may not talk about the same. Be a bit more specific.
You talking about free memory, committed, paged, nonpaged, system wide or application only? (and yes that is a question on which id expect multiple answers)
What I ment is, do you still have the memory leak when you play on dx11?
What do you make of the .log's @ironhorse? I could not reproduce the same errors with verbose 3, so I assume they are part of the problem. Prediction world seems... off
@IronHorse It is false because you are just guessing. Like Mephilles and another guy posted (whose post just got deleted) it happens on every server (and is mostly related to a bad network on the client side). I understand the fact that the tech support files may produce "false positives" values, it is still vague to claim it is only happen on servers with more than 24 slots.
The mods i am using are there to offer the people a good experience while playing ns2 (NS2+ and Shine Administration plus Custom Badges) which wouldn't be possible with vanilla. Also there are no gameplay changes made since the server is running.
And yes i am using a "hacked" executable and i am glad that this has not been changed. Else we would have many 24+ servers with bad performance.
Edit: If you check the current playerbase you will see that 1/4 - 1/6 Players playing on a Server with 24+ Slots. I always tell them to contact me first so i can try solve their problem since there is (still) no acceptance here. I understand the fact that such servers may produce extra work for the CDT, but how they (or most of them) represent their view will just split the community into two parts... (Which already happened)
developers should fix this and add game Match making like Insurgency ( they still have dedicated server , offical server is 6v6 for match making)
@Perman12 That frequent for you, huh? Tough luck. Patience - that programming nonsense takes time, especially if you do more nonsense at the same time https://trello.com/b/91ApENY6/ns2-cdt-development-tracker for free (or are you getting someting for your work CDT?). You can try some things, to kill time(or do something else entirely, you know): reinstall (forums.unknownworlds.com/discussion/131428/obbys-full-nuke-ns2-guide-only-way-to-be-sure), mess around with game settings, update all your drivers, try more reliable network if you practically can(LAN cable), disable "Show hints"(that fixed it for one guy in previous thread, so who knows...), try uninstalling overlay software(Fraps, AMD Gaming evolved/raptr, NVidia Shadowplay, disable steam overlay too perhaps), check your disk for errors, post your tech_support zip (forums.unknownworlds.com/discussion/131384/how-to-make-a-good-tech-support-post). Maybe it can be reduced to less annoying frequency for you in the meantime... or if not this should get a laugh: dilbert.com/strip/2015-03-01
As long as the modded servers are not in use (and no indication of being used that day) I have no issues shutting one down and booting the vanilla one. Especially if you can test this within a reasonable timeframe. (note that I ment in a solo or 1 vs 1 enviroment, I do not have a modless pub available atm, they are all scrim servers.)
I am often pressed for time so your best attempt to do this is during the weekends.. (Note current weekend is a nono)
so i dont have to creat "more" of them , developers should consider go on techsupport forums and say more about these "frequently with many user crash"
instead creating another Trello board =='
This is just the remainder, and I assume from a different cause.
Yes, if you still have the error the cdt needs more info.. More info is always good.
>edit
I tried to find some info what went wrong with memory, in the .dmp.
I eventually found the heap (to my knowledge) which was close to max. namely:
heap @ 08430000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
8703c 1 - 8703c (95.14)
I had hoped to pull the stack information out of it with -p -a, however when I enable Page Heap, ns2 simply crashes upon boot.
If the dump file isnt made with page heap on, I can not grab it out to my knowledge. (if it worked I mend to ask you to make one with heap on)
Now I never tried to lookup memory info in a dmp before, so I may be going about it the wrong way.. If I have more ideas ill get back to you.
Good way to get into programming as any, though you won't see much in the dumps. You need source code to do anything useful. Well you can at least see the stack (where it crashed and what was immediately before that ), because for some reason we got *.pdb(symbol database) in our installations. You will see pretty much, what we already know(something or other wants memory at the end, but there is no more, so bam, crash!).
If you want to try, what you do is install Visual Studio(should be free). Then double click the *.dmp file. Then in VS click "Debug" (and wish that you are not broking some random EULA in the process ). Somewhere the stack should show up(bottom right?). If it's not legible(0xblahblah instead nice function names) you need to load the *.pdb files, but it should have been done automagically.
Those I uploaded are with heap allocations. Again that is pretty much useless without source code.
Ive been using Windows debugger for well, quite some while now. Which is of course setup with a symbol path (and linked to ns'2 symbols also because why not.)
The .pdb are ment to be supplied with ns2.. They desided to do that some while ago and ive ran both symbol paths ever since. ^^ (ok I made a seperate workspace for ns2 as the 2nd path slows analyze -v down)
The odd part is, it does NOT supply the stack.. which is what I was digging for. I was hoping to read the stacks of the growing heap. I found several large heaps close to max %, (70%~ up to the 90%~ one I posted) and I wanted to see what their stacks contained. You know, get fresh ideas.
But it does not do so.
-p -a <UsrPtr> should give me a call stack, but it doesn't.
This is why:
The !heap -p command displays various forms of page heap information. Before using !heap -p, you must enable the page heap for the target process. This is done through the Global Flags (gflags.exe) utility. To do this, start the utility, fill in the name of the target application in the Image File Name text box, select Image File Options and Enable page heap, and click Apply. Alternatively, you can start the Global Flags utility from a Command Prompt window by typing gflags /i xxx.exe +hpa, where xxx.exe is the name of the target application.
Assuming I didnt screw up somewhere, its just not giving.
naah, I can not code. I barely understand code.. I do understand logic which usually gets me the info I need from a dmp, ironic right?
I mainly use the debugger to see what breaks (.dll, hardware etc) when I get some crashes somewhere in software. (because normal crash dumps from like windows do contain stacks thankfully)
Just hoped to expand the mind and see if I could dig up the leak in the dmp itself.
(hmm makes me wonder what stack you would see if you setup process explorer or a live debug session when it crashes)
Nothing I said in there was false, and never did I "claim it is only happen(ing) on servers with more than 24 slots".
I merely explain there is a chance, and that it is not a good testing environment due to bugs that we cannot test for because it is outside of what is intended for the game... something you already recognize in the quote above.
Lastly, I am not getting drawn into another discussion that you or your regulars derail in a misguided attempt to explain what good your historically poor performing servers have provided to new players. (not even mentioning the entirely unintended gameplay results.) I don't care what you think, frankly, as I've heard it all before. And that's really what I have a problem with : the technical support forums are not a place for discussion, but to aid players in resolving technical issues.
So, since you clearly agree with the CDT's assessment of your servers not being an adequate environment to diagnose problems with - Please refrain from responding to posts in these technical support forums that mention your servers if you have nothing productive to contribute or are just looking to save face - it is simply derailing and a waste of time for everyone.
@krOoze Still no news to update you with, but it seems like we definitely have an idea of why it is occurring, just might be more work than anticipated.
We will definitely need you though when we have a fix to test
IMHO pdb files are waste of space for end user. I am curious, do you know more about that decision?
"stacks of growing heap"??? Well I thought you ment THE stack. As in not heap.
Can't help you much with command line debug, I am not masochistic that way... that tool you describe is for debugging Windows itself and drivers, no?
Well I do wonder how would you interpret anything useful from dmp without source code. I mean the leak is probably NetworkMemory, but that name mean bat s*** to me without source codes...
(Un)fortunately I do not get the crashes frequently enough to sufficiently test much in any reasonable time. Sometimes it's week somtimes two consecutive gameplays. Maybe it's time to put @Perman12 to work Right now I am little paranoid about Fraps(and the like) incompatibility and still testing that...
Meh, varied result I would guess in its use.. If most of the memory would have stacks calling upon NetworkMemory it would only be a stronger indication. (the failing area did say stuff about Networkmemory btw)
But yeh, its for me personally most useful debugging windows issues so I often hit a wall with program digging. :P
I actually got a bit further but hit a new wall as the symbols for the specific handle seemed either nonexistant, or off.
also about the pdb files, im the wrong person to ask.. ive spend to much time around these forums to remember every how and why, but I think it wasnt a mistake if I remember correct.
But im sure CDT will find it eventually.
You were warned.
Just make techsupport.exe report like you are told, before clicking OK to the message (described how here: forums.unknownworlds.com/discussion/131384/how-to-make-a-good-tech-support-post Go to the "C:\Program Files\Steam\SteamApps\common\Natural Selection 2" or whatever your installation is and run techsupport.exe, let it do its thing then click save). If the zip is less than 10 MB(doesn't contain minidump folder), then open task manager(ctrl-alt-esc) and right mouse click NS2.exe in it and click "Create dump file". It will tell you where it is saved. Compress it (it will be like 4GB. Best use 7zip with best compression - I get 400MB from it). Alternatively you can try Process Explorer from Windows Sysinternals instead and create mini-dump (~20 MB). Then post the report zip and the dump(if it needed to be done separately) here or in your new thread. And wait wait wait...
There's some consistency errors in the logs you posted. You should check hard disk in Windows and do "Verify game cache integrity" in steam.
Name: Realtek PCIe GBE Family Controller
Device ID: PCI\VEN_10EC&DEV_8168&SUBSYS_E0001458&REV_06\00E2
Driver: n/a
Name: Realtek PCIe GBE Family Controller
Device ID: PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&11EB9DBD&0&00E4
Driver: n/a
According to http://pcidatabase.com, this is apparently a
Chip Number: RTL8168E/RTL8111F/RTL.
Which supplies the newest drivers here:
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#1
Internet search shows lotsa issues with this network card.
1) It's what 99% people have in their PCs, if they have integrated LAN chip.
2) I don't even run over it and use wi-fi instead.
3) Even if it does bad stuff like dropping packets, why should that cause software to leak. The game still needs to get fixed.
The driver should behave. The game should say 'hell no' to the driver.
Just saying its worth a try. ^^
I mentioned another similarity in the other thread. We both have lame CPUs (so maybe some ugly race-condition?).
If noone ever had ns2 tech probs again?