This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: rxvt SEGV (Win98, 1.1.5s/2000-10-08)


On Mon, Oct 16, 2000 at 11:28:58PM -0400, Jonathan Kamens wrote:
>(Note: I do not subscribe to the "cygwin" list.  If you send a
>response to this message, please make sure to CC me at jik@curl.com.
>Thank you.)
>
>>  Date: Sat, 14 Oct 2000 00:17:43 +0100
>>  From: David Starks-Browning <starksb@ebi.ac.uk>
>>  
>>  On Thursday 12 Oct 00, Chris Faylor writes:
>>  > On Wed, Oct 11, 2000 at 10:45:42PM +0100, David Starks-Browning wrote:
>>  > >I've run Bub's rxvt-2.7.2-w32c from <http://www.io.com/~bub/rxvt.html>
>>  > >on Win98 without problem, under Cygwin-1.1.4.  With the 2000-10-08
>>  > >snapshot, rxvt now crashes with a stackdump upon exit.  Other than
>>  > >that, it works OK.
>>  > 
>>  > I've checked in a fix for this.
>>  
>>  Thanks Chris, I just checked it against the 2000-10-12 snapshot and
>>  the problem is gone.
>
>Alas, it just got worse for us on Windows NT 4.0.  The 20001012,
>20001013 and 20001014 snapshots all die horrible deaths with multiple
>"handle_exceptions" errors when we drop them into place on top of
>Cygwin 1.1.4 and try to run builds of our product, which use a GNU
>autoconf configure script and GNU make.
>
>I suspect that the fact that we run our builds on multiprocessor
>machines has a lot to do with this.
>
>What can we do to help get this problem debugged and fixed?

You can help by dropping the "horrible deaths" hyperbole and provide the
actual output that you're seeing.  I appreciate that you are willing to
help, but I don't understand why you didn't take at least an initial stab
at providing some details to your problem.

If you're really motivated, you can build cygwin yourself and set
CYGWIN=error_start=x:/path/to/gdb.exe .  This will cause cygwin to pop
up a gdb window when it encounters an error.  If you then issue the
following commands:

    thread 1
    bt

It should be a little clearer what is going on.

Barring that, strace output would also probably help pinpoint the problem:

strace -om:/tmp/strace.out make

(this will probably be a big file) Please do this with the most recent
snapshot.  That would be 2000-10-16.

My main development machine is 300MHZ P2 SMP, so it's not just as simple
as this being an SMP problem.

You can also provide 'cygcheck -r -s -v' output.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]