Bloodshot caused by a Buffer

Background

The current project needs to be: the server uses Servlet + JDBC technology to read content from the Oracle server and write it to the SQLite database file. The Android client downloads this file and uses it on the target Android system.

Problem Reproduction

The above requirement does not seem complicated, but after I download the generated database file, I cannot even execute basic SQL statements. For example, there is a table named t_name. When I execute the following code, the exception db is the SQLiteDatabase object opened from this file ):

Cursor cursor = db.rawQuery("select * from t_name", null);

Some exception stack information is as follows:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131229/12332350S-0.png "title =" ExceptionStack "alt =" 232411151.png"/>

Key code

The code for generating the Server File and the Code for reading the file from the Android client are very simple. Here, only part of the code for downloading the program is pasted:

// Source is the URLURLConnection conn of the target file = source. openConnection (); BufferedInputStream bis = new BufferedInputStream (conn. getInputStream (); // target is the target file name FileOutputStream fos = new FileOutputStream (target); byte [] buf = new byte [1024]; int read = 0; while (read = bis. read (buf)> 0) {fos. write (buf);} bis. close (); fos. close ();

Solution Process

1. First of all, I think it is just an accidental phenomenon. Uninstall the project, reinstall it, and there is no change.

2. Check whether the database is opened or closed because the image file has been damaged before, because the file is not closed after it is opened. This vulnerability does not occur after the code check is completed.

3. Check whether the generated database file is correct. Create a new Java SE project on the server and read the file using standard JDBC. Everything works.

4. transmission errors may occur when the database file is downloaded. Clear data and download again. The error message still exists.

5. Use the visual management tool SQLiteStudio to open the Server File and view the file content, which is completely normal. Use adb to send the downloaded file from the client back to the computer and open it. The following warning is displayed.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131229/1233234X0-1.png "title =" SQLiteStudio warning "alt =" 090509630.png"/>

6. Check the downloading program. I think there seems to be some problems in the buffer zone. I think there may be errors in the automatic submission of large batches of databases. If the buffer zone is larger, will it reduce the error probability? Considering that the actual size of the file to be downloaded is about 1024000 kb, the code of the above program was slightly changed, and the buffer size was changed to 1000, that is, kb, and the file was downloaded again. Then, looking at the downloaded file, I was shocked:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131229/123323DI-2.jpg "title =" files K in size "alt =" 090213890.jpg"/>

7. find the root cause of the problem. Since the buffer zone is too large, it is obvious that it should always be the last time in theory.) If the buffer zone is not fully read, the above Code also writes a blank character to the db file. Database image errors are hard to understand.

8. The modified code is as follows. Solve the problem after modification.

// Source is the URLURLConnection conn of the target file = source. openConnection (); BufferedInputStream bis = new BufferedInputStream (conn. getInputStream (); // target is the target file name FileOutputStream fos = new FileOutputStream (target); byte [] buf = new byte [1024]; int read = 0; while (read = bis. read (buf)> 0) {// This line of code is the key code fos. write (buf, 0, read);} bis. close (); fos. close ();

Summary

This Bug has plagued me for two days. In the end, I found a problem in the near-unexpected situation. I learned a lot and summarized the following points:

1. I didn't have a deep understanding of BufferedInput/OutputStream methods. I used to think that the write (byte [] buf) method is similar to the write (byte [] buf, int offset, int length) method, it is just a heavy load. The former is too lazy to pass parameters, so you can use it without thinking about it. We will pay attention to this issue in the future and treat the buffer zone with caution.

2. After this lesson, I deeply realized that the vast majority of standard library methods are "exist as reasonable. Before using a seemingly convenient method, you must know whether there is anything wrong.

3. We should not be lucky enough to doubt the network transmission problem. We should first start with ourselves. In fact, the probability of network transmission problems today is almost zero.
   

This article is from the "flying cat" blog, please be sure to keep this source http://flyingcat2013.blog.51cto.com/7061638/1319343