Dmitrii Kuvaiskii

Let's put this PR on hold. We are very busy with preparing for the new release of Gramine.

@boryspoplawski Disregard this particular log for now. But I have high confidence in the created issue. At some point, I would like to write a microbenchmark that highlights this perf...

We should be talking about the usages of `PalStreamAttributesQueryByHandle()`.

@boryspoplawski Yes, these are the usages. I think also `getsockopt`. Well, need to verify all the places that lead to calling the `attrquerybyhdl()` callback, I think there were a couple...

The problem is somewhere here: ``` 2022-10-13T11:45:14.318774028Z [P1:T1:dotnet] trace: ---- gettid() = 0x1 2022-10-13T11:45:14.318777338Z [P1:T1:dotnet] trace: ---- getpid() = 0x1 2022-10-13T11:45:14.318782955Z [P1:T1:dotnet] trace: ---- tgkill(1, 1, [SIGABRT]) = 0x0 2022-10-13T11:45:14.318784882Z...

Ok, now I get it about the manifest. The manifest looks reasonable, but what is this: ``` fs.mounts = [ { path = "/tmp", uri = "file:/tmp", type = "tmpfs"...

Yes, it could be the root cause. But without knowing what these directories/files are and the context of this execution, I can't give any advice. I have zero clue what...

Ok, this seems to make sense. Now we're back to the original issue of `SIGABRT`. Unfortunately, we need more information. As I said previously, this should be a result of...

> thus preserve backwards compatibility for almost all users By this you mean that **both** Gramine runtime and the `gramine-sgx-pf-crypt` use *absolute paths* for checking during opening Encrypted Files, right?

Thanks @deliciousdish for the bug report. This looks like some corner case in Gramine, because something inside Gramine itself fails, based on this line of log: ``` error: Unexpected memory...