About three-quarters through a slide-show presentation on Impress
(openoffice.org), the application is killed. The system log has the
following messages:
Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0
Nov 21 14:46:57 jimmy kernel: DMA per-cpu:
Nov 21 14:46:57 jimmy kernel: cpu 0 hot: low 2, high 6, batch 1 used:2
Nov 21 14:46:57 jimmy kernel: cpu 0 cold: low 0, high 2, batch 1 used:1
Nov 21 14:46:57 jimmy kernel: Normal per-cpu:
Nov 21 14:46:57 jimmy kernel: cpu 0 hot: low 62, high 186, batch 31 used:84
Nov 21 14:46:57 jimmy kernel: cpu 0 cold: low 0, high 62, batch 31 used:61
Nov 21 14:46:57 jimmy kernel: HighMem per-cpu: empty
Nov 21 14:46:57 jimmy kernel: Free pages: 4528kB (0kB HighMem)
Nov 21 14:46:57 jimmy kernel: Active:61340 inactive:61011 dirty:0 writeback:0
unstable:0 free:1132 slab:2770 mapped:121873 pagetables:925
Nov 21 14:46:57 jimmy kernel: DMA free:2068kB min:88kB low:108kB high:132kB
active:5416kB inactive:5024kB present:16384kB pages_scanned:10977
all_unreclaimable? yes
Nov 21 14:46:57 jimmy kernel: lowmem_reserve[]: 0 495 495
Nov 21 14:46:57 jimmy kernel: Normal free:2460kB min:2804kB low:3504kB
high:4204kB active:239944kB inactive:239020kB present:507840kB
pages_scanned:569469 all_unreclaimable? yes
Nov 21 14:46:57 jimmy kernel: lowmem_reserve[]: 0 0 0
Nov 21 14:46:57 jimmy kernel: HighMem free:0kB min:128kB low:160kB high:192kB
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Nov 21 14:46:57 jimmy kernel: lowmem_reserve[]: 0 0 0
Nov 21 14:46:57 jimmy kernel: DMA: 1*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB
0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2068kB
Nov 21 14:46:57 jimmy kernel: Normal: 81*4kB 7*8kB 4*16kB 3*32kB 2*64kB 0*128kB
1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2460kB
Nov 21 14:46:57 jimmy kernel: HighMem: empty
Nov 21 14:46:57 jimmy kernel: Swap cache: add 872953, delete 872705,
find 482926/497658, race 0+1
Nov 21 14:46:57 jimmy kernel: Free swap = 0kB
Nov 21 14:46:57 jimmy kernel: Total swap = 987988kB
Nov 21 14:46:58 jimmy kernel: of Memory: Killed process 7891 (soffice.bin).
This happens on two different systems; both have 512 MB of ram and large swap
partitions.
Is this a kernel (2.6.14-1.1637_FC4) issue or an openoffice.org (2.0) issue?

Tue, 22 Nov 2005 15:16:30 +0100, Michael Heiming wrote:

>About three-quarters through a slide-show presentation on Impress
>(openoffice.org), the application is killed. The system log has the
>following messages:
>
>Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0
>
switch on overcommit_memory

How do I do that? Is it a kernel configuration option?

Bob T.

Tue, 22 Nov 2005 15:16:30 +0100, Michael Heiming wrote:
>
>Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0
>
oom_killer in action, switch on overcommit_memory, retry and see
if this helps?

overcommit_memory does not help.

Is it conceivable that the slide show requires too much memory, or is it
likely there's a memory leak in Impress?

Tue, 22 Nov 2005 22:12:37 +0100, Michael Heiming wrote:

>>Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0
>>
>oom_killer in action, switch on overcommit_memory, retry and see
>if this helps?
>
>overcommit_memory does not help.
>
Good. If you are already running the latest 2.0, there have
been some updates, iirc.
>
>Is it conceivable that the slide show requires too much memory, or is it
>
Unlikely, what size is the file?

The file is some 300 MB. It was converted from a Powerpoint file created
by someone who didn't appreciate image-resolution issues.

>likely there's a memory leak in Impress?
>
Perhaps, can't look into your system, we don't know how much
memory it uses, since you sadly didn't gave much info.

The program loads the file and runs well through 3/4 of it. That
suggests to me that there is a problem with not returning temporary
memory. The file is Banquet.odp available by anonymous ftp at host
linus.cs.queensu.ca, directory PonyClub.

Fill in a bug report.

To openoffice.org or to the kernel list? That was my original question.

Bob T.

Michael Heiming wrote:
In comp.os.linux.misc Bob Tennent <BobT@cs.queensu.ca>:
>
>Tue, 22 Nov 2005 22:12:37 +0100, Michael Heiming wrote:
>>
>>
Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0

oom_killer in action, switch on overcommit_memory, retry and see
if this helps?

overcommit_memory does not help.

Good. If you are already running the latest 2.0, there have
been some updates, iirc.

Is it conceivable that the slide show requires too much memory, or is it

Unlikely, what size is the file?
>
>
>>The file is some 300 MB. It was converted from a Powerpoint file created
>>by someone who didn't appreciate image-resolution issues.
>
>
Idiotic, but that makes sense, so it seems now, with this
information much more likely you simply don't have enough memory
to handle this file. Get more.

I downloaded the file to give it a try on a machine with 2 GB of RAM,
but I can't even get to open it.

[snip]
>>linus.cs.queensu.ca, directory PonyClub.
>
>
Had a look, but since you seem to run on a modem/ISDN it would
take ages, at 8.2 kB/s.

I had no trouble downloading the file at more than 380 KBytes/sec, but
then I'm a little closer to Queens University. (Although traceroute
shows some unexpected hops between here and there, covering an extra
1000 miles of Internet backbone. To the P: I bet you didn't know
Chicago was between Toronto and Kingston.)

