[Mono-osx] OSX/x86 bug when chunking in machine.config in StreamReader

Sean Hignett seanhig at geminibay.com
Fri Mar 17 19:25:53 EST 2006


Hi folks, 

Re: the call for OSX86 testing.

I posted this in bugzilla as #77810.
http://bugzilla.ximian.com/show_bug.cgi?id=77810

I spent some time trying to figure out what was causing this, and I think I
have tracked it down (to a certain level)...  I used some hack
instrumentation to dig into the Exception that was coming out of
StreamReader.ReadToEnd() when I was trying to use XSP.

Below is the output from XSP as the first page is loaded, and it tries to
parse the machine.config.

xsp
Listening on port: 8080 (non-secure)
Listening on address: 0.0.0.0
Root directory: /usr/local/lib/xsp/test
Hit Return to stop the server.
Attempting a Read on: [Unknown]
Read: target buffer length (dest): 1024
ReadInternal: dest length: 1024, count: 1024
ReadSegment: adjusting count: [new] 0
ReadSegment: start read segment: buf_length: 0, buf_offset: 0, count: 0
ReadSegment: new buff_offset: 0
ReadInternal: ReadSegment returned n: 0
ReadInternal: copied was 0, now: 0
ReadInternal: count is now: 1024
ReadInternal: read as much as we can up to count: 1024
/usr/local/etc/mono/1.0/machine.config
creating the stream reader
About to call the streamreader
StreamReader.ReadToEnd: decoded_buffer.length: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 4096
ReadInternal: dest length: 4096, count: 4096
ReadSegment: adjusting count: [new] 0
ReadSegment: start read segment: buf_length: 0, buf_offset: 0, count: 0
ReadSegment: new buff_offset: 0
ReadInternal: ReadSegment returned n: 0
ReadInternal: copied was 0, now: 0
ReadInternal: count is now: 4096
ReadInternal: ** refilling buffer
ReadSegment: start read segment: buf_length: 8192, buf_offset: 0, count:
4096
ReadSegment: new buff_offset: 4096
ReadInternal: ReadSegment returned n: 4096
ReadInternal: returning copied to caller: 4096
StreamReader: created new buffer: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 4096
ReadInternal: dest length: 4096, count: 4096
ReadSegment: start read segment: buf_length: 8192, buf_offset: 4096, count:
4096
ReadSegment: new buff_offset: 8192
ReadInternal: ReadSegment returned n: 4096
ReadInternal: copied was 0, now: 4096
ReadInternal: count is now: 0
ReadInternal: count is 0 returning copied value to caller
StreamReader.ReadToEnd: len after Read : 4096
StreamReader.ReadToEnd: text : 4096
StreamReader: created new buffer: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 4096
ReadInternal: dest length: 4096, count: 4096
ReadSegment: adjusting count: [new] 0
ReadSegment: start read segment: buf_length: 8192, buf_offset: 8192, count:
0
ReadSegment: new buff_offset: 8192
ReadInternal: ReadSegment returned n: 0
ReadInternal: copied was 0, now: 0
ReadInternal: count is now: 4096
ReadInternal: ** refilling buffer
ReadSegment: start read segment: buf_length: 8192, buf_offset: 0, count:
4096
ReadSegment: new buff_offset: 4096
ReadInternal: ReadSegment returned n: 4096
ReadInternal: returning copied to caller: 4096
StreamReader.ReadToEnd: len after Read : 4096
StreamReader.ReadToEnd: text : 8192
StreamReader: created new buffer: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 4096
ReadInternal: dest length: 4096, count: 4096
ReadSegment: start read segment: buf_length: 8192, buf_offset: 4096, count:
4096
ReadSegment: new buff_offset: 8192
ReadInternal: ReadSegment returned n: 4096
ReadInternal: copied was 0, now: 4096
ReadInternal: count is now: 0
ReadInternal: count is 0 returning copied value to caller
StreamReader.ReadToEnd: len after Read : 4096
StreamReader.ReadToEnd: text : 12288
StreamReader: created new buffer: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 6488165
System.TypeInitializationException: An exception was thrown by the type
initializer for System.Runtime.Remoting.RemotingServices --->
System.ObjectDisposedException: The object was used after being disposed.
in <0x00446> System.IO.FileStream:Read (Sys

I believe it is related to the [in,out] parameter on the FileStream.Read
method for the destination buffer:

        public override int Read ([In,Out] byte[] dest, int dest_offset, int
count)
        {
            System.Console.WriteLine("Attempting a Read on: " + name);
            System.Console.WriteLine("Read: target buffer length (dest): " +
dest.Length);


This section of the output is what shows where the memory corruption occurs,
and what follows is exceptions (and SIGSEVs):
        
StreamReader: created new buffer: 4096
Attempting a Read on: /usr/local/etc/mono/1.0/machine.config
Read: target buffer length (dest): 6488165

The following (hacked up) code snippet shows the caller StreamReader loop
for chunking the file.  It gets about 3/4 into the file, reading it properly
(I can dump out the text StringBuffer and see the XML). For each chunk I had
it create a new dest buffer... The original code re-uses the same buffer, so
I tried this to see if it changed the outcome - and it didn't... With the
new buffer in hand it then attempts to pass it into the FileStream.Read():

            while (len > 0 || len == -1)
            {      
                buffer = new char [size];
                System.Console.WriteLine("StreamReader: created new buffer:
" + buffer.Length);
                
                len = Read (buffer, 0, size);
                System.Console.WriteLine("StreamReader.ReadToEnd: len after
Read : " + len);   

                if(len > 0)
                {
                    text.Append (buffer, 0, len);
                    System.Console.WriteLine("StreamReader.ReadToEnd: text :
" + text.ToString().Length);
                }
            }


what the output shows is that the destination buffer, when it is created, is
4096 as expected, but just after it has been passed into Read() it is some
obviously bogus length: 6488165.

This is likely something down in the core mem handling that is way beyond
me.  I assume it is related to the [in, out] param, as the buffer looks fine
just before the call.

Is anyone aware of this and working on it?  Anything more I can do?

Hope this helps - I really need mono to run on my MacBook :)




More information about the Mono-osx mailing list