Some common problems with GDAL

1 When using ground control points for geometric correction, an unhandled exception pops up at 0x00007FFF2CBAEBB4 (gdal302.dll) (in SURFMatch.exe): 0xC0000005: An access violation occurred while reading the position 0xFFFFFFFFFFFFFFFF.

Problem: Unable to correct
Reason: I searched for the cause and found that it was caused by not setting the ID of the ground control point. After setting the ID, it ran normally.

gcplist[i].pszId = id;

2 ERROR 1 appears when running gdal in c++: PROJ: proj_create_from_database: cannot find proj.db

The idea is:
If you can't find this file, let it find it. There are 3 ways:
1. Add environment variables and then restart the computer ;
2. Specify the path in the code;
3. Put it under the exe;
sometimes these 3 methods are needed Both methods in are set.

After referring to some documents, I found that there are two main solutions:
This problem was successfully solved with the second method:
one is to add environment variables ;
the other is to configure the path to proj.db directly in the code.

std::string path = "C:\\Program Files\\PROJ\\share\\proj";//proj.db所在文件夹
const char* proj_path[] = {
    
    path.c_str(), nullptr};
OSRSetPROJSearchPaths(proj_path);

C++ version GDAL3.5 cannot find the proj.db file_c++ db file_Linlp93's blog-CSDN blog

Solution to the problem of Cannot find proj.db when GDAL is running_Akuya Motata (Zhang Xuepeng)'s Blog-CSDN Blog

3 When using gdal and omp of c++ to read data, an error ERROR 1 is reported: GetBlockRef failed at X block offect 0, Y block offect 12210. Segmentation fault (core dumped). These are two different errors.

GetBlockRef failed at X block off 0, Y block off 12210. It's an error in gdal reading data.
Segmentation fault (core dumped). It's an out of memory error

1. Possible reasons:
I ran the code normally on Windows, and then I ran it on Linux, and this error was reported.
There are nothing more than the following 4 reasons:
(1) omp resource conflict; I run it normally on Windows and basically eliminate this error.
(2) The read data is wrong; in order to verify, I turned off omp acceleration and found that it was running normally and the data could be read normally, indicating that it must be the cause of omp.
(3) Reasons for relying on libraries; I had an omp code that could run normally before, but it cannot run this time, and this error has not been eliminated.
(4) The reason for insufficient memory resources; my omp found that many threads were running at the same time, so I added export OMP_NUM_THREADS=4 in the shell script. Discovery didn't work. Afterwards, I added the following words to the code and found that the program executed normally. The number of threads is limited to 4 instead of many, so that the program takes up less memory:

#include <omp.h>

int main() {
    
    
    omp_set_num_threads(4);
    // 并行读取的代码
    // ...
    return 0;
}

2. Reason:
Insufficient memory resources cause this problem.

3. Solution 1: Limit the number of omp threads in the program
. Add the above code to the program and the program will run normally.

#include <omp.h>

int main() {
    
    
    omp_set_num_threads(4);
    // 并行读取的代码
    // ...
    return 0;
}

Solution 2: Clear system memory
. Use the following command to clear the cache in the system and provide more memory:

sudo sync && sudo echo 3 > /proc/sys/vm/drop_caches

4 Segmentation fault (core dumped)Insufficient memory

Segmentation fault (core dumped) is mostly caused by improper memory operation. Read and write operations of null pointers and wild pointers, array out-of-bounds access, destruction of constants, etc. Initializing each pointer to NULL after declaration is a good way to avoid this problem.

A quick solution is to check the system memory, free -h, and see how many G memory is left in the free field.

If there is insufficient memory, you need to clear the memory:

sudo sync && sudo echo 3 > /proc/sys/vm/drop_caches

5 4 errors reported at the same time: GetBlockRef failed at X block offect 0, Y block offect 4373,

ERROR1: GF2-035009809.tif，band 2: IReadBlock failed at X offset 0, Y offset 4373，
ERROR1:GetBlockRef failed at X block offect 0, Y block offect 4373，
ERROR1:TIFFFillStrip:Read error at scanline 2; get 0 bytes, expected 18438,
ERROR1:RIFFReadEncodedStrip() failed.

