Bug 166707 - gcc4-compiled mkisofs generates bad iso-images
gcc4-compiled mkisofs generates bad iso-images
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cdrtools (Show other bugs)
4
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-24 16:03 EDT by Magnus Hultman
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-18 03:33:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cdrtools.patch (2.60 KB, patch)
2005-08-27 04:43 EDT, Jakub Jelinek
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 23561 None None None Never

  None (edit)
Description Magnus Hultman 2005-08-24 16:03:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
The precompiled mkisofs generates iso-images which are not readable by Windows (at least Windows 98). If I recompile the source-rpm of mkisofs with gcc32 (compat-gcc-32-3.2.3-47.fc4) it works fine.

Version-Release number of selected component (if applicable):
mkisofs-2.01.1-9 gcc-4.0.1-4.fc4

How reproducible:
Always

Steps to Reproduce:
mkdir /tmp/empty
touch /tmp/empty/file.txt
mkisofs.gcc32 -o /tmp/empty32.iso /tmp/empty
mkisofs -o /tmp/empty40.iso /tmp/empty
ls -l /tmp/empty*iso
cmp -lc /tmp/empty32.iso /tmp/empty40.iso



Actual Results:  -rw-r--r--  1 root root 356352 Aug 24 20:51 /tmp/empty32.iso
-rw-r--r--  1 root root 356352 Aug 24 20:51 /tmp/empty40.iso

32775   1 ^A     0 ^@
34823   1 ^A     0 ^@


Expected Results:  The files should be identical except for perhaps the date.

Additional info:
Comment 1 Jakub Jelinek 2005-08-25 05:35:52 EDT
The source is crappy (initializes a 5 byte long array field with 6 bytes using
memcpy), but GCC should handle this.

Simplified testcase:
struct A
{
  char a1[1];
  char a2[5];
  char a3[1];
  char a4[2048 - 7];
} a;

typedef __SIZE_TYPE__ size_t;
extern void *memset (void *, int, size_t);
extern void *memcpy (void *, const void *, size_t);
extern int memcmp (const void *, const void *, size_t);
extern void abort (void);

void
bar (struct A *x)
{
  size_t i;
  if (memcmp (x, "\1HELLO\1", sizeof "\1HELLO\1"))
    abort ();
  for (i = 0; i < sizeof (x->a4); i++)
    if (x->a4[i])
      abort ();
}

int
foo (void)
{
  memset (&a, 0, sizeof (a));
  a.a1[0] = 1;
  memcpy (a.a2, "HELLO", sizeof "HELLO");
  a.a3[0] = 1;
  bar (&a);
  return 0;
}

int
main (void)
{
  foo ();
  return 0;
}
Comment 2 Jakub Jelinek 2005-08-27 04:43:15 EDT
Created attachment 118185 [details]
cdrtools.patch

Should be fixed in gcc-4.0.1-11.
Reassigning to cdrtools, as this is really something that should be fixed
in cdrtools, it is a clear thinko to memcpy 6 bytes into a 5 byte character
array, especially when the following field that overlaps the 6th byte is
immediately written afterwards.
Plus, warn_unused_result warnings found 2 places where realloc did not check
the
result, which is a very severe bug.
Comment 3 Fedora Update System 2005-09-30 10:34:37 EDT
From User-Agent: XML-RPC

cdrtools-2.01.1-9.0.FC4.1 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 4 Fedora Update System 2005-10-07 11:52:12 EDT
From User-Agent: XML-RPC

cdrtools-2.01.1-9.0.FC4.1 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 5 Magnus Hultman 2005-10-17 15:12:18 EDT
It works perfectly. Thank you!

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