Skip to Content.
Sympa Menu

charm - [charm] Debugging Race Conditions

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

[charm] Debugging Race Conditions


Chronological Thread 
  • From: Robert Bird <r.bird AT warwick.ac.uk>
  • To: charm AT cs.illinois.edu
  • Subject: [charm] Debugging Race Conditions
  • Date: Mon, 18 Aug 2014 13:51:12 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

Hey all

I've got a (rare) race condition, where by a charm element is inserted twice (according to the error int he stack trace when Charm aborts). 

I can only get this to happen in parallel, with random message queues, so I'm having a hard time tracking it down.

Is there an obvious way to debug race conditions such as this? 

I've tried to use ++debug in order to get reliable access to the trace in gdb, but it doesn't seem to launch quite as expected. I get debug prints about the threads at the start and the program runs, but no xterm window appears (nor waits for my input to start -- As far as I can tell I meet all the requirements, I can spawn X-window, $DISPLAY is set, xterm is in path.)

Any obvious pointers/hints? Especially about a general method for tracking down race conditions

Thanks
Bob
NB:  During a quick chat with Phil Miller he mentioned +record, does this allow me to record it in parallel, then replay on a serial gdb? 

--
Robert Bird
http://go.warwick.ac.uk/robertbird

+44 (0)24 7652 2863
CS202, High Performance Lab
Department of Computer Science
University of Warwick



Archive powered by MHonArc 2.6.16.

Top of Page