Re: [petsc-users] Question about correctly catching fp_trap

2019-01-07 Thread Balay, Satish via petsc-users 
On Mon, 7 Jan 2019, Sajid Ali via petsc-users wrote:

> Hi Satish,
> 
> Please find attached the logs for the previous patch for petsc+debug.

>>>
Compilers:
  C Compiler: 
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpicc
  -fPIC  -g3
  C++ Compiler:   
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpic++
  -g   -fPIC
  Fortran Compiler:   
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpif90
  -fPIC -g
Linkers:
  Shared linker:   
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpicc
  -shared  -fPIC  -g3
  Dynamic linker:   
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpicc
  -shared  -fPIC  -g3



So the build did use '-g' flag - so it looks good to me..

Satish

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-07 Thread Balay, Satish via petsc-users 
On Mon, 7 Jan 2019, Sajid Ali wrote:

> @Satish Balay  : I tried building with the patch and
> don't see any difference. Do you want me to send you the config and build
> logs to investigate further?

Hm - you should see '-g' for 'petsc+debug'. Send the logs. 

I have - in 
/home/balay/spack/opt/spack/linux-fedora29-x86_64/gcc-8.2.1/petsc-3.10.3-q5v3hfhsecvhf3geffeyrm5j3bm6orup/.spack/build.out

Compilers:
  C Compiler: /home/petsc/soft/mpich-3.3b1/bin/mpicc-g3 
  C++ Compiler:   /home/petsc/soft/mpich-3.3b1/bin/mpic++  -g  
  Fortran Compiler:   /home/petsc/soft/mpich-3.3b1/bin/mpif90   -g  
Linkers:
  Shared linker:   /home/petsc/soft/mpich-3.3b1/bin/mpicc  -shared-g3
  Dynamic linker:   /home/petsc/soft/mpich-3.3b1/bin/mpicc  -shared-g3
<

Note: the patch I sent earlier fails for 'petsc~debug' - but the
attached updated patch should work for it.

> Apart from the -g flag, as I've stated above
> another bug is that petsc uses the system gdb (rhel-7) and not the gdb
> associated with the gcc that was used to build petsc.

It uses gdb from your PATH - so you can setup your PATH to use the appropriate 
gdb.

Satish
diff --git a/var/spack/repos/builtin/packages/petsc/package.py 
b/var/spack/repos/builtin/packages/petsc/package.py
index 99800b501..b40173fe6 100644
--- a/var/spack/repos/builtin/packages/petsc/package.py
+++ b/var/spack/repos/builtin/packages/petsc/package.py
@@ -195,10 +195,7 @@ class Petsc(Package):
'--download-hwloc=0',
'CFLAGS=%s' % ' '.join(spec.compiler_flags['cflags']),
'FFLAGS=%s' % ' '.join(spec.compiler_flags['fflags']),
-   'CXXFLAGS=%s' % ' '.join(spec.compiler_flags['cxxflags']),
-   'COPTFLAGS=',
-   'FOPTFLAGS=',
-   'CXXOPTFLAGS=']
+   'CXXFLAGS=%s' % ' '.join(spec.compiler_flags['cxxflags'])]
 options.extend(self.mpi_dependent_options())
 options.extend([
 '--with-precision=%s' % (
@@ -209,6 +206,13 @@ class Petsc(Package):
 '--with-debugging=%s' % ('1' if '+debug' in spec else '0'),
 '--with-64-bit-indices=%s' % ('1' if '+int64' in spec else '0')
 ])
+if '+debug' in spec:
+options.append('--with-debugging=%s')
+else:
+options.extend(['COPTFLAGS=',
+'FOPTFLAGS=',
+'CXXOPTFLAGS='])
+
 # Make sure we use exactly the same Blas/Lapack libraries
 # across the DAG. To that end list them explicitly
 lapack_blas = spec['lapack'].libs + spec['blas'].libs

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-07 Thread Sajid Ali via petsc-users 
 >   Anyway the FPE occurs in MatSolve_SeqAIJ_NaturalOrdering which usually
indicates a zero on the diagonal of the matrix. Is that possible?
It looks like this is indeed the case here. Thanks for the hint.

@Satish Balay  : I tried building with the patch and
don't see any difference. Do you want me to send you the config and build
logs to investigate further? Apart from the -g flag, as I've stated above
another bug is that petsc uses the system gdb (rhel-7) and not the gdb
associated with the gcc that was used to build petsc.

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Smith, Barry F. via petsc-users 
 
   Looks like spack did not compile PETSc with the -g option; which is strange 
because in both debug and and --with-debugging=0 PETSc ./configure make uses 
debug symbols

#0  __muldc3 (a=-6.6364040265716871e-306, b=1.1689456061105587e-305, 
c=-0.0024992568840190117, d=0.024886737403015963)
at 
/raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:1978
#1  0x7630fe87 in MatSolve_SeqAIJ_NaturalOrdering ()
   from 
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010

   Anyway the FPE occurs in MatSolve_SeqAIJ_NaturalOrdering which usually 
