Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#273 closed defect (fixed)

p(r) inversion broken

Reported by: ajj Owned by:
Priority: blocker Milestone: SasView 3.1.0
Component: SasView Keywords:
Cc: Work Package: SasView GUI Redesign

Description

On mac and linux P(r) inversion became broken some time after release 3.0.0

Symptoms: Load data into p(r) inversion and sasview hangs. You might be lucky and get one calculation of P(r) but after that, changing parameters causes sasview to hang.

Notes: The button for the "suggested value" of "number of terms" does not have a label or click (see screenshot attached).

This happens reliably with many data sets.

Attachments (1)

Screen Shot 2014-11-01 at 10.43.49.png (84.1 KB) - added by ajj 5 years ago.
Screen shot showing failure of P(r) inversion in sasview r7115

Download all attachments as: .zip

Change History (4)

Changed 5 years ago by ajj

Screen shot showing failure of P(r) inversion in sasview r7115

comment:1 Changed 5 years ago by butler

  • Work Package set to SasView GUI Redesign

Note that exact same problem exists on Windows and seems to be very reliable

comment:2 Changed 5 years ago by butler

  • Resolution set to fixed
  • Status changed from new to closed

The problem turns out to be the thread "fix" implemented in Aug 2014 to fix the constant crashing of SasView? when running fits. PrView? being older code probably is treating threads correctly? Whatever the case, the "wait" fix was causing an infinite wait state and thus a crashing of PrView?.

From the commit that fixed this problem (note incorrect year in commit comment):

Fix Pr failure ticket #273

Long version: In August 2013 it was determined that many instability problems experienced by SasView? were do to a threading problem in fitting.py. Mainly the authors seemed to not realize that calling thread.stop just raised a flag and that the thread itself needed to check for said flag regularly and kill the thread if it found the flag raised. A quick fix was implemented by adding a wait till the existing thread ended naturally to the two places in the code where the stop is raised. This seems to work.
At the same time pr.py was found to use the same raising of the stop flag three times and it was assumed that the same problem existed and the same wait “fix” was implemented. Subsequenty it has been shown that the new wait code in pr.py NEVER gets reached and thus the fix breaks the PrView? perspective. It may be that this earlier code properly dealt with threads properly(still remembering how the thread code was meant to be used). Whatever the case will remove this fix for now.
Finally another thread.stop was found once in simulation.py. since this is older code it may also be handled properly so am removing the “Fix” from that as well for now.

to quickly find these points in the future:
fitting.py - two instances that seem to need fixing
pr.py - three instances that may work correctly
simulation.py - one instace

search terms:
“-PDB” or
“d.stop” (thread.stop or thread_1D.stop or 2D.stop)

comment:3 Changed 4 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 3.1.0
Note: See TracTickets for help on using tickets.