Patch to handle out-of-memory conditions in mythsystemunix.cpp - fixes Coverity 1028695

[Gary Buhrmaster <gary.buhrmaster@…>]

Static analysis determined that a check for cmdargs being NULL at cleanup was out of place (because it was already used without such checks). Further examination of the code showed that the codes did not properly handle out-of-memory allocations in strdup and malloc. While not likely, if they occured, a NULL pointer dereference could have occured in storing one of the command arg pointers, or the command could have been forked without the correct args. This was a real potential bug.

Fixes Coverity 1028695

Note that this patch appears to be huge, and somewhat unusual. This is an artifact of putting some of the code in a conditional (and the resulting indentation changes, and diff matching on random blank lines and braces).

Note that this patch depends on the patch in ticket #11607 (since it indents that code).

btw, the frees at clean up do not really need to be protected by checking for NULL since free does that internally, but since the existing code did that check, I followed the style, and made it consistent.

If this patch is accepted (style wise), I will look to (speculatively) change the mythsystemwindows.cpp file (which also does not check strdup).

github ref: ​https://github.com/garybuhrmaster/mythtv/commit/a70341e59962e43e85ef882c8b7d435b68500e0b github git-am ref: ​https://github.com/garybuhrmaster/mythtv/commit/a70341e59962e43e85ef882c8b7d435b68500e0b.patch

[paulh]

This depends on the patch in #11607 otherwise I would commit it myself

[stuartm]

Gary this patch no longer seems to apply cleanly to master.

[gary.buhrmaster@…]

Correct. As you may recall, while this patch was settling in trac, you applied a specific coverity detected fix, which partially addressed a few of the issues (but not the complete list I attempted to fix). At the time, I sent a message indicating such. You stated you had overlooked my patch, but would review it later to do the merging (or just close the ticket, or revert your patch and apply mine, depending on what made the most sense).

How would you like to proceed?

[stuartm]

Right, I'd forgotten that, sorry. I guess I'll do the latter, revert my fix and commit yours since it's more thorough.

[stuartm]

Having looked at it closer, it's not just my fix which prevents this being cleanly applied by at least one other by Karl Dietz. Rather than try to unpick it all I'm going to call it a day.

I'm sorry I didn't see and apply this patch when you first submitted it.

[gary.buhrmaster@…]

Fair enough. If I end up with some future time, I may try to come up with a new patch, but probably not anytime soon (because, as I recall, it takes some time to carefully evaluate the various failure conditions and cleanups). Thanks for looking.