Subject: Re: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes
From: "Elliott Hughes" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 4 Oct 2007 18:41:58 -0700 (PDT)
List-Id: <cygwin.cygwin.com>

On Thu, October 4, 2007 16:33, Lewis Hyatt wrote:
>> $ cat ex.cpp
>> #include <stdexcept>
>> int main() { try { throw new std::exception(); } catch (const
>> std::exception& ex) {
>> return 1; }
>> return 0; }
>>
>
> You are throwing a pointer and trying to catch a reference, so the
> exception never gets caught at all, which causes the program to abort. You
> should should do
>
> throw std::exception();
>
> instead.
>
> -Lewis

sorry, that was a Javaism that slipped into my test case. the real code
does throw by value and catch by const reference. as you say, though, if i
change the test case, it doesn't crash.

here are the relevant snippets:

extern "C" JNIEXPORT void JNICALL
Java_terminator_terminal_PtyProcess_sendResizeNotification(JNIEnv* env,
jobject instance, jobject a0, jobject a1) {
    try {
        terminator_terminal_PtyProcess proxy(env, instance);
        proxy.sendResizeNotification(a0, a1);
    } catch (const std::exception& ex) {
        translateToJavaException(env, "java/io/IOException", ex);
    }
}

void terminator_terminal_PtyProcess::sendResizeNotification(jobject
sizeInChars, jobject sizeInPixels) {
        throw std::exception();
}

i'm not throwing across shared library boundaries, but i am throwing
within shared library code. (obviously sendResizeNotification usually has
more content, but i've pulled the real content out to try to move closer
to a useful test case.)

i can remove the method call, too. this also crashes:

extern "C" JNIEXPORT void JNICALL
Java_terminator_terminal_PtyProcess_sendResizeNotification(JNIEnv* env,
jobject instance, jobject a0, jobject a1) {
    try {
        throw std::exception();
    } catch (const std::exception& ex) {
    }
}

taking the pc from the JVM crash log:

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x610b48b6, pid=3112,
tid=1244

and the output of "nm cygwin1.dll | sort" suggests we're in
pthread_key_create:

610b47a0 T _pthread_key_create
610b4980 T __ZN11pthread_keyC2EPFvPvE

but i don't know that isn't just an implementation detail. (certainly i
get a lot of seemingly irrelevant matches if i search the web.)

-- 
Elliott Hughes, http://www.jessies.org/~enh/

--
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/