This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Yeah, you're right. But why is this thread getting a SIGPIPE? Shouldn't it be blocked?Sounds like write() is segfaulting for some reason, and the segv is being caught by libgcj's segv handler, which converts segv's into NullPointerExceptions.
From this stack trace, it looks to me as though write gets a SIGPIPE in9173, then the pthread_sighandler segv's trying to call the signal
handler, which sets off the segv handler in the runtime.
Oh, ok. My glibc manual must be too old to mention that. In that case, switching to send() is an option. But I'd like to understand why you're getting a SIGPIPE delivered in the first place.I don't think so. send() can potentially generate a SIGPIPE just like write(), according to my glibc docs.
The send() manpage mentions a MSG_NOSIGNAL option. I was under the impression that it pretty much ment no SIGPIPEs. It's not very clear as to whether that's the case or if there are other cases which may generate the signal that are not covered by the option.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |