Patch for silent crash with Cygwin1.dll v 1.5.19-4

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis
Hi,
 
Since installing Cygwin1.dll v 1.5.19-4, I have a
problem with the computer algebra system SAGE dying at
startup with no error messages (i.e. I get returned to
the bash prompt with no messages of any sort).
I tracked the problem down to
verifyable_object_isvalid() in winsup/thread.cc. The
added the check below corrects this problem:

CHANGELOG:
2006-03-02 Gary Zablackis [hidden email]
 * thread.cc (verifyable_object_isvalid): check for
NULL object or reference

CVS DIFF FILE:
Index: cygwin/thread.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.196
diff -u -p -r1.196 thread.cc
--- cygwin/thread.cc    6 Feb 2006 18:24:06 -0000    
 1.196
+++ cygwin/thread.cc    2 Mar 2006 18:06:50 -0000
@@ -122,6 +122,9 @@ verifyable_object_isvalid (void
const *
   if (efault.faulted ())
     return INVALID_OBJECT;

+  if(!object || !*object)
+     return INVALID_OBJECT;
+
   if ((static_ptr1 && *object == static_ptr1) ||
       (static_ptr2 && *object == static_ptr2) ||
       (static_ptr3 && *object == static_ptr3))



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Christopher Faylor-2
On Thu, Mar 02, 2006 at 10:11:39AM -0800, Gary Zablackis wrote:

>Since installing Cygwin1.dll v 1.5.19-4, I have a problem with the
>computer algebra system SAGE dying at startup with no error messages
>(i.e.  I get returned to the bash prompt with no messages of any sort).
>I tracked the problem down to verifyable_object_isvalid() in
>winsup/thread.cc.  The added the check below corrects this problem:
>
>CHANGELOG:
>2006-03-02 Gary Zablackis [hidden email]
> * thread.cc (verifyable_object_isvalid): check for
>NULL object or reference

The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.  I suspect that you were probably misled by the fact
that gdb might show a SEGV in this function but that is to be expected
(see lots of discussion in the cygwin mailing list about this) and there
are patches pending for gdb which will work around this behavior.

So, sorry, but I doubt that this is actually your problem.

cgf

>CVS DIFF FILE:
>Index: cygwin/thread.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
>retrieving revision 1.196
>diff -u -p -r1.196 thread.cc
>--- cygwin/thread.cc    6 Feb 2006 18:24:06 -0000    
> 1.196
>+++ cygwin/thread.cc    2 Mar 2006 18:06:50 -0000
>@@ -122,6 +122,9 @@ verifyable_object_isvalid (void
>const *
>   if (efault.faulted ())
>     return INVALID_OBJECT;
>
>+  if(!object || !*object)
>+     return INVALID_OBJECT;
>+
>   if ((static_ptr1 && *object == static_ptr1) ||
>       (static_ptr2 && *object == static_ptr2) ||
>       (static_ptr3 && *object == static_ptr3))
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis
--- Christopher Faylor
<[hidden email]> wrote:

> The "efault.faulted()" two lines above your change
> is supposed to catch
> NULL dereferences.  I suspect that you were probably
> misled by the fact
> that gdb might show a SEGV in this function but that
> is to be expected
> (see lots of discussion in the cygwin mailing list
> about this) and there
> are patches pending for gdb which will work around
> this behavior.
>
> So, sorry, but I doubt that this is actually your
> problem.
>
> cgf
>

Christopher,

Actually, as far as I can see, the "efault.faulted()"
does NOT catch the NULL dereference, unless it is
confused about where to return. If it did, the code I
added should not stop my program from crashing. I will
go back and look into this further, though, to see if
I have missed something.

Thanks for your time.

Gary

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Christopher Faylor-2
On Fri, Mar 03, 2006 at 09:13:53AM -0800, Gary Zablackis wrote:

>--- Christopher Faylor
><[hidden email]> wrote:
>
>>The "efault.faulted()" two lines above your change is supposed to catch
>>NULL dereferences.  I suspect that you were probably misled by the fact
>>that gdb might show a SEGV in this function but that is to be expected
>>(see lots of discussion in the cygwin mailing list about this) and
>>there are patches pending for gdb which will work around this behavior.
>>
>>So, sorry, but I doubt that this is actually your problem.
>>
>>cgf
>
>Actually, as far as I can see, the "efault.faulted()" does NOT catch
>the NULL dereference, unless it is confused about where to return.  If
>it did, the code I added should not stop my program from crashing.  I
>will go back and look into this further, though, to see if I have
>missed something.

You have missed how efault.faulted() is supposed to be operating and,
AFAICT, *does* operate throughout the Cygwin DLL.  It really is supposed
to be catching NULL dereferences.

It's possible of course, that there is something wrong with efault.faulted()
but that doesn't mean we need to extra code around efault.faulted.  It means
that efault.faulted needs to be fixed.

i.e., we need to fix the problem not the symptom.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis
--- Christopher Faylor
<[hidden email]> wrote:

> You have missed how efault.faulted() is supposed to
> be operating and,
> AFAICT, *does* operate throughout the Cygwin DLL.
> It really is supposed
> to be catching NULL dereferences.
>
> It's possible of course, that there is something
> wrong with efault.faulted()
> but that doesn't mean we need to extra code around
> efault.faulted.  It means
> that efault.faulted needs to be fixed.
>
> i.e., we need to fix the problem not the symptom.
>
> cgf
>
I did some more research over the weekend and my
problem seems to only come when loading a dll via
dlopen() and run_ctors() is called from dll:init() and
pthread_key_create() is called during the time that
run_ctors() is active. I still have not found who is
calling pthread_key_create(), but will be working on
this as time permits this week.

It's been several years since I did any assembly
language coding, so I have to study what's going on
when efault.faulted() returns non-zero - and figure
out how to get gdb to step through the assembly code.

Thanks,
Gary

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Brian Dessent
Gary Zablackis wrote:

> I did some more research over the weekend and my
> problem seems to only come when loading a dll via
> dlopen() and run_ctors() is called from dll:init() and
> pthread_key_create() is called during the time that
> run_ctors() is active. I still have not found who is
> calling pthread_key_create(), but will be working on
> this as time permits this week.

If you are trying to track down why you get a SIGSEGV in
pthread_key_create while running your app in gdb you are wasting your
time.  This is not a fault, it is expected and normal.  Search the
archives.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis
--- Brian Dessent <[hidden email]> wrote:

> If you are trying to track down why you get a
> SIGSEGV in
> pthread_key_create while running your app in gdb you
> are wasting your
> time.  This is not a fault, it is expected and
> normal.  Search the
> archives.
>
> Brian
>

In this case, the fault is NOT normal: instead of
returning to pthread_key_create(),
verifyably_object_isvalid() crashes.

Normally, verifyably_object_isvalid() catches the
fault and returns INVALID_OBJECT to
pthread_key_create().

The crash I have occurs when loading a dll via
dlopen() and the cygwin dll intialization code calls
dll:init() which calls
run_ctors()  which calls (eventually)
pthread::once() which calls
init_routine() and init_routine() happens to be
fc_key_init().
fc_key_init() sets up the pthread_key_t object, calls
_sigfe_pthread_key_create() which jumps into
pthread_key_create() which calls
verifyably_object_isvalid() and we crash.
------------------------------------------------
I think that what is happening is that if one
dlopen()s a dll that is created with -lstdc++, the dll
initialization code called by the cygwin
initialization code has a bug in it. If ANY dll which
is created with -lstdc++ is LINKED into the
executable, everything gets initialized properly and
pthread_key_create() catches the SIGSEGV and continues
normally.

Here is a simplified test to show what is going on:

------Simple script to put everything together:
#!/bin/sh
#NOTE: add -DHARDLINKTEST to ct.c compile to get
#      a non-crashing exe
#1st dll to be dlopen()ed only:
gcc -DDEBUG -gstabs+ -g3 -fno-strict-aliasing -Wall -c
CrashTest.cc -o CrashTest.o
g++ -shared  ./CrashTest.o -o CrashTest.dll -lstdc++

#2nd dll to linked directly by exe
gcc -DDEBUG -gstabs+ -g3 -fno-strict-aliasing -Wall -c
Crash2.cc -o Crash2.o
g++ -shared -Wl,--out-implib=libCrash2.dll.a
-Wl,--export-all-symbols -Wl,--enable-auto-import
-Wl,--whole-archive Crash2.o -Wl,--no-whole-archive -o
Crash2.dll -lstdc++

#3rd dll without -lstdc++
gcc -DDEBUG -gstabs+ -g3 -fno-strict-aliasing -Wall -c
OK.cc -o OK.o
g++ -shared  ./OK.o -o OK.dll -lstdc++

#exe test program
gcc -DDEBUG -gstabs+ -g3 ct.c -o ct.exe -L./ -lCrash2


------Code for exe (ct.c):
#include <windows.h>
#include <winbase.h>
#include <stdio.h>
extern void test();   /* test function in dlls */

void TestLinked(char* pszdll);
void TestLoad(char* pszdll);

int main(int argc, char** argv)
{
    int     ret;
/* NOTE: -DHARDLINKTEST in makefile if you want this
         to run
 */
#ifdef HARDLINKTEST
    TestLinked("./Crash2.dll");
#endif
    TestLoad("./OK.dll");
    TestLoad("./CrashTest.dll");

    printf("THAT'S ALL FOLKS\n");
}


#ifdef HARDLINKTEST
void TestLinked(char* pszdll)
{
    printf("Testing build time linked %s\n", pszdll);
    _Z4testv(); /* call test() in dll - real code
would
                   have __declspec(dllexport), etc and
                   extern "C" syntactic sugar
                 */
}
#endif

typedef UINT (CALLBACK* LPFNDLLFUNC1)(DWORD,UINT);

void TestLoad(char* pszdll)
{
    printf("dlopening %s\n", pszdll);

    HANDLE  hDLL = (HANDLE)dlopen(pszdll);

    if(hDLL){
        printf("Getting proc address for test\n");

        LPFNDLLFUNC1    lpfnDllFunc1 =
(LPFNDLLFUNC1)GetProcAddress(hDLL,
                                                     
             "_Z4testv");

        if (!lpfnDllFunc1){
            // handle the error
            printf("Failed to get the function: %d\n",
GetLastError());
            FreeLibrary(hDLL);
            return;
        }
        else {
            // call the function
            printf("Calling test\n");
            UINT uReturnVal = lpfnDllFunc1(0,0);
            printf("Back from test\n");
        }
    }
    else
        printf("Error %d dlopening %s\n",
GetLastError(), pszdll);
}

------Code for 1st dll (CrashTest.cc):
#include <iostream>
using namespace std;

void test()
{
        cout << "\tCRASHTEST: This is a test." << endl
<< "Did you crash?" << endl;
}

------Code for 2nd dll (Crash2.cc):
#include <iostream>
#include "Crash2.h"
using namespace std;
void test()
{
        cout << "\tCRASH2: This is a test." << endl <<
"Did you crash?" << endl;
}
------Code for 3rd dll (OK.c):
#include <windows.h>
#include <stdio.h>
void test()
{
        printf("\tOK: This is a test.\n");
}

----------------------------------------------
NOTE: I have also tested all of this with
      __declspec(dllexport) and
      __declspec(dllimport)
      and everything works exactly the same

Thanks,
Gary


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Christopher Faylor-2
On Thu, Mar 09, 2006 at 07:04:23AM -0800, Gary Zablackis wrote:
>--- Brian Dessent <[hidden email]> wrote:
>>If you are trying to track down why you get a SIGSEGV in
>>pthread_key_create while running your app in gdb you are wasting your
>>time.  This is not a fault, it is expected and normal.  Search the
>>archives.
>
>In this case, the fault is NOT normal: instead of returning to
>pthread_key_create(), verifyably_object_isvalid() crashes.

We've moved out of the realm of a "patch" here.  Please use the main
cygwin list to report and diagnose problems.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

Gary Zablackis
--- Christopher Faylor
<[hidden email]> wrote:


> We've moved out of the realm of a "patch" here.
> Please use the main
> cygwin list to report and diagnose problems.
>
> cgf
>

OK

Thanks,
Gary

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com