Re: Segfault upon exit when rxvt-unicode 9.22 is compiled against Perl 5.32

2020-07-01 Thread Marc Lehmann
On Tue, Jun 30, 2020 at 10:46:54PM -0500, Rob Hoelz  wrote:
> That would work, but wouldn't that potentially break users' extensions by 
> getting rid
> of global destruction time?  For example, if a user did something like this:

No, because a) perl doesn't guarantee calling destructors on process
exit and b) perl corrupts data structures at this stage, so it's not a
reliable mechanism in any case. (See e.g.
http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-or-how-perl-6-deals-with-bugs.html).

> ...the clean up code in the guard would never run, right?

Yes, but IMnsHO that's better than if it were to run only sometimes, and
lead to crashes at other times, but it all seemed to work during development.

> Also, if any *other* library decided to call getenv in an exit handler,
> the segfault would pop up again.

The solution could be further optimised by calling _exit, leading to even
faster exit times.

> on the details of the copying and swapping of the environment that 
> rxvt-unicode does (I'm
> guessing it has to do with urxvtd), but is there a way the code could be 
> modified to restore
> environ to a valid pointer before main() returns?

Possibly. But anything added makes things bigger and slower, and this must
be offset by a tangible gain.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode


Re: Segfault upon exit when rxvt-unicode 9.22 is compiled against Perl 5.32

2020-06-30 Thread Rob Hoelz
On Tue, 30 Jun 2020 09:26:17 +0200
Marc Lehmann  wrote:

> Hi, and thanks for your report!
> 
> On Mon, Jun 29, 2020 at 07:40:41PM -0500, Rob Hoelz 
> wrote:
> > I just upgraded my system (Arch Linux) to Perl 5.32, and I noticed
> > that urxvt started dropping core files upon exit.  I dug into this,
> > and it seems that unlike Perl 5.30 or previous versions, Perl 5.32
> > unconditionally calls getenv("PERL_DESTRUCT_LEVEL") in
> > perl_destruct, which is called at atexit handler time.  Because
> > rxvt_term makes a copy of the original process environment which it
> > assigns to environ, and then it frees that copy in its destructor
> > when ev_run is wrapping up, this results in a use-after-free when
> > perl_destruct is called, and occasionally a segfault.
> > 
> > I patched my local rxvt-unicode package with a workaround - it just
> > sets environ = rxvt_environ after ev_run returns, but maybe a
> > better approach exists.  
> 
> Hmm, I think the altogether better solution is to simply get rid of
> ~rxvt_perl_interp. Does something like this also work for you?
> 
>rxvt_perl_interp::~rxvt_perl_interp ()
>{
>}
> 
> i.e. simply remove all code from ~rxvt_perl_interp.
> 
> That's basically what I aim for in the next release.
> 

That would work, but wouldn't that potentially break users' extensions by 
getting rid
of global destruction time?  For example, if a user did something like this:

  use Guard;

  our $g = guard {
# clean up
  };

...the clean up code in the guard would never run, right?  Also, if any *other* 
library
decided to call getenv in an exit handler, the segfault would pop up again.  
I'm not super clear
on the details of the copying and swapping of the environment that rxvt-unicode 
does (I'm
guessing it has to do with urxvtd), but is there a way the code could be 
modified to restore
environ to a valid pointer before main() returns?

-Rob

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode


Re: Segfault upon exit when rxvt-unicode 9.22 is compiled against Perl 5.32

2020-06-30 Thread Marc Lehmann
Hi, and thanks for your report!

On Mon, Jun 29, 2020 at 07:40:41PM -0500, Rob Hoelz  wrote:
> I just upgraded my system (Arch Linux) to Perl 5.32, and I noticed that urxvt 
> started dropping core files upon exit.  I dug into this, and it seems
> that unlike Perl 5.30 or previous versions, Perl 5.32 unconditionally calls 
> getenv("PERL_DESTRUCT_LEVEL") in perl_destruct, which is called at
> atexit handler time.  Because rxvt_term makes a copy of the original process 
> environment which it assigns to environ, and then it frees that copy
> in its destructor when ev_run is wrapping up, this results in a 
> use-after-free when perl_destruct is called, and occasionally a segfault.
> 
> I patched my local rxvt-unicode package with a workaround - it just sets 
> environ = rxvt_environ after ev_run returns, but maybe a better approach
> exists.

Hmm, I think the altogether better solution is to simply get rid of
~rxvt_perl_interp. Does something like this also work for you?

   rxvt_perl_interp::~rxvt_perl_interp ()
   {
   }

i.e. simply remove all code from ~rxvt_perl_interp.

That's basically what I aim for in the next release.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode


Segfault upon exit when rxvt-unicode 9.22 is compiled against Perl 5.32

2020-06-30 Thread Rob Hoelz
Hello!

I just upgraded my system (Arch Linux) to Perl 5.32, and I noticed that urxvt 
started dropping core files upon exit.  I dug into this, and it seems
that unlike Perl 5.30 or previous versions, Perl 5.32 unconditionally calls 
getenv("PERL_DESTRUCT_LEVEL") in perl_destruct, which is called at
atexit handler time.  Because rxvt_term makes a copy of the original process 
environment which it assigns to environ, and then it frees that copy
in its destructor when ev_run is wrapping up, this results in a use-after-free 
when perl_destruct is called, and occasionally a segfault.

I patched my local rxvt-unicode package with a workaround - it just sets 
environ = rxvt_environ after ev_run returns, but maybe a better approach
exists.

-Rob Hoelz

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode