Ticket #847 (closed: wontfix)

Opened 11 years ago

Last modified 5 years ago

Bad alloc when encountering CompressedWorkspace2D

Reported by: Russell Taylor Owned by: Roman Tolchenov
Priority: blocker Milestone: Iteration 23
Component: Keywords:
Cc: Blocked By:
Blocking: Tester:

Description

Do the following on a Windows PC with a good amount of memory:

  • Load a GEM file
  • Run AlignDetectors - store the output in a different workspace
  • Run AlignDetectors again - give another new workspace for the output
  • BOOM! At least for me and Aziz.

Change History

comment:1 Changed 11 years ago by Nick Draper

  • Priority changed from major to blocker
  • Owner set to Roman Tolchenov

comment:2 Changed 11 years ago by Roman Tolchenov

(In [3139]) Switched off the use of the CompressedWorkspace in the .properties file until the bug is fixed. re #847

comment:3 Changed 11 years ago by Nick Draper

  • Milestone changed from Iteration 19 to Iteration 20

Moved as part of the end of Iteration 19

comment:4 Changed 11 years ago by Roman Tolchenov

(In [3398]) Set a lower free memory limit to 200MB when creating a CompressedWorkspace2D, meaning that a compressed workspace will not be created if the system will be left with less than 200mb of free memory. This reduces the risk of bad allocs on Windows. re #847

comment:5 Changed 11 years ago by Roman Tolchenov

  • Status changed from new to accepted

comment:6 Changed 11 years ago by Roman Tolchenov

  • Status changed from accepted to testing
  • Resolution set to fixed

comment:7 Changed 11 years ago by Russell Taylor

Well, this particular problem is resolved for me - the above now works without crashing. For a full GEM file it ends up going to a ManagedWorkspace on the third step. If I initially load only 6000 spectra it now creates a CompressedWorkspace and doesn't crash.

Don't think I could confidently say that a bad_alloc will never happen now though. Also, I don't much like the fact that there's now a 'magic' 200 hard-coded in.

comment:8 Changed 11 years ago by Nick Draper

  • Status changed from testing to reopened
  • Resolution fixed deleted

Testing this one my laptop,

I loaded 2Gem datasets, and then 2 hrpd datsets.

On the 2nd HRPD dataset I got this in the log

* Run title: 39182 Commissioning NBS Si 10-110ms 15*20 mm 04-Jul-2008 16:30:34 * Error in execution of algorithm LoadRaw: bad allocation

For this release turn off this functionality in the .properties file, and then move this ticket to iteration 22.

comment:9 Changed 11 years ago by Nick Draper

  • Status changed from reopened to assigned

comment:10 Changed 11 years ago by Roman Tolchenov

  • Milestone changed from Iteration 21 to Iteration 22

comment:11 Changed 10 years ago by Nick Draper

  • Status changed from assigned to testing
  • Resolution set to wontfix

Priority decreased, functionality turned off for now, may revisit later.

Resolved as won't fix for now.

comment:12 Changed 10 years ago by Nick Draper

This functionality apears to be too fragile for production at the moment. Mainly due to the uncertainty about the amount of compression that will actually be acheived. Leave disabled for now.

comment:13 Changed 10 years ago by Nick Draper

  • Status changed from testing to closed

comment:14 Changed 5 years ago by Stuart Campbell

This ticket has been transferred to github issue ​1695

Note: See TracTickets for help on using tickets.