indicates a zero on the diagonal of the matrix. Is that possible?

   Barry


Satish,

  Does spack somehow turn off the -g ?

> On Jan 4, 2019, at 3:24 PM, Sajid Ali  
> wrote:
> 
> Trying it slightly differently, I do see it's a SIGFPE, arithmetic exception 
> but all it shows is that it's an error in TSSolve but no further than that. 
> 
> [sajid@xrm free_space]$ gdb ex_modify 
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from 
> /raid/home/sajid/packages/xwp_petsc/2d/free_space/ex_modify...done.
> (gdb) run -ts_type cn --args -fp_trap
> Starting program: /raid/home/sajid/packages/xwp_petsc/2d/free_space/ex_modify 
> -ts_type cn --args -fp_trap
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> warning: File 
> "/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/libstdc++.so.6.0.24-gdb.py"
>  auto-loading has been declined by your `auto-load safe-path' set to 
> "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
> To enable execution of this file add
> add-auto-load-safe-path 
> /raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/libstdc++.so.6.0.24-gdb.py
> line to your configuration file "/raid/home/sajid/.gdbinit".
> To completely disable this security protection add
> set auto-load safe-path /
> line to your configuration file "/raid/home/sajid/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
> info "(gdb)Auto-loading safe path"
> Solving a linear TS problem on 1 processor
> mx : 512, my: 512 lambda : 1.239840e-10
> 
> Program received signal SIGFPE, Arithmetic exception.
> __muldc3 (a=-6.6364040265716871e-306, b=1.1689456061105587e-305, 
> c=-0.0024992568840190117, d=0.024886737403015963)
> at 
> /raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:1978
> 1978
> /raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:
>  No such file or directory.
> Missing separate debuginfos, use: debuginfo-install blas-3.4.2-8.el7.x86_64 
> bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64 
> elfutils-libs-0.168-8.el7.x86_64 glibc-2.17-196.el7.x86_64 
> lapack-3.4.2-8.el7.x86_64 libattr-2.4.46-12.el7.x86_64 
> libcap-2.22-9.el7.x86_64 libgfortran-4.8.5-16.el7.x86_64 
> libxml2-2.9.1-6.el7_2.3.x86_64 systemd-libs-219-42.el7_4.4.x86_64 
> xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64
> (gdb) bt
> #0  __muldc3 (a=-6.6364040265716871e-306, b=1.1689456061105587e-305, 
> c=-0.0024992568840190117, d=0.024886737403015963)
> at 
> /raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:1978
> #1  0x7630fe87 in MatSolve_SeqAIJ_NaturalOrdering ()
>from 
> /raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
> #2  0x75ba61a8 in MatSolve ()
>from 
> /raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
> #3  0x76bc8a55 in PCApply_ILU ()
>from 
> /raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
> #4  0x76cde6eb in PCApply ()
>from 
> /raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
> #5

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Sajid Ali via petsc-users 
Trying it slightly differently, I do see it's a SIGFPE, arithmetic
exception but all it shows is that it's an error in TSSolve but no further
than that.

[sajid@xrm free_space]$ gdb ex_modify
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from
/raid/home/sajid/packages/xwp_petsc/2d/free_space/ex_modify...done.
(gdb) run -ts_type cn --args -fp_trap
Starting program:
/raid/home/sajid/packages/xwp_petsc/2d/free_space/ex_modify -ts_type cn
--args -fp_trap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: File
"/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/libstdc++.
so.6.0.24-gdb.py" auto-loading has been declined by your `auto-load
safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
add-auto-load-safe-path
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/libstdc++.
so.6.0.24-gdb.py
line to your configuration file "/raid/home/sajid/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/raid/home/sajid/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the
shell:
info "(gdb)Auto-loading safe path"
Solving a linear TS problem on 1 processor
mx : 512, my: 512 lambda : 1.239840e-10

Program received signal SIGFPE, Arithmetic exception.
__muldc3 (a=-6.6364040265716871e-306, b=1.1689456061105587e-305,
c=-0.0024992568840190117, d=0.024886737403015963)
at
/raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:1978
1978
/raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:
No such file or directory.
Missing separate debuginfos, use: debuginfo-install blas-3.4.2-8.el7.x86_64
bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64
elfutils-libs-0.168-8.el7.x86_64 glibc-2.17-196.el7.x86_64
lapack-3.4.2-8.el7.x86_64 libattr-2.4.46-12.el7.x86_64
libcap-2.22-9.el7.x86_64 libgfortran-4.8.5-16.el7.x86_64
libxml2-2.9.1-6.el7_2.3.x86_64 systemd-libs-219-42.el7_4.4.x86_64
xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0  __muldc3 (a=-6.6364040265716871e-306, b=1.1689456061105587e-305,
c=-0.0024992568840190117, d=0.024886737403015963)
at
/raid/home/sajid/packages/spack/var/spack/stage/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/gcc-7.3.0/libgcc/libgcc2.c:1978
#1  0x7630fe87 in MatSolve_SeqAIJ_NaturalOrdering ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#2  0x75ba61a8 in MatSolve ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#3  0x76bc8a55 in PCApply_ILU ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#4  0x76cde6eb in PCApply ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#5  0x76e3ad4a in KSP_PCApply ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#6  0x76e3bc36 in KSPInitialResidual ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#7  0x76dc0736 in KSPSolve_GMRES ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#8  0x76e1158e in KSPSolve ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#9  0x76fac311 in SNESSolve_KSPONLY ()
   from
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj/lib/libpetsc.so.3.010
#10 0x76f346c7 in SNESSolve ()
   from

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Sajid Ali via petsc-users 
Going by the advice given here : https://stackoverflow.com/a/2792735

I tried running the program, hoping to catch the FP exception and I got the
error I had before (which turned out to be due to an FP exception as per
previous petsc thread):

