Author Topic: SE-64/Linux resource hog  (Read 772 times)

marcos91360

  • Community Member
  • Posts: 10
  • Hero Points: 0
SE-64/Linux resource hog
« on: August 02, 2016, 06:26:05 pm »
For the 3rd time today the editor has become unusable. The CPU% climbs to 100% and it does not drop.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                         
  858 marcos    20   0 4570720 2.601g 411208 R 100.0 16.7 545:35.94 vs_exe
                                                           
If there is something I can do to gather info and send back please let me know. The only solution so far is to kill the process, and unfortunately I cannot pinpoint if there is a specific action that triggers this event.

---
SlickEdit Pro 2016 (v21.0.0.2 64-bit)

Serial number: FE24597_BETA
License type: Beta License
License expiration: 2016-10-30 17:00:00
License file: /opt/slickedit-pro2016/bin/slickedit.lic

Build Date: July 14, 2016
Emulation: Visual C++ 6

OS: Linux
OS Version: Debian GNU/Linux testing (stretch)
Kernel Level: 4.4.0-1-amd64
Build Version: #1 SMP Debian 4.4.6-1 (2016-03-17)
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation
Memory: 81% Load, 11450MB/14088MB Virtual
Shell Information: /opt/slickedit-pro2016/bin/secsh -i
Screen Size: 1920 x 1080, 1680 x 1050

Project Type: Single file project - Gnuc
Language: .c (C/C++)
Encoding: Automatic

Installation Directory: /opt/slickedit-pro2016/
« Last Edit: August 02, 2016, 06:30:22 pm by marcos91360 »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2891
  • Hero Points: 436
Re: SE-64/Linux resource hog
« Reply #1 on: August 02, 2016, 10:49:26 pm »
Is the editor just slow, or completely unresponsive?

If it is just a slowdown, a good start is to turn on Slick-C profiling, and collect profiling information.

If it is completely unresponsive, the best technique is to attach to vs_exe with GDB and create a core to send into support so that we can unravel where it is hanging.

If it is very slow, but not completely unresponsive, you could attach with GDB and create several cores at different points, in order to catch it in the act where it is slowing down.

If your machine does not have much memory, you might want to turn off memory mapped tag files.  Tools > Options > Editing > Context Tagging