Seg fault in _size_of_stack_reserve__ ()

Seg fault in _size_of_stack_reserve__ ()

[James Stern]

This is the latest chapter in my struggle with Windows
DLLs.

I combined the advice of Mumit Khan (use dllwrap) with
that of Paul Sokolovsky (link your static libraries
into one DLL), with the result that I can finally
build a DLL.  My thanks to both of you.

My DLL consists of two files, static link library
libntonly.a and "DLL proper" ntonly.dll.

BTW, I had to put ntonly.dll in the directory that
holds my executables.  I couldn't get either -rpath or
LD_RUN_PATH to work.  But never mind.  That's minor.

What's major is what happens when I run the program. 
I call a function, it enters a `for' loop and I die in
_size_of_stack_reserve__().  Anyone got an
explanation?

Other clues:  `nm' says that both the executable and
ntonly.dll know the above symbol, as well as a
__size_of_heap_reserve__.  Each file says the symbols
are type 'A' and they agree on their addresses.
===
-- 
Opinions expressed above are not necessarily my employer's.
James M. Stern
ITG Inc.  Culver City, CA (213) 270-7955
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Seg fault in _size_of_stack_reserve__ ()

[Mumit Khan]

James Stern <jsternitg@yahoo.com> writes:
> This is the latest chapter in my struggle with Windows
> DLLs.
> 
> I combined the advice of Mumit Khan (use dllwrap) with
> that of Paul Sokolovsky (link your static libraries
> into one DLL), with the result that I can finally
> build a DLL.  My thanks to both of you.
> 
> My DLL consists of two files, static link library
> libntonly.a and "DLL proper" ntonly.dll.

fyi, the proper terminology is "import library" when
referring to libntonly.a. Helps to avoid confusion.

So far so good.

> 
> BTW, I had to put ntonly.dll in the directory that
> holds my executables.  I couldn't get either -rpath or
> LD_RUN_PATH to work.  But never mind.  That's minor.

That's a Windows thing. Please see windows docs for info
on how the OS locates "linked" DLLs (NT and Win9x differ
slightly).

> What's major is what happens when I run the program. 
> I call a function, it enters a `for' loop and I die in
> _size_of_stack_reserve__().  Anyone got an
> explanation?

It just means your code is running into bad things. That's
what a debugger is for. If by any chance you see that
the code is crashing right where you're referring to an
external variable, you'ver forgotten to mark it imported
from a DLL via __declspec(dllimport). If elsewhere, the
debugger should be able to provide a clue. Compile it
all files -g for the best debugging experience ...

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Seg fault in _size_of_stack_reserve__ ()

[John R Hanson]

_size_of_stack_reserve__()

(It is actually in the 'A'bsolute .section, and is the 
Size you want windows to reserve for your stack-)

Is the Highest addressed symbol in your program it just means
that the program is dying in a system .dll that doesn't have any
symbols.

you need to compile and link with -gcoff == /ZI
link the program with ld.exe

gdb yourprog.exe
b main  /* or WinMain */
run /* to get the dll symbols to load */
b    /* at the function you are trying to call in the .dll */
s   /* until you get to the call into the system .dll that's having
   the problem */
  figure out what went wrong.-)

Otherwise use Visual Stupidio if you can't link with ld.

On Tue, 24 Aug 1999 16:01:49 -0700 (PDT), you wrote:

>This is the latest chapter in my struggle with Windows
>DLLs.
>
>I combined the advice of Mumit Khan (use dllwrap) with
>that of Paul Sokolovsky (link your static libraries
>into one DLL), with the result that I can finally
>build a DLL.  My thanks to both of you.
>
>My DLL consists of two files, static link library

No, this is a stub library, or implib

>libntonly.a and "DLL proper" ntonly.dll.
>
>BTW, I had to put ntonly.dll in the directory that
>holds my executables.  I couldn't get either -rpath or
>LD_RUN_PATH to work.  But never mind.  That's minor.

windows searches %path% and a few other places. use

path %path%;path\to\dll\dir or PATH=$PATH:path/to/dll/dir depending on your shell

>
>What's major is what happens when I run the program. 
>I call a function, it enters a `for' loop and I die in
>_size_of_stack_reserve__().  Anyone got an
>explanation?
>
>Other clues:  `nm' says that both the executable and
>ntonly.dll know the above symbol, as well as a
>__size_of_heap_reserve__.  Each file says the symbols
>are type 'A' and they agree on their addresses.
>===
>-- 
>Opinions expressed above are not necessarily my employer's.
>James M. Stern
>ITG Inc.  Culver City, CA (213) 270-7955
>__________________________________________________
>Do You Yahoo!?
>Bid and sell for free at http://auctions.yahoo.com

________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Seg fault in _size_of_stack_reserve__ ()

[James Stern]

This is the latest chapter in my struggle with Windows
DLLs.

I combined the advice of Mumit Khan (use dllwrap) with
that of Paul Sokolovsky (link your static libraries
into one DLL), with the result that I can finally
build a DLL.  My thanks to both of you.

My DLL consists of two files, static link library
libntonly.a and "DLL proper" ntonly.dll.

BTW, I had to put ntonly.dll in the directory that
holds my executables.  I couldn't get either -rpath or
LD_RUN_PATH to work.  But never mind.  That's minor.

What's major is what happens when I run the program. 
I call a function, it enters a `for' loop and I die in
_size_of_stack_reserve__().  Anyone got an
explanation?