Missing separate debuginfos, use: debuginfo-install blas-3.4.2-8.el7.x86_64
bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64
elfutils-libs-0.168-8.el7.x86_64 glibc-2.17-196.el7.x86_64
lapack-3.4.2-8.el7.x86_64 libattr-2.4.46-12.el7.x86_64
libcap-2.22-9.el7.x86_64 libgfortran-4.8.5-16.el7.x86_64
libxml2-2.9.1-6.el7_2.3.x86_64 systemd-libs-219-42.el7_4.4.x86_64
xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) run -ts_type cn
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Killed
[sajid@xrm free_space]$ Starting program:
/raid/home/sajid/packages/xwp_petsc/2d/free_space/./ex_modify -ts_type cn
[setting tty state failed in terminal_inferior: Input/output error]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: File
"/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/libstdc++.
so.6.0.24-gdb.py" auto-loading has been declined by your `auto-load
safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
Solving a linear TS problem on 1 processor
mx : 512, my: 512 lambda : 1.239840e-10
[0]PETSC ERROR: - Error Message
--
[0]PETSC ERROR:
[0]PETSC ERROR: TSStep has failed due to DIVERGED_NONLINEAR_SOLVE, increase
-ts_max_snes_failures or make negative to attempt recovery
[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for
trouble shooting.
[0]PETSC ERROR: Petsc Development GIT revision:
bd27d3f284687498e4c4678d234c0e308a5bc236  GIT Date: 2019-01-02 11:00:20
-0600
[0]PETSC ERROR:
/raid/home/sajid/packages/xwp_petsc/2d/free_space/./ex_modify on a  named
xrm by sajid Fri Jan  4 14:47:56 2019
[0]PETSC ERROR: Configure options
--prefix=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/petsc-develop-2u6vuwagkoczyvnpsubzrubmtmpfhhkj
--with-ssl=0 --download-c2html=0 --download-sowing=0 --download-hwloc=0
CFLAGS= FFLAGS= CXXFLAGS= COPTFLAGS= FOPTFLAGS= CXXOPTFLAGS=
--with-cc=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpicc
--with-cxx=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpic++
--with-fc=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mpich-3.3-z5uiwmx24jylnivuhlnqjjmm674ozj6x/bin/mpif90
--with-precision=double --with-scalar-type=complex
--with-shared-libraries=1 --with-debugging=1 --with-64-bit-indices=0
--with-blaslapack-lib="/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/intel-mkl-2019.0.117-wzqlcijwx7odz2x5chembudo5leqpfh2/compilers_and_libraries_2019.0.117/linux/mkl/lib/intel64/libmkl_intel_lp64.so
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/intel-mkl-2019.0.117-wzqlcijwx7odz2x5chembudo5leqpfh2/compilers_and_libraries_2019.0.117/linux/mkl/lib/intel64/libmkl_sequential.so
/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/intel-mkl-2019.0.117-wzqlcijwx7odz2x5chembudo5leqpfh2/compilers_and_libraries_2019.0.117/linux/mkl/lib/intel64/libmkl_core.so
/lib64/libpthread.so /lib64/libm.so /lib64/libdl.so" --with-x=1
--with-clanguage=C --with-scalapack=0 --with-metis=1
--with-metis-dir=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/metis-5.1.0-nhgzn4kjskctzmzv35mstvd34nj2ugek
--with-hdf5=1
--with-hdf5-dir=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/hdf5-1.10.4-ltstvsxvyjue2gxfegi4nvr6c5xg3zww
--with-hypre=0 --with-parmetis=1
--with-parmetis-dir=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/parmetis-4.0.3-hw3j2ss7mjsc5x5f2gaflirnuufzptil
--with-mumps=0 --with-trilinos=0 --with-cxx-dialect=C++11
--with-superlu_dist-include=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/superlu-dist-develop-cpspq4ca2hnyvhx4mz7zsupbj3do6md3/include
--with-superlu_dist-lib=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/superlu-dist-develop-cpspq4ca2hnyvhx4mz7zsupbj3do6md3/lib/libsuperlu_dist.a
--with-superlu_dist=1 --with-suitesparse=0
--with-zlib-include=/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/zlib-1.2.11-ldu43taplg2nbkxtem346zq4ibhad64i/include
--with-zlib-lib="-L/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/zlib-1.2.11-ldu43taplg2nbkxtem346zq4ibhad64i/lib
-lz" --with-zlib=1
[0]PETSC ERROR: #1 TSStep() line 3673 in
/tmp/sajid/spack-stage/spack-stage-0boEG4/petsc/src/ts/interface/ts.c
[0]PETSC ERROR: #2 TSSolve() line 3847 in

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Smith, Barry F. via petsc-users 


  Why did you quit the debugger?

(gdb) quit  

Why didn't set the appropriate gdb option for catching floating point 
exceptions and then type cont ?

  Barry


> On Jan 4, 2019, at 10:24 AM, Sajid Ali  
> wrote:
> 
> Spack changes the configuration if debug variant is enabled as per this line :
> 
> '--with-debugging=%s' % ('1' if '+debug' in spec else '0'), 
> 
> I'm not sure what needs to be done to change this. 
> 
> In the meantime, I added -g to CFLAGS in the makefile and now I have this : 
> https://pastebin.com/wxf05BH0

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Sajid Ali via petsc-users 
I asked in the spack-slack channel and was told to include the explicitly
link the gfortran associated with the gcc version I build petsc with.
Following that advice, I'm using gcc@7.3.0, linking gcc@7.3.0/lib64 in
FFLAGS and setting -g option to CFLAGS in my makefile.

Yet, somehow the executable still picks up the system gfortran (It picks
both libgfortran.so.4 and libgfortran.so.3). Anything else I missed trying?

PS: My makefile looks like this:

[sajid@xrm free_space]$ cat makefile

ALL:

CFLAGS  = -g
FFLAGS  =
-L/raid/home/sajid/packages/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-7.3.0-qrjpi76aeo4bysagruwwfii6oneh56lj/lib64/
CPPFLAGS=
FPPFLAGS=
CLEANFILES  = ex_matlab

include ${PETSC_DIR}/lib/petsc/conf/variables
include ${PETSC_DIR}/lib/petsc/conf/rules

# your targets if any

include ${PETSC_DIR}/lib/petsc/conf/test

I've looked into the superludist and can confirm that it is indeed linked
to the system gfortran due to it's build error and since it's a petsc
dependency, it might be that this is where the system gfortran is coming in
instead of the newer gfortran associated with gcc-7.3.0 but I'm not sure.

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Sajid Ali via petsc-users 
Should gdb : https://spack.readthedocs.io/en/latest/package_list.html#gdb
be listed as an explicit dependency ?

Also, why is the error message asking me to re-install my system
blas/lapack ? I installed petsc with intel-mkl as blas/lapack provider and
the linking failed for superlu-dist. Is that carrying over here ?

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-04 Thread Sajid Ali via petsc-users 
Spack changes the configuration if debug variant is enabled as per this
line :

'--with-debugging=%s' % ('1' if '+debug' in spec else '0'),

I'm not sure what needs to be done to change this.

In the meantime, I added -g to CFLAGS in the makefile and now I have this :
https://pastebin.com/wxf05BH0

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-03 Thread Smith, Barry F. via petsc-users 



> On Jan 3, 2019, at 8:44 PM, Balay, Satish  wrote:
> 
> I guess the primary bug here is 'petsc+debug' option is broken in spack.
> 
> Its not clear to me if a package in spack should have 'debug' option. [so I 
> should remove this?]

   Question  you should ask the spack folks. Many systems such as Xcode and 
Visual Studio have a debug and release mode, spack should also.

   Barry

> 
> since spack way is perhaps:
> 
> spack install CFLAGS=-g FFLAGS=-g CXXFLAGS=-g petsc
> 
> Satish
> 
> On Fri, 4 Jan 2019, Smith, Barry F. via petsc-users wrote:
> 
>> 
>>   This appears to be more a spack question than a PETSc question. That make 
>> (that doesn't have the -g) is controlled by spack, not PETSc.
>> 
>>   Barry
>> 
>> 
>>> On Jan 3, 2019, at 6:15 PM, Sajid Ali via petsc-users 
>>>  wrote:
>>> 
>>> Hi, 
>>> 
>>> I've compiled a program using petsc with debugging enabled. 
>>> Confirmation of the same : https://pastebin.com/aa0XDheD (check if the 
>>> loaded module is indeed petsc+debug, compile)
>>> 
>>> When I run it in a debugger, I get the error as shown below: 
>>> https://pastebin.com/GJtB2Ghz
>>> 
>>> What am I missing?
>>> 
>>> Thank You,
>>> Sajid Ali
>>> Applied Physics
>>> Northwestern University
>> 
>

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-03 Thread Balay, Satish via petsc-users 
I guess the primary bug here is 'petsc+debug' option is broken in spack.

Its not clear to me if a package in spack should have 'debug' option. [so I 
should remove this?]

since spack way is perhaps:

spack install CFLAGS=-g FFLAGS=-g CXXFLAGS=-g petsc

Satish

On Fri, 4 Jan 2019, Smith, Barry F. via petsc-users wrote:

> 
>This appears to be more a spack question than a PETSc question. That make 
> (that doesn't have the -g) is controlled by spack, not PETSc.
> 
>Barry
> 
> 
> > On Jan 3, 2019, at 6:15 PM, Sajid Ali via petsc-users 
> >  wrote:
> > 
> > Hi, 
> > 
> > I've compiled a program using petsc with debugging enabled. 
> > Confirmation of the same : https://pastebin.com/aa0XDheD (check if the 
> > loaded module is indeed petsc+debug, compile)
> > 
> > When I run it in a debugger, I get the error as shown below: 
> > https://pastebin.com/GJtB2Ghz
> > 
> > What am I missing?
> > 
> > Thank You,
> > Sajid Ali
> > Applied Physics
> > Northwestern University
>

Re: [petsc-users] Question about correctly catching fp_trap

2019-01-03 Thread Smith, Barry F. via petsc-users 


   This appears to be more a spack question than a PETSc question. That make 
(that doesn't have the -g) is controlled by spack, not PETSc.

   Barry


> On Jan 3, 2019, at 6:15 PM, Sajid Ali via petsc-users 
>  wrote:
> 
> Hi, 
> 
> I've compiled a program using petsc with debugging enabled. 
> Confirmation of the same : https://pastebin.com/aa0XDheD (check if the loaded 
> module is indeed petsc+debug, compile)
> 
> When I run it in a debugger, I get the error as shown below: 
> https://pastebin.com/GJtB2Ghz
> 
> What am I missing?
> 
> Thank You,
> Sajid Ali
> Applied Physics
> Northwestern University

[petsc-users] Question about correctly catching fp_trap

2019-01-03 Thread Sajid Ali via petsc-users 
Hi,

I've compiled a program using petsc with debugging enabled.
Confirmation of the same : https://pastebin.com/aa0XDheD (check if the
loaded module is indeed petsc+debug, compile)

When I run it in a debugger, I get the error as shown below:
https://pastebin.com/GJtB2Ghz

What am I missing?

Thank You,
Sajid Ali
Applied Physics
Northwestern University