1 Question:
When using GDAL to read data, this error occurs when omp is enabled. The omp enabled thread is 1 and no error is reported. The omp enabled thread is 2, and an error is reported twice. Sometimes this error is not reported. But when omp enabled threads to be 8, this error was reported more than 1,000 times.

The greater the number of threads, the more times the above error is reported, which can exceed several thousand times at most. That is, the data cannot be obtained.

2 Reasons:
Exclusion:
(1) Reasons for excluding image size: mss.tif and dom.tif will report errors. mss.tif will report an error if the size is 1000 1000, and dom.tif will report an error if it is 3000 3000, but dom.tif will report an error. More errors are reported. If the size of dom.tif is set to 1400*1400, the above error will also be reported.
(2) Exclude data problems. The data is correct because single-thread access is normal.

The reason found:

There is a conflict in gdal's access to resources. Multi-threads of gdal will conflict when reading image blocks at the same location. That is, when reading a certain pixel, only one thread can read.

这些错误可能是由于并行处理导致的内存访问冲突或资源竞争引起的。当您增加线程数时，多个线程可能会同时访问相同的内存位置或资源，导致读取错误或失败。
为了解决这个问题，您可以尝试以下几点：
确保在并行处理期间，每个线程都在不同的内存位置上进行操作，以避免冲突。可以使用OpenMP的private和shared指令来控制变量的私有和共享访问。
尝试减少并行处理的线程数，以降低资源竞争的可能性。您可以逐步减少线程数，直到不再出现错误。
检查代码中是否存在其他可能导致冲突的部分。例如，如果有其他共享资源或全局变量，可能需要使用互斥锁或其他同步机制来保护它们。
确保您的代码在并行处理期间正确释放和管理内存，以避免内存泄漏或访问已释放内存的错误。
如果可能的话，尝试使用调试工具来跟踪错误发生的位置，并查看是否有任何明显的冲突或错误。
请注意，并行处理可能会增加代码的复杂性和调试难度。因此，在使用并行处理时，确保您的代码正确地处理并发访问和资源管理非常重要。

3 Solution:
Multiple threads using gdal to read remote sensing data blocks at the same time may cause conflicts and incorrect results. To avoid this, we can use OpenMP's critical directive to protect access to shared resources.
Use #pragma omp critical {} to wrap the code for reading pixels. Note that {} must start on a new line and cannot be on the same line as #pragma omp critical.

std::vector<cv::Mat> imgMat;     // 每个波段
int size = xpixel * ypixel;      // 这里必须是int
float* pafScan = new float[abs(size)];   // 存储数据，这句读取大影像直接报错了
if (pafScan == NULL) {
    
    
	std::cerr << "pafScan Failed to allocate memory." << std::endl;
	cv::Mat img_null;
	return img_null;
}
#pragma omp critical 
{
    
    
	for (int i = 0; i < band_number; i++) {
    
    
	int band = bands[i];
	GDALRasterBand* pBand = poDataset->GetRasterBand(band);
	// 读取栅格数据，并将其存储在pafScan中
	pBand->RasterIO(GF_Read, left, top, xpixel, ypixel, pafScan,
		xpixel, ypixel, St.iDataType, 0, 0);
	// 这里创建的时候是行数、列数
	cv::Mat tmpMat = cv::Mat(ypixel, xpixel, MdataType, pafScan);
	imgMat.push_back(tmpMat.clone());  // n个波段放到imgMat数组中去
	tmpMat.release();
	}
}

//释放内存
delete[]pafScan;
pafScan = NULL;
cv::Mat img;
img.create(St.Ysize, St.Xsize, MdataTypes);
// 将多通道数组转换为图像数组
cv::merge(imgMat, img);

5 Unable to find .dll library

Solution:
Place the .dll dynamic link library where the executable file .exe can be found

6 Unable to locate program input point

Unable to locate the program input point solid3 column origin name in dynamic link library D: XiaoMaCode\CPlusPlusCode Third party library GDAL322\bingdal302dll

2.2 Reasons

It is most likely because the .dll library cannot be used, or the library adjustment is confusing.

2.3 Solution

I started putting the .dll library into the system variables, but something went wrong.
Place the .dll file in the same directory as the exe and it can be executed normally.