Changes between Version 8 and Version 9 of DevWikiGettingABackTrace
- Timestamp:
- 12/12/21 08:58:13 (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevWikiGettingABackTrace
v8 v9 155 155 = Using with regression tests = 156 156 157 Sometimes there is a crash during regression tests. 157 Sometimes there is a crash during regression tests, and it's useful to get a backtrace 158 159 == Safer Instructions == 160 161 These instructions are likely better and safer. 162 163 * make staged-install # from top-level 164 * regress/run_test.pl --nodrop regress/core/geography.sql 165 * psql postgis_reg 166 * select pg_backend_pid(); 167 * attach gdb to backend 168 * psql> \i regress/core/geography.sql 169 170 == Simpler, perhpas less reliable approach == 158 171 159 172 When running "make test", a number of things happen, including creating some test files and creating the "postgis_reg" database and loading the working tree postgis into it. Then, tests are run. It would be difficult to replicate all of this in a script to run gdb. 160 173 161 Instead, the recommended approach is to first run "make test", to cause all the setup to happen.Then, identify the first failing test, as debugging anything after the first failure is far less likely to be useful. Connect as "psql -d postgis_reg", and get the pid and attach gdb as above.174 Instead, one can first run "make test", to cause all the setup to happen. While the database is normally dropped, it is (usually?) left on failure. Then, identify the first failing test, as debugging anything after the first failure is far less likely to be useful. Connect as "psql -d postgis_reg", and get the pid and attach gdb as above. 162 175 163 176 Then, e.g.