<div dir="ltr">Hi Nathan, Matt,<div><div><br></div><div>I'm working on getting some more debugging information with your suggestions. So far, I've been able to track it to the loop inside QuadTree.initialize_chunk. This appears to loop over all the points within the chunk, calling add_to_position for each point. The loop looks like this:</div>
</div><div><br></div><div><div> for p in range(num): </div><div> pos[0] = pxs[p] </div>
<div> pos[1] = pys[p] </div><div> self.add_to_position(level[p], pos, NULL, 0.0, 1)<br>
</div></div><div><br></div><div>If I print the values of p, level[p], pos[0], pos[1] inside this loop, I see the following (with a few extra lines leading up):</div><div><br></div><div>1893689 22 1148578047 1106259970</div>
<div>1893690 22 1148578047 1106259971</div><div>1893691 22 1148578047 1106259972</div><div>1893692 22 1148578047 1106259973</div><div>1893693 22 1148578047 1106259979</div><div>1893694 23 -1997811214 -2082447348</div><div>
<br></div><div>So, somehow, starting on level 23, the x and y positions are messed up in some way. Is this a precision issue? How are these positions calculated?</div><div><br></div><div>Britton </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 5:54 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Britton,<div><br></div><div>On my machine it will tell me line numbers in the .C file if a crash happens inside a .so file, even if it's called from python. I'm not sure how to get that information on your system without knowing more about your setup. </div>
<div><br></div><div>PDB doesn't know about C extensions so that won't be helpful unfortunately.</div><div><br></div><div>If you're running serially you should be able to run python under gdb and get a traceback that way. I'm not sure how to do that for parallel runs.<span></span></div>
<div><br></div><div>This page might be helpful: <a href="http://docs.cython.org/src/userguide/debugging.html" target="_blank">http://docs.cython.org/src/userguide/debugging.html</a><br></div><div class="HOEnZb"><div class="h5">
<div><br></div><div>Nathan</div><div><br>On Thursday, February 27, 2014, Britton Smith <<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Nathan,<div><br></div><div>I'm having a hard time getting a traceback that goes into the QuadTree source. The seg fault I get stops at QuadTree.so. Is there a way to recompile this in debug mode to get some more information? It doesn't look like pdb is able to step into QuadTree either.</div>
<div><br></div><div>Britton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 5:22 PM, Nathan Goldbaum <span dir="ltr"><<a>nathan12343@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Britton,<div><br></div><div>Can you get a traceback from the seg fault? It would help to see the line number in the autogenerated QuadTree.c where the crash happens. Autogenerated C files produced by cython<span></span> reproduce the original .pyx files line by line as comments so it's usually pretty easy to back out where the crash is happening in the original Pyrex file.</div>
<span><font color="#888888">
<div><br></div></font></span><div><span><font color="#888888">Nathan</font></span><div><div><br><br>On Thursday, February 27, 2014, Britton Smith <<a>brittonsmith@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi all,<div><br></div><div>I'm trying to make projections of a rather large Enzo dataset and getting a segfault somewhere in Quadtree.so. This dataset is ~230 GB in size with 27 levels of AMR. As far as I can tell, the only hard coded limit I could find in QuadTree.pyx is for 80 levels, which I am clearly below. Does anyone familiar with this part of the code have any idea if there are any other hard-coded limits in here that I might be exceeding? If not, does anyone have any advice for how I might debug this? I'm seeing this behavior in both yt-2.x and yt-3.0, so it does seem to be something intrinsic to the quadtree code.</div>
<div><br></div><div>Thanks!</div><div>Britton</div></div>
</blockquote></div></div></div>
<br>_______________________________________________<br>
yt-users mailing list<br>
<a>yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br></div>