Ticket #4645 (closed: wontfix)
Crash after using colour plot on a workspace
Reported by: | Anders Markvardsen | Owned by: | Anders Markvardsen |
---|---|---|---|
Priority: | minor | Milestone: | Release 3.3 |
Component: | MantidPlot | Keywords: | |
Cc: | peter.parker@… | Blocked By: | |
Blocking: | Tester: | Harry Jeffery |
Description (last modified by Anders Markvardsen) (diff)
When doing a colour plot the workspace table is opened with all column highligthed.
When Richard repeats a 2D reduction where he has done the above beforehand Mantid crashes, using a version of Mantid from this week. He said this did not use to happen in a past version.
This might be a generic bug or a sans2d bug only, I am not sure yet
Change History
comment:2 Changed 9 years ago by Anders Markvardsen
More testing of installers on win32 machines
Note Jenkins Thursday morning build = 3295 Jenkins Friday morning builds = 3318 & 3319
Jenkins Thursday 17:17:19 = 3305
Just tried the 3305 again and this time it fails. A possible cause is that some signal end up not being executed in an expected order
comment:3 Changed 9 years ago by Anders Markvardsen
- Milestone changed from Iteration 32 to Iteration 33
comment:4 Changed 9 years ago by Anders Markvardsen
- Priority changed from critical to minor
All the isis sans scientists have been upgraded to Win64 where they don't see this problem. So priority less.
Note that from a discussion with Freddie he said the problem may be related to: (below copy from email from Freddie)
it is mentioned at http://www.boost.org/doc/libs/1_48_0/libs/bind/bind.html#stdcall
I also noticed that the end of the following discussion http://www.gamedev.net/topic/569351-boostfunction-__stdcall-__fastcall-etc/ seems to mention a similar problem to what you are seeing (debug issue, disappears in release)
comment:5 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.1 to Release 2.2
Moved at end of release 2.1
comment:7 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.3 to Release 2.4
Moved to release 2.4
comment:8 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.4 to Release 2.5
Moved at the code freeze for release 2.4
comment:10 Changed 7 years ago by Nick Draper
- Milestone changed from Release 2.6 to Backlog
Moved to the Backlog after the code freeze for R2.6
comment:11 Changed 7 years ago by Nick Draper
- Status changed from new to assigned
bulk move to assigned at the into of the triage step
comment:12 Changed 6 years ago by Anders Markvardsen
- Cc peter.parker@… added
- Status changed from assigned to verify
- Resolution set to wontfix
- Description modified (diff)
We no longer support win32 and since this was found to be win32 specific, see comments, I am hereby declaring this one as 'wontfix'.
To tester: if you agree on the above then pass
comment:14 Changed 6 years ago by Harry Jeffery
- Status changed from verify to verifying
- Tester set to Harry Jeffery
comment:16 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 5492
I have had mixed experiences with reproducing the bug above on my Win64 developing machine. Definitely at the moment it is not reproducable.
Yesterday about 5pm had Richard to test (again) that the bug was still there on his win32 machine and the answer is yes.
This morning I have tried to reproduce it on a win32 machine.