Ticket #6732 (closed: fixed)

Opened 8 years ago

Last modified 5 years ago

Windows: Number of process handles way too high

Reported by: Martyn Gigg Owned by: Martyn Gigg
Priority: major Milestone: Release 2.5
Component: Mantid Keywords:
Cc: Blocked By:
Blocking: Tester: Nick Draper

Description

The handle.exe program, available from http://technet.microsoft.com/en-gb/sysinternals/bb896655.aspx, can display a list of active handles from a given process.

Running a script through MantidPlot for roughly 20mins produces this output:

> handle -s -p 4864

Handle v3.51
Copyright (C) 1997-2013 Mark Russinovich
Sysinternals - www.sysinternals.com

Handle type summary:
  ALPC Port       : 7
  Desktop         : 1
  Directory       : 2
  EtwRegistration : 113
  Event           : 456
  File            : 36
  IoCompletion    : 3
  Key             : 47
  KeyedEvent      : 2
  Mutant          : 68
  Process         : 7670
  Section         : 19
  Semaphore       : 36
  Thread          : 17
  Timer           : 5
  TpWorkerFactory : 12
  WindowStation   : 2
Total handles: 8496

The 'Process' type handle should only increase when a subprocess handle is open but is currently very much higher than it should be. Using Process Explorer, http://technet.microsoft.com/en-us/sysinternals/bb896653, the output suggests that each process handle is a process to MantidPlot itself (see attachment).

Attachments

Mantid-ProcExp.png (107.1 KB) - added by Martyn Gigg 8 years ago.

Change History

Changed 8 years ago by Martyn Gigg

comment:1 Changed 8 years ago by Martyn Gigg

To reproduce this you can in fact simply:

  • Download & extract handle.exe application
  • Open MantidPlot & find the process ID from the task manager
  • Open a command prompt and navigate to the location where handle.exe was extracted
  • Run "handle -s -p <PID>" where <PID> should be replaced by the MantidPlot process ID.
  • The list should not contain any handles of type 'Process'
  • Run any algorithm, e.g. CreateSingleValueWorkspace
  • Rerun step 4 and you should see a Process type in the list with the value 1. Running other algorithms produces different numbers of increments of the value.

comment:2 Changed 8 years ago by Martyn Gigg

  • Status changed from new to accepted

comment:3 Changed 8 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:4 Changed 8 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:5 Changed 8 years ago by Martyn Gigg

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

Tester: Use the steps in comment 1 but run many more algorithms from either Python or the GUI, it makes no difference. The handle list should not contain a line for 'Process' types.

Branch name: feature/6732_win32_proc_handles

comment:6 Changed 8 years ago by Nick Draper

  • Status changed from verify to verifying
  • Tester set to Nick Draper

comment:7 Changed 8 years ago by Nick Draper

Test Results:

Number of handles
Stage      Before Change    After changes
Startup    371              368
1 alg      383              380
2nd alg    384              379
1000 more  1383             376

comment:8 Changed 8 years ago by Nick Draper

  • Status changed from verifying to closed

comment:9 Changed 8 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:10 Changed 8 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:11 Changed 8 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:12 Changed 7 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:13 Changed 7 years ago by Martyn Gigg

Close process handle after memory check on Windows. Refs #6732

If it is not closed then every call to verify the free memory leaves open another process handle and very slowly leaks resources.

Changeset: abe9a88d31a0568dc9d15670ff38a4435e3e8dc2

comment:14 Changed 5 years ago by Stuart Campbell

This ticket has been transferred to github issue 7578

Note: See TracTickets for help on using tickets.