Bug#5259: oleo goes nuts on improper copy command
This bug has been forwarded to the oleo maintainer with the following
Date: Thu, 7 Nov 96 00:01:16 PST
From: Kevin Dalley <email@example.com>
Subject: oleo-1.6 problem with copying region when column unspecified
In oleo-1.6, during a copy, if the destination column is unspecified,
the column is assumed to be c1:MAX_COL. Unfortunately, for copying,
this tends to put oleo into a very long loop.
I am currently the Debian maintainer for oleo. This bug was reported
by Kevin M Bealer as a bug. I am forwarding this report to the oleo
bug list. The original bug report is included below.
To reproduce the problem, bring up oleo. Place a number in R1C1.
Move the cursor to R1C1, mark the position. Then copy-region (M-c)
this region to r10 <CR>. Do not enter a column specification. After
quite a few minutes, this region will be copied to r1c1:65535 (the
default value of MAX_COL). Similarly, if column is
specified, but row is not, say c4, the region will be copied to
r1:65535c4. I cannot find a place in the documentation which
specifies that a region with an unspecified row or column becomes a
very large number.
For many operations with regions, it makes sense to assume that an
unspecified dimension covers the entire array. Unfortunately, with
copies, the source region is duplicated until it fills up the
destination region. This takes a long time to accomplish, eats up a
lot of CPU and memory, and is likely to be the result of mistake.
I suggest that something be changed so that the user can quickly
realize what went wrong and correct it. A printed explanation of the
ranges involved may be sufficient, with a chance to stop the copy if
the copy is incorrect.
From: Kevin M Bealer <firstname.lastname@example.org>
Subject: Bug#5259: oleo goes nuts on improper copy command
To: Debian Bug Reports <email@example.com>
Date: Mon, 4 Nov 1996 23:36:15 -0500 (EST)
Reply-To: Kevin M Bealer <firstname.lastname@example.org>, email@example.com
Resent-From: Kevin M Bealer <firstname.lastname@example.org>
Resent-CC: Kevin Dalley <kevin>
Resent-Date: Tue, 05 Nov 1996 05:03:27 GMT
X-From-Line: kevin Mon Nov 4 21:14:00 1996
Received: (from kevin@localhost) by aplysia.iway.aimnet.com (8.7.6/8.7.3) id VAA24497 for kevin; Mon, 4 Nov 1996 21:14:00 -0800
Received: from submailer.bugs.debian.org (email@example.com-Connect.Net [188.8.131.52]) by aimnet.com (8.8.2/8.7.1) with SMTP id VAA10785 for <firstname.lastname@example.org>; Mon, 4 Nov 1996 21:02:02 -0800 (PST)
Received: by submailer.bugs.debian.org id m0vKdfj-000CeSC
(Debian /\oo/\ Smail184.108.40.206 #29.35); Mon, 4 Nov 96 21:03 PST
Received: via spool by email@example.com id=B.84716936527342
(code B ref -1); Tue, 05 Nov 1996 05:03:27 GMT
Content-Type: TEXT/PLAIN; charset=US-ASCII
Xref: aplysia.iway.aimnet.com debian-devel:13417
When copying a block of cells with oleo, I selected the block
with the ^@ and moved the cursor to the lower right. I hit
ESC-c and then went to type in the coordinates of the recieving
After typing r12:14 (or similar) I hit return by mistake.. The
spreadsheet starting copying the block to fill the entire
universe of rows 12 through 14, and filling memory up in doing
The concept of a spreadsheet is meant to appear infinite (even
though in practice they are, of course, not) and it seems like a
bug to me for the program to try to fill the cell range
r12:14c1:65536, especially since this an unwitting user could
trigger a denial-of-service attack this way without bad intent.
I may be wrong in my guess as to why the program goes silent and
starts eating memory like this.
Develop free apps? http://www.jagunet.com/~braddock/fslu/org
You have new mail in /dev/null
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com