When trying to emerge Mozilla or Mozilla Firebird using either GTK or GTK2 the compiler SegFaults after a few minutes of compiling. Problem is easily avoided by disabling the openmosix services in /etc/init.d/openmosix but can cause problems for OpenMosix users trying to set up Gnome desktops which require mozilla. Reproducible: Always Steps to Reproduce: 1. USE="gtk2" ;emerge mozilla 2. 3. Actual Results: I tried to compile approximately 3 times and it SegFaulted on the same code every time, as of this writing i have disabled the openmosix services and finally got mozilla to compile so i do not have the exact output. Expected Results: Finished compiling OpenMosix kernel 2.4.22 "cluster" 2X P4 1.8ghz machine with 512M RAM P4 2.4ghz machine with 512M RAM
*** Bug 32310 has been marked as a duplicate of this bug. ***
WORKSFORME on ~x86 with the migshm patch applied - can someone confirm the continued existence of this bug without the migshm patch? And if so, do we need to enable migshm by default in openmosix kernel source ebuilds?
I'm having similar problems (linux-2.4.22-openmosix-r3) with emerges blocking or segfaulting in different places. Stopping the om-services doesn't work, I really need to boot a non-openmosix kernel (linux-2.4.22-gentoo-r5) to have an emerge finish successfully. Sometimes the emerge hangs when trying to extract the archive, or during the configure phase.
It would be nice to have the migshm patch in openmosix-kernels! Is there an ebuild that has it already? I wonder, if apache will work on openmosix with migshm finally?
It sounds like this isn't a mozilla problem but an openmosix problem. Reassigning to tantive for investigation or triage.
I am having segfault problems when running emerge, but preventing the processes from migrating (mosrun -h -L <command>) is a workaround. I may try the following fix: http://article.gmane.org/gmane.linux.cluster.openmosix.general/7432
Now it's known "gs-bug". To be sure, you can check it by: 1) run `gdb /lib/libpthread.so.0` 2) type 'disassemble pthread_self' 3) and, finally, check output for availability of "%gs" register segment (something like "mov %gs:0x8,%eax"). Possible ways to eliminate this bug: 1) wait, until it'll be fixed in one of the oM's patchset's ;-) 2) recompile your glibc with CFLAGS="...-march=pentium2 -mcpu=pentium2..." Otherwise, every time you run pthread-based application - run it at your home node, using "mosrun -h"
*** Bug 37307 has been marked as a duplicate of this bug. ***
