Bug 50016 - tree dumps core if LS_COLORS is big
tree dumps core if LS_COLORS is big
Product: Red Hat Linux
Classification: Retired
Component: tree (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2001-07-25 21:13 EDT by gsr.bugs
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-30 13:32:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is slightly more robust. (385 bytes, patch)
2001-07-30 08:26 EDT, Tim Waugh
no flags Details | Diff

  None (edit)
Description gsr.bugs 2001-07-25 21:13:37 EDT
Description of Problem:

tree dumps core if LS_COLORS is big.

How Reproducible:

When $LS_COLORS really big ("echo $LS_COLORS | wc -c" gives over 1500
here, and in DIR_COLORS I can grep over 100 lines with the char ";", aka
over 100 with colour info), and tree is invoked with colour option. If no
colour or piped, it works fine. 

Steps to Reproduce:
1. Edit /etc/DIR_COLORS to add lots of entries, or set a big $LS_COLORS
(but valid data, it is not due wrong data).
2. Do tree in a dir where you can write, and instead of the list you get
a new file named core.
3. >Pick core. "The core is recent" >Examine core. "This core was created
by tree" :]

Actual Results:

Cores with colors, no cores if piped to somewhere or the nocolor
option is used. The core happens before anything can be shown.

Expected Results:

A nice ASCII representation of the files, with colour if requested,
but never cores.

Additional Information:
I talked with the coder of tree some months (years?) ago, and after
some comments about what was going on in the traces I did, he pointed
me to an area of the code, asking me to change an array size. I did,
and it works now. So the problem is that the array was too small for
my LS_COLORS info. Another solution would be to change that code to
use lists.

Dunno why has not been fixed yet, cos the first time I saw it I think
7.0 had not been released, and I have patched my files two or three

Here is a diff based in the tree.c I got from the RH71 SRPM:

--- tree.c-new  Mon Jul 16 01:13:14 2001
+++ tree.c      Mon Jan  6 04:56:17 1997
@@ -752,7 +752,7 @@
 char **parse(b)
 char *b;
-  static char *arg[1000];
+  static char *arg[100];
   int i, j;
   for(j=0;*b;b++) {


I use around 140 of the array now, so 1000 should be enough until
a real solution is applied. I guess few people use so many entries, but
I would like to see the solution applied.
Comment 1 Tim Waugh 2001-07-30 08:26:39 EDT
Created attachment 25371 [details]
This is slightly more robust.
Comment 2 gsr.bugs 2001-07-30 13:32:09 EDT
That extra line does not seem to break anything, it works too. So if it avoids
future problems, fine.
Comment 3 Tim Waugh 2001-07-31 19:09:29 EDT
Fixed in 1.2-13.  Thanks for the report.

Note You need to log in before you can comment on or make changes to this bug.