Those weird bugs

We can't say that all bugs are paper tigers, but often the seemingly weird bugs are caused by very simple reasons. They annoy you for a while, but when you find the truth, you can't help but laugh. What is a weird bug? My definition is: the code logic is the same, but it works at A, but not at B, or the same type of ABC is good, but not at D. In the end, the problem is not in the code logic, but often in configuration, permissions or other places outside the business logic.

The local machine is ok, but the server is not working. Blame me.

Case 1: After the local project was modified, it was pushed to the server, but after a while, the tester called again, "It still doesn't work, try again." I frowned, how could it be possible? I ran it again, and it was OK. Then I pushed it to the server and ran it again, and it was OK. Only the ccnet continuous integration compilation could not pass. I scratched my head and thought for a long time. I found that the debug version was just run, while ccnet ran the Release version. And it was wrong because some configurations were written for Debug but not for Release.

Summary: Don't make the wrong changes from the beginning. In addition to debug and Release, there are many versions in git, such as master, release, prelease, newFunction, etc. If you make a mistake, it may cause greater trouble.

Case 2: I modified the function according to the customer's requirements. Before putting it on the cloud server, I would publish it in the local IIS to confirm it passed. But one time, I suddenly found that I had to log in and authenticate every time I accessed it. As shown in the figure below:

I clearly set anonymous access, and granted IUSR_xxxx, Everone, and various permissions, but it just doesn't work. The local version is IIS7, and the server is IIS6, so what difference does that make? But other websites in the same directory are all ok. I configured the website normally, but it didn't work, and redeploying didn't solve the problem. Then I searched and read various posts, thinking that it must be related to permissions, maybe a certain file, or maybe the configuration of webconfig, but I found that it still didn't work. In the middle of the night, I stared at the screen silently. Outside the window, the autumn wind blew, and inside the room, my roommate was already asleep.

[[154475]]

Suddenly, I had an idea. A blog said that the IUSR_xxx account may not have AD permissions, and an account with permissions needs to be set up in the anonymous user place. I changed it to xxxx/Adminstrator, and it worked. But why is it like this? The anonymous user of other websites is IUSR_xxx and it works fine. Will there be any problems? The phenomenon is solved, but the real cause of the problem has not been found. Maybe it is a certain program or a certain file. I will continue to follow up.

Summary: Individuals who are similar on the surface still have their own differences. But this problem only solves the phenomenon, not the essence.

Case 3: This problem is really weird. My colleague asked me that he couldn't call the webservice. It was fine in the morning, but it reported a 407 proxy error in the afternoon. But there is the old saying again: "I can call other services, and I can call them on other computers, but this computer suddenly doesn't work." He and I tested it again and again, and there was no problem with the API itself, the network, the computer, and the code, because it didn't come in at all. So what's the problem? Then his wife (yes, he and his wife sat together) accidentally opened app.config in VS. Then this file was automatically modified, and then the program was connected. I have encountered similar problems. I have a program that uses the XDocument.Save method to overwrite a file every time, but it always fails to overwrite successfully, even though vs prompts: "The file has been modified, do you want to reload the current file?" I clicked OK, but it still didn't change, but I deleted the file content. But it can be overwritten successfully. Then my colleague suggested that I change to File.WriteAllText method, and it worked.

Summary: Have you ever encountered that the XML file was not successfully modified? Or is it that the frequently changing files are not suitable for XML persistence?

EF is a joke

Here's the thing: in order to make the content display better in the table, I cut a longer piece of content, but found that all the places where it was used were changed, but when I looked in the database, there was no change.

 foreach (var note in notes)
 {
             var str = CommonHelper.StripHTML(note.Content);
 if (str.Length > 15 )
 {
                 note.Content = str.Substring( 0 , 12 ) + "..." ;
 }
 }

But it was not saved. But when I fished out another one, the content had changed.

 raw = _respository.GetNoteById(id);

But the database has not changed.

Then restart and visit the edit page first. The data is normal again, which is obviously affected by the previous method. Is the data cached? Later I found out that I was too clever to create a singleton, and the db inside the warehouse = xxDB.GetInstance(). As a result, because these two pages are the same context. The data is cached, resulting in the query object not coming from the database. At this time, if you save it, the other shortened content will also be saved in the database. The simplest way is db = new dbcontext();

Summary: This is purely a trouble caused by not understanding the mechanism of EF, which backfired.

ckeditor is not obedient

A colleague made a function to asynchronously load an edit box, and found that sometimes it can be loaded successfully, and sometimes it can't. Some pages can always be loaded, and some pages can never be loaded.

 <textarea class = "" name= "Content" id= "Content" > 
 
    CKEDITOR.replace( 'Content' ,
 {
 toolbar: ...
 });

Actually, for ckeditor, the parameter id or name after replace can also be used. But I found that the two parameters were different. After changing them to the same, they were both loaded successfully. Maybe some pages are interfering.

There are also some "magical phenomena" that I can't explain, so I won't mention them. But often these bugs will waste a lot of our time. Most of the problems that can find the cause have solutions. Problems that can't find the cause are the hardest to solve. Sometimes even if the phenomenon is solved, the cause of the problem may not be solved, so I am used to recording these things. If they appear once, they may appear again. This article is dedicated to those fragmented times when we debug bugs.