Bug 643305

Why are you trying to build xulrunner with -gstabs+?  STABS is an horribly unexpressible old debugging format, which is further completely unsuitable for most of the 64-bit architectures.

Because we need to submit firefox/xulrunner crashes directly at mozilla.org instead of our bugzilla/abrt combo and they require the STABS debuginfo format.

BTW. The same package builds fine in Fedora 13....

Can't reproduce this, neither with 4.5.1-3.fc14 (why are you still using it, it is known to miscompile things) nor 4.5.1-4.fc14, at least not on f13 with the f14 cc1plus.  Can you g++ -S -gstabs+ output.ii and as output.s separately
and post here how line 562 looks like?

Created attachment 453694 [details]
output.s

Same problem with gcc-4.5.1-4.fc14.x86_64. Attaching output.s (line 562 is too long to paste here).

Can't reproduce this (with
gcc-c++-4.5.1-4.fc14.x86_64
binutils-2.20.51.0.7-5.fc14.x86_64
in mock), neither from the *.ii file, nor with the output.s file.

Still can reproduce with 
gcc-4.5.1-4.fc14.x86_64
binutils-2.20.51.0.7-5.fc14.x86_64
by:

g++ -c output.cpp -gstabs+
/tmp/ccN0IeZP.s: Assembler messages:
/tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `4'
/tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `:'
/tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `2'
/tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `"'

on kernel 2.6.35.4-28.fc14.x86_64. However cannot reproduce by:

as output.s -gstabs+

Scratch build which is failing:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2548101

Actually I cannot reproduce it here ... testcase from comment 0 recompiles here just fine with

gcc-c++-4.5.1-4.fc14.x86_64

on plain Fedora 14. Could you please post somewhere src.rpm so I can try to reproduce exactly what you are doing?

Thank you

Seems to be a bug in gas.

$ as -o /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa nsHtml5ElementName.s
$ as -o /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa nsHtml5ElementName.s
nsHtml5ElementName.s: Assembler messages:
nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `4'
nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `:'
nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `2'
nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `"'
$ rpm -qf /usr/bin/as
binutils-2.20.51.0.7-5.fc14.x86_64

Once the filename is longer than certain number of bytes, it fails assembling
a very long .stabs line (> 9200 chars long line).

Created attachment 460078 [details]
nsHtml5ElementName.s

Workaround - don't use ccache (then the -o filenames are reasonably short).

Might be a glibc bug too.  Matej, if you still have that box around, can you see if glibc-2.12.90-19 helps (and if the box has sse4_2)?

I've just spent a lot of time trying to find out why gcc build fails on x86_64 in f15 and it turned about to be buggy glibc on SSE4.2 capable boxes.  glibc-2.12.90-19 fixed that.

Ah, the box is still around.

So, the answer is easy, the box has sse 4.2, but glibc-2.12.90-19 does not help.

Running as under valgrind gives the clues though:

valgrind /usr/bin/as -o /tmp/a nsHtml5ElementName.s
==28535== Memcheck, a memory error detector
==28535== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==28535== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==28535== Command: /usr/bin/as -o /tmp/a nsHtml5ElementName.s
==28535== 
==28535== Source and destination overlap in memcpy(0x5b3fde1, 0x5b42d2f, 20936)
==28535==    at 0x4C27A3A: memcpy (mc_replace_strmem.c:497)
==28535==    by 0x411068: input_scrub_next_buffer (string3.h:52)
==28535==    by 0x41CC39: read_a_source_file (read.c:612)
==28535==    by 0x405808: main (as.c:1044)
==28535== 
==28535== 
==28535== HEAP SUMMARY:
==28535==     in use at exit: 6,985,320 bytes in 8,789 blocks
==28535==   total heap usage: 9,717 allocs, 928 frees, 8,737,826 bytes allocated
==28535== 
==28535== LEAK SUMMARY:
==28535==    definitely lost: 29,810 bytes in 58 blocks
==28535==    indirectly lost: 130,400 bytes in 6,520 blocks
==28535==      possibly lost: 5,047,136 bytes in 1,389 blocks
==28535==    still reachable: 1,777,974 bytes in 822 blocks
==28535==         suppressed: 0 bytes in 0 blocks
==28535== Rerun with --leak-check=full to see details of leaked memory
==28535== 
==28535== For counts of detected and suppressed errors, rerun with: -v
==28535== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

And a quick look at the code in question reveals this is
http://sourceware.org/bugzilla/show_bug.cgi?id=11456

Hi Guys,

  I have imported the patch for PR 11456 into the F14 binutils branch:

   binutils-2.20.51.0.7-6.fc14.x86_64

  Can someone let me know if this is sufficient to fix the problem ?

Cheers
  Nick

Looks fine. Cannot reproduce with binutils-2.20.51.0.7-6.fc14.x86_64.

Releasing the box, it doesn't seem like it is needed anymore.

binutils-2.20.51.0.7-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/binutils-2.20.51.0.7-6.fc14

binutils-2.20.51.0.7-6.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update binutils'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/binutils-2.20.51.0.7-6.fc14

binutils-2.20.51.0.7-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.