Opened 7 years ago
Closed 7 years ago
#2831 closed defect (done)
Breakpoints in ParallelEngine can cause unexpected behavior
Reported by: | pfleck | Owned by: | jkarder |
---|---|---|---|
Priority: | medium | Milestone: | HeuristicLab 3.3.15 |
Component: | ParallelEngine | Version: | trunk |
Keywords: | Cc: |
Description
The ParallelEngine does not correctly reschedule operations after hitting a breakpoint.
If a breakpoint is encountered, a OperationCanceledException is thrown. If an OperationCanceledException is caught, the remaining Operations of the (parallel) stacks are saved an added to the current ExecutionStack. However, Parallel.ForEach throws an AggregateException, which is not caught therefore the remaining Operations are not rescheduled.
For example: GA-TSP sample with a breakpoint set on the Evaluator. Some of the parallel Operations (Evaluator) are executed and afterwards throw the OperationCanceledException. The remaining Evaluations are not executed anymore (the Parallel.ForEach stops after the first exception) and are not rescheduled.
This behavior also applies to any other exceptions that occur during parallel execution of Operations in the ParallelEngine.
Furthermore, when multiple breakpoints are hit in parallel, the thread-unsafe Log.LogMessage can cause race-conditions. Firstly, Log.LogMessage calls List<T>.Add, which is not thread-safe (IndexOutOfRangeException add during resizing of internal array). Secondly, Messages.ToArray() in LogView.Content_MessageAdded is not thread-safe either (ArgumentOutOfRangeException during internal Array.Copy).
Change History (14)
comment:1 Changed 7 years ago by pfleck
- Summary changed from Breakpoints in ParallelEngine can cause unexpected behaviour to Breakpoints in ParallelEngine can cause unexpected behavior
comment:2 Changed 7 years ago by jkarder
- Owner set to jkarder
- Status changed from new to assigned
comment:3 Changed 7 years ago by jkarder
- Status changed from assigned to accepted
comment:4 Changed 7 years ago by jkarder
- disabled breakpoints for the sequential and parallel engines
- fixed exception handling in parallel engine
comment:5 Changed 7 years ago by jkarder
- Version changed from 3.3.14 to trunk
comment:6 Changed 7 years ago by jkarder
- Owner changed from jkarder to pfleck
- Status changed from accepted to reviewing
comment:7 Changed 7 years ago by pfleck
- Owner changed from pfleck to jkarder
- Status changed from reviewing to readytorelease
reviewed r15368: ok
comment:8 Changed 7 years ago by jkarder
- Status changed from readytorelease to assigned
comment:9 Changed 7 years ago by jkarder
- Status changed from assigned to accepted
comment:10 Changed 7 years ago by jkarder
r15376: changed exception handling in engines
comment:11 Changed 7 years ago by jkarder
- Owner changed from jkarder to pfleck
- Status changed from accepted to reviewing
comment:12 Changed 7 years ago by pfleck
reviewed r15376: ok, but I have some suggestions for future improvements:
Currently, the exception handling of the engines is done somewhat different in all engines. In the future we should unify the exception handling of all engines.
For example, every Operator should catch any exception and wrap it within an OperatorExecutionException. Then, the engines could distinguish between exceptions that occurred within the operators and the ones that occurred within the engine execution (e.g. Operation-Canceled).
comment:13 Changed 7 years ago by pfleck
- Owner changed from pfleck to jkarder
- Status changed from reviewing to readytorelease
comment:14 Changed 7 years ago by jkarder
- Resolution set to done
- Status changed from readytorelease to closed
As discussed, I will disable breakpoints for the sequential and parallel engines.