Skip to content

series/values: fix negative relative time offsets and async crash on …#2507

Open
tallpsmith wants to merge 1 commit intoperformancecopilot:mainfrom
tallpsmith:series-values-fix
Open

series/values: fix negative relative time offsets and async crash on …#2507
tallpsmith wants to merge 1 commit intoperformancecopilot:mainfrom
tallpsmith:series-values-fix

Conversation

@tallpsmith
Copy link
Contributor

Summary

Fixes #2503 — three tiers of breakage in /series/values time parameter handling.

  • Root cause (Tier 1/2): parsetime() in src/libpcp_web/src/query.c used PM_MAX_TIME_T as the end-time sentinel when calling __pmtimespecParse(). Because rtime.c:656 gates the negative-relative branch on end.tv_sec < PM_MAX_TIME_T, any negative offset (-30s, -2m, -1h, -7d) fell through to glib_get_date() which cannot handle them. Fix: use the current wall-clock time (pmtimespecNow()) so the negative-relative branch is taken correctly.

  • Crash path (Tier 2/3): pmSeriesValues() launched the async Redis pipeline even when initSeriesGetValues() had already set baton->error due to a parse failure. Corrupt/zero timing state then propagated into Redis queries, causing crashes. Fix: early abort — call series_query_finished() to invoke on_done with the error and free the baton cleanly before any async phase is started.

Test plan

  • New unit test qa/src/series_time_parse_test.c builds and passes (no Redis/pmcd required)
    • Demonstrates pre-fix breakage: PM_MAX_TIME_T sentinel rejects -30s, -7d
    • Verifies fix: end=now correctly parses -30s, -2m, -1h, -7d with ±1s tolerance
    • Regression: positive offsets (+30s, 30s) still work
    • Crash safety: 2024-01-15T10:30:00Z survives __pmtimespecParse() without crashing
  • Full CI/QA matrix (Cirrus) green
  • Manual smoke test: GET /series/values?series=<id>&start=-30s returns data (not a disconnect)

…bad input

PM_MAX_TIME_T as the end-time sentinel in parsetime() caused
__pmtimespecParse() to skip the negative-relative branch entirely,
silently rejecting "-30s", "-7d" etc.  Use wall clock instead.

Add early abort in pmSeriesValues() before async phases are launched
so parse errors invoke on_done cleanly rather than propagating corrupt
timing state into Redis queries.

Fixes: performancecopilot#2503
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

pmproxy /series/values crashes on certain time formats — 3 severity tiers including unauthenticated DoS

1 participant