<div dir="ltr">Dominik,<br><br>On Wednesday, March 9, 2016 at 6:43:00 AM UTC-6, Dominik Mierzejewski wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Eric,
<br>
<br>On Wednesday, 09 March 2016 at 13:11, Eric Hermes wrote:
<br>> Dominik,
<br>>
<br>> On Wednesday, March 9, 2016 at 2:55:05 AM UTC-6, Dominik Mierzejewski wrote:
<br>> >
<br>> > Hi, Eric.
<br>> >
<br>> > On Tuesday, 08 March 2016 at 22:48, Eric Hermes wrote:
<br>> > [...]
<br>> > > This is why I am trying to build the cp2k_shell binaries in the first
<br>> > > place. Unfortunately, I cannot get cp2k_shell to run at all, let alone
<br>> > > within the framework of ASE. The problem is that the binary produces a
<br>> > > buffer overflow when run by itself with no arguments.
<br>> >
<br>> > Please try compiling with debugging information included (with gcc it's
<br>> > enough to add -g to compiler flags, but I don't know the equivalent
<br>> > for Intel compiler). Then, run the binary under gdb and post the output
<br>> > of 'where' command once it crashes.
<br>>
<br>> Slight correction to my previous post: the compiled executable does not
<br>> result in a buffer overflow when it is run by itself, but only when it is
<br>> run with mpirun. I have tried compiling CP2K with both mvapich2-2.2b and
<br>> openmpi-1.10.2, and the buffer overflow happens for both of these MPI
<br>> implementations. Since it only crashes when run with mpirun, and I do not
<br>> know how to debug an MPI process with gdb (since it crashes immediately, I
<br>> can't exactly attach gdb to the process once it's running), I don't think I
<br>> can easily debug the process with gdb.
<br>
<br>You can run mpirun under gdb:
<br>
<br>$ gdb mpirun
<br>...
<br>(gdb) run insert_the_rest_of_the_<wbr>commandline_here
<br></blockquote><div><br></div><div>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:</div><div><br></div><div><div class="prettyprint" style="border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class="prettyprint"><div class="subprettyprint"><div class="subprettyprint">(gdb) where</div><div class="subprettyprint">#0 0x00000039d4c32625 in raise () from /lib64/libc.so.6</div><div class="subprettyprint">#1 0x00000039d4c33e05 in abort () from /lib64/libc.so.6</div><div class="subprettyprint">#2 0x00000039d4c70537 in __libc_message () from /lib64/libc.so.6</div><div class="subprettyprint">#3 0x00000039d4d02567 in __fortify_fail () from /lib64/libc.so.6</div><div class="subprettyprint">#4 0x00000039d4d00450 in __chk_fail () from /lib64/libc.so.6</div><div class="subprettyprint">#5 0x00000039d4cff8a9 in _IO_str_chk_overflow () from /lib64/libc.so.6</div><div class="subprettyprint">#6 0x00000039d4c74639 in _IO_default_xsputn_internal () from /lib64/libc.so.6</div><div class="subprettyprint">#7 0x00000039d4c451a8 in vfprintf () from /lib64/libc.so.6</div><div class="subprettyprint">#8 0x00000039d4cff94d in __vsprintf_chk () from /lib64/libc.so.6</div><div class="subprettyprint">#9 0x00000039d4cff88f in __sprintf_chk () from /lib64/libc.so.6</div><div class="subprettyprint">#10 0x0000000008005e33 in for__compute_filename ()</div><div class="subprettyprint">#11 0x0000000008007bf9 in for__open_proc ()</div><div class="subprettyprint">#12 0x0000000007fbe2cd in for__open_default ()</div><div class="subprettyprint">#13 0x0000000007fec269 in for_write_seq_fmt ()</div><div class="subprettyprint">#14 0x0000000000411af0 in cp2k_shell () at cp2k_shell.f90:186</div><div class="subprettyprint">#15 0x000000000040e81e in main ()</div><div class="subprettyprint">#16 0x00000039d4c1ed5d in __libc_start_main () from /lib64/libc.so.6</div><div class="subprettyprint">#17 0x000000000040e729 in _start ()</div><div class="subprettyprint">(gdb)</div></div></code></div><div><br></div>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.<br> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> That said, I did try compiling CP2K with the Intel compiler debugging
<br>> options enabled. What this showed was that any attempt to print or write to
<br>> the screen was what was causing the buffer overflow. Specifically, it
<br>> points to line 185 in cp2k_shell.f90, which after preprocessing looks like
<br>> this:
<br>>
<br>> DO
<br>> IF (para_env%mepos==para_env%<wbr>source) THEN
<br>> WRITE (sout,'("* READY")')
<br>> CALL m_flush(sout)
<br>> END IF
<br>>
<br>> Line 185 is the one that contains the WRITE statement. I attempted
<br>> debugging this issue by placing a simple 'print *, "Hello"' line above this
<br>> on line 183, and after recompiling cp2k_shell.o and relinking
<br>> cp2k_shell.popt, the resulting buffer overflow occurs at line 183 instead,
<br>> with "Hello" not having been printed to the screen. I also tried explicitly
<br>> writing to unit 6 with 'write (6, *) "Hello"', and this results in the same
<br>> error.
<br>
<br>Interesting. I've never seen this, but I only build with gcc.
<br></blockquote><div><br></div><div>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?</div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Regards,
<br>Dominik
<br>--
<br>Fedora <a href="http://fedoraproject.org/wiki/User:Rathann" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ffedoraproject.org%2Fwiki%2FUser%3ARathann\46sa\75D\46sntz\0751\46usg\75AFQjCNEVbJI8uIQZqQ5a2A32BKj2MsEvQg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Ffedoraproject.org%2Fwiki%2FUser%3ARathann\46sa\75D\46sntz\0751\46usg\75AFQjCNEVbJI8uIQZqQ5a2A32BKj2MsEvQg';return true;">http://fedoraproject.org/wiki/<wbr>User:Rathann</a>
<br>RPMFusion <a href="http://rpmfusion.org" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Frpmfusion.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGuXI6q1gR3iH1rL6kQDvuA2gqJwQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Frpmfusion.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGuXI6q1gR3iH1rL6kQDvuA2gqJwQ';return true;">http://rpmfusion.org</a>
<br>"Faith manages."
<br> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
<br></blockquote><div><br></div><div>Eric </div></div>