Re: nxclient (NoMachine) after recent Leopard X package updates
Re: nxclient (NoMachine) after recent Leopard X package updates
- Subject: Re: nxclient (NoMachine) after recent Leopard X package updates
- From: Jeremy Huddleston <email@hidden>
- Date: Fri, 14 Dec 2007 15:49:48 -0800
alloca() is by design not very good for machines with limited stack
space. Traditional machines (eg: mips32) start stack at one end of
memory space and heap at the other and let the two grow until they hit
each other (global, text, and other "static" memory is always at one
end of memory in this case, so it often looks
like :GLOBL:TEXT:STACK:_______:HEAP: ... I don't know if that exact
ordering is correct or not, but you get the idea).
Other methods involve segmenting up memory space well in advanced and
limiting each "class" to an specific amount of space. Thus in the
case where we have 4G of VM and grow heap and stack from both ends
togehter, we can theoretically do alloca(2GB) and be ok. If we
segment out memory early and say "stack can't be more than 8M" and we
do alloca(2G), we die.
This is a *HUGE* oversimplification of the problem but should be
enough to get you to understand what's going on under the hood. From
my brief discussion, you might think "well then why do it that way?"
and the reason stems from mainly security as well as performance
concerns. You can get higher performance by designating a segment of
memory as always being text (that is, executable instruction code)
than to rely on flags for this set by the program in a page table. It
is also much more secure as you can easily disable writing to segments
of memory by address at a lower level (again, without needing to use
page table flags). By no means is this a full discussion, and there
are volumes of differing opinions on what is the best solution from a
systems standpoint.
Hope this helps,
Jeremy
On Dec 14, 2007, at 15:27, Mark J. Reed wrote:
If I may interject a dumb question born of not being familiar with the
codebase - is that a baby floating downstream with your bathwater?
What is wrong with alloca? Is it a buggy implementation? Or was it
being used in places where it shouldn't be because the mem needs to
stick around after the allocating function returns? Or something else?
Just curious...
On 12/14/07, Jeremy Huddleston <email@hidden> wrote:
On Dec 14, 2007, at 10:37, Paul Ingram wrote:
I've had at least a dozen X11 crashes using NX with the 1.2a* builds
of Xquartz. Sometimes it would be days between crashes, sometimes
only minutes. It always seemed to occur when switching focus and
xemacs was often involved.
Each time I this happened I needed to restart my computer before NX
would work again.
On the upside, the notorious yellow cursor problem was fixed. That's
almost worth taking the crashes for.
I've upgraded to the new 1.2.1 build and haven't seen a crash in
about 6 hours of use so it's probably still too early to be certain
that the problem is fixed.
You probably mean 2.1.1.
I believe a good handful of the crashes were caused by alloca()
related issues. So 2.1.1 should see a nice stability improvement
because we are now not using alloca().
--Jeremy
--
Mark J. Reed <email@hidden>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden