Skip to content

Commit

Permalink
don't try to clean up the COP pointer during global destruction
Browse files Browse the repository at this point in the history
At this point there should be no further debugging code trying to
use the COP pointer.

On threaded builds the call to CopFILEAV() could cause a segmentation
fault, since during late destruction gv_fetchfile() could return
NULL, which the threaded version of CopFILEAV() would blindly call
GvAV() on.
  • Loading branch information
tonycoz committed Nov 15, 2021
1 parent 0cdbe21 commit 9bce496
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion op.c
Expand Up @@ -1316,7 +1316,11 @@ S_cop_free(pTHX_ COP* cop)
{
PERL_ARGS_ASSERT_COP_FREE;

if (cop->op_type == OP_DBSTATE) {
/* If called during global destruction PL_defstash might be NULL and there
shouldn't be any code running that will trip over the bad cop address.
This also avoids uselessly creating the AV after it's been destroyed.
*/
if (cop->op_type == OP_DBSTATE && PL_phase != PERL_PHASE_DESTRUCT) {
/* Remove the now invalid op from the line number information.
This could cause a freed memory overwrite if the debugger tried to
set a breakpoint on this line.
Expand Down

0 comments on commit 9bce496

Please sign in to comment.