Changes between Version 8 and Version 9 of DevWikiGettingABackTrace


Ignore:
Timestamp:
Dec 12, 2021, 8:58:13 AM (10 months ago)
Author:
gdt
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • DevWikiGettingABackTrace

    v8 v9  
    155155= Using with regression tests =
    156156
    157 Sometimes there is a crash during regression tests.
     157Sometimes there is a crash during regression tests, and it's useful to get a backtrace
     158
     159== Safer Instructions ==
     160
     161These 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 ==
    158171
    159172When 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.
    160173
    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.
     174Instead, 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.
    162175
    163176Then, e.g.