This is kind of dangerous I think. The signal handler should be changed from
libcurl's back to the old one as a single operation, or eventually you'll
get a signal in the intervening time that will kill your process off.

> -----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 5:16 PM
> To: libcurl development; Mohun Biswas
> Subject: RE: libcurl in JNI context
>
>
> 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-16