Please Help!! Calling Socket function in a dll file (that is created using cygwin library), by a Microsoft Visual C++ program resulting in infinite loop

Brian Dessent
Wed May 9 06:44:00 GMT 2007

kalasad mailu wrote:

> I read the following from the how-cygtls-works.txt
> "If you load cygwin1.dll dynamically from a non-cygwin application, it is
>   vital that the bottom CYGTLS_PADSIZE bytes of the stack are not in use
>   before you call cygwin_dll_init()"
> How do I make sure bottom CYGTLS_PADSIZE bytes of the stack are not in use
> before you call cygwin_dll_init()"
> I could not find any information at: winsup/testsuite/cygload

The files and cygload.h are in winsup/testsuite/winsup.api. 
They show a pretty complete example of how to dynamically load the DLL
and deal with the stack and signals.  There are several general ways to
make sure the bottom of the stack contains the scratch space, in roughly
ascending order of ease/quality:

- Reserve the space at the earliest possibility in the CRT startup
objects (this is how native Cygwin apps do it, or rather how they don't
have to worry about it)

- Change the entry point to your custom routine that saves the state of
whatever is at the bottom of the stack (hopefully nothing or close to
nothing, since this is very early in the init sequence), replaces the
bottom of the stack with your scratch/padding, calls the stock entry
point, and after that returns restores the previous contents at the
bottom of the stack.  This is how cygload does it, using the neat
feature of C++ ctors and dtors to take care of some of the housekeeping.

- If you can't do either of the above then you roughly do the same thing
but at a later point in execution, e.g. by wrapping main() (or WinMain
or DllMain or ....) or even by initializing/deinitialzing your scratch
space as the first and last things in main(), etc.  (Look in CVS at
older versions of cygload which did it with less finesse this way.)

It's all still the same concept though, just with various amounts of
already existing stuff (from zero to lots) at the base of the stack when
your routine gets called.

Note about terminology, the scratch space needs to exist at the bottom
of the stack in logical terms, i.e. the very first n bytes pushed on the
stack.  But because on x86 the stack grows down this scratch space will
be at the numerically highest address.  Don't get confused though, it
all essentially amounts to just being the first to allocate a large auto
char[] array; or faking it by manipulating the stack pointer directly if
you aren't the first in line to touch the stack, and saving the state of
whatever was there before you so you can restore it before ceding
control back to whoever called you.


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list