<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 2:19 AM Clemens Lang <<a href="mailto:cal@macports.org">cal@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Mihir,<br><br>
In my experience, it will make it much simpler to review the entire code<br>
if you expand your repository with a README file which gives a (textual)<br>
rough overview of how the code works, possibly with a link to the paper<br>
you implemented. I'd also advise extensively commenting your code to<br>
explain why you do things the way to implemented them, but from a quick<br>
glance, it seems you already did that to a certain extent.<br></blockquote><div><br></div><div><a href="https://github.com/MihirLuthra/sharedMemory">https://github.com/MihirLuthra/sharedMemory</a><br></div><div><br></div><div>I made a readme for the repository just as you suggested. Although if it lacks to be understandable, I will update it accordingly as you say. I have made the code extensively commented now and refactored it to a nice extent I guess.</div><div><br></div><div>Also when reading code I suggest reading “sharedmemory.h” first and then “sharedmemory.c” will make the comments more understandable.</div><div><br></div><div>Although this is the first time I coded multi-threaded program, and now I realise that it really takes long to remove a small bug. But now I belief the code is bug free and works completely correct.</div><div>Two extra things which I plan to do is reference counting for munmap(2) after expanding and utilisation of wasted space in file(which will drop the memory usage to almost half of what it currently is).</div><div>I have planned for them and probably will do these two in 2-3 days more.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
You can further abstract using a separate SharedMemoryManager object per<br>
thread if you use the pthread API. See for example<br>
__darwintrace_sock_set and sock_key in darwintrace.h and darwintrace.c.<br>
<br>
This should allow you to write a get_memory_manager() function that will<br>
automatically give you a thread-specific SharedMemoryManager object or<br>
create one if none exists for the current thread yet.<br>
<br></blockquote><div><br></div><div>I saw the code in darwintrace.c.</div><div>Probably yes, I can call insert() and inside it I could call get_memory_manager() which checks thread specific storage for it and it makes the code pretty clean too.</div><div>Is that the way you mean?</div><div><br></div><div>Also, this reminded me of one more thing, if I implement search() in open.c, access.c etc. I need not call __darwintrace_setup() right?</div><div>Like is there any other important thing darwintrace calls do which I need to do separately after search() or can I straight away skip to the end according to search() results?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
It's probably a good idea to move the path normalization to a separate<br>
function, yes. Note that the current does not correctly deal with<br>
directory symlinks. For example, trace mode does not recognize that<br>
<br>
  /opt/local/libexec/qt5/include/QtCore/QByteArray<br>
<br>
is a file installed by the qt5-qtbase port, because<br>
<br>
  /opt/local/libexec/qt5/include/QtCore<br>
<br>
is a symbolic link to<br>
<br>
  /opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/Headers<br>
<br>
Once path lookup is fast, we could actually modify the normalization<br>
code to also check folder symbolic links inside the MacPorts prefix<br>
against the database of ports.<br>
<br>
This would require intertwining the path lookup with path normalization.<br>
Keep that in mind for later, but don't do it now.<br>
<br></blockquote><div>Got it. Will do once this shared memory functionality is complete. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
On Wed, May 08, 2019 at 04:24:28PM +0530, Mihir Luthra wrote:<br>
> I figured out the right ways to use my files in code. Can you explain<br>
> me why is it causing these errors.[1]<br>
> <br>
> Just before __darwintrace_is_in_sandbox_check returns path permission,<br>
> I captured it in a bool variable and inserted the normal path in the<br>
> shared file. Each time it prints insertion successfull, so probably I<br>
> feel the extra code I inserted didn’t’ crash, but if you can give me<br>
> some idea what possibly could have gone wrong I maybe able to debug<br>
> it.<br>
> <br>
> [1] <a href="https://pastebin.com/1t7a0GJq" rel="noreferrer" target="_blank">https://pastebin.com/1t7a0GJq</a><br>
<br>
:info:extract sip_copy_proc: mkdir(/opt/macports-test/var/macports/sip-workaround): No such file or directory<br>
<br>
We use this directory to create a copy of system binaries that we<br>
wouldn't be able to inject into because they have the magic<br>
"unmodifiable system file" bit introduced by Apple in 10.13. Normally,<br>
typing 'sudo make install' in your macports development copy should have<br>
created this directory (see doc/<a href="http://base.mtree.in" rel="noreferrer" target="_blank">base.mtree.in</a>), but that doesn't seem to<br>
have happened for you. You should be able to create the directory<br>
manually and chmod it to 1777.<br></blockquote><div> <br></div><div>Got it. That error is gone now.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br><br>
> 2) When I install copies with multiple names, i mean I tried with<br>
> prefixes macports-test2, macports-test3 but just as like I sent you<br>
> the log file last time, it actually reads hardcoded “macports-test”<br>
> somewhere which I am unable to understand.<br>
<br>
You'll have to re-run ./configure with a different value for --prefix<br>
for each different installation. If you want to install into multiple<br>
places, it's probably wise to have multiple copies of the source code as<br>
well, otherwise you'll end up recompiling unchanged files very often<br>
during development.<br>
<br><br>
> 4) What location I should choose for my temporary shared files in your<br>
> opinion? I currently specified the path to be /tmp/.sharedmemory<br>
> <br>
> Is there any better location within macports directories?<br>
<br>
A path similar to what we use for the trace mode socket might be a good<br>
choice. The template for that socket is<br>
<br>
  /tmp/macports-trace-XXXXXX<br>
<br>
see src/port1.0/porttrace.tcl:51<br></blockquote><div><br></div><div>Got it. Will do the same.</div><div><br></div><div>Meanwhile till the time you review my code, I will see if I can get the code right into base and add other features to it.</div><div><br></div><div>Thanks for the help,</div><div>Mihir  </div></div></div></div></div>