I assume this bug is just a placeholder while you debug the issue? What process
is stuck and what is it doing?

The Logs: link above seems not to work.

As I'm sure you'll have worked out for yourself in the last four months, it's in
an endless loop re-executing itself...

execve("../bin/M2", ["../bin/M2", "-q", "--silent", "--stop", "-e",
"errorDepth=0", "./makesyms.m2", "-e", "exit 0"], [/* 67 vars */]) = 0

Did you make any progress investigating _why_ it's doing that?

(gdb) break execve
Function "execve" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (execve) pending.
(gdb) run
Starting program:
/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2 
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 268388672 (LWP 5864)]
Breakpoint 2 at 0xf519fa8: file ../sysdeps/unix/sysv/linux/execve.c, line 32.
Pending breakpoint "execve" resolved
[Switching to Thread 268388672 (LWP 5864)]

Breakpoint 2, __execve (
    file=0xfc56f788
"/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2",
argv=0xfc56f5e4, envp=0xfc56f5ec)
    at ../sysdeps/unix/sysv/linux/execve.c:60
60        return INLINE_SYSCALL (execve, 3, file, argv, envp);
(gdb) bt
#0  __execve (
    file=0xfc56f788
"/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2",
argv=0xfc56f5e4, envp=0xfc56f5ec)
    at ../sysdeps/unix/sysv/linux/execve.c:60
#1  0x0f51a674 in *__GI_execvp (
    file=0xfc56f788
"/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2",
argv=0xfc56f5e4) at execvp.c:75
#2  0x1000a5e4 in ?? ()
#3  0x1000b7c0 in __gmp_default_allocate ()
#4  0x0f48dd4c in generic_start_main (
    main=0x1000b7b0 <__gmp_default_allocate+1440>, argc=1, ubp_av=0xfc56f5e4, 
    auxvec=0xfc56f6c8, init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=<value optimized out>)
    at ../csu/libc-start.c:231
#5  0x0f48df74 in __libc_start_main (argc=1, ubp_av=0xfc56f5e4, 
    ubp_ev=<value optimized out>, auxvec=0xfc56f6c8, 
    rtld_fini=0xffceba0 <_dl_fini>, stinfo=0x102b0108, 
    stack_on_entry=0xfc56f5d0)
    at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:127
#6  0x00000000 in ?? ()

That's more useful if we don't let it strip itself during the build (which will
also be screwing your -debuginfo packages)...

(gdb) bt
#0  __execve (
    file=0xf81bf782
"/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2.tmp",
argv=0xf81bf5e4, envp=0xf81bf5ec)
    at ../sysdeps/unix/sysv/linux/execve.c:60
#1  0x0f51a674 in *__GI_execvp (
    file=0xf81bf782
"/home/dwmw2/working/extras/Macaulay2/devel/Macaulay2-0.9.95/Macaulay2/bin/M2.tmp",
argv=0xf81bf5e4) at execvp.c:75
#2  0x1000a5e4 in Macaulay2_main (argc=1, argv=0xf81bf5e4) at M2lib.c:371
#3  0x1000b7c0 in main (argc=-132384894, argv=0xf81bf5e4) at main.c:7

Aha. It's the code which sets the ADDR_NO_RANDOMIZE bit in the personality and
re-execs itself. That doesn't always work as expected though -- when running
32-bit processes on ppc64 and x86_64, those extra bits get lost when we set the
personality to 32-bit. So it just sets that bit and re-executes itself over and
over again. A simple fix is to add '--no-personality' to the command line when
it re-execs, to avoid the loop.

I'm not sure if we actually _need_ to turn randomisation off -- if we do, that's
probably separate bug and should be fixed rather than worked around with a hack
like this.

Created attachment 144462 [details]
fix endless loop

This adds '--no-personality' to the command line when re-executing, so we don't
get stuck in an endless loop when running 32-bit M2 on 64-bit machines.

I have to say I'm not massively impressed that the maintainer didn't manage to
fix this fairly simple and obvious bug in over four months. Fedora Extras is
not somewhere to just dump packages and forget them; we need active
maintenance.

The lack of inheritance of personality is arguably a kernel bug; bug #220892

David, thanks so much for the adept detective-work.

Should I add this patch to FC-5, FC-6 and devel packages or will you do it?

We should _also_ fix the kernel, but M2 shouldn't fail like this even if the
kernel doesn't let it inherit the personality flags over exec.

David, I won't have a chance to get to this for 1-2 weeks, so you certainly have
my blessing to patch in the meantime.

Nevermind, I *should* be able to find the requisite few moments within the next
few days to incorporate the patch.

%changelog
* Sat Jan 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.9.95-3
- re-enable ppc build (#201739)

Cross your fingers, patched build queue'd/building now:
http://buildsys.fedoraproject.org/build-status/job.psp?uid=25172

Re: comment #7
It just occurs to me that if personality isn't inherited, several other
personality modifiying/disabling apps will see breakage, (Extras lisps mostly
that I'm aware of) including gcl, sbcl, cmucl

Builds completed, closing.