2:26 p.m.
Hello,
I'm getting a build failure on the armv7hl arch
and the i686 arch, which do not make much sense.
The build is [1] and only those arche are complaining about an sprintf() statement.
The rest of the arches are fine with the statment... %99.9 of the arches
that are used today... I didn't even realize i686 was still supported!
The is the failure:
conffile.c: In function 'conf_init_dir':
conffile.c:707:22: error: '%s' directive writing between 6 and 2147483645 bytes
into a region of size between 4095 and 4096 [-Werror=format-overflow=]
707 | sprintf(fname, "%s/%s", dname, d->d_name);
| ^~
In file included from /usr/include/stdio.h:866,
from conffile.c:45:
/usr/include/bits/stdio2.h:38:10: note: '__sprintf_chk' output 8 or more bytes
(assuming 2147483648) into a destination of size 4097
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So I change the sprintf() to an snprintf() [2] guaranteeing no
overflow and I got the same failure. So it is something esoteric
about those arches... that I'm missing...
Anybody have clue as to what is going on??
tia,
steved.
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=55126237
2:38 p.m.
On 11/7/20 1:26 PM, Steve Dickson wrote:
Hello,
I'm getting a build failure on the armv7hl arch
and the i686 arch, which do not make much sense.
The build is [1] and only those arche are complaining about an sprintf() statement.
The rest of the arches are fine with the statment... %99.9 of the arches
that are used today... I didn't even realize i686 was still supported!
The is the failure:
conffile.c: In function 'conf_init_dir':
conffile.c:707:22: error: '%s' directive writing between 6 and 2147483645 bytes
into a region of size between 4095 and 4096 [-Werror=format-overflow=]
707 | sprintf(fname, "%s/%s", dname, d->d_name);
| ^~
In file included from /usr/include/stdio.h:866,
from conffile.c:45:
/usr/include/bits/stdio2.h:38:10: note: '__sprintf_chk' output 8 or more bytes
(assuming 2147483648) into a destination of size 4097
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So I change the sprintf() to an snprintf() [2] guaranteeing no
overflow and I got the same failure. So it is something esoteric
about those arches... that I'm missing...
Anybody have clue as to what is going on??
tia,
steved.
I think the compiler is trying to keep track of how large string pointed
to by d->d_name could be. You'll need to look into how that is created.
No idea why snprintf() doesn't help.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
3:41 p.m.
On 11/7/20 1:38 PM, Orion Poplawski wrote:
On 11/7/20 1:26 PM, Steve Dickson wrote:
> Hello,
>
> I'm getting a build failure on the armv7hl arch
> and the i686 arch, which do not make much sense.
>
> The build is [1] and only those arche are complaining about an
> sprintf() statement.
> The rest of the arches are fine with the statment... %99.9 of the arches
> that are used today... I didn't even realize i686 was still supported!
>
> The is the failure:
> conffile.c: In function 'conf_init_dir':
> conffile.c:707:22: error: '%s' directive writing between 6 and
> 2147483645 bytes into a region of size between 4095 and 4096
> [-Werror=format-overflow=]
> 707 | sprintf(fname, "%s/%s", dname, d->d_name);
> | ^~
> In file included from /usr/include/stdio.h:866,
> from conffile.c:45:
> /usr/include/bits/stdio2.h:38:10: note: '__sprintf_chk' output 8 or
> more bytes (assuming 2147483648) into a destination of size 4097
> 38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 39 | __bos (__s), __fmt, __va_arg_pack ());
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So I change the sprintf() to an snprintf() [2] guaranteeing no
> overflow and I got the same failure. So it is something esoteric
> about those arches... that I'm missing...
>
> Anybody have clue as to what is going on??
>
> tia,
>
> steved.
I think the compiler is trying to keep track of how large string
pointed to by d->d_name could be. You'll need to look into how that
is created.
That is precisely what it is doing.
No idea why snprintf() doesn't help.
Likewise. I recommend filing an upstream GCC bug report. Feel free to
cc law(a)redhat.com and msebor(a)redhat.com on that upstream bug.
jeff
4:18 p.m.
Steve Dickson wrote:
So I change the sprintf() to an snprintf() [2] guaranteeing no
overflow and I got the same failure.
Not quite the same. It still doesn't know how long the string can be,
and so assumes that it can be too long, but after the change it warns
about truncation instead of overflow.
Björn Persson
3:58 a.m.
Steve Dickson wrote on 2020/11/08 5:26:
Hello,
I'm getting a build failure on the armv7hl arch
and the i686 arch, which do not make much sense.
The build is [1] and only those arche are complaining about an sprintf() statement.
The rest of the arches are fine with the statment... %99.9 of the arches
that are used today... I didn't even realize i686 was still supported!
The is the failure:
conffile.c: In function 'conf_init_dir':
conffile.c:707:22: error: '%s' directive writing between 6 and 2147483645 bytes
into a region of size between 4095 and 4096 [-Werror=format-overflow=]
707 | sprintf(fname, "%s/%s", dname, d->d_name);
| ^~
In file included from /usr/include/stdio.h:866,
from conffile.c:45:
/usr/include/bits/stdio2.h:38:10: note: '__sprintf_chk' output 8 or more bytes
(assuming 2147483648) into a destination of size 4097
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So I change the sprintf() to an snprintf() [2] guaranteeing no
overflow and I got the same failure. So it is something esoteric
about those arches... that I'm missing...
Anybody have clue as to what is going on??
tia,
steved.
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=55126237
Not a direct
answer, but it seems checking the return value of snprintf() makes
-Werror=format-overflow or -Werror=format-truncation happy:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55157631
How I've changed is to modify your
"0001-conffile-process-config.d-directory-config-files.patch" as:
========================================================================
--- 0001-conffile-process-config.d-directory-config-files.patch.old 2020-11-07
00:32:04.000000000 +0900
+++ 0001-conffile-process-config.d-directory-config-files.patch 2020-11-08
18:40:02.634207926 +0900
@@ -106,7 +106,7 @@
+ continue;
+
+ fname_len = strlen(d->d_name);
-+ if (!fname_len || (fname_len + dname_len) > PATH_MAX) {
++ if (!fname_len || (snprintf(fname, PATH_MAX + 1, "%s/%s", dname,
d->d_name) > PATH_MAX)) {
+ xlog(L_WARNING, "conf_init_dir: Too long file name: %s in %s",
+ d->d_name, dname);
+ continue;
@@ -128,7 +128,7 @@
+ continue;
+ }
+
-+ sprintf(fname, "%s/%s", dname, d->d_name);
++ /*sprintf(fname, "%s/%s", dname, d->d_name);*/
+
+ if (conf_load_files(trans, fname))
+ continue;
========================================================================
Regards,
Mamoru
10:21 p.m.
New subject: nfs-utils: compiler error tracking strlen on Rawhide armv7hl and i686
Let's handle some preliminary errors in this thread on building nfs-utils, before they
spread even more.
1. Be specific. State the package name in both the Subject and the first line of the
body.
This provides context which aids the scanning of Subjects and enables detection and
correction
of copy+paste errors.
2. The return value from both printf() and snprintf() with a format of "%s/%s"
is
s(trlen(str1) + 1 + strlen(str2)) /* +1: the '/' separator */
[note that this is strlen() of the unconstrained destination array],
and the number of bytes written (if not limited by the size parameter to snprintf())
is 1 more because of the terminating NUL byte '\0'.
Thus the minimum size of the unconstrained destination is (2 + strlen(str1) +
strlen(str2)).
3. Do not use "PATH_MAX + 1". Almost always it indicates a programmer error.
From /usr/include/linux/limits.h we see that
#define PATH_MAX 4096 /* # chars in a path name including nul */
Increasing the size does not work: if (4096 <= strlen(path)) /* Yes, '<='
*/
then the Linux kernel will do something other than what you naively expect.
The "destination too small" error condition for (rv = snprintf(array, size,
format, ...))
is (size <= rv); using anything else is a bug.
After taking care of those bugs above, and looking at the constants such as
'2147483645'
and '2147483648' in the compiler's complaints, it is obvious that the compiler
erred
when tracking the result value from some call to strlen(). If you want help then
please supply the complete source code. I could not locate the downloadable source for
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
even after following several links.
12:03 a.m.
New subject: nfs-utils: compiler error tracking strlen on Rawhide armv7hl and
i686
John Reiser wrote on 2020/11/09 13:21:
If you want help then
please supply the complete source code. I could not locate the downloadable source for
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
even after following several links.
Replying to this instead of the people who posted this thread first, the original source
is located on:
https://kojipkgs.fedoraproject.org//work/tasks/5503/55125503/nfs-utils-2....
(Well, actually difficult to find, however you can get to this by
- opening [1]
- click "rebuildSRPM (noarch)" task URL
- then you'll find the actuall srpm link
Regards,
Mamoru
9:13 a.m.
New subject: nfs-utils: compiler error tracking strlen on Rawhide armv7hl and
i686
On 11/8/20 11:21 PM, John Reiser wrote:
Let's handle some preliminary errors in this thread on building
nfs-utils, before they spread even more.
1. Be specific. State the package name in both the Subject and the first line of the
body.
This provides context which aids the scanning of Subjects and enables detection and
correction
of copy+paste errors.
2. The return value from both printf() and snprintf() with a format of "%s/%s"
is
s(trlen(str1) + 1 + strlen(str2)) /* +1: the '/' separator */
[note that this is strlen() of the unconstrained destination array],
and the number of bytes written (if not limited by the size parameter to snprintf())
is 1 more because of the terminating NUL byte '\0'.
Thus the minimum size of the unconstrained destination is (2 + strlen(str1) +
strlen(str2)).
3. Do not use "PATH_MAX + 1". Almost always it indicates a programmer error.
From /usr/include/linux/limits.h we see that
#define PATH_MAX 4096 /* # chars in a path name including nul */
Increasing the size does not work: if (4096 <= strlen(path)) /* Yes, '<='
*/
then the Linux kernel will do something other than what you naively expect.
The "destination too small" error condition for (rv = snprintf(array, size,
format, ...))
is (size <= rv); using anything else is a bug.
By using PATH_MAX instead of
PATH_MAX +1 and
by using snprintf() instead of sprintf() and
finally checking the return value of snprintf()
the error no longer exists.
After taking care of those bugs above, and looking at the constants such as
'2147483645'
and '2147483648' in the compiler's complaints, it is obvious that the
compiler erred
when tracking the result value from some call to strlen(). If you want help then
please supply the complete source code. I could not locate the downloadable source for
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
even after following several links.
If still interested here is the srpm [1] (the
patch is in tmp.diff)
Thanks everyone for all the input!!! It was definitely appreciated!!
steved.
[1] http://people.redhat.com/steved/.tmp/nfs-utils-2.5.2-1.fc34.src.rpm
1273
days inactive
1275
days old
7 comments
6 participants
participants (6)
-
Björn Persson -
Jeff Law -
John Reiser -
Mamoru TASAKA -
Orion Poplawski -
Steve Dickson