Skip to content

#599 follow-up: batch sweep walk is dead code (order bug from #600) AND activating it crashes fbird_batch_multitype_001 at exit #603

Description

@satwareAG-ironMike

Two nested findings from the PR #601 human-level review round 2:

1. The #599 batch detach walk never executes (order bug, introduced in #600/4be1c1f)

_php_fbird_trans_detach_queries() clears trans->batch_head BEFORE the batch walk reads it:

trans->query_head = NULL;
trans->batch_head = NULL;  /* <-- premature (#600 init-regex collateral) */
fbird_batch *b = trans->batch_head;  /* always NULL -> walk dead */

Consequence: batches enrolled on a dying transaction keep a DANGLING fb_batch->trans - the exact UAF class #599 was meant to prevent. Not observed crashing because _php_fbird_free_batch never derefs trans and fbird_batch_execute on a freed-struct trans reads garbage that usually null-checks out in release builds.

2. Simply activating the walk (moving the clear below) crashes fbird_batch_multitype_001

Fix for (1) applied in PR #601 review round: test output completes fully then Segmentation fault (core dumped) at process EXIT. Simple case passes (issue599_batch_survives_trans_death.phpt), so the walk itself works; the multitype lifecycle (multiple batches, explicit trans commit/rollback sequences, mid-test trans death, batch reuse) crashes somewhere in shutdown cleanup - suspected: fbbatch_cancel on a wrapper whose attachment already died (batch wrappers are NOT covered by the #591/#593 statement sweep).

Reverted to the dead-walk state with a jane: comment; root-cause needed.

Acceptance criteria

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions