[protobuf] CodedInputStream hanging in constructor

2010-02-25 Thread Patrick
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,
WireFormatLite::WIRETYPE_LENGTH_DELIMITED);
printf(Writing tag [%x]\n, tag);
int i =0;
while (i2050)
{
output-WriteTag(tag);
i++;
}

The backtrace to the hang:
#0  0xe524 in __kernel_vsyscall ()
#1  0xb7de999b in read () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7eb928a in
google::protobuf::io::FileInputStream::CopyingFileInputStream::Read
(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
(this=0x807b718,
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:
http://groups.google.com/group/protobuf/browse_thread/thread/6e9da43146339ee2/241f0aa64c4c80ca?lnk=gstq=codedinputstream#241f0aa64c4c80ca

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 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.



Re: [protobuf] CodedInputStream hanging in constructor

2010-02-25 Thread Kenton Varda
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,
 WireFormatLite::WIRETYPE_LENGTH_DELIMITED);
printf(Writing tag [%x]\n, tag);
int i =0;
while (i2050)
{
output-WriteTag(tag);
i++;
}

 The backtrace to the hang:
 #0  0xe524 in __kernel_vsyscall ()
 #1  0xb7de999b in read () from /lib/tls/i686/cmov/libpthread.so.0
 #2  0xb7eb928a in
 google::protobuf::io::FileInputStream::CopyingFileInputStream::Read
 (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
 (this=0x807b718,
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:

 http://groups.google.com/group/protobuf/browse_thread/thread/6e9da43146339ee2/241f0aa64c4c80ca?lnk=gstq=codedinputstream#241f0aa64c4c80ca

 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
 protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/protobuf?hl=en.



-- 
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 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.