Bob Tennent <BobT@cs.queensu.cawrites:

Tue, 22 Nov 2005 22:12:37 +0100, Michael Heiming wrote:
>
>>Nov 21 14:46:57 jimmy kernel: oom-killer: gfp_mask=0x601d2, order=0
>>
>oom_killer in action, switch on overcommit_memory, retry and see
>if this helps?
>
>overcommit_memory does not help.
>
Good. If you are already running the latest 2.0, there have
been some updates, iirc.
>
>Is it conceivable that the slide show requires too much memory, or is it
>
Unlikely, what size is the file?

>The file is some 300 MB. It was converted from a Powerpoint file created
>by someone who didn't appreciate image-resolution issues.

>likely there's a memory leak in Impress?
>
Perhaps, can't look into your system, we don't know how much
memory it uses, since you sadly didn't gave much info.

>The program loads the file and runs well through 3/4 of it. That
>suggests to me that there is a problem with not returning temporary
>memory. The file is Banquet.odp available by anonymous ftp at host
>linus.cs.queensu.ca, directory PonyClub.

Well, look at the memory useage as you use the program. See if the memory
useage goes up. It should just start using swap ( and slow down by a factor
of 1000) if there is a leak.

(That file is 300 MB long. Why would anyone download it?)

Fill in a bug report.

>To openoffice.org or to the kernel list? That was my original question.

If it is an openoffice problem to openoffice. That is where I would start.


>Bob T.

Tue, 22 Nov 2005 18:57:50 -0500, John-Paul Stewart wrote:

I downloaded the file to give it a try on a machine with 2 GB of RAM,
but I can't even get to open it.

The initial conversion from .ppt was very lengthy but subsequent loads
have been quite fast (for openoffice!). Are you using ?

linus.cs.queensu.ca, directory PonyClub.
>>
>Had a look, but since you seem to run on a modem/ISDN it would
>take ages, at 8.2 kB/s.

Nonsense. It's on a university network with a fat pipe to the internet.

I had no trouble downloading the file at more than 380 KBytes/sec, but
then I'm a little closer to Queens University. (Although traceroute
shows some unexpected hops between here and there, covering an extra
1000 miles of Internet backbone. To the P: I bet you didn't know
Chicago was between Toronto and Kingston.)

Hmm. Hard to imagine how the packets could get to Chicago *without*
going through Toronto.

Bob T.

Wed, 23 Nov 2005 07:43:07 +0100, Michael Heiming wrote:

>>Had a look, but since you seem to run on a modem/ISDN it would
>>take ages, at 8.2 kB/s.
>
>Nonsense. It's on a university network with a fat pipe to the internet.
>
No nonsense involved, just the download speed I got when trying.
Let's retry now:

$ ncftpget
Banquet.odp: ETA: 598:13 0.30/284.95 MB 8.12 kB/s

Hmm. That's not what someone in Toronto reported getting. And here's what I
get from another system in Canada:

% ncftpget
Banquet.odp: ETA: 9:21 4.64/284.95 MB 511.65 kB/s

Perhaps Canadian clients get privileged network access? Not much I can
do about it. I know my home system has uploads throttled by the cable
company.

Bob Tennent wrote:
I had no trouble downloading the file at more than 380 KBytes/sec, but
then I'm a little closer to Queens University. (Although traceroute
shows some unexpected hops between here and there, covering an extra
1000 miles of Internet backbone. To the P: I bet you didn't know
Chicago was between Toronto and Kingston.)

Hmm. Hard to imagine how the packets could get to Chicago *without*
going through Toronto.

Traceroute showed .Detroit.Level3.net and .Chicago.Level3.net hosts
between Bell's network and Telus. (Telus being the last few hops before
queensu.ca, and Bell being my ISP.) It's an odd loop, going through
Toronto twice.

At least the traceroute kept me entertained during the download!

Wed, 23 Nov 2005 17:09:01 +0100, Michael Heiming wrote:

Did you checked the memory usage of your presentation already?

The memory usage of soffice.bin (%MEM in top) fluctuates widely,
depending I presume on the resolution of the slides being shown. It
starts at about 25%, increases at times to 70%, but averages around 35%.
Meanwhile swap usage increases consistently, eventually to the available
swap size, at which point bad things happen.

Bob T.

Bob Tennent <BobT@cs.queensu.cawrites:

Wed, 23 Nov 2005 17:09:01 +0100, Michael Heiming wrote:

Did you checked the memory usage of your presentation already?

>The memory usage of soffice.bin (%MEM in top) fluctuates widely,
>depending I presume on the resolution of the slides being shown. It
>starts at about 25%, increases at times to 70%, but averages around 35%.
>Meanwhile swap usage increases consistently, eventually to the available
>swap size, at which point bad things happen.

Yes, that is a memory leak.


>Bob T.

Wed, 23 Nov 2005 20:41:51 +0100, Michael Heiming wrote:

Did you checked the memory usage of your presentation already?

The memory usage of soffice.bin (%MEM in top) fluctuates widely,
depending I presume on the resolution of the slides being shown. It
starts at about 25%, increases at times to 70%, but averages around 35%.
Meanwhile swap usage increases consistently, eventually to the available
swap size, at which point bad things happen.
>
>Yes, that is a memory leak.
>
Looks like, after downloading the monster, run the sideshow up to
picture 76 and top on the second monitor, it had already used
355MB (RES), now without doing anything, memory climbed about to
750MB (RES), when stopping simpress. Looked like it would use all
memory/swap soon if you let it run. There's 1GB RAM in the box.

Iirc already mentioned to fill in a bug report to the openoffice
team.

Done. They've reproduced the issue using the released version but
apparently it doesn't happen in an internal development version.

Thanks.
Bob T.