Bug 50016 - tree dumps core if LS_COLORS is big
Summary: tree dumps core if LS_COLORS is big
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tree   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-26 01:13 UTC by gsr.bugs
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-30 17:32:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 12:26 UTC, Tim Waugh
no flags Details | Diff

Description gsr.bugs 2001-07-26 01:13:37 UTC
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
times.

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

---8<---
--- 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++) {

--->8---

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 12:26:39 UTC
Created attachment 25371 [details]
This is slightly more robust.

Comment 2 gsr.bugs 2001-07-30 17:32:09 UTC
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 23:09:29 UTC
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.