From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: I did a fresh install of Fedora Core 4 on a computer and have come to realize that "top" is ignoring $HOME/.toprc and /etc/toprc. I did an strace on top and it seems to be encountering an error with the toprc format generated by - you guessed it - top. I did not have this problem on a Fedora Core 3 box. Version-Release number of selected component (if applicable): procps-3.2.5-6 How reproducible: Always Steps to Reproduce: 1. Run top. 2. Configure, as desired, for the display. 3. "w" to write out a user-configuration file. 4. Quit top. 5. Reload top. Actual Results: Top reverts to default display mode. Expected Results: Top reads the $HOME/.toprc and restores user configured display. Additional info: $ rpm -qif `which top` Name : procps Relocations: (not relocatable) Version : 3.2.5 Vendor: Red Hat, Inc. Release : 6 Build Date: Tue 10 May 2005 09:52:03 AM CDT Install Date: Wed 22 Jun 2005 02:45:23 PM CDT Build Host: decompose.build.redhat.com Group : Applications/System Source RPM: procps-3.2.5-6.src.rpm Size : 358119 License: GPL Signature : DSA/SHA1, Fri 20 May 2005 12:40:47 PM CDT, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : System and process monitoring utilities. Description : The procps package contains a set of system utilities that provide system information. Procps includes ps, free, skill, snice, tload, top, uptime, vmstat, w, and watch. The ps command displays a snapshot of running processes. The top command provides a repetitive update of the statuses of running processes. The free command displays the amounts of free and used memory on your system. The skill command sends a terminate command (or another specified signal) to a specified set of processes. The snice command is used to change the scheduling priority of specified processes. The tload command prints a graph of the current system load average to a specified tty. The uptime command displays the current time, how long the system has been running, how many users are logged on, and system load averages for the past one, five, and fifteen minutes. The w command displays a list of the users who are currently logged on and what they are running. The watch program watches a running program. The vmstat command displays virtual memory statistics about processes, memory, paging, block I/O, traps, and CPU activity. Excerpt from strace (I will attach strace log to this bug later). open("/etc/toprc", O_RDONLY) = 3 read(3, "RCfile for \"top with windows\"\t\t#"..., 1087) = 605 close(3) = 0 open("/home/myohe/.toprc", O_RDONLY) = 3 read(3, "RCfile for \"top with windows\"\t\t#"..., 1085) = 605 close(3) = 0
Created attachment 115876 [details] strace output of top when it ignores system toprc and user toprc
Created attachment 115877 [details] toprc (user and system) - tried both
Does this have anything to do with "top" being in secure mode? I cannot find documentation on this behavioral change. Please advise.
Created attachment 116068 [details] bug fix patch The problem is in the top.c: windows_stage1() function where is bad code that doesn't work with gcc4. The bug fix should be available in next procps update (this or next week).
I rebuilt the package using the bugfix you provided. I still receive the same results. From strace: open("/etc/toprc", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/myohe/.toprc", O_RDONLY) = 3 read(3, "RCfile for \"top with windows\"\t\t#"..., 1085) = 605 close(3) = 0 From spec file: Patch1: procps-3.2.5-selinux.patch Patch2: procps-3.1.15-misc.patch Patch3: procps-3.2.3-FAQ.patch Patch4: procps-3.2.1-selinux-workaround.patch Patch5: procps-3.2.1-top-vmsize-env.patch Patch6: procps-3.2.3-noproc.patch Patch7: procps-3.2.3-pseudo.patch Patch8: procps-3.2.4-0x9b.patch Patch9: procps-3.2.5-sysctl-writeonly.patch Patch10: procps-3.2.5-gcc4.patch From procps-3.2.5-gcc4.patch: --- procps-3.2.5/top.c.rc 2005-06-28 17:53:14.000000000 +0200 +++ procps-3.2.5/top.c 2005-06-28 17:58:36.000000000 +0200 @@ -2365,7 +2365,7 @@ for (i = 0; i < GROUPSMAX; i++) { w = &Winstk[i]; w->winnum = i + 1; - w->rc = Rc.win[i]; + memcpy(&w->rc, &Rc.win[i], sizeof(RCF_t)); w->captab[0] = Cap_norm; w->captab[1] = Cap_norm; w->captab[2] = w->cap_bold; @@ -2375,9 +2375,10 @@ w->captab[6] = w->capclr_hdr; w->captab[7] = w->capclr_rowhigh; w->captab[8] = w->capclr_rownorm; - w->next = w + 1; - w->prev = w - 1; - ++w; + if (i < GROUPSMAX+1) + w->next = w + 1; + if (i > 0) + w->prev = w - 1; } /* fixup the circular chains... */ Winstk[3].next = &Winstk[0]; Patch applied without issue. Any clues?
Oh - I forgot to add that I did have "%patch10 -p1 -b .gcc4" in the spec file.
I took a hint from your reply that GCC 4 is the cause. So, I changed the SPEC file to "gcc32" (compat-gcc-32 installed), and rebuilt - everything works great. So there must be another GCC 4 quirk somewhere that has yet to be found.
Sorry, the patch is wrong. Problem is -O2 gcc4 option; with -O0 it works fine.
Created attachment 116089 [details] second version of the patch
Ooops.. bad day, I sent previous version of the patch.
Created attachment 116090 [details] bug fix patch
Fixed in procps-3.2.5-6.3 (FC4) and procps-3.2.3-5.3 (FC3).
*** Bug 162941 has been marked as a duplicate of this bug. ***
*** Bug 163411 has been marked as a duplicate of this bug. ***