RE: loading of wsock32 disturbs FPU

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Corinna Vinschen
>Sent: 02 March 2005 14:32

> On Mar  2 13:33, Dave Korn wrote:
>>   Hm.  We probably need to put a finit instruction into the autoload code
>> somewhere.  wsock_init () looks like just the place......  now if I just
>> persuade the CVS code to build without a SIG11 (grmbl grmbl....)
> 
> Hmm?  -v please.

[ObTopic bit below, this bit can be skipped safely]

  Oh, just one of those obscure SEGVs that you sometimes see during long GNU
configure/build processes and never quite know where it came from.  This is
during the first 'make all' after doing top-level configure, when it starts
recursing into the top-level subdirectories and configuring them:

Configuring in libiberty
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
 [ ... snip ... ]
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
Signal 11
make: *** [configure-libiberty] Error 1

  At this point the sh.exe subprocess that invoked make dies so badly it
kills not just make but also the bash parent shell and ends up dropping out
the bottom of the cygwin.bat file!  Not sure if the line info is still good,
but addr2line has this to say about the contents of the .stackdump file:

dk@mace /usr/build/obj/libiberty> cat sh.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=61001F5D
eax=00000000 ebx=0022E800 ecx=00006E28 edx=61780000 esi=61780000
edi=00000000
ebp=0022E7C8 esp=0022E620 program=C:\cygwin\bin\sh.exe, pid 3544, thread
main
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:

dk@mace /usr/build/obj/libiberty> addr2line --exe=/bin/cygwin1-20041201.dll
61001F5D
/usr/build/winsup-build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/
cygwin/cygheap.cc:97
6104A8B1
/usr/build/winsup-build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/
cygwin/fork.cc:625
610854FF
??:0
00402A3A
??:0

....which interestingly enough is this memcpy line....

static void dup_now (void *, child_info *, unsigned) __attribute__
((regparm(3)));
static void
dup_now (void *newcygheap, child_info *ci, unsigned n)
{
  if (!VirtualAlloc (newcygheap, n, MEM_COMMIT, PAGE_READWRITE))
    api_fatal ("couldn't allocate new cygwin heap %p, %d for child, %E",
	       newcygheap, n);
  memcpy (newcygheap, cygheap, n);

...(and to be precise, which is the repz movsb instruction that does the
memcpy).

  Which is _very_ strange indeed, since it seems to suggest that
VirtualAlloc returned an OK indication, but newcygheap == NULL
none-the-less.

  Anyway that was cygwin1-20041201.dll; with the 20050228 snapshot
everything worked fine, as indeed it does with the homebrewed 20050302 that
I am now using.  I'll keep an eye out for it but it doesn't seem to be
happening any more.


ObBackOnTheFpuTopic:

  And I can confirm that adding 'asm ("finit");' to wsock_init (I put it
inside the "if (!wsock_started)" clause, just after the closing brace of the
"if (wsastartup)" clause) fixes both the testcase that Ralf posted this
morning and also fixes his original example code so that it produces the
same results whether or not the hostname call is made.  (It doesn't of
course fix the problem if the user calls LoadLibrary directly on either
ws2_32 or msvcrt, but we don't expect it to, we just want the cygwin library
calls to not have unexpected side-effects!)


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/