[
https://issues.apache.org/jira/browse/THRIFT-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858954#comment-13858954
]
Branden Visser edited comment on THRIFT-1754 at 12/30/13 5:44 PM:
------------------------------------------------------------------
Speaking to this issue specifically, if a blob of data came in that ended one
frame and started another, but an exception was thrown by the consumer callback
when the frame was ended (therefore the next frame is not started), then the
next blob of data that comes in will think it is starting a frame, but in
reality there is a frame in progress!
So it reads the first 4 bytes of that data and it could be some huge number,
1.7 billion, then it tries to allocate a buffer of that size and you end up
with the error.
Another exception can occur in similar scenarios:
RangeError: targetStart out of bounds
at Buffer.copy (buffer.js:526:11)
at Socket.<anonymous>
(/opt/oae/node_modules/helenus/node_modules/helenus-thrift/lib/thrift/transport.js:72:14)
at Socket.EventEmitter.emit (events.js:95:17)
at Socket.<anonymous> (_stream_readable.js:746:14)
at Socket.EventEmitter.emit (events.js:92:17)
at emitReadable_ (_stream_readable.js:408:10)
at emitReadable (_stream_readable.js:404:5)
at readableAddChunk (_stream_readable.js:165:9)
at Socket.Readable.push (_stream_readable.js:127:10)
at TCP.onread (net.js:526:21)
was (Author: mrvisser):
Speaking to this issue specifically, if a blob of data came in that ended one
frame and started another, but an exception was thrown by the consumer callback
when the frame was started (therefore the next frame is not started), then the
next blob of data that comes in will think it is starting a frame, but in
reality there is a frame in progress!
So it reads the first 4 bytes of that data and it could be some huge number,
1.7 billion, then it tries to allocate a buffer of that size and you end up
with the error.
Another exception can occur in similar scenarios:
RangeError: targetStart out of bounds
at Buffer.copy (buffer.js:526:11)
at Socket.<anonymous>
(/opt/oae/node_modules/helenus/node_modules/helenus-thrift/lib/thrift/transport.js:72:14)
at Socket.EventEmitter.emit (events.js:95:17)
at Socket.<anonymous> (_stream_readable.js:746:14)
at Socket.EventEmitter.emit (events.js:92:17)
at emitReadable_ (_stream_readable.js:408:10)
at emitReadable (_stream_readable.js:404:5)
at readableAddChunk (_stream_readable.js:165:9)
at Socket.Readable.push (_stream_readable.js:127:10)
at TCP.onread (net.js:526:21)
> RangeError in buffer handling
> -----------------------------
>
> Key: THRIFT-1754
> URL: https://issues.apache.org/jira/browse/THRIFT-1754
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
> Affects Versions: 0.9
> Environment: Ubuntu 12.04, Node.js v0.8.8
> Reporter: Vesa Poikajärvi
> Priority: Minor
>
> I have a Node.js service that connects to multiple Thrift servers (using
> TFramedTransport with C++ servers and TBufferedTransport with Python
> servers). Every now and then for reasons rather hard to track the following
> happens:
> {noformat}
> buffer.js:242
> this.parent = new SlowBuffer(this.length);
> ^
> RangeError: length > kMaxLength
> at new Buffer (buffer.js:242:21)
> at Socket.TFramedTransport.receiver
> (/home/me/my_service/node_modules/thrift/lib/thrift/transport.js:59:17)
> at Socket.EventEmitter.emit (events.js:88:17)
> at TCP.onread (net.js:395:14)
> {noformat}
> Node module is extracted from Thrift 0.9 tarball due to THRIFT-1637. And as
> mentioned, I cannot really tell what triggers the behavior. When running in
> development mode I use [Forever|https://github.com/nodejitsu/forever] to
> relaunch a crashed process, and when it first crashes because of this it will
> keep relaunching a few times, maybe ten or so (I connect to the services upon
> startup), and then it starts working again.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
