[prev in list] [next in list] [prev in thread] [next in thread]
List: uwsgi
Subject: Re: [uWSGI] pyuwsgi and environ handling under macOS
From: Nate Coraor <nate () bx ! psu ! edu>
Date: 2018-03-20 20:08:52
Message-ID: CALT861FcMfXvxZSp4dD1uqt9n10bvToFDv7Ouv_SYMz_3FiMtg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Roberto,
Thanks for the response, I created an issue here:
https://github.com/unbit/uwsgi/issues/1762
--nate
On Tue, Mar 20, 2018 at 2:24 PM, Roberto De Ioris <roberto@unbit.it> wrote:
>
> > Because of the... unique... way that macOS handles the standard `environ`
> > when running as a shared library[1], uWSGI segfaults under certain
> > conditions on macOS when built as a CPython extension (pyuwsgi).
> >
> > What many projects faced with this issue do is something like:
> >
> > #if defined(__APPLE__) && defined(UWSGI_AS_SHARED_LIBRARY)
> > #include <crt_externs.h>
> > #define environ (*_NSGetEnviron())
> > #else
> > extern char **environ;
> > #endif
> >
> > uWSGI does something similar but instead of the preprocessor define,
> > assigns `environ` to the return of `_NSGetEnviron()` at runtime. However,
> > this approach doesn't work because after a `setenv()`, the address in
> > `environ` is no longer valid, and `_NSGetEnviron()` needs to be called
> > again. That's why the define works, since under that method, `environ`
> > always points at the address returned by `_NSGetEnviron()`.
> >
> > I made a naive attempt at addressing the problem[2] by reinitializing
> > `environ` after the environment is manipulated, but it's not sufficient.
> > Rather than hunting through the code and reinitializing `environ`
> > everywhere, which is sure to be error prone and likely to introduce more
> > bugs in the future, I tried to just switch to using the define method.
> >
> > Unfortunately, this doesn't work as the `uwsgi_server` and `uwsgi_app`
> > structs have an `environ` member, so there's a name conflict with the
> > defined `environ`. I have two possible solutions but I am not sure how
> > they'd be received by the uWSGI developers, so I wanted to get some
> > guidance before committing any effort:
> >
> > 1. Rename the struct member.
> > 2. Replace access to `environ` throughout the code with a function call
> > returning either `environ` or `_NSGetEnviron()` as appropriate.
> >
> > The first option seems the most future-proof as it avoids any cases in
> the
> > future where developers forget to use the function rather than `environ`
> > directly, but it might also be frustrating to have such a core name
> > changed. There are probably simpler solutions, however, as I am by no
> > means
> > a C expert with a lot of tricks up my sleeve.
> >
> > Thanks,
> > --nate
> >
>
> Hi Nate, this is an interesting issue, would you like to move it in a
> github issue to reach wider audience ?
>
> By the way, neither of the two solutions will be "zero-cost" (we need to
> retain ABI backward compatibility) so i think we need to find another way
>
> Thanks a lot
>
> --
> Roberto De Ioris
> http://unbit.com
> _______________________________________________
> uWSGI mailing list
> uWSGI@lists.unbit.it
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi Roberto,<div><br></div><div>Thanks for the response, I created an \
issue here: <a href="https://github.com/unbit/uwsgi/issues/1762">https://github.com/unbit/uwsgi/issues/1762</a></div><div><br></div><div>--nate</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 20, 2018 at 2:24 PM, \
Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" \
target="_blank">roberto@unbit.it</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br> > Because of \
the... unique... way that macOS handles the standard `environ`<br> > when running \
as a shared library[1], uWSGI segfaults under certain<br> > conditions on macOS \
when built as a CPython extension (pyuwsgi).<br> ><br>
> What many projects faced with this issue do is something like:<br>
><br>
> #if defined(__APPLE__) && defined(UWSGI_AS_SHARED_<wbr>LIBRARY)<br>
> #include <crt_externs.h><br>
> #define environ (*_NSGetEnviron())<br>
> #else<br>
> extern char **environ;<br>
> #endif<br>
><br>
> uWSGI does something similar but instead of the preprocessor define,<br>
> assigns `environ` to the return of `_NSGetEnviron()` at runtime. However,<br>
> this approach doesn't work because after a `setenv()`, the address in<br>
> `environ` is no longer valid, and `_NSGetEnviron()` needs to be called<br>
> again. That's why the define works, since under that method, `environ`<br>
> always points at the address returned by `_NSGetEnviron()`.<br>
><br>
> I made a naive attempt at addressing the problem[2] by reinitializing<br>
> `environ` after the environment is manipulated, but it's not sufficient.<br>
> Rather than hunting through the code and reinitializing `environ`<br>
> everywhere, which is sure to be error prone and likely to introduce more<br>
> bugs in the future, I tried to just switch to using the define method.<br>
><br>
> Unfortunately, this doesn't work as the `uwsgi_server` and `uwsgi_app`<br>
> structs have an `environ` member, so there's a name conflict with the<br>
> defined `environ`. I have two possible solutions but I am not sure how<br>
> they'd be received by the uWSGI developers, so I wanted to get some<br>
> guidance before committing any effort:<br>
><br>
> 1. Rename the struct member.<br>
> 2. Replace access to `environ` throughout the code with a function call<br>
> returning either `environ` or `_NSGetEnviron()` as appropriate.<br>
><br>
> The first option seems the most future-proof as it avoids any cases in the<br>
> future where developers forget to use the function rather than `environ`<br>
> directly, but it might also be frustrating to have such a core name<br>
> changed. There are probably simpler solutions, however, as I am by no<br>
> means<br>
> a C expert with a lot of tricks up my sleeve.<br>
><br>
> Thanks,<br>
> --nate<br>
><br>
<br>
</div></div>Hi Nate, this is an interesting issue, would you like to move it in a<br>
github issue to reach wider audience ?<br>
<br>
By the way, neither of the two solutions will be "zero-cost" (we need \
to<br> retain ABI backward compatibility) so i think we need to find another way<br>
<br>
Thanks a lot<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Roberto De Ioris<br>
<a href="http://unbit.com" rel="noreferrer" target="_blank">http://unbit.com</a><br>
______________________________<wbr>_________________<br>
uWSGI mailing list<br>
<a href="mailto:uWSGI@lists.unbit.it">uWSGI@lists.unbit.it</a><br>
<a href="http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi" rel="noreferrer" \
target="_blank">http://lists.unbit.it/cgi-bin/<wbr>mailman/listinfo/uwsgi</a><br> \
</font></span></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic