On Feb 14, 2011, at 9:05 PM, ext Karol Lewandowski wrote:
On 02/14/2011 05:39 PM, Lauri T. Aarnio wrote:
You could also try if the vm settings (of Linux kernel) have any
effect
on the bug. e.g. change what you have in
/proc/sys/kernel/randomize_va_space, /proc/sys/vm/mmap_min_addr might
also have some effect, etc.
Interesting. With kernel.randomize_va_space=0 I can easily trigger
this using following Makefile
once:
sb2 -m devel -- echo bug >LOG.once.stdout 2>LOG.once.stderr
At least it's reproductible this time... I'm using 64bit kernel and
userland for host system while tools are 32bit (both are Debian
squeeze). Stock Debian 2.6.32-squeeze kernel (I've also tried
2.6.37 with the same result).
We have seen the same effect: Changes to the vm randomization settings
do not remove the problems, but instead make them permanent and easier
to reproduce. Unfortunately it seems that not all newer vm features
(of the linux kernel) are too stable, or to put it another way, the
kernel and ld.so are not co-operating as they should be. The kernel is
usually the place which can be considered faulty: It should remain
compatible with older loaders as well (e.g. when we use something like
the ld.so from glibc 2.5, it should still work with the newer kernels!)
Anyway, one more thing to test out now is to use strace; check if the
crashing program is able to reserve memory with brk. See if brk starts
to return the same value just before the program crashes. If that is
the case, then your problem probably looks and feels very much like
what we had seen here in the past.
btw, I'm using ubuntu lucid 64-bit, tools are 32-bit (but not from
ubuntu or debian, instead you can probably guess where those came
from :-) and I haven't seen this problem since we finally got the fix
to ubuntu.
Lauri
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
