Weird, read() on a socket should return as soon as *any* data is available,
not wait until the entire buffer can be filled. Have you set some unusual
flags on your socket which may be causing it to behave this way?
On Thu, Feb 25, 2010 at 5:20 PM, Patrick <schultz.patr...@gmail.com> wrote:
> When I construct a new CodedInputStream:
> this->fd = sock.impl()->sockfd();
> ZeroCopyInputStream *raw_input = new FileInputStream(this->fd);
> this->input = new CodedInputStream(raw_input);
> It hangs in the constructor. I ran a backtrace and can see that it is
> hanging in the Refresh().
> From my client side:
> int fd = sock.impl()->sockfd();
> ZeroCopyOutputStream *raw_output = new FileOutputStream(fd);
> CodedOutputStream *output = new CodedOutputStream(raw_output);
> uint32 tag = WireFormatLite::MakeTag(Stream::kRFieldNumber,
> printf("Writing tag [%x]\n", tag);
> int i =0;
> while (i<2050)
> The backtrace to the hang:
> #0 0xffffe524 in __kernel_vsyscall ()
> #1 0xb7de999b in read () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0xb7eb928a in
> (this=0x807b71c, buffer=0x807cc48, size=8192)
> at google/protobuf/io/zero_copy_stream_impl.cc:141
> #3 0xb7e4dc70 in
> google::protobuf::io::CopyingInputStreamAdaptor::Next (
> this=0x807b730, data=0xbfb08204, size=0xbfb08200)
> at google/protobuf/io/zero_copy_stream_impl_lite.cc:238
> #4 0xb7eb836e in google::protobuf::io::FileInputStream::Next
> data=0xbfb08204, size=0xbfb08200)
> at google/protobuf/io/zero_copy_stream_impl.cc:89
> #5 0xb7e4ba69 in google::protobuf::io::CodedInputStream::Refresh (
> this=0x807b758) at google/protobuf/io/coded_stream.cc:492
> #6 0x0805dacf in CodedInputStream (this=0x807b758, input=0x807b718)
> at /usr/local/include/google/protobuf/io/coded_stream.h:1056
> #7 0x0805c961 in Connection (this=0x807c500, so...@0xbfb082c0)
> at src/Connection.cc:56
> I noticed that the Read() in the bt has size set to 8192. So I got
> curious and sent enough tags to hit this size limit. As soon as it
> receives this much data, the code proceeds.
> According to a previous post:
> you indicated that it should only block if there is no data available.
> This is obviously not the case.
> Any idea where I'm going wrong? It looks pretty simple to me.
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at