<html>
<head>
<base href="http://www.jacorb.org/bugzilla/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - BufferManager gives bad buffers"
href="http://www.jacorb.org/bugzilla/show_bug.cgi?id=958">958</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>BufferManager gives bad buffers
</td>
</tr>
<tr>
<th>Product</th>
<td>JacORB
</td>
</tr>
<tr>
<th>Version</th>
<td>3.3
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>major
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>ORB
</td>
</tr>
<tr>
<th>Assignee</th>
<td>jacorb-bugs@lists.spline.inf.fu-berlin.de
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mesnier_p@ociweb.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=419&action=diff" name="attach_419" title="Buffer manager diff">attachment 419</a> <a href="attachment.cgi?id=419&action=edit" title="Buffer manager diff">[details]</a></span>
Buffer manager diff
The application was choking when a stream became corrupt, forcing socket
closure and loss of message. The stream was corrupted because a previous read
request had a buffer too small for desired read. That previous read had pulled
the GIOP message header and determined the message length which was between
2^18 and 2^19 bytes. The reader went to the buffer manager, which correctly
determined a buffer from slot 18 was needed, and slot 18 had an available
buffer. Unfortunately the actual size of that buffer was 0x5A000 rather than
the expected 0x7FFFF, and thus insufficient for the necessary read.
The problem is that somehow a buffer was offered to the buffer manager that
stored it in the appropriate slot, but without checking that the actual size of
the returned buffer actually met the criteria for that slot.
The source of the bad buffer was the CDROutputStream class. In this case, the
user had obtained one from the ORB, then used setBuffer() to supply a buffer
into which the data was marshaled but then when done, the buffer was returned
to the buffer manager.
The solution is 2 fold. First, the buffer manager should validate the size of
returned buffers. Second, the CDROutputStream should have a sense of buffer
ownership.
Addressing the buffer manager is straight forward. The CDROuputStream's buffer
ownership is a little trickier. I think the easiest solution would be to add an
overloaded setBuffer method that takes an explicit ownership flag indicating
that the stream can return the buffer to the manager or not. The existing 1-arg
call would be the same as the 2-arg call with the second argument true:
The only risk is that if the externally set buffer were insufficient for the
data being marshaled, the check() method would grow the buffer discarding the
original.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>