[Mesa-dev] [PATCH 4/4] util: Get program name based on path when possible

Kazlauskas, Nicholas nicholas.kazlauskas at amd.com
Wed Sep 12 14:55:10 UTC 2018


On 09/12/2018 10:28 AM, Nicolai Hähnle wrote:
> On 12.09.2018 14:31, Kazlauskas, Nicholas wrote:
>> On 09/12/2018 12:26 AM, Timothy Arceri wrote:
>>> On 12/9/18 2:24 am, Nicholas Kazlauskas wrote:
>>>> Some programs start with the path and command line arguments in
>>>> argv[0] (program_invocation_name). Chromium is an example of
>>>> an application using mesa that does this.
>>>
>>> This change breaks the detection of Wine applications. Can you give 
>>> an example of the string in program_invocation_name for Chromium? Can 
>>> we not remove the arguments from the string?
>>
>> The issue shows up with the subprocesses spawned by Chromium or Chome 
>> where program_invocation_name shows up as something like this:
>>
>> /usr/lib/chromium/chromium --type=gpu-process --field-trial-handle=...
>>
>> The fix to this patch to avoid breaking Wine programs is probably just 
>> deferring the realpath logic until the inner part of of the '/' path 
>> detection.
>>
>> I think this is the simplest method of dropping the arguments while 
>> still retaining the exact program name match with strcmp.
> 
> Could we instead extend the syntax of the process filter? For example, 
> understand a '*' wildcard at the end of the program name in the drirc 
> XML do a prefix match instead of a full string match in that case.
> 
> Cheers,
> Nicolai

That's an option I considered as well. Though on Linux it's possible to 
have '*' as part of an actual program name so it could get confusing.

For now I think the realpath methods works - I tested a version of this 
patch with the realpath check only after it picks up on a '/' in the 
path and it seems to be working fine for both Wine programs and Linux 
ones as well (which would make sense since '/' is forbidden as part of 
Windows paths).

It's debatable whether a solution that checks if the realpath program is 
the wine launcher is more robust or not. I'd imagine not.

Nicholas Kazlauskas

> 
> 
>>
>>>
>>>>
>>>> This tries to query the real path for the symbolic link /proc/self/exe
>>>> to find the program name instead.
>>>>
>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas at amd.com>
>>>> ---
>>>>   src/util/u_process.c | 17 ++++++++++++++---
>>>>   1 file changed, 14 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/src/util/u_process.c b/src/util/u_process.c
>>>> index 5e5927678d..ca4d0770cb 100644
>>>> --- a/src/util/u_process.c
>>>> +++ b/src/util/u_process.c
>>>> @@ -29,6 +29,7 @@
>>>>   #include <string.h>
>>>>   #include <errno.h>
>>>>   #include <stdlib.h>
>>>> +#include <stdio.h>
>>>>   #undef GET_PROGRAM_NAME
>>>> @@ -36,22 +37,32 @@
>>>>   #    if !defined(__GLIBC__) || (__GLIBC__ < 2)
>>>>   /* These aren't declared in any libc5 header */
>>>>   extern char *program_invocation_name, *program_invocation_short_name;
>>>> +extern char *__progname;
>>>>   #    endif
>>>>   static const char *
>>>>   __getProgramName()
>>>>   {
>>>> -   char * arg = strrchr(program_invocation_name, '/');
>>>> +   static char * actual_path;
>>>> +   char * path = NULL;
>>>> +   char * arg = NULL;
>>>> +
>>>> +   if (!actual_path)
>>>> +      actual_path = realpath("/proc/self/exe", NULL);
>>>> +
>>>> +   path = actual_path ? actual_path : program_invocation_name;
>>>> +
>>>> +   arg = strrchr(path, '/');
>>>>      if (arg)
>>>>         return arg+1;
>>>>      /* If there was no '/' at all we likely have a windows like 
>>>> path from
>>>>       * a wine application.
>>>>       */
>>>> -   arg = strrchr(program_invocation_name, '\\');
>>>> +   arg = strrchr(path, '\\');
>>>>      if (arg)
>>>>         return arg+1;
>>>> -   return program_invocation_name;
>>>> +   return path;
>>>>   }
>>>>   #    define GET_PROGRAM_NAME() __getProgramName()
>>>>   #elif defined(__CYGWIN__)
>>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> Nicholas Kazlauskas
> 



More information about the mesa-dev mailing list