Re: WSAENOBUFS on winsock client application

I use the default stack size, that is 1MB as I remember and there are no big
memory allocations.
40 threads is only the maximum for my application. In the case where the
problem appears there are only 3 communication threads running...

I do not think that the memory consumption is the problem, there might be an
interrelation with the unexpected loss of TCP connections.

--
best regards
friedhelm


"Volodymyr M. Shcherbyna" wrote:

I think that the problem is connected with low resources issue (of course, I
may be wrong). Does your code make any big memory allocations? Did you
estimate memory usage of your process when it is heavily overloaded by
requests from clients?

You wrote previously that you have 40 threads. What is the default stack
size of thread? I remember, someone here were asking a question: "why do I
get WSAENOBUFS error when the stack size of my thread is ~860 MB" :) . The
problem is that the stack is allocated in a heap for a given process; and
the virtual memory usage is limited to 2 GB. So if you have many threads
with a big stack size the low resources issue comes. You can do the
following at the beginning to clarify my assumptions,

1) Make tests and see memory usage of your process; and if the mem
usage is big, redesign application

2) Increase address space of a process by using /3GB switch and see if
the problem remains


--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"FriedhelmEichin" <FriedhelmEichin@xxxxxxxxxxxxxxxx> wrote in message
news:BEA93BFB-9325-480F-B41B-BFA9AAB4F42A@xxxxxxxxxxxxxxxx
The application is running on Windows XP SP2.

The error code is returned if a preceeding connection has been broken
caused
by network issues and a new connection attempt is made within the thread.
But
this is not deterministic, normally the following connection attempt
succeeds. It may happen after a few disconnects after minutes or even
days...

--
best regards
friedhelm


"Volodymyr M. Shcherbyna" wrote:

I analyzed winsock sources (XP SP2), and the error WSAENOBUFS is returned
usually when allocation of memory failes (RtlHeapAllocate(...)) or
equivalents:

What is your OS?

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"FriedhelmEichin" <FriedhelmEichin@xxxxxxxxxxxxxxxx> wrote in message
news:FB4F7278-628C-4AF1-A22A-278509CE667B@xxxxxxxxxxxxxxxx




.

Relevant Pages

  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Resolving internal links
    ... You have to pass all workspace in via ... Which highlights another issue - you could not use Fortify (or similar code which uses these functions to replace the memory allocators) within the main application code unless you also used it within the module. ... At best you'll reference memory which does not exist and cause an abort. ... will only be able to use 256 bytes of stack space IIRC. ...
    (comp.sys.acorn.programmer)