By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,148 Members | 1,322 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,148 IT Pros & Developers. It's quick & easy.

Very bizzare code behaviour.

P: n/a
G'Day,

I have a simple peice of code behaving in a rather eratic manner.

outputStreams[(int)service] = new MemoryStream();
//.... some code to add values to the stream ...
bool ready = false;
//.... some code...
ready = (outputStreams[(int)service].Length > 0);

The last line of code is giving me extrodanary grivance so I put a
breakpoint on it.
When inspected at this breakpoint "outputStreams[(int)service].Length"
equates to 45.
Yet after the statement completes "ready" remains false.

"outputStreams" does not have anything else using it's name in a
different scope so the watch is definatly inspecting the variable in
the statement.

"ready" does not have anything else using it's name in a different
scope so the assignment is definatly inspecting the variable in the
statement. Yes ready is a local variable.

I can only think of two unlikely scenarios to explain this problem I am
facing.
1) The ">" operator does not like to compare a long value with the
expession "0".
2) The watch is given a eronious value when it reads the poperty
outputStreams[(int)service].Length and the code revices a another value
when calling the property.

Well if either of those two possibilites were true id be rather
suprissed.

Anyway for the paraniod I include a dump of the watch in question.

I just find this particular problem so bizzare I thought I'd share it.

-dm
- outputStreams[(int)service] {System.IO.MemoryStream} System.IO.MemoryStream
- System.IO.Stream {System.IO.MemoryStream} System.IO.Stream
+ System.MarshalByRefObject {System.IO.MemoryStream} System.MarshalByRefObject
CanRead true bool
CanSeek true bool
CanWrite true bool
Length 45 long
+ Null {System.IO.Stream.NullStream} System.IO.Stream
Position 45 long
+ _buffer {Length=256} byte[]
_capacity 256 int
_expandable true bool
_exposable true bool
_isOpen true bool
_length 45 int
_origin 0 int
_position 45 int
_writable true bool
CanRead true bool
CanSeek true bool
CanWrite true bool
Capacity 256 int
Length 45 long
MemStreamMaxLength 2147483647 int
Position 45 long

Apr 6 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
I just simplifiedied a bit to isolate the problem, I added this
statement.

long foobar = outputStreams[(int)service].Length;

Looking at watches before this new statement
foobar = undefined
outputStreams[(int)service].Length = 45

Looking at watches after this new statement
foobar = 0
outputStreams[(int)service].Length = 45

It's official I've broken my watch!

My dev enviroment is visual studio 2003. My os is winXP prof and I am
developing with full administarative privilages.

Anybodey seen this before. ever?

My best guess if that the get accesor code for "MemoryStream.Length "
does some sort of security check and returns 0 if the calling code
doesn't meat some condition.

In this whay the debuger might have sufficent privliges and my own code
(which created the streams) has lost privliges.

This guess is afdmitably very unlikely,

Smobody got a better Idea?

-dm

Apr 6 '06 #2

P: n/a


th*********@gmail.com wrote:
I just simplifiedied a bit to isolate the problem, I added this
statement.
You can make it even more debug-friendly:

int index = (int)service;
Stream outstream = outputStreams[index];
long len = outstream.Length;

Here you can verify each of the crucial assumptions:

- Is the code indexing right?
- Is the indexed stream correct?
Anybodey seen this before. ever?
I have seen something like it, it was due to a watch-expression mutating
the state by invoking a method -- be sure that's not what's hapeening to
you. You don't have a property that clears the stream and returns it's
former length, do you?

If your bug remains, reduce the amount of code running .. effectively
try and end up with something like:

public static int Main() {
MemoryStream m = new MemoryStream();
m.Write('xxx');
int len = m.Length;
}

which still produces your problem.
My best guess if that the get accesor code for "MemoryStream.Length "
does some sort of security check and returns 0 if the calling code
doesn't meat some condition.
That's not what's happening.
This guess is afdmitably very unlikely,


yes ;)

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Apr 6 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.