gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Bug#572538: gclcvs dies at startup when run by non-root


From: Faré
Subject: [Gcl-devel] Re: Bug#572538: gclcvs dies at startup when run by non-root user
Date: Thu, 29 Apr 2010 12:01:30 -0400

On 7 April 2010 14:48, Camm Maguire <address@hidden> wrote:
> severity 572538 important
> thanks
>
> Greetings, and thank you for your detailed feedback.  This does appear
> quite kernel/platform specific, as the default /sbin/sysctl
> vm.mmap_min_addr on my system is 0, (default kernel, i386), and of
> course I cannot reproduce your problem.  My guess is that this is also
> the the default, (or the also working 65536, which probably means
> "any") on the autobuilder which contructed your package.
>
> The gcl binary is saved via unexec from an executing state on a
> machine which successfully built the package (same as emacs).  My
> guess also is that if you built from source, you would likely get a
> working image dump.  gclcvs attempts to detect whether it can get more
> heap room by lowering its start address at configure time.  If this
> works, a linker script is constructed
> (/usr/lib/gcl-2.7.0/unixport/gcl.script) with the correct
> instructions, and perhaps 128Mb extra heap is available.  I think you
> have found a situation in which such an "optimized" binary is not
> portable across multiple kernel configurations.
>
> This is not new.  gcl must also work around sbrk randomization by the
> kernel, which it attempts to do automatically at runtime.  It tests
> segfault address recovery at first run of (si::sgc-on), and disables
> the facility if broken on the running machine.  Certain arm machines
> allowed certain assembly instructions that others simply ignored.
> Finally, if some kernel security package prohibits execution from the
> .data section, gcl will also bail.
>
> I think that this is best addressed by a trap statement in the wrapper
> script pointing to possible kernel settings needing adjustment.
> Perhaps an external webpage with updated info as time goes on.
>
> Do you agree?
>
I mostly agree. But additionally, I'd say it would be nice if the
"optimization" was careful not to go as low as zero, but stayed on the
right side of a global minimum (say 64K) as well as any detected
limitation (including checking the sysctl when available). This
matters especially if/when gcl is compiled as root, where some
limitations don't apply that will apply to the user who tries to run
same "optimized" binary.

Sorry for late reply, email got categorized in a folder I don't often check.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Lisp programmer available: Will write code
that writes code that writes code for food. — Rob Warnock




reply via email to

[Prev in Thread] Current Thread [Next in Thread]