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