Ok I found the problem...

The signal handler for SIGPIPE is changed after the curl_easy_perform call to a default one, which happens to kill the process.

I fixed it by saving the current signal handler before curl_easy_perform and then restore it after. The problem then went away.

Thanks,
Andy

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se]On Behalf Of Lai, Andy
Sent: Thursday, July 14, 2005 1:07 PM
To: Mohun Biswas; libcurl development
Subject: RE: libcurl in JNI context

This is due to a mixed architecture we currently have...

Our C module (which uses libcurl to POST HTTP request) can be linked by other C/C++ programs.

And then we have a java wrapper around that module so that it can be used by java program as well. And the java program has no knowledge about the HTTP request at all.

Here is the last part of what I got from truss.. Apparently EPIPE and EINTR happens just before the process dies. Other than that, I'm not sure how I can make more sense out of it.

13.2787 getsockopt(84, 65535, 8192, 0xFEE0B250, 0xFEE0B248, 0) = 0
13.2796 fcntl(84, F_GETFL, 0x00000000) = 2
13.2803 fstat64(84, 0xFEE0B150) = 0
13.2812 lwp_cond_broadcast(0x0032CEF0) = 0
13.2818 lwp_cond_wait(0x0032CEF0, 0x0032CED8, 0x00000000) = 0
13.2824 lwp_mutex_wakeup(0x0032CED8) = 0
13.2826 getsockopt(84, 65535, 8192, 0xFEE0B250, 0xFEE0B248, 0) = 0
13.2832 lwp_mutex_lock(0x0032CED8) = 0
13.2840 lwp_mutex_wakeup(0x000D2948) = 0
13.2839 fstat64(84, 0xFEE0B150) = 0
13.2846 lwp_mutex_lock(0x000D2948) = 0
13.2852 getsockopt(84, 65535, 8192, 0xFEE0B250, 0xFEE0B24C, 0) = 0
13.2859 setsockopt(84, 65535, 8192, 0xFEE0B250, 4, 0) = 0
13.2866 fcntl(84, F_SETFL, 0x00000082) = 0
13.2872 read(84, 0xFEE0B964, 16) Err#11 EAGAIN
13.2879 setsockopt(21, 6, 1, 0xEF1814F0, 4, 1) = 0
13.2890 send(19, " H T T P / 1 . 1 4 0 4".., 1236, 0) Err#32 EPIPE
13.2888 poll(0xEF180AE8, 1, 20000) = 1
13.2898 signotifywait() = 13
13.2906 Received signal #13, SIGPIPE, in accept() [caught]
13.2904 lwp_sigredirect(1, SIGPIPE, 0xFF00FC6C) = 0
13.2913 accept(10, 0xFFBED18C, 0xFFBED1AC, 1) Err#4 EINTR
13.2920 sigaction(SIGPIPE, 0xFFBECC38, 0x00000000) = 0
13.2921 read(21, " G E T / a d m i n c o".., 4096) = 584
13.2931 sigprocmask(SIG_SETMASK, 0xFF37CFB8, 0x00000000) = 0
13.2938 sigprocmask(SIG_SETMASK, 0xFF388CE0, 0x00000000) = 0
13.2945 setcontext(0xFFBECB18)
13.2953 send(19, " H T T P / 1 . 1 4 0 4".., 1236, 0) Err#32 EPIPE
13.2960 signotifywait() = 13
13.2966 lwp_sigredirect(1, SIGPIPE, 0xFF00FC6C) = 0
13.2967 poll(0xF9781B68, 0, 50) = 0
13.2973 Received signal #13, SIGPIPE, in accept() [default]
13.2979 accept(10, 0xFFBED18C, 0xFFBED1AC, 1) Err#4 EINTR
        *** process killed ***
~

Thanks
Andy

-----Original Message-----
From: Mohun Biswas [mailto:m_biswas_at_mailinator.com]
Sent: Thursday, July 14, 2005 12:58 PM
Cc: Lai, Andy
Subject: Re: libcurl in JNI context

1. Since the problem happens on Solaris, use truss instead of strace.
2. Is there a reason to use libcurl instead of the native HTTP client
support in Java, or even the Apache Commons HTTP client
(<http://jakarta.apache.org/commons/httpclient/>)? Libcurl is a great
piece of code but it's rarely smart to link JNI code into a JVM when the
same functionality is available as safe bytecodes. If bytecodes fail you
get a nice exception with a backtrace you can analyze; if JNI code fails
you have the problem you have now.

Lai, Andy wrote:

> OS is actually the most interesting part. The problem happens only on
> solaris so far. I was not able to reproduce it on windows, linux, and
> aix.
>
> And the same problem happens with libcurl 7.12.2, 7.13.1, and 7.14.0.
>
> I think strace is a good idea... only problem is that doing strace
> against java (tomcat) can be very tricky, as you said.
>
> If strace does not give me much info, I will debug libcurl.
>
> Thanks,
> Andy
>
>
> -----Original Message-----
> From: curl-library-bounces_at_cool.haxx.se
> [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
> Sent: Wednesday, July 13, 2005 11:53 PM
> To: libcurl development
> Subject: Re: libcurl in JNI context
>
> On Wed, 13 Jul 2005, Lai, Andy wrote:
>
>
>>I ran purify and I did not see any memory corruption caused by
>
> libcurl. Yet
>
>>I do not understand why calling curl_easy_perform will cause JVM to go
>
> down
>
>>at a later point of time.
>>
>>Any help, suggestion, or advice is greatly appreciated.
>
>
> What OS? What libcurl version?
>
> I really think you should start figuring out the "goes down siliently"
> part.
> Why exactly does is stop. When you know that I think you have a better
> chance
> to understand or figure out what libcurl's part in that might be.
>
> Personally I like using 'strace' or similar to figure out such things,
> but in
> a server environment like this it might be tricky.
>
> And no, I don't have any sensisble ideas why this happens, but then JVMs
> are
> not within my area of expertise.
>
Received on 2005-07-15