From: Eric L. <Eri...@ma...> - 2012-06-07 14:34:49
|
Hi, One flag you can modify to control how much memory is used is comint-buffer-maximum-size, where comint is a utility matlab-shell uses to interact with MATLAB. That controls how much text is in the buffer. I'm going to guess that is not the problem though. MATLAB shell has a feature where it scans the MATLAB output for things to highlight, such as error messages, anchors (like urls), and stacks, which enables you to click on some text for some action. This works by keeping a buffer of text matlab has recently output and scanning it for those things. When it finds something, it converts the text into urls, etc. In theory, it should only keep 1 line of text or close to it, and be periodically flushed. You can test that by checking the value of gud-marker-acc from in your matlab-shell buffer. (where gud is part of the Grand Unified Debugger, which is part of Emacs.) M-: gud-marker-acc RET If it has grown super huge, then it would indeed get very slow, since every time MATLAB output text it would be searching the buffer for errors, and probably re-tagging old errors. The key would be figuring out why the clear conditions aren't met. You can find that in a bit of code like this: (if (and matlab-prompt-seen ;; Don't collect during boot (not frame) ;; don't collect debug stuff (let ((start (string-match gud-matlab-marker-regexp-prefix gud-marker-acc))) (and start (not (string-match "\n" gud-marker-acc start)) ;;(not (string-match "^K?>>\\|\\?\\?\\?\\s-Error while evaluating" gud-marker-acc start)) ))) ;; We could be collecting something. Wait for a while. nil ;; Finish off this part of the output. None of our special stuff ;; ends with a \n, so display those as they show up... (while (string-match "^[^\n]*\n" gud-marker-acc) (setq output (concat output (substring gud-marker-acc 0 (match-end 0))) gud-marker-acc (substring gud-marker-acc (match-end 0)))) in matlab.el. It will require a bit of analysis to see why it is failing. Good Luck Eric -----Original Message----- From: Jan-Pieter Jacobs [mailto:jan...@gm...] Sent: Thursday, June 07, 2012 5:31 AM To: mat...@li... Subject: [Matlab-emacs-discuss] Memory Leak? Hi all! I was really delighted to see an extension to a free editor that allows for usage of the Matlab debugger, etc. I installed the whole set of functions using dl_emacs_support. After a bit of fiddling with my .emacs file I have everything running. The problem that I encounter though, is that when using matlab-mode, Emacs' memory will steadily rise, also maxing out CPU load, up until the point I need to kill emacs because it does not respond any longer. I have the feeling that the problem lies with the communication between Emacs and Matlab, because before starting Matlab, everything goes well. I also noticed that upon every communication with Matlab (like when completing symbols etc), I get a new line + prompt sign (>>) in the matlab-shell window. For example, I've got some Matlab code that I'm debugging, and after stepping a few times through the code, emacs hardly responds, CPU load is 100% and memory is (according to top): Virt: 2244M Res: 1909M (or about 2Gb). The process of memory growth seems to go exponentially: Each attempt to access emacs makes the increase go faster and faster. I'm using Emacs 23.3.1 on Kubuntu 12.04 and Matlab R2011b (7.13.0.564). If anyone knows any solutions, or might point me where to look, I'd be really happy. Kind regards, Jan-Pieter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Matlab-emacs-discuss mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss |