Modification of a bug about C # XML serialization

Original: Modification of a bug about C # XML serialization

Modification of a bug about C # XML serialization

In my previous blog, I mentioned the use of XML serialization as a database scheme, @ Take the pen with caution when they are serialized with XML, there is a serious bug, that is, the XML is not closed, the system does not load the XML correctly. In my development experience, I have also encountered such a problem. Now the description and solution of this bug is recorded below, also for the friend who encountered this bug reference.

Bug Description

The appearance of this bug is also very strange, we give the customer a system, the system will write the data into n XML files, there is no problem under normal circumstances. Until one day ... The client runs the program one day, to get off work, to save the data to the database; the next day came to work, suddenly found that the data are not, that is, yesterday day work White did.

When the customer told me the bug, my first reaction was to reproduce the bug. Since the same system n has been running for a year, there has never been a problem. As a result, the customer tested again on the same machine and did not encounter this problem. I thought the bug was accidental and didn't deal with it, and the nightmare started.

When the customer put the system into the production system, occasionally this problem occurs in the production system, each occurrence of this problem, basically delayed the work of the day, the loss is n million, when the pressure is huge, hurriedly tied to the scene to solve the problem.

I found that this bug did not occur before because the amount of data used was very small, but this version of the data is very large. I looked at the data file and found that it was caused by a part of the end of the XML file missing. If a > is lost, the XML is not loaded correctly and the data is lost.

Solutions 1

Now that the problem is fixed, there is a solution. Every time I finish writing the data, I reload the data to verify correctness, and if not, write the data again. With this idea, I quickly changed the version, deployed to the production environment. (The test environment is hard to re-error).

However, the problem is still unresolved, and one months later, the same problem has arisen. It seems necessary to find the root cause and not trickery solve the problem.

Solutions 2

I started Google this issue, and finally found on StackOverflow: XDocument save adding extra characters. His description is that the XML will increase the character and my problem is that it will reduce the characters.

The original XML is written in the following way:

config.Save(new FileStream(@"c:\foo.xml", FileMode.Create, FileAccess.Write), SaveOptions.None);

should read

using (FileStream fs = new FileStream(@"C:\foo.xml", FileMode.Truncate, FileAccess.Read)){    config.Load(fs);}

The main change is to change the filemode.create to Filemode.truncate.

Use Filemode.truncate-Your write FileStream so, the file is truncated to 0 bytes before you start writing to it.

This plan seems to be reliable, however, I still do not rest assured.

Solutions 3

To prevent problems again, I wrote a Fixerrorxmlfile method that solves the problem of removing XML multi-character, and calls this method to fix the XML error every time the XML is loaded, if an error occurs. The core code is as follows:

  private static bool ReadFile (string filePath, out string realcontent) {string content = string.            Empty; Realcontent = string.            Empty; using (FileStream fs = new FileStream (FilePath, filemode.truncate)) {using (StreamReader sr = n EW StreamReader (FS)) {content = Sr.                ReadToEnd (); }}///First, to find the index value of ' > ' (that is, the first right angle bracket) at the end of the file header index1, if the value of index1 is less than 1, the description ' > ' does not exist, jump out: otherwise go down//Then, find the root      The index value of ' < ' on the left side of the element index2, similarly, if ' < ' exists to continue down execution//find the index value of the first ' > ' on the right of the root element index3 and the index value of the first ' index4// Compare index3 and index4, smaller is the index of the first element to the right of the root element//Find the name of the root element///And then find the beginning of the last matching root element name Index5//Last , determine the index value of the first ' > ' on the right side of the root element to get the real content of the file realcontent int index1 = content.            IndexOf (' > ');            if (Index1 < 1) {return false; } int index2 = content.       IndexOf ("<", index1);     if (Index2 < 1) {return false; } int index3 = content.            IndexOf (">", Index2); int index4 = content.            IndexOf ("", index2); int index = INDEX3 < index4?            index3:index4; String rootname = content.            Substring (Index2 + 1, index-index2-1); int index5 = content.            LastIndexOf (Rootname);            if (Index5 < 1) {return false;            } index5 + = Rootname.length; realcontent = content.            Substring (0, index5 + 1);        return true; }

Postscript

I have also modified solution 2 and Solution 3, and put it in the production system again. A year passed and there was no such bug. this year refers to the simultaneous operation of 5 machines.

Then I looked again, as if my solution 3 didn't work at all and never entered this function. In other words, Solution 2 has solved this problem.

Although this problem has not been reproduced, I still do not think that this problem has been solved perfectly. I think this is a Microsoft bug, in the case of normal application serialization of the loss of data, should be resolved by Microsoft, rather than the use of other patches to solve the problem. Microsoft has encountered several similar bugs.

In short, this problem is solved, and hope to meet the similar problems of people to help. You are also welcome to point out my question.

Reference:

Http://www.cnblogs.com/wardensky/p/4170605.html

My colleague was documenting the problem: XML storage bugs

Modification of a bug about C # XML serialization