Bug 178824 - garbled display when using x86_64 hexedit package, i386 package fine
garbled display when using x86_64 hexedit package, i386 package fine
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-24 12:27 EST by Henrik Nordstrom
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: ncurses-5.5 Rel.17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-31 05:09:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ncurses-5.4-17 ouput (1.04 KB, text/plain)
2006-01-24 17:23 EST, Henrik Nordstrom
no flags Details
ncurses-5.5-10 output (4.75 KB, text/plain)
2006-01-24 17:25 EST, Henrik Nordstrom
no flags Details
The newest SRPM hexedit. (67.29 KB, application/x-rpm)
2006-01-25 09:02 EST, Jindrich Novy
no flags Details
New hexedit binary package to check. (36.77 KB, application/x-rpm)
2006-01-25 16:11 EST, Jindrich Novy
no flags Details
Trivial curses program showing the same error (146 bytes, text/plain)
2006-01-26 07:38 EST, Henrik Nordstrom
no flags Details
ncurses-5.5-17.src.rpm (1.67 MB, application/x-rpm)
2006-01-28 04:21 EST, Petr Raszyk
no flags Details
Add --with-chtype=long to the spec file to preserve x86_64 ABI with earlier releases (1.16 KB, patch)
2006-01-28 13:19 EST, Henrik Nordstrom
no flags Details | Diff

  None (edit)
Description Henrik Nordstrom 2006-01-24 12:27:11 EST
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.
Comment 1 Henrik Nordstrom 2006-01-24 16:41:20 EST
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.

Comment 2 Henrik Nordstrom 2006-01-24 16:54:52 EST
Downgraded to ncurses-5.4-17 and problem is gone
Comment 3 Henrik Nordstrom 2006-01-24 17:18:07 EST
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.
Comment 4 Henrik Nordstrom 2006-01-24 17:23:11 EST
Created attachment 123637 [details]
ncurses-5.4-17 ouput

xterm
hexedit /etc/hosts
arrow-down
control-c
Comment 5 Henrik Nordstrom 2006-01-24 17:25:11 EST
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.
Comment 6 Jindrich Novy 2006-01-25 08:55:53 EST
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. 
Comment 7 Jindrich Novy 2006-01-25 09:02:04 EST
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?
Comment 8 Henrik Nordstrom 2006-01-25 09:48:09 EST
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.
Comment 9 Jindrich Novy 2006-01-25 16:11:49 EST
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.
Comment 10 Henrik Nordstrom 2006-01-25 20:43:30 EST
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.
Comment 11 Jindrich Novy 2006-01-26 04:34:07 EST
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
Comment 12 Henrik Nordstrom 2006-01-26 06:04:28 EST
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.
Comment 13 Henrik Nordstrom 2006-01-26 06:06:58 EST
$ /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
Comment 14 Henrik Nordstrom 2006-01-26 07:33:05 EST
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.
Comment 15 Henrik Nordstrom 2006-01-26 07:38:02 EST
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.
Comment 16 Henrik Nordstrom 2006-01-26 07:39:57 EST
Why your hexedit binary works is still a big mystery.

Which version of ncurses-devel are you using?
Comment 17 Jindrich Novy 2006-01-26 08:02:08 EST
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
Comment 18 Henrik Nordstrom 2006-01-26 08:48:23 EST
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.
Comment 19 Henrik Nordstrom 2006-01-26 08:49:29 EST
If both i386 and x86_64 variants are installed (as we both had) then which gets
broken depends on install order.
Comment 20 Henrik Nordstrom 2006-01-26 09:00:12 EST
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.
Comment 21 Henrik Nordstrom 2006-01-26 09:32:58 EST
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.
Comment 22 Henrik Nordstrom 2006-01-26 09:44:24 EST
--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.
Comment 23 Jindrich Novy 2006-01-26 10:02:02 EST
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.
Comment 24 Jindrich Novy 2006-01-26 10:05:18 EST
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.
Comment 26 Bill Nottingham 2006-01-26 15:22:39 EST
Cc'ing RPM maintainer. In theory, this conflict should be raised on package
installation.
Comment 27 Petr Raszyk 2006-01-28 04:21:32 EST
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.
Comment 28 Thomas E. Dickey 2006-01-28 10:01:32 EST
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.
Comment 29 Henrik Nordstrom 2006-01-28 13:19:51 EST
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.
Comment 30 Henrik Nordstrom 2006-01-28 13:22:10 EST
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.
Comment 31 Henrik Nordstrom 2006-01-28 13:33:18 EST
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.
Comment 32 Lonni J Friedman 2006-01-29 12:53:47 EST
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.
Comment 33 Petr Raszyk 2006-01-30 05:32:44 EST
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' ?

Comment 34 Lonni J Friedman 2006-01-30 11:37:45 EST
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
Comment 36 Thomas E. Dickey 2006-01-30 20:41:48 EST
>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.
Comment 37 Jindrich Novy 2006-01-31 05:00:48 EST
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.
Comment 38 Henrik Nordstrom 2006-02-01 23:47:46 EST
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).

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