SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2016 v21 Beta Discussion => Topic started by: marcos91360 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/
-
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