Red Hat Bugzilla – Bug 50016
tree dumps core if LS_COLORS is big
Last modified: 2008-05-01 11:38:00 EDT
Description of Problem:
tree dumps core if LS_COLORS is big.
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" :]
Cores with colors, no cores if piped to somewhere or the nocolor
option is used. The core happens before anything can be shown.
A nice ASCII representation of the files, with colour if requested,
but never cores.
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
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 @@
- static char *arg;
+ static char *arg;
int i, j;
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.
Created attachment 25371 [details]
This is slightly more robust.
That extra line does not seem to break anything, it works too. So if it avoids
future problems, fine.
Fixed in 1.2-13. Thanks for the report.