Dave Page wrote:
> On Tue, Aug 31, 2010 at 4:35 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Dave Page wrote:
> >> On Tue, Aug 31, 2010 at 4:27 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > We have already found that exceeding desktop heap might cause a
> >> > CreateProcess to return success but later fail with a return code of
> >> > 128, which causes a server restart.
> >>
> >> That doesn't mean that this is desktop heap exhaustion though - just
> >> that it can cause the same effect.
> >
> > Right, but it is the only possible server crash cause we have come up
> > with so far.
>
> Understood - I'm just unconvinced it's the cause - aside from the
> point I made earlier about heap exhaustion being very predictable and
> reproducible (which this issue apparently is not), when the server is
> run under the SCM, it creates a logon session for that service alone
> which has it's own heap allocation which is entirely independent of
> the allocation used by any interactive logon sessions.
>
> So unless there's a major isolation bug in Windows, any desktop heap
> usage in an interactive session for one user should have zero effect
> on a non-interactive session for another user.
Well, the only description that we have ever heard that makes sense is
some kind of heap exhaustion, perhaps triggered by a Windows bug that
doesn't properly track heap allocations sometimes.
Of course, the cause might be aliens, but we don't have any evidence of
that either. :-|
What we do know is that CreateProcess is returning success, and the
child is exiting with 128 no_such_child, and that logging out can
trigger it sometimes.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
