From: Reuben D. B. <tec...@vo...> - 2004-07-14 14:47:11
|
Hello, I'm editing a rather large text file (40 MB) with Joe. When doing macro recording, then I run the macro command using the 'repeat' (ie. ^k\ 500 times, of macro 0 (^k0) ), Joe gives me out of memory. This has happened twice. The macro is just basically do search then remove the line (with ^ Y) that contains the searched term. This was run on a 1 GB RAM, 2 GB Swap, Dual 2.7GB Athlon machine, so I don't think RAM is the problem for out of memory, is it? Any help is appreciated. Thanks. |
From: <ja...@av...> - 2004-07-14 16:31:58
|
JOE makes a swap file in /tmp, so possibly the filesystem containing /tmp is full (otherwise it's a bug...). "Reuben D. Budiardja" <tec...@vo...> wrote: > > Hello, > I'm editing a rather large text file (40 MB) with Joe. When doing macro > recording, then I run the macro command using the 'repeat' (ie. ^k\ 500 > times, of macro 0 (^k0) ), Joe gives me out of memory. This has happened > twice. The macro is just basically do search then remove the line (with > ^ Y) that contains the searched term. > > This was run on a 1 GB RAM, 2 GB Swap, Dual 2.7GB Athlon machine, so I > don't think RAM is the problem for out of memory, is it? > > Any help is appreciated. |
From: Reuben D. B. <tec...@vo...> - 2004-07-14 21:41:17
|
ja...@av... wrote: > JOE makes a swap file in /tmp, so possibly the filesystem containing /tmp is > full (otherwise it's a bug...). > /tmp in my system is part of the / partition, which still has over 60 GB space. This happen numerous time today, while I was trying to edit that big file. When I tried to repeat the macro 100 times at a time (^K\ 100), most of the time it's fine. When I went about 300 or 400 times at a time, most likely Joe crash with out of memory after about 1 or 2 times doing that. I'm pretty sure I can find a way reproduce this rather consistently. Should I file a bug report in the Joe's sourceforge page, or is this email report enough? Let me know if you want more detail description, or need more info. Thanks a lot. Reuben D. Budiardja |
From: Brian C. <B.C...@po...> - 2004-07-14 21:54:46
|
On Wed, Jul 14, 2004 at 05:39:58PM -0400, Reuben D. Budiardja wrote: > ja...@av... wrote: > >JOE makes a swap file in /tmp, so possibly the filesystem containing /tmp > >is > >full (otherwise it's a bug...). > > > > /tmp in my system is part of the / partition, which still has over 60 GB > space. This happen numerous time today, while I was trying to edit that > big file. > When I tried to repeat the macro 100 times at a time (^K\ 100), most of > the time it's fine. When I went about 300 or 400 times at a time, most > likely Joe crash with out of memory after about 1 or 2 times doing that. > I'm pretty sure I can find a way reproduce this rather consistently. Just a few thoughts (from someone who doesn't know anything about the internal operation of joe): - Check the output of 'ulimit -a' to see if you have a limit of, say, 64MB per process set. - Monitor the process with 'top' or 'ps' while you are running your macros 300 or 400 times in another window. See if the memory usage is going up. See what's the highest value it gets to. That might show if there's a memory leak in joe. - Do you get a core dump? If so, gdb might be able to interpret it usefully. Regards, Brian. |
From: Reuben D. B. <tec...@vo...> - 2004-07-15 12:37:17
|
Brian Candler wrote: > Just a few thoughts (from someone who doesn't know anything about the > internal operation of joe): > > - Check the output of 'ulimit -a' to see if you have a limit of, say, 64MB > per process set. Looks like it's unlimited, unless I interpret this wrong (?): $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 4 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 7168 virtual memory (kbytes, -v) unlimited > - Monitor the process with 'top' or 'ps' while you are running your macros > 300 or 400 times in another window. See if the memory usage is going up. See > what's the highest value it gets to. That might show if there's a memory > leak in joe. In top, when I did this and crashed joe, CPU usage only goes up to abour 2%, while memory usage shows only about 0.0% - 0.1%. In general, only CPU usage went up, and then joe crashed. This machine is not so busy also, ie. when I tried this, the machine was mostly idle and very little IO activity. Joe crashed with the following message in console: "vfile: out of memory" > - Do you get a core dump? If so, gdb might be able to interpret it usefully. There's no Core dump. Thanks for the suggestions. Reuben D. Budiardja |
From: <ja...@av...> - 2004-07-15 13:52:19
|
So this means that more memory handles (buffer pointers, 'P *') were allocated than there are pages in memory. One simple fix is this: look for ILIMIT in config.h. It's defined as (PGSIZE*1024). This is the maximum number of bytes which JOE will allocate from RAM for the edit buffers. PGSIZE is 4K, so this gives only 4MB. Change the 1024 to 10240 and try your macros again. I suppose we can safely increase this limit above 4MB these days :-) I'll try to figure out why all the pages are being allocated. "Reuben D. Budiardja" <tec...@vo...> wrote: > > Joe crashed with the following message in console: "vfile: out of memory" > |
From: Reuben D. B. <tec...@vo...> - 2004-07-16 02:20:12
|
On Thursday 15 July 2004 09:55, ja...@av... wrote: > So this means that more memory handles (buffer pointers, 'P *') were > allocated than there are pages in memory. One simple fix is this: look for > ILIMIT in config.h. It's defined as (PGSIZE*1024). This is the maximum > number of bytes which JOE will allocate from RAM for the edit buffers. > PGSIZE is 4K, so this gives only 4MB. Change the 1024 to 10240 and try > your macros again. OK, that solution works ! Thanks a lot. I repeat the macro 2000 times and it's fine. > I suppose we can safely increase this limit above 4MB > these days :-) Agreed. RDB |