[gmx-developers] gmx master: compiling on mac and segfault

Fri Jul 27 04:56:43 CEST 2012

On Fri, Jul 27, 2012 at 4:26 AM, Roland Schulz <roland at utk.edu> wrote:

> On Thu, Jul 26, 2012 at 10:12 PM, Szilárd Páll <szilard.pall at cbr.su.se>
> wrote:
> > On Fri, Jul 27, 2012 at 12:07 AM, Roland Schulz <roland at utk.edu> wrote:
> >>
> >> On Thu, Jul 26, 2012 at 8:09 AM, Jochen Hub <jhub at gwdg.de> wrote:
> >> > Hi,
> >> >
> >> > I am trying to compile and run the git master on my Macbook air (OS X
> >> > Lion). Without success. If I compile with a newer gcc (4.5 or newer,
> >> > installed from Macports), I get errors like (does this have to do with
> >> > AVX?)
> >> >
> >> > [  1%] Building C object
> >> > src/gromacs/CMakeFiles/libgromacs.dir/gmxpreprocess/add_par.c.o
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:66:no
> such
> >> > instruction: `vmovups 0(%r13), %ymm0'
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:69:no
> such
> >> > instruction: `vmovups %ymm0, 24(%rdi)'
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:79:no
> such
> >> > instruction: `vmovss 0(%r13), %xmm1'
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:83:no
> such
> >> > instruction: `vmovss %xmm1, 24(%rdi,%r9,4)'
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:99:no
> such
> >> > instruction: `vmovss 0(%r13), %xmm2'
> >> > /var/folders/ys/rh9lzqpj7854h34d2__mznph0000gn/T//ccPxJmjg.s:102:no
> such
> >> > instruction: `vmovss %xmm2, 24(%rdi,%r9,4)'
> >>
> >> What is GMX_ACCELERATION set to? Make sure it isn't set to AVX or that
> >> if it is that your cflags contain -mavx.
> >>
> >> > On a gcc 4.4 or earlier, compiling works fine, but mdruns stops with a
> >> > segfault. A backtrace in gdb gives the following. Seems like something
> >> > goes wrong in FFTW (which was compiled with the same gcc and with
> >> > --enable-threads --enable-sse --enable-sse2).
> >> >
> >> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> >> > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000048
> >> > [Switching to process 44300 thread 0x1b03]
> >> > 0x0000000100050ebd in gomp_resolve_num_threads ()
> >> > (gdb) bt
> >> > #0  0x0000000100050ebd in gomp_resolve_num_threads ()
> >> > #1  0x0000000100050fc3 in GOMP_parallel_start ()
> >> > #2  0x00000001004c0bc2 in fft5d_plan_3d ()
> >> > #3  0x0000000100434a52 in gmx_parallel_3dfft_init ()
> >> > #4  0x000000010046b6fc in gmx_pme_init ()
> >> > #5  0x0000000100026ab3 in mdrunner (nthreads_requested=4, fplog=0x0,
> >> > cr=0x102100b40, nfile=36, fnm=0x103808200, oenv=0x101000c10,
> bVerbose=0,
> >> > bCompact=1, nstglobalcomm=-1, ddxyz=0x1013c0e04, dd_node_order=1,
> rdd=0,
> >> > rconstr=0, dddlb_opt=0x10002e26a "auto", dlb_scale=0.800000012,
> >> > ddcsx=0x0, ddcsy=0x0, ddcsz=0x0, nstepout=100, resetstep=-1,
> >> > nmultisim=0, repl_ex_nst=0, repl_ex_nex=0, repl_ex_seed=-1, pforce=-1,
> >> > cpt_period=15, max_hours=-1, deviceOptions=0x10002e276 "", Flags=7168)
> >> > at /Users/jhub/src/gmx/gromacs/src/programs/mdrun/runner.c:844
> >> > #6  0x0000000100024f2d in mdrunner_start_fn (arg=0x101005d60) at
> >> > /Users/jhub/src/gmx/gromacs/src/programs/mdrun/runner.c:173
> >> > #7  0x0000000100242bfb in tMPI_Thread_starter ()
> >> > #8  0x00007fff9785f8bf in _pthread_start ()
> >> > #9  0x00007fff97862b75 in thread_start ()
> >>
> >> Did you try a version which included the bugfix for issue 900
> >> (002c4985c1d839810816b5c1ba347634b7d7cabb)?
> >> What exact compiler did you try? Is it LLVM-gcc or gcc with gcc
> >> backend (not llvm)? Also so far we only saw OpenMP problems with
> >> llvm-gcc 4.2 not 4.4. So more details would be useful to know.
> >>
> >> > Can anyone give me a hint how to fix this? Or is the master so
> >> > experimental that it is not interned to be used at all right now?
> >> No it should work pretty well and the testsuite is run before any
> >> commit. And the Jenkins configuration does include gcc 4.2 and 4.6 on
> >
> >
> > It does, but it uses only the auto-detected GMX_ACCELERATION which gets
> set
> > to SSE4.1 (as the CPUs in the machine don't support AVX).
> >
> > This does suggest to me that we might want to have more thorough
> (probably
> > nightly) builds with virtually all-vs-all important settings (compilers,
> > platforms, mandatory libraries, etc.).
>
> anywhere close to all-vs-all will never be possible unless we
> drastically reduce the possible compile time options.
> 10 compilers (including different versions) * 3 parallelization * gsl
> on/off * xml on/off * 3 different FFT * double on/off * 5
> accelerations * openmp on/off * 5 os (including version)

> is over 30,000 possible configurations and this doesn't even include
> yet (gpu, different library versions, more exotic os, older os
> versions, cmake versions, ....)
>
> Of course that doesn't mean it wouldn't be useful to have more
> different options (or better combinations) and that nightly tests
> might help with that.

Note the *important* adjective above ;)

XML and GSL is irrelevant and I think we can be a bit smart and prune some
configs that we can be fairly confident that they're more or less
equivalent.

Not sure what you mean by "3 parallelization"; if it's MPI, tMPI, and
OpenMP than it's two or four (depending on weather we want to test both
MPI/tMPI + OpenMP on/off). The number of (CPU) acceleration types can be
slightly reduced as I wouldn't consider anything but SSE/AVX that highly
important. Also, I'd consider only three OS-es and on some of them not all
compilers are available.

So we're left with ~ 10x2x3x2x4 = 480 configs per OS (and less on Win).
Assuming that each build takes ~3 min which is the case on 2-3 cores (note
that I mean build only!), all builds would take 24h per OS. Now, we'll have
to dedicate a few cores on a Mac to the task (as it can't be easily
virtualized), so the rest, Linux + Win, we can easily run on half of a
build server (8 out of 16 cores) in 24h or so. So I don't think it's really
unfeasible, even if we'd run such thorough tests for two branches.

Even if we multiply the above 24h/4cores/OS with 3-4, it's still a rather
manageable number especially that AFAIK hardware resources are not the
biggest issue.

Of course if we want to be strict about all-vs-all we'll lose quickly
against the sheer number of combinations. The above exercise was only meant
to show that even a *very* extensive weekly building can be feasible.  Also
note that IMO we should separate builds and tests for everything but gerrit
auto-triggered stuff which should be kept at the necessary minimum.

Cheers,
Sz.

> Roland
>
>
>
> >
> > --
> > Szilárd
> >
> >>
> >> Mac. So it is somewhat surprising that you have 2 independent
> >> problems.
> >>
> >> Roland
> >>
> >> >
> >> > Many thanks,
> >> > Jochen
> >> >
> >> >
> >> > --
> >> > ---------------------------------------------------
> >> > Dr. Jochen Hub
> >> > Computational Molecular Biophysics Group
> >> > Institute for Microbiology and Genetics
> >> > Georg-August-University of Göttingen
> >> > Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany.
> >> > Phone: +49-551-39-14189
> >> > http://cmb.bio.uni-goettingen.de/
> >> > ---------------------------------------------------
> >> > --
> >> > gmx-developers mailing list
> >> > gmx-developers at gromacs.org
> >> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >> > Please don't post (un)subscribe requests to the list. Use the
> >> > www interface or send it to gmx-developers-request at gromacs.org.
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> >> 865-241-1537, ORNL PO BOX 2008 MS6309
> >> --
> >> gmx-developers mailing list
> >> gmx-developers at gromacs.org
> >> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >> Please don't post (un)subscribe requests to the list. Use the
> >> www interface or send it to gmx-developers-request at gromacs.org.
> >
> >
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20120727/29218411/attachment.html>