From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Description of problem:
glibc-2.2.4-30 and glibc-2.2.4-29.2, IA64
strncpy(D, S, N) fails if:
1) S is paged out and
2) N > 24
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.run the attached program in "Additional Information"
Actual Results: program prints *buf = 0x0
Expected Results: should print *buf = 0x3b
# This program demonstrates a bug in strncpy when the first argument
# is paged out and n (third argument) is > 24.
# This program calls strncpy(buf, string, 25) where string is a
# paged-out string constant. A subsequent call to print *buf shows
# incorrect data was copied.
# If the program is called with one argument (argc == 2), then the
# data at *string is referenced (paged in) before the call to
# strncpy and the copy and print succeed.
# as bug.s -o bug.o
# cc -o bug bug.o
# *buf = 0x0
# ./bug X
# *buf = 0x3b
# Strings section
# Put them way out there
stringz "*buf = 0x%x\n"
# local vars
alloc r35 = ar.pfs, 0, 8, 3, 0
# save b0, r1
mov r34 = b0
mov r33 = r1
# load addresses of strings
addl r36 = @ltoff(.string), gp
addl r37 = @ltoff(.fmt1), gp
addl r38 = @ltoff(.buf), gp
ld8 r36 = [r36]
ld8 r37 = [r37]
ld8 r38 = [r38]
# if (argc == 2) dummy = *string;
cmp.eq p2,p3 = 2,r32
(p2) ld1 r39 = [r36]
# strncpy(buf, string, 25);
mov r40 = r38
mov r41 = r36
addl r42 = 25, r0
br.call.sptk.many b0 = strncpy#
mov r1 = r33
# printf("*buf = %x\n", *buf);
mov r40 = r37
ld8 r41 = [r38]
br.call.sptk.many b0 = printf#
# restore and return
mov ar.pfs = r35
mov b0 = r34
mov r1 = r33
This patch fixes the problem - apply after the patch which is included in
--- strncpy.S Thu Oct 31 15:19:46 2002
+++ strncpy.S Thu Oct 31 17:11:34 2002
@@ -214,11 +214,11 @@
ld8 r = [tmp]
- add tmp = -MEMLAT * 8, src ;;
+ add tmp = -(MEMLAT+1) * 8, src ;;
ld8 r[MEMLAT] = [tmp]
- add tmp = -(MEMLAT - 1) * 8, src ;;
+ add tmp = -(MEMLAT) * 8, src ;;
ld8 r[MEMLAT - 1] = [tmp]
Also Issue Tracker #9868
Oops, forgot to update this bug.
The folks at Intel found more issues, their cumulative patch can be found at:
This is from Kenneth Chen <kenneth.w.chen atsign intel.com>
All this is in glibc-2.2.4-31.4 and above (ATM 31.7) for about a month.
the patch from Intel is more extensive than the one listed in the comment of
11/7/2002. is all of it in there?
if so, let's close the bug so i stop looking at it ;-)
Everything posted so far is in there, up to:
2002-12-07 Kenneth W. Chen <email@example.com>
* sysdeps/ia64/strncpy.S (strncpy): Clear ar.ec. Fix .recovery4.
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.