Hi everyone, I am running in a crash when using

proc_pidpath

from

libproc.h

to get the path of the process from the pid. The code is pretty standard :

char path[PROC_PIDPATHINFO_MAXSIZE] = {0};
int bufsize = proc_pidpath(pid, path, sizeof(path));
if(bufsize > 0)
   return std::string(path);
return {};

Also osquery already uses it so it should work fine. Am I missing something? Anybody experienced the same ?

Can you share the stacktrace?

ProductName:    macOS
ProductVersion: 12.1
BuildVersion:   21C52

Everything I can get is this:

Process 6936 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ff7bf6ffff8)
    frame #0: 0x0000000100025615 processinfo-test`std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) + 47
processinfo-test`std::__1::__put_character_sequence<char, std::__1::char_traits<char> >:
->  0x100025615 <+47>: callq  0x10002c558               ; symbol stub for: std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::sentry(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)
    0x10002561a <+52>: cmpb   $0x0, -0x40(%rbp)
    0x10002561e <+56>: je     0x1000256a8               ; <+194>
    0x100025624 <+62>: movq   (%r14), %rax

can you try replacing

PROC_PIDPATHINFO_MAXSIZE

with something like

4096

in the char array and try again? I think

PROC_PIDPATHINFO_MAXSIZE

doesn't come from libproc.h header, it might be coming from somewhere else

I have tried with the numeric value too. same crash. 🤔

What's the locale on the machine? Does the path have any non-ascii characters? Perhaps something like that..?

the path is definitely under 4096 and definitely ASCII

weird..not sure, since this works locally for me..probably attach a debugger?

the simplest example works here too :

andrea@andrea-macbook ~ % ./pidpath 543
proc 543: /Applications/Google <http://Chrome.app/Contents/Frameworks/Google|Chrome.app/Contents/Frameworks/Google> Chrome Framework.framework/Versions/103.0.5060.134/Helpers/chrome_crashpad_handler %                                      
andrea@andrea-macbook ~ % ./pidpath 883
proc 883: /Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Helpers/chrome_crashpad_handler %

Is this code part of an osquery extension? I wonder if codesign or something comes into play

I thought about it too but I find out because the app, signed and notarised was crashing 😕

I thought about it too but I find out because the app, signed and notarised was crashing

Which app? Is the crash happening in osquery?

no no don't worry. it's not osquery

ah..still quite an interesting crash though..the only other thing I can think of is when a

pid

doesn’t have a path in the filesystem (kinda zombie like process), but that’s far fetched

so apparently the function was written as part of a Objective C file (.mm).. so defining the function in that context was creating some issues

Ah, I guess ARC may not play that nicely..I am sure there is a way to guard/retain that memory

not sure what ARC is but I ll have a look. Anyway, thank you for your help!! very appreciated!

cool, no problem — arc is the reference counting in Objective-C

ahh ok