…7862)

The smaps pipeline was too complicated, trying to aggregate some of the
memory consumers which were similarly named, such as those with the
pattern "mem/shared_memory", among others. There are concerns that this
masked or dropped the smaps data, leading to low counts for PSS and RSS.
This change speculatively removes this aggregation in case this is a
problem. This also fixes some bugs in the visualization script and adds
testing to ensure memory leaks are properly accounted for.

The smaps analysis pipeline failed on a couple of attempts due to
visualize_smaps_analysis.py receiving invalid timestamp strings from
analyze_smaps_logs.py. This occurred when analyze_smaps_logs.py
encountered log files with names that did not conform to the expected
timestamp format.

This change addresses the issue by:
- Modifying analyze_smaps_logs.py's extract_timestamp function to return
None for filenames that do not contain a valid timestamp, instead of a
placeholder string.
- Updating the file filtering logic in analyze_smaps_logs.py to skip any
log files for which a valid timestamp cannot be extracted, preventing
them from being passed to downstream visualization.
- Correcting the regular expression in extract_timestamp to accurately
match the _processed.txt suffix of the log files generated by
read_smaps_batch.py.
- Ensuring the run_analysis_pipeline.py script uses the correct log
directory path.

On top of that this adds a test hardening the data integrity for leak
detection. The analyze_smaps_logs_test.py includes a test
(test_analyze_logs_json_output) that simulates a memory leak. It creates
dummy smaps files where a component (<leaking_lib>) shows increasing PSS
and RSS values over time. This test then asserts that this time-series
memory growth is correctly captured and structured within the JSON
output. This ensures that the foundational data required for identifying
leaks is accurately processed.

Bug: 456178181
(cherry picked from commit 448df2e)

…st invalid timestamps (#7874)

Refer to the original PR: #7862

The smaps pipeline was too complicated, trying to aggregate some of the
memory consumers which were similarly named, such as those with the
pattern "mem/shared_memory", among others. There are concerns that this
masked or dropped the smaps data, leading to low counts for PSS and RSS.
This change speculatively removes this aggregation in case this is a
problem. This also fixes some bugs in the visualization script and adds
testing to ensure memory leaks are properly accounted for.

The smaps analysis pipeline failed on a couple of attempts due to
visualize_smaps_analysis.py receiving invalid timestamp strings from
analyze_smaps_logs.py. This occurred when analyze_smaps_logs.py
encountered log files with names that did not conform to the expected
timestamp format.

This change addresses the issue by:
- Modifying analyze_smaps_logs.py's extract_timestamp function to return
None for filenames that do not contain a valid timestamp, instead of a
placeholder string.
- Updating the file filtering logic in analyze_smaps_logs.py to skip any
log files for which a valid timestamp cannot be extracted, preventing
them from being passed to downstream visualization.
- Correcting the regular expression in extract_timestamp to accurately
match the _processed.txt suffix of the log files generated by
read_smaps_batch.py.
- Ensuring the run_analysis_pipeline.py script uses the correct log
directory path.

On top of that this adds a test hardening the data integrity for leak
detection. The analyze_smaps_logs_test.py includes a test
(test_analyze_logs_json_output) that simulates a memory leak. It creates
dummy smaps files where a component (<leaking_lib>) shows increasing PSS
and RSS values over time. This test then asserts that this time-series
memory growth is correctly captured and structured within the JSON
output. This ensures that the foundational data required for identifying
leaks is accurately processed.

#vibe-coded
Bug: 456178181

Co-authored-by: Adam Walls <avvall@google.com>