问题描述：
在使用EAS SANP软件进行影像数据裁剪的时候，遇到了程序报错，通过观察报错信息无法定位错误原因，如下图。
从报错信息来看，提示“Points of LinearRing do not form a closed linestring”，但是我仔细检查了用于裁剪的多边形数据（以WKT格式表示的POLYGON）是闭合的，和报错信息不相符。
至此，陷入迷惘中……
解决思路：
SNAP软件是使用Java开发，GPT工具是一个BASH脚本（类UNIX系统下），这个脚本调用了JAVA实现的功能。那如何进行代码调试找到报错原因呢？
第一：我们需要弄清楚BASH是如何调用Java的；
由于GPT实质是一个BASH脚本，我们可以通过调试BASH的技巧，找到GPT这个脚本到底干了什么，如何调用Java。
通过`bash -x`参数可以实现将BASH脚本的运行过程进行输出，在输出的信息中，我们可以定位到Java的调用代码，如下图。
bash -x ~/Applications/snap/bin/gpt Subset -PgeoRegion="POLYGON((87.40 41.80, 87.40 42.10, 86.70 42.10, 86.70 41.80, 87.40 41.80))" -Ssource=A2014115074500.L2.h5 -f HDF5 -t A2014115074500.L2.h5
第二：我们需要直接调试Java打包的二进制文件。
可以使用Java JDK自带的JDB工具在命令行中直接对Java程序进行调试，JDB的使用和C++ GDB以及Python 的PDG调试类似。但是还有一个问题：这个程序是Java编译以后的字节码，无法查看Java源码。
这个问题可以通过在GitHub下载EAS SANP软件的源码，在调试过程中可以对照源码进行调试。
操作实践：
我们在命令行通过JDB命令启动Java程序：
jdb -Dsnap.mainClass=org.esa.snap.core.gpf.main.GPT -Dsnap.home=/Users/tanzhenyu/Applications/snap/bin/.. -Djava.awt.headless=true -Dinstall4j.noLoggingFix=true -Xmx22G -classpath /Users/tanzhenyu/Applications/snap/.install4j/i4jruntime.jar:/Users/tanzhenyu/Applications/snap/.install4j/launcher4522bb12.jar:/Users/tanzhenyu/Applications/snap/snap/modules/ext/org.esa.snap.snap-core/org-esa-snap/snap-runtime.jar install4j.org.esa.snap.runtime.Launcher_gpt Subset '-PgeoRegion=POLYGON((87.40 41.80, 87.40 42.10, 86.70 42.10, 86.70 41.80, 87.40 41.80))' -Ssource=A2014115074500.L2.h5 -x -f HDF5 -t A2014115074500.L2.h5 4313 bash -x ~/Applications/snap/bin/gpt Subset -PgeoRegion="POLYGON((87.40 41.80, 87.40 42.10, 86.70 42.10, 86.70 41.80, 87.40 41.80))" -Ssource=A2014115074500.L2.h5 -f HDF5 -t A2014115074500.L2.h5
启动JDB调试以后，首先，首先需要在程序可能出错的地方设置断点。我们可以通过程序的报错信息大致确定需要打断点的地方。通过使用`stop in`在某个类的某个方法中设置断点或者使用`stop at`在某个类文件的某一行设置断点；然后，使用`run`命令将程序跑起来，程序会在之前设置断点的地方停下来；最后，使用`next`、`step`、`step up`以及`cont`等命令进行程序调试，可以使用`print`以及`dump`等命令查看指定变量的值。调试完成，通过`exit`或者`quit`退出JDB调试。
这里涉及很多JDB命令，我们进入JDB以后，可以通过`help`命令查询这些命令是干什么用的，不用刻意进行记忆。基本上每个命令的名字大致给出了其作用。