Other clues:  `nm' says that both the executable and
ntonly.dll know the above symbol, as well as a
__size_of_heap_reserve__.  Each file says the symbols
are type 'A' and they agree on their addresses.
===
-- 
Opinions expressed above are not necessarily my employer's.
James M. Stern
ITG Inc.  Culver City, CA (213) 270-7955
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Seg fault in _size_of_stack_reserve__ ()

[Mumit Khan]

James Stern <jsternitg@yahoo.com> writes:
> This is the latest chapter in my struggle with Windows
> DLLs.
> 
> I combined the advice of Mumit Khan (use dllwrap) with
> that of Paul Sokolovsky (link your static libraries
> into one DLL), with the result that I can finally
> build a DLL.  My thanks to both of you.
> 
> My DLL consists of two files, static link library
> libntonly.a and "DLL proper" ntonly.dll.

fyi, the proper terminology is "import library" when
referring to libntonly.a. Helps to avoid confusion.

So far so good.

> 
> BTW, I had to put ntonly.dll in the directory that
> holds my executables.  I couldn't get either -rpath or
> LD_RUN_PATH to work.  But never mind.  That's minor.

That's a Windows thing. Please see windows docs for info
on how the OS locates "linked" DLLs (NT and Win9x differ
slightly).

> What's major is what happens when I run the program. 
> I call a function, it enters a `for' loop and I die in
> _size_of_stack_reserve__().  Anyone got an
> explanation?

It just means your code is running into bad things. That's
what a debugger is for. If by any chance you see that
the code is crashing right where you're referring to an
external variable, you'ver forgotten to mark it imported
from a DLL via __declspec(dllimport). If elsewhere, the
debugger should be able to provide a clue. Compile it
all files -g for the best debugging experience ...

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Seg fault in _size_of_stack_reserve__ ()

[John R Hanson]

_size_of_stack_reserve__()

(It is actually in the 'A'bsolute .section, and is the 
Size you want windows to reserve for your stack-)

Is the Highest addressed symbol in your program it just means
that the program is dying in a system .dll that doesn't have any
symbols.

you need to compile and link with -gcoff == /ZI
link the program with ld.exe

gdb yourprog.exe
b main  /* or WinMain */
run /* to get the dll symbols to load */
b    /* at the function you are trying to call in the .dll */
s   /* until you get to the call into the system .dll that's having
   the problem */
  figure out what went wrong.-)

Otherwise use Visual Stupidio if you can't link with ld.

On Tue, 24 Aug 1999 16:01:49 -0700 (PDT), you wrote:

>This is the latest chapter in my struggle with Windows
>DLLs.
>
>I combined the advice of Mumit Khan (use dllwrap) with
>that of Paul Sokolovsky (link your static libraries
>into one DLL), with the result that I can finally
>build a DLL.  My thanks to both of you.
>
>My DLL consists of two files, static link library

No, this is a stub library, or implib

>libntonly.a and "DLL proper" ntonly.dll.
>
>BTW, I had to put ntonly.dll in the directory that
>holds my executables.  I couldn't get either -rpath or
>LD_RUN_PATH to work.  But never mind.  That's minor.

windows searches %path% and a few other places. use

path %path%;path\to\dll\dir or PATH=$PATH:path/to/dll/dir depending on your shell

>
>What's major is what happens when I run the program. 
>I call a function, it enters a `for' loop and I die in
>_size_of_stack_reserve__().  Anyone got an
>explanation?
>
>Other clues:  `nm' says that both the executable and
>ntonly.dll know the above symbol, as well as a
>__size_of_heap_reserve__.  Each file says the symbols
>are type 'A' and they agree on their addresses.
>===
>-- 
>Opinions expressed above are not necessarily my employer's.
>James M. Stern
>ITG Inc.  Culver City, CA (213) 270-7955
>__________________________________________________
>Do You Yahoo!?
>Bid and sell for free at http://auctions.yahoo.com

________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com