My tangential testing that began with my problems with commands run via WinRs during some distributed load testing are slowly unravelling back to the start. I now have a better build and test system for the server examples that ship as part of The Server Framework. I have a test runner that runs the examples with memory limits to help spot memory leak bugs and a test runner that checks for lock inversions. My test scripts are also more flexible and I’ve found a couple of bugs.
Today I used a variation on my job object based memory limiting test runner to investigate the original problem with commands spawned remotely using WinRS. Given that I had a test runner that could spawn a process and place it into a job object it was simple to adjust this so that the target process was instead broken out of any job that the test runner might be in; just add
CREATE_BREAKAWAY_FROM_JOB to the process creation flags and hope… This seemed to work so I then looked into reporting on the job that the test runner found itself in… Some simple calls to
QueryInformationJobObject() with null jobs showed that the WinRS processes were being run inside of a job and that the limits (on my particular box) were as follows:
Job report for process: 10676
Process IS in a job
Flags: 0x2b08 -
The problem limits being the job and process memory limits. Luckily the WinRS job has
JOB_OBJECT_LIMIT_BREAKAWAY_OK set so my attempt to break the target process free of these limits works fine.
I still haven’t found where any of this is documented, but at least I now don’t have to write my own remote process spawning code.