macOS: normalize SHM names and propagate blob creation failures

[jovemexausto]

Summary

• Normalize POSIX shared-memory names on macOS before calling shm_open().
• Propagate the return value from stream_renderer_create_blob() instead of always reporting success.

Why

These fixes make blob-backed GPU resources fail loudly and keep macOS SHM creation compatible with the expected POSIX naming rules.

Validation

• Rebuilt gfxstream locally on macOS.
• Exercised this path as part of the macOS/libkrun Android integration work.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jovemexausto]

Reopened after signing the CLA. I hope this fix is useful to the project; it was essential for my current research, and I’m happy to help with any follow-up.

[jovemexausto]

The companion patch in libkrun is here. Together they unblock the macOS gfxstream blob-mapping path.

[gurchetansingh]

Can you add which MacOS builds configuration you're using (I assume) to the Gitlab CI/CD via modifying the actions?

[gurchetansingh]

I guess you can make this slash universal, even on linux. Also, cite the POSIX standard that requires a slash in a comment.

[jovemexausto]

Thanks! Made the shm_open() name normalization universal, not macOS-only, and added an inline POSIX.1-2017 citation.

[jovemexausto]

Hi! I addressed both comments in this PR:

• shm_open() names are now normalized unconditionally, with a POSIX.1-2017 citation inline.
• A macOS GitHub Actions workflow was added to make the build configuration explicit.

I should be candid here: I initially scoped this PR narrowly to a concrete bug fix, but that turned out to be incomplete because the change really only makes sense with a working macOS build path. I overlooked that at first.

The complete macOS stack is already working in my companion branch, with a passing build here.

If you'd prefer, I can fold that macOS host-build stack into this PR so the CI job reflects a fully green macOS path.

[gurchetansingh]

Yeah, it makes sense to add all of the MacOS build support patches, to ensure CI/CD coverage of the use case. Can you add them here?

Also, make common: make shm_open names POSIX-compliant and common: fix macOS shared memory names one commit.

Thanks!

[gurchetansingh]

Can you add this presubmit.yml instead of it's own file?

[jovemexausto]

Thanks for the follow-up, @gurchetansingh! I'll take some time this weekend to go through and address all your points