public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "deller at gmx dot de" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/29583] New: iconv failures on 32bit platform due to missing large file support
Date: Sun, 18 Sep 2022 16:53:10 +0000	[thread overview]
Message-ID: <bug-29583-131@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=29583

            Bug ID: 29583
           Summary: iconv failures on 32bit platform due to missing large
                    file support
           Product: glibc
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: deller at gmx dot de
                CC: carlos at redhat dot com
  Target Milestone: ---

While compiling glibc in a 32-bit environment (hppa architecture, 32-bit
userspace, but 64-bit kernel, glibc target is 32-bit as well) I see lots of
failures with iconv like this one:

/build/glibc/glibc-2.34/build-tree/hppa-libc/iconv/iconv_prog: failed to start
conversion processing

I traced it with strace:
3438821
openat(AT_FDCWD,"/build/glibc/glibc-2.34/build-tree/hppa-libc/iconvdata/gconv-modules",O_RDONLY|O_CLOEXEC)
= 3
3438821 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0xf50013c8)
= 0
3438821 read(3,0xfa034678,4096) = 3808
3438821 read(3,0xfa034678,4096) = 0
3438821 close(3) = 0
3438821
openat(AT_FDCWD,"/build/glibc/glibc-2.34/build-tree/hppa-libc/iconvdata/gconv-modules.d",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_NONBLOCK|O_CLOEXEC)
= 3
3438821 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0xf5001148)
= 0
3438821 getdents64(3,-100439584,32768,99,8,0) = 96
3438821 close(3) = 0

This part comes from gconv_parseconfdir() in  conv/gconv_parseconfdir.h:

  /* Read the gconv-modules configuration file first.  */
  found = read_conf_file (buf, dir, dir_len);

  /* Next, see if there is a gconv-modules.d directory containing
     configuration files and if it is non-empty.  */
  cp--;
  cp[0] = '.';
  cp[1] = 'd';
  cp[2] = '\0';

  DIR *confdir = opendir (buf);
  if (confdir != NULL)
    {
      struct dirent *ent;
      while ((ent = readdir (confdir)) != NULL)

as can be seen, readdir() is called and the syscall returns 96 bytes for
getdents64(), but the "ent" variable nevertheless gets NULL and returns without
reading the "gconv-modules-extra.conf" file.

Finally it turns out, that this is a problem of missing large file support
while scanning the contents of the gconv-modules.d/ directory.
In my build environment the
/build/glibc/glibc-2.34/build-tree/hppa-libc/iconvdata/gconv-modules.d/gconv-modules-extra.conf
file is located on-disk on a high inode, 
thus the readdir() function returns NULL.

I manually changed the code above to use the 64-bit variants to become:
      struct dirent64 *ent;
      while ((ent = readdir64 (confdir)) != NULL)
which then worked.

So finally, I'd suggest to enable 64-bit file-support for this specific
function.
Either by manually using the 64-bit variants, or by compiling with 
-D_LARGE_FILE_SOURCE=1  -D_FILE_OFFSET_BITS=64
(whatever is possible and makes sense).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

             reply	other threads:[~2022-09-18 16:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-18 16:53 deller at gmx dot de [this message]
2022-09-18 17:07 ` [Bug build/29583] " danglin at gcc dot gnu.org
2022-09-19  6:59 ` fweimer at redhat dot com
2022-09-19  7:27 ` fweimer at redhat dot com
2022-09-20 10:13 ` fweimer at redhat dot com
2022-09-20 19:13 ` deller at gmx dot de
2022-09-21 12:13 ` fweimer at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-29583-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).