From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5 Description of problem: Display of hexedit messet up on x86_64 architecture Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. hexedit somefile 2. move the cursor in any direction 3. Actual Results: display gets quite messed up. Seems it forgets all spaces or something.. Expected Results: same nice structured display as when using the i386 version of the package. Additional info: Seems to be dependent on some system libraries (ncurses?) Same sources on FC3 seems to work just fine. Tested in the sourceforge compilefarm. Additionally replacing hexedit with the i386 version of the package produces the correct results.
Same sources on FC4 x86_64 also works fine. The binary RPM from development/fc5-test2 can not be tested on FC4 however due to glibc binary dependencies, but there is now very strong indication the problem is not in hexedit but in some x86_64 library, probably ncurses x86_64. - The binary RPM hexedit-1.2.12-2.1 from development/FC5-test2 fails - The binary RPM hexedit-1.2.10-4 from FC4 fails if installed in FC5-test2 - The same binary RPM hexedit-1.2.10-4 from FC4 works fine in FC4 - The i386 version of the binary RPMs works fine - hexedit compiled from source same results (fails on FC5-test2, works on earlier Fedora versions) One more parameter just discovered: Problem only seems to show in xterm, not in the text console or gnome-terminal. But it should also be noted that all the positive tests above was using the exact same xterm window.
Downgraded to ncurses-5.4-17 and problem is gone
Problem has now been isolated to something related to libncurses.so.5.5 (ncurses-5.5-10.x86_64). If only /usr/lib64/libncurses.so.5 is substituted with the version from FC4 (ncurses-5.4-17.x86_64), keeping all the other files intact (terminfo, hexedit etc) from FC5-test2 then the problem is gone.
Created attachment 123637 [details] ncurses-5.4-17 ouput xterm hexedit /etc/hosts arrow-down control-c
Created attachment 123638 [details] ncurses-5.5-10 output exact same procedure using ncurses from development/FC5-test2 quite different and odd output. A quick inspection shows lots of NULs and other interesting garbage.
I can confirm that the display is broken in the way that there are missing spaces on x86_64 with hexedit-1.2.10, currently present in FC4 (following your reproduction case in comment #4). I'm no more able to reproduce it with hexedit-1.2.12 on my x86_64 box.
Created attachment 123671 [details] The newest SRPM hexedit. I noticed you had problems installing the latest rawhide hexedit due to dependency problems, so I'm attaching SRPM here. Could you please compile it and try whether it works as expected?
For me the problem is only seen on FC5T2. Not on FC4 or earlier. And same problem is seen with all hexedit binaries I have. hexedit-1.2.12-2.1 hexedit-1.2.10-4 and versions built directly from upstream sources. If I have ncurses-5.5.10 then there is caos. If I instead use ncurses-5.4-17 (or just libncurses.so.5 from there) from FC4 on the FC5T2 system then everything is again fine. Comment #4 shows correct output. Comment #5 destroyed output. I have no dependency problems installint the latest hexedit package on my FC5T2, the only dependency issue mentioned above was that I could not test upgrading FC4 to the ncurses library from FC5T2 as a final verification that the problem is in ncurses and not hexedit. The srpm you attached IS the version I currently have and had when first seeing the issue. It still shows the problem. Additinally the problem only shows if using the x86_64 version of hexedit. The i386 version of the same version on x86_64 runs fine. I currently have: /bin/rpm -q --qf '%{name}-%{version}-%{release}.%{arch}.rpm\n' hexedit ncurses glibc hexedit-1.2.12-2.1.x86_64.rpm ncurses-5.5-10.x86_64.rpm ncurses-5.5-10.i386.rpm glibc-2.3.90-30.x86_64.rpm glibc-2.3.90-30.i686.rpm And the problem very much shows it's ugly face.
Created attachment 123690 [details] New hexedit binary package to check. Could you test this binary hexedit for x86_64? Problems are gone for me with this version.
Problem confirmed gone with this binary. but I had to forcing the package to be replaced as the version I had installed from fedora development had the exact same version number.. next time you build a test rpm please try to add a .0.test or similar to the Release to make your victims less confused.
Ok, not sure what happened here. The only thing I've made is that I rebuilt the hexedit on my rawhide x86_64 box and then tested and the bug was gone, so I needed feedback from you it really works for you as well. It looks like buildroot on the build machine was polluted, I've no clue what happened otherwise as I rebuilt it with the same CFLAGS as the build system. I'll rebuild hexedit what should fix it. FYI: $ ll total 76 -rwxr-xr-x 1 root root 34192 Jan 26 09:19 hexedit -rwxr-xr-x 1 root root 32608 Dec 11 11:13 hexedit.old $ ldd hexedit libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x0000003ad9a00000) libc.so.6 => /lib64/libc.so.6 (0x000000340a700000) libdl.so.2 => /lib64/libdl.so.2 (0x000000340aa00000) /lib64/ld-linux-x86-64.so.2 (0x000000340a500000) $ ldd hexedit.old libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x0000003ad9a00000) libc.so.6 => /lib64/libc.so.6 (0x000000340a700000) libdl.so.2 => /lib64/libdl.so.2 (0x000000340aa00000) /lib64/ld-linux-x86-64.so.2 (0x000000340a500000) $ file hexedit hexedit: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped $ file hexedit.old hexedit.old: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.20, dynamically linked (uses shared libs), for GNU/Linux 2.4.20, stripped
If so then my machine is polluted as well. If I compile hexedit from sources the same problem is seen. Only your binary works to ncurses-5.5. All others including the ones I compile either manually or using rpm fails, but all of them do work fine if ncurses is downgraded to 5.4.
$ /bin/rpm -q --qf '%{name}-%{version}-%{release}.%{arch}.rpm\n' glibc-devel ncurses-devel gcc glibc-devel-2.3.90-30.i386.rpm glibc-devel-2.3.90-30.x86_64.rpm ncurses-devel-5.5-10.x86_64.rpm ncurses-devel-5.5-10.i386.rpm gcc-4.1.0-0.15.x86_64.rpm
Personally I think it's something on your machine which is different. Remember that the symptoms is also seen if using the hexedit binary from FC4. And just for fun I now tried the FC3 x86_64 hexedit binary on my FC5T2 box and that too shows the same symptoms with this verision of ncurses. Have debugged it a bit further and it defenitely is a ncurses issue. I'll attach a small trivial curses program showing the same symptoms shortly.
Created attachment 123712 [details] Trivial curses program showing the same error gcc -o bugtest bugtest.c -lncurses; ./bugtest should show " Hello there" at the top of the screen (without quotes). WIth broken ncurses it shows "Hellothere" with the space characters replaced by null characters. The culpit is the attrset() call.
Why your hexedit binary works is still a big mystery. Which version of ncurses-devel are you using?
The only difference to your setup is the gcc version, what shouldn't be a culprit of it. $ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}.rpm\n' glibc-devel ncurses-devel gcc glibc-devel-2.3.90-30.x86_64.rpm ncurses-devel-5.5-10.i386.rpm ncurses-devel-5.5-10.x86_64.rpm gcc-4.1.0-0.16.x86_64.rpm
Found the pollution source. yum installed both x86_64 and i386 versions of ncurses-devel with no complaints, the two conflicts heavily however. Fix: rpm -e --almatches ncurses-devel yum install ncurses-devel.x86_64 Warning: arch must be specified otherwise yum brings in the i386 version as well causing a big mess.
If both i386 and x86_64 variants are installed (as we both had) then which gets broken depends on install order.
Think someone who knows how to deal with the i386/x86_64 duality of Fedora x86_64 needs to carefully look at these problems before FC5 release. A "rpm -q --verify -a" reports quite many mismatches on my system, and it's a fairly small developer workstation install. Another good question is why yum silently instealled ncurses-devel of both architectures even when they conflict. It's not just timestamp conflicts but MD5 checksum conflicts as well.
To summarize the all the issues seen in this small bug: a) ncurses-devel.i386 conflicts with ncurses-devel.x86_64 usr/include/curses.h differs between the two. b) yum happily installed both without complaints when asked to install ncurses-devel. c) x86_64 ncurses.so.5 in FC5 is apparently not ABI compatible with ncurses.so.5 in FC4 or earlier. Applications including the simple test program mentioned above built on FC4 x86_64 fails with this error if run on FC5T2 x86_64. As the FC4 I have does not have this duality of the ncurses-devel package this problem must be that something did change in key structures of ncurses x86_64 without the so versions being bumped.. I suspect this being a mistake as the i386 x86_64 variant is not affected. d) There is several dual-architecture FC5T2 packages with file content conflicts, not only ncurses-devel. Back to the analyzis of the ncurses problem: A diff between the two versions of curses.h on x86_64 reveals the following key change: i386 : typedef unsigned long chtype; x86_64 : typedef unsigned int chtype; Where in FC4 it's x86_64 : typedef unsigned long chtype; There was a bit of other differences in ncurses.h between the i386 and x86_64 variants in x86_64, but probably harmless.
--with-chtype="unsigned long" should fix the ncurses (and -devel) x86_64 package to be ABI compatible with FC4 and earlier, and as side effect should also fix the current hexedit (not your private rebuild) without the need for a rebuild. Perhaps this should be reported upstream.. Note of warning: There may be packages of both "dialects" in the x86_64 repository currently. Probably a good idea to have all the packages using ncurses rebuilt after fixing ncurses x86_64.
Thanks for the investigation, mass rebuilds are planned at least before the final FC5 relase (and maybe prior FC5t3) so packages are going to be rebuild by rel-eng team AFAIK. Reassigning to ncurses for now.
Bill, could you please have a look at comment #20? IMO it'd be good if someone from rel-eng would know about it. Thanks.
Cc'ing RPM maintainer. In theory, this conflict should be raised on package installation.
Created attachment 123831 [details] ncurses-5.5-17.src.rpm I will send you new *.src.rpm. Pease, can you try it in your scenario ? Many thanks.
in INSTALL: --with-chtype=TYPE Override type of chtype, which stores the video attributes and (if --enable-widec is not given) a character. Prior to ncurses 5.5, this was always unsigned long, but with ncurses 5.5, it may be unsigned. Use this option if you need to preserve compatibility with 64-bit executables.
Created attachment 123841 [details] Add --with-chtype=long to the spec file to preserve x86_64 ABI with earlier releases As noted in comment #22 I second Thomas on how this should be fixed. --with-chtype=long but your patch ends up in the same end result. patch attached.
Forgot to mention that this patch is tested. I have not tested your patch, but as the end result in the source tree is exactly the same (just different means to get there) I assume it also works.
In response to comment #26 on the install checks. If the x86_64 and i386 packages gets installed separately the conflict appears to be properly raised. The problem only goes undetected bu rpm when both arch packages gets installed in the same transaction.
This problem is more generic than just hexedit (as someone already illustrated, i believe). Just doing a 'make menuconfig' on the kernel source also reproduces this problem. Someone let me know if they'd like me to test the attached ncurses SRPM as well.
To comment #32: I am careful to use (&& install) x86_64*rpm/i386*rpm packages on the same 'computer' (and 'at once'). Please, see #143182, #169062 To comment #29: (many thanks for your 'bug detection/description') To 'avoid a bug in ncurses': Can we use 'my solution' (== in fact your solution) ? Please, see #143182, #169062 I do not want to see 'an ncurses' bug because a user/administrator 'uses' a 'bad' order/install-flags. To comment #28: I do not see this as a bug in ncurses. We need your help: Do you see there a possible bug, if we install always 'chtype' (ncurses-5.5) as 'unsigned long int' ?
Petr, I'm afraid I don't understand how your last comment applies to my comment #32. Also, I'm not permitted to view bug #143182, so I don't know what's in there. Bug 169062 doesn't seem to have any relevance to this bug as far as I can tell. thanks, Lonni
>I do not see this as a bug in ncurses. > We need your help: > Do you see there a possible bug, if we install always > 'chtype' (ncurses-5.5) as 'unsigned long int' ? It probably won't break applications, but is inefficient, and it won't be the default in ncurses 6.
I added --with-chtype=long since ncurses-5.5-18. Thomas, feel free to propose a better solution for this and I can eventually apply it. I don't see a better fix than the --with-chtype=long for now.
In reply to comment #33 Yes Petr, either approach works fine as they end up in the same result, just different paths to get there (yours by hand-patching the sources, mine and Thomas by using the hooks already provided by ncurses) In reply to comment #38: Next time the soversion of ncurses.so is bumped --with-chtype=long and any other flags used for binary ABI compatibility with earlier releases should be removed allowing ncurses to use it's own defaults, but until then it probably has to stay. But it may be possible to make a workaround by padding the structures accordingly to allow old binaries to work. Not sure it's worth the trouble to go thru this pain however. The i386/x86_64 header mismatch can be solved by slightly rearranging curses.h to have the correct definitions for both architectures in conditional blocks selected base on the current compile target, preferably by separating out the arch dependent parts into separate arch dependent files conditionally included from curses.h. As this requires a hardcoded list of conditions for the different architectures supported I suppose it will be partially Fedora unique. Not sure how many other distributions have this duality in ncurses development.. (same headers, different targets: i386/x86_64).