Bug 201739
Summary: | Macaulay2: ppc build hangs, never finishes | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> | ||||
Component: | Macaulay2 | Assignee: | Rex Dieter <rdieter> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | dwmw2, extras-qa | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-01-07 01:08:09 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 179260, 213321 | ||||||
Attachments: |
|
Description
Rex Dieter
2006-08-08 17:35:39 UTC
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. |