On Wed, Jan 25, 2012 at 3:28 PM, Dominik Szczerba <span dir="ltr"><<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> So ParMETIS crashes on the hostile platform where it is slow to debug, fine.<br>
><br>
> But your code is calling it in cases where it doesn't crash, so why not run<br>
> the same code in your friendly environment and set a breakpoint in<br>
> MatPartitioningApply() (or even the ParMETIS routine where the assert is<br>
> failing) so that you can find out where else it is being called from. This<br>
> should take about 10 seconds.<br>
<br>
It will take several minutes till xterm gdb windows will pop up, till<br>
I will manage to type "c+ENTER" into 64 windows on my 1024x768<br>
quadcore, and then till I find the right window where the executions<br>
stopped - but yes, it is definitely doable, and I already did that, as<br>
posted separately. The point I was trying to clarify here was if one<br>
at all expects calls to parmetis (or equivalent) other than<br>
MatPartitioning after it was destroyed (e.g. for some hidden internal<br>
matrix partitioning later). I just wanted to hear a hard yes or no.<br></blockquote><div><br></div><div>No, only MatPartitioning. Also, why not use --debugger_nodes 0?</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Dominik<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>