Possible DataCoruption by using StringBuilder?!?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The code below was coded to to take the xml that is sent to and from a Data
Object in our system and strip out any strange characters that may creap into
the xml that is received from a Mainframe system. The code works fine, except
that we noticed some data coruption happening in the system, and have
subsiquently confirmed that it was this peice of code.

The xml would just get corrupted. We had parameters called index that would
suddenly be named iindex. (Notice two i's) The coruption was totally random
though, and would occure in variuous places in the xml document.

I once had a similar situation using the a Byte array to ascii converter
also in the System.Text namespace that turned out to only convert the first
128 bytes and then wrapped for any byte values greater than this.

If anyone could shed some light on this I would seriously apreciate it.

Dim TempSreamReader As System.IO.StreamReader = New
System.IO.StreamReader(stmXML)
Dim TempString As New
System.Text.StringBuilder(TempSreamReader.ReadToEnd())
TempString = TempString.Replace("& ", "& ")

Dim FindValues() As Char =
System.Configuration.ConfigurationSettings.AppSettings("FindValues").ToCharArray()
Dim ReplaceValues() As Char =
System.Configuration.ConfigurationSettings.AppSettings("ReplValues").ToCharArray()
Dim c As Int32 = 0
For c = 0 To FindValues.Length - 1
TempString = TempString.Replace(FindValues(c),
ReplaceValues(c))
Next

stmXML.Position = 0
Dim TempStreamWriter As System.IO.StreamWriter = New
System.IO.StreamWriter(stmXML)
TempStreamWriter.Write(TempString.ToString())
stmXML.Position = 0
 
W1ld0ne74 said:
The code below was coded to to take the xml that is sent to and from a Data
Object in our system and strip out any strange characters that may creap into
the xml that is received from a Mainframe system. The code works fine, except
that we noticed some data coruption happening in the system, and have
subsiquently confirmed that it was this peice of code.

The xml would just get corrupted. We had parameters called index that would
suddenly be named iindex. (Notice two i's) The coruption was totally random
though, and would occure in variuous places in the xml document.
Click to expand...

It seems unlikely to me that it's actually a bug in StringBuilder. It's
hard to say more without some concrete code and a sample file, however.

When you say the corruption is totally random, do you mean that if you
give it the same file twice, it corrupts it in different places, or
just that you can't see any pattern in the corruption when giving it
different files?
I once had a similar situation using the a Byte array to ascii converter
also in the System.Text namespace that turned out to only convert the first
128 bytes and then wrapped for any byte values greater than this.
Click to expand...

That's understandable, as ASCII doesn't have any values over 127 - you
shouldn't be using it with bytes which are over 127.
 
This peice of code was added to a very high volume web site, so very
difficult to say if it would corrupt the same file in the same way. However,
we did not pick up this problem during testing (Aprox 3 users).

I noticed that StringBuilder is not threadsafe for instances. Could this be
the cause of the problem?
 
W1ld0ne74 said:
This peice of code was added to a very high volume web site, so very
difficult to say if it would corrupt the same file in the same way. However,
we did not pick up this problem during testing (Aprox 3 users).

I noticed that StringBuilder is not threadsafe for instances. Could this be
the cause of the problem?
Click to expand...

Well it would be if you were sharing the same StringBuilder between
different threads - are you doing that?
 
I do not have it in a shared method or anything. The code is in a .Net
assembly that is used by the entire site (ASP.Net and other assemblies)
directly. Does .Net spawn a new thread for every new user that connects to
the ASP.Net application or could multiple users share the same thread to this
code and thus cause data coruption?
 
W1ld0ne74 said:
I do not have it in a shared method or anything.
Click to expand...

What about stmXml? Is that shared, or is one created per request?
The code is in a .Net
assembly that is used by the entire site (ASP.Net and other assemblies)
directly. Does .Net spawn a new thread for every new user that connects to
the ASP.Net application or could multiple users share the same thread to this
code and thus cause data coruption?
Click to expand...

Well, multiple users could get the same thread, but not while one
request is processing. Each request gets a thread pool thread (I
believe - an ASP.NET expert could say whether it's the system thread
pool or something else), so two requests could use the same thread, one
request after another, but you won't have two requests active on the
same thread at the same time. (If you think about it, you couldn't.)
 
Or is this in a "module" ?

Showing the minimal account of code that exhibit the problem may help...

Patrice
 
Back
Top