I noticed today that my server was was losing diskspace (down over 8 gigs since last Monday). This server should not lose diskspace There is nothing that creates any files or data on it, so I went a'looking.
Lo and behold, in the temp directory there are several protrace files, and some of them are *huge*. We're talking 3.9GB and 2.7GB etc. So I tried to remove them.
No go. "This file is in use by another process". wtf ? a protrace is a result of a crashed session right ? So the session has crashed - which means that there cannot be a process that is still holding on to the file ...
wait ... yes there is. The prowin32 session is still there, chewing up CPU, and still writing to the protrace file !! This session crashed 4 days ago ...
I think that this crash happens when the user logs out of the application.
1) How / why is the protrace so large ?
2) Why is it still going after 4 days
3) How do I begin to try and find out where a crash like this happens ?
This is not an isolated incident either - I have 4 protrace files in the same situation right now ...
I'm surprised you didn't notice a performance hit. These zombies are famous for chewing up CPU. I haven't seen one create infinite protrace files before, but I have seen them produce infinite other kinds of output. It is just caught in a loop and will keep doing what it is doing until you succeed in killing it ... which can sometimes be difficult.
yeah - performance was becoming an issue. I need to try and find out
what's causing the problem in the first place.
On 7 July 2011 17:11, Thomas Mercer-Hursh
You should have plenty of protrace to help ...
Sure. Except it's not that useful ....
PROGRESS stack trace as of Thu Jul 07 12:03:49 2011
=====================================================
Startup parameters:
-pf C:\Progress\OpenEdge\startup.pf,-cpinternal ISO8859-1,-cpstream ISO8859-1,-cpcoll Basic,-cpcase Basic,-d dmy,-numsep 44,-numdec 46,(end .pf),-p C:\data\testing\source\trunk\startup.p,-pf c:\data\testing\einstein.pf,-d dmy,-T c:\temp,-rand 2,-mmax 32768,-rereadnolock,-s 4096,-debugalert,-assemblies C:\data\testing\source\trunk\dll,-preloadCLR,-icfparam startp.r,-pf c:\data\testing\Einsteindb.pf,-db einstein,-H olympia,-S 23456,-N TCP,-Mm 8192,-ld DEBT,(end .pf),-wy,-noincrwarn,(end .pf)
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 10165D5A 01:00164D5A C:\Progress\OpenEdge\bin\prow32.dll
Registers:
EAX:00000000
EBX:0D5B93F8
ECX:10165C60
EDX:1074E7E0
ESI:0D5B9344
EDI:0D5B93D4
CS:EIP:001B:10165D5A
SS:ESP:0023:0012F940 EBP:0D4E582C
DS:0023 ES:0023 FS:003B GS:0000
Flags:00210206
Debugging dll C:\WINDOWS\system32\DBGHELP.DLL
Symbol Path:
C:\Progress\OpenEdge\bin;C:\Progress\OpenEdge\pdbfiles
Call Stack:
Address Frame
10165D5A 00000000 DllStartup+DCE2A
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
0D5B9344 00000000 0000:00000000
0D4E582C 00000000 0000:00000000
0D502690 00000000 0000:00000000
note the repeating addresses 0D5B9344 , 0D4E582C , 0D502690 , 0D5B9344 , 0D4E582C , 0D502690 , 0D5B9344 , 0D4E582C , 0D502690 ......
can you imagine how much effort goes into creating a protrace file of 4GB by just repeating those three blocks ...
So, no help here
The stack is smashed and the stack trace will never finish the infinite loop (unless you get a really fast machine).
right. So, I have a system where I can reproduce this at will - is
that of any use to you, or should I just go ahead and try to fix it my
making some changes to my system ?
FWIW, this seems to happen every time the application quits.
oh, and it's 10.2B04 on windows server