Thanks. I've forwarded this to a bug opened today which looks related.
----- Forwarded message from Marc Lehmann <[EMAIL PROTECTED]> -----
Date: Fri, 28 Jul 2006 18:46:54 +0200
From: Marc Lehmann <[EMAIL PROTECTED]>
To: Decklin Foster <[EMAIL PROTECTED]>
Subject: Re: [rxvt-unicode] stupid non-important buffer overwriting bug
On Mon, Jul 24, 2006 at 05:48:06PM -0400, Decklin Foster <[EMAIL PROTECTED]>
wrote:
> point urxvtd segfaulted. I was only able to reproduce this when forking
> the daemon. In gdb I determined that locale had been corrupted:
>
> #0 0xb7b63a7b in getenv () from /lib/tls/i686/cmov/libc.so.6
> #1 0xb7b57803 in setlocale () from /lib/tls/i686/cmov/libc.so.6
seems more like the environment was corrupted (if it crashes within getenv).
> Which appeared to come from something overwriting static storage:
>
> (gdb) print curlocale
> $1 = "[EMAIL PROTECTED]", '\0' <repeats 116 times>
This might be a symptom of the corrupted environment. If setlocale crashes
when called with that curlocale, its buggy (likely its not, as it has no
reason to call getenv if it gets passed a valid locale).
> How this is happening, I'm not really sure. I've also seen things like
> this show up:
>
> Watchpoint 4: locale
>
> Old value = 0x8190f98 "en_US.UTF-8"
> New value = 0x81910d8 "`C\031\bSER=firefox"
Do you know whwre this happens, and in in which function?
> I saw the comment in rxvtperl.xs about perl destroying the current
> locale (and maybe other parts of the environment) and suspect it could
> be the culprit.
Since I cannot debug this easily, let me explain whats going on with perl,
the environment, and locales.
Perl destroys the current locale, it does not destroy the environment. What
it does is take a copy of the environment, to make sure it can free() the
stuff again. Actually, perl has a number of strategies to deal with the
environment.
rxvtd sort of emulates processes. To do this, it has to save the environment
of every window "pseudo-process". It also chdir's to the right directory when
it creates the window.
That means there is an environ-pointer for every terminal (rxvt_term->envv).
It's only used for locale-variables, the initial shell environment for the
subprocess, and possibly lots of other os-specific things (xim etc.).
There is also the original environment from starting rxvtd.
Now, perl also "messes" with the environment. It has to to do this, as there
is no standardised and nice way to manipulate the environment in unix.
For this reason, everytime urxvtd calls into perl, it restores the original
startup environment.
In earlier times, this was also necessary to avoid environment poisoning
by urxvtc. And it just makes more sense to give perl a single, consistent
environment independnet of which window context calls it.
Now, environment corruption as seen by you happens easily when some other
part (perl, libc, x...) manipulates the environment, deleting and free()ing
stuff that never has been allocated in the first place. Or something similar.
It might be perl-related, but could have lots of other reasons.
The logic is:
a) rxvtd has its own environment. Its used for and by perl only.
b) everytime a callback executes, it will set the environment pointer
(make_current ()).
c) when a window gets destroyed, env etc. gets corrupted, but thats no
problem, as its being set to somethign correct before calling anything
important.
d) startup is also noin-trivial, urxvt calls setlocale and restores the env a
few times there, too.
If one of those assumptions/rules is broken, you will get behaviour as you
have seen.
It could be caused by something completely else, too.
If it were easily reproducable I could debug it... as it is, I can only
glance over the code and guess.
> There is also a strcpy instead of strncpy in rxvt_push_locale, but it
> seems innocent (I thought at first it might be a simple matter of that,
> but no).
Indeed, the strcpy is correct, whats broken is the strncpy. This is "fixed"
in CVS (it will just rxvt_fatal in that case).
Both of those are, of course, just symptoms.
> wants to happen...). I can't reproduce with 7.7, either, even though I
> don't see any code changes that look like the problem.
If its random memory corruption, a few lines of code somewhere else, or
a different compiler, can easily mask or unmask the problem. environment
corruption is usually easier to reproduce (it mostly depends on order of
calls).
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
----- End forwarded message -----
--
things change.
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
