[CP2K:7489] Buffer overflow in cp2k_shell.popt

Eric Hermes erich... at gmail.com
Wed Mar 9 14:48:09 UTC 2016


Dominik,

On Wednesday, March 9, 2016 at 6:43:00 AM UTC-6, Dominik Mierzejewski wrote:
>
> Eric, 
>
> On Wednesday, 09 March 2016 at 13:11, Eric Hermes wrote: 
> > Dominik, 
> > 
> > On Wednesday, March 9, 2016 at 2:55:05 AM UTC-6, Dominik Mierzejewski 
> wrote: 
> > > 
> > > Hi, Eric. 
> > > 
> > > On Tuesday, 08 March 2016 at 22:48, Eric Hermes wrote: 
> > > [...] 
> > > > This is why I am trying to build the cp2k_shell binaries in the 
> first 
> > > > place. Unfortunately, I cannot get cp2k_shell to run at all, let 
> alone 
> > > > within the framework of ASE. The problem is that the binary produces 
> a 
> > > > buffer overflow when run by itself with no arguments. 
> > > 
> > > Please try compiling with debugging information included (with gcc 
> it's 
> > > enough to add -g to compiler flags, but I don't know the equivalent 
> > > for Intel compiler). Then, run the binary under gdb and post the 
> output 
> > > of 'where' command once it crashes. 
> >   
> > Slight correction to my previous post: the compiled executable does not 
> > result in a buffer overflow when it is run by itself, but only when it 
> is 
> > run with mpirun. I have tried compiling CP2K with both mvapich2-2.2b and 
> > openmpi-1.10.2, and the buffer overflow happens for both of these MPI 
> > implementations. Since it only crashes when run with mpirun, and I do 
> not 
> > know how to debug an MPI process with gdb (since it crashes immediately, 
> I 
> > can't exactly attach gdb to the process once it's running), I don't 
> think I 
> > can easily debug the process with gdb. 
>
> You can run mpirun under gdb: 
>
> $ gdb mpirun 
> ... 
> (gdb) run insert_the_rest_of_the_commandline_here 
>

Unfortunately, doing so doesn't produce any stack info, because gdb is 
attempting to debug mpirun rather than cp2k_shell.popt. However, I inserted 
a sleep statement into cp2k_shell.f90 before the location of the crash, 
which give me time to attach gdb to the process after it's been started but 
before it crashes. Doing so results in the following stack trace:

(gdb) where
#0  0x00000039d4c32625 in raise () from /lib64/libc.so.6
#1  0x00000039d4c33e05 in abort () from /lib64/libc.so.6
#2  0x00000039d4c70537 in __libc_message () from /lib64/libc.so.6
#3  0x00000039d4d02567 in __fortify_fail () from /lib64/libc.so.6
#4  0x00000039d4d00450 in __chk_fail () from /lib64/libc.so.6
#5  0x00000039d4cff8a9 in _IO_str_chk_overflow () from /lib64/libc.so.6
#6  0x00000039d4c74639 in _IO_default_xsputn_internal () from 
/lib64/libc.so.6
#7  0x00000039d4c451a8 in vfprintf () from /lib64/libc.so.6
#8  0x00000039d4cff94d in __vsprintf_chk () from /lib64/libc.so.6
#9  0x00000039d4cff88f in __sprintf_chk () from /lib64/libc.so.6
#10 0x0000000008005e33 in for__compute_filename ()
#11 0x0000000008007bf9 in for__open_proc ()
#12 0x0000000007fbe2cd in for__open_default ()
#13 0x0000000007fec269 in for_write_seq_fmt ()
#14 0x0000000000411af0 in cp2k_shell () at cp2k_shell.f90:186
#15 0x000000000040e81e in main ()
#16 0x00000039d4c1ed5d in __libc_start_main () from /lib64/libc.so.6
#17 0x000000000040e729 in _start ()
(gdb)

Unfortunately there doesn't appear to be much info here. I'm unsure where 
the for_* symbols are from, but presumably the sprintf statement causing 
the buffer overflow is located in those routines.
 

>
> > That said, I did try compiling CP2K with the Intel compiler debugging 
> > options enabled. What this showed was that any attempt to print or write 
> to 
> > the screen was what was causing the buffer overflow. Specifically, it 
> > points to line 185 in cp2k_shell.f90, which after preprocessing looks 
> like 
> > this: 
> > 
> >   DO 
> >      IF (para_env%mepos==para_env%source) THEN 
> >         WRITE (sout,'("* READY")') 
> >         CALL m_flush(sout) 
> >      END IF 
> > 
> > Line 185 is the one that contains the WRITE statement. I attempted 
> > debugging this issue by placing a simple 'print *, "Hello"' line above 
> this 
> > on line 183, and after recompiling cp2k_shell.o and relinking 
> > cp2k_shell.popt, the resulting buffer overflow occurs at line 183 
> instead, 
> > with "Hello" not having been printed to the screen. I also tried 
> explicitly 
> > writing to unit 6 with 'write (6, *) "Hello"', and this results in the 
> same 
> > error. 
>
> Interesting. I've never seen this, but I only build with gcc. 
>

I will try building CP2K with the GNU compilers, though my cluster is 
running CentOS 6 (or a derivative thereof), so the latest gfortran 
available to me is 4.4.6. To get CP2K to compile, do I need to specify 
something like -std=f2003?

>
> Regards, 
> Dominik 
> -- 
> Fedora http://fedoraproject.org/wiki/User:Rathann 
> RPMFusion http://rpmfusion.org 
> "Faith manages." 
>         -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" 
>

Eric 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20160309/c5905f37/attachment.htm>


More information about the CP2K-user mailing list