On Mon, Dec 12, 2011 at 7:11 AM, 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">
Thanks for your answers. Meanwhile I clarified the situation a bit:<br>
<br>
I can bring xterm up manually from the command line, but the job is<br>
run using a scheduler (slurm). It then gets executed on arbitrary<br>
nodes (some stripped down linux) which apparently can not make X11<br>
connections.<br></blockquote><div><br></div><div>Sometimes you can set the env on the compute nodes, and get DISPLAY right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course, they have their own debugging environment, but I just do<br>
not want to learn it now. The admins are unable to help me more. I<br></blockquote><div><br></div><div>They should definitely be fired.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tried running the debugger explicitly:<br>
<br>
aprun -n 2 -N 1 -d 1 -cc cpu gdb Solver run.xml<br>
<br>
but so only one gdb instance is invoked in the terminal window, the<br>
other is in a parallel universe or something... Still any chance to<br>
get the second window somehow?<br></blockquote><div><br></div><div>Why not run 2 procs locally, instead of through the scheduler?</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>
<br>
On Mon, Dec 12, 2011 at 1:52 PM, Aron Ahmadia <<a href="mailto:aron.ahmadia@kaust.edu.sa">aron.ahmadia@kaust.edu.sa</a>> wrote:<br>
> Sorry, to expand my answer, "what Matt said". You don't have the advantage<br>
> of using the functionality of -start_in_debugger if you cannot make X11<br>
> connections from the compute nodes, so you will need to rely on whatever<br>
> debugging facilities your systems team has set up, and break on PetscError<br>
> if you want to catch PETSc errors percolating up the stack.<br>
><br>
> A<br>
><br>
><br>
> On Mon, Dec 12, 2011 at 3:48 PM, Aron Ahmadia <<a href="mailto:aron.ahmadia@kaust.edu.sa">aron.ahmadia@kaust.edu.sa</a>><br>
> wrote:<br>
>><br>
>> Not on a BG/P you can't.<br>
>><br>
>> A<br>
>><br>
>><br>
>> On Mon, Dec 12, 2011 at 3:46 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Mon, Dec 12, 2011 at 2:48 AM, Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>> I am debugging my code on a system that does not allow any X11<br>
>>>> connections, therefore the following does not work:<br>
>>>><br>
>>>> mpiexec -n 2 solver run.xml -start_in_debugger -display :0.0<br>
>>>><br>
>>>> Are there alternative ways of using a debugger circumventing X11<br>
>>>> connections?<br>
>>><br>
>>><br>
>>> No. You can usually set the DISPLAY correctly for the backend machine.<br>
>>> Consult the admin.<br>
>>><br>
>>> Matt<br>
>>><br>
>>>><br>
>>>> Thanks<br>
>>>> Dominik<br>
>>><br>
>>><br>
>>><br>
<span class="HOEnZb"><font color="#888888">>>><br>
>>> --<br>
>>> What most experimenters take for granted before they begin their<br>
>>> experiments is infinitely more interesting than any results to which their<br>
>>> experiments lead.<br>
>>> -- Norbert Wiener<br>
>><br>
>><br>
><br>
</font></span></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>