Page MenuHomePhabricator

get scan-view executable from environment
ClosedPublic

Authored by asmar on Apr 10 2020, 8:51 AM.

Details

Summary

Fixes "Use of uninitialized value $ScanView in exec" error on systems with scan-view executable not located in the expected place.

Currently when scan-build is installed in Debian-like (Ubuntu 18.04 my case) system the scan-view executable is not correctly identified when installed by apt from clang-tools package.

The buggy code was first introduced here 10 ago:

https://bugs.llvm.org/show_bug.cgi?id=3725

The issue was recently reported on Debian Bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941614

The problem lies in current master scan-build:974:

https://github.com/llvm/llvm-project/blob/350522670232c74587138dc83161de514567f411/clang/tools/scan-build/bin/scan-build#L974

Searching for "$RealBin/../../scan-view/bin/scan-view" may not work in such cases because directories are versioned e.g. "$RealBin/../../scan-view-6.0/bin/scan-view".

Diff Detail

Event Timeline

asmar created this revision.Apr 10 2020, 8:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 10 2020, 8:51 AM
NoQ accepted this revision.Apr 15 2020, 4:53 PM

Thank you!

While it probably will never matter in practice because scan-view is barely ever updated, wouldn't it be a bit safer from revision lock perspective to keep looking for scan-view relative to scan-build but instead glob through the version number? I.e., $RealBin/../../scan-view*/bin/scan-view.

Should we emit an error if scan-view is not found, instead of failing with a perl crash? Should we emit a warning if scan-build is taken from $PATH and is therefore of potentially mismatching version?

I'll be happy to commit this as-is but these seem to be some reasonable ideas for improvement.

This revision is now accepted and ready to land.Apr 15 2020, 4:53 PM

Rather than globbing I would check whether there's a scan-view directory with the same version suffix as in the scan-build's one. Getting "random" version from other directories doesn't seem transparent to me. When this fails, which for the system version is expected behaviour I suppose.

I believe that Perl error is sufficient. It emits the correct error code, helps to spot the root of the error right away and custom error will not have any other benefits.

I am not sure about reporting $PATH though.

This revision was automatically updated to reflect the committed changes.