[Bug gcov-profile/64123] New: [5 Regression] Instrumented Firefox segfaults on start

[Bug gcov-profile/64123] New: [5 Regression] Instrumented Firefox segfaults on start

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

            Bug ID: 64123
           Summary: [5 Regression] Instrumented Firefox segfaults on start
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Building Firefox with PGO results in a segfault in the instrumented
browser:

markus@x4 bin % gdb ./firefox
Reading symbols from ./firefox...done.
(gdb) set follow-fork-mode parent                                               
(gdb) run
Starting program: /var/tmp/moz-build-dir/dist/bin/firefox 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
[New Thread 0x7fffe7caa700 (LWP 17887)]
[Thread 0x7fffe7caa700 (LWP 17887) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7429fdd in fread () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff7429fdd in fread () from /lib/libc.so.6
#1  0x00007ffff7feff59 in gcov_read_words (words=words@entry=2) at
../../../gcc/libgcc/../gcc/gcov-io.c:518
#2  0x00007ffff7ff055e in __gcov_read_counter () at
../../../gcc/libgcc/../gcc/gcov-io.c:555
#3  0x00007ffff7fefc8d in gcov_get_counter () at
../../../gcc/libgcc/libgcov.h:316
#4  __gcov_merge_add (counters=0x7ffff7ff4a10
<__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=<optimized out>)
at ../../../gcc/libgcc/libgcov-merge.c:56
#5  0x00007ffff1f2a736 in merge_one_data (crc32=3590671895,
eof_pos_p=<synthetic pointer>, summary_pos_p=<synthetic pointer>,
this_prg=0x7fffffff8620, prg_p=0x7fffffff9df0, 
    gi_ptr=0x7ffff7ff4540, filename=0x48fb70
"/var/tmp/moz-build-dir/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda") at
../../../gcc/libgcc/libgcov-driver.c:472
#6  dump_one_gcov (all_prg=<synthetic pointer>, this_prg=0x7fffffff8620,
crc32=3590671895, run_counted=0, gf=<synthetic pointer>, gi_ptr=0x7ffff7ff4540)
    at ../../../gcc/libgcc/libgcov-driver.c:787
#7  gcov_do_dump (list=<optimized out>, run_counted=0) at
../../../gcc/libgcc/libgcov-driver.c:846
#8  0x00007ffff1f2aab2 in __gcov_dump_one (root=root@entry=0x7ffff7ff5a80
<__gcov_root>) at ../../../gcc/libgcc/libgcov-driver.c:858
#9  0x00007ffff1f2acd8 in __gcov_dump_int () at
../../../gcc/libgcc/libgcov-interface.c:164
#10 0x00007ffff1f2ab7f in __gcov_flush () at
../../../gcc/libgcc/libgcov-interface.c:88
#11 0x00007ffff1f28bc6 in __gcov_fork () at
../../../gcc/libgcc/libgcov-interface.c:179
#12 0x00007ffff0fc4698 in fire_glxtest_process() () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#13 0x00007ffff0fb7ab2 in XREMain::XRE_mainInit(bool*) () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#14 0x00007ffff0fbdda3 in XREMain::XRE_main(int, char**, nsXREAppData const*)
() from /var/tmp/moz-build-dir/dist/bin/libxul.so
#15 0x00007ffff0fbe47b in XRE_main () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#16 0x0000000000404e59 in do_main(int, char**, nsIFile*) [clone .constprop.0]
()
#17 0x0000000000403b2f in main ()
(gdb) up
#1  0x00007ffff7feff59 in gcov_read_words (words=words@entry=2) at
../../../gcc/libgcc/../gcc/gcov-io.c:518
518           excess = fread (gcov_var.buffer + gcov_var.length,
(gdb) l
513     #else
514           if (gcov_var.length + words > gcov_var.alloc)
515             gcov_allocate (gcov_var.length + words);
516           excess = gcov_var.alloc - gcov_var.length;
517     #endif
518           excess = fread (gcov_var.buffer + gcov_var.length,
519                           1, excess << 2, gcov_var.file) >> 2;
520           gcov_var.length += excess;
521           if (gcov_var.length < words)
522             {

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Works for me now.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[marxin at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2551 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Unfortunately, I can still reproduce the problem.

Martin
>From gcc-bugs-return-474539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 23 12:16:50 2015
Return-Path: <gcc-bugs-return-474539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10979 invoked by alias); 23 Jan 2015 12:16:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10922 invoked by uid 48); 23 Jan 2015 12:16:41 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64745] Generic vectorization missed opportunities
Date: Fri, 23 Jan 2015 12:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-64745-4-lIIYgFZW9R@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64745-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64745-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02533.txt.bz2
Content-length: 247

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd745

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4545&actioníit
patch for the alingment issue

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2014-12-02 00:00:00         |2015-1-29
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Still reproduces...

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that -fno-ipa-icf does not seem to solve the crash for me.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK,
I get:
(gdb) bt
#0  _IO_fread (buf=0x7ffff7fe6740 <__gcov_var+32>, size=size@entry=1,
count=count@entry=4096, fp=0x0) at iofread.c:43
#1  0x00007ffff7fe1719 in gcov_read_words (words=words@entry=2) at
../../../libgcc/../gcc/gcov-io.c:518
#2  0x00007ffff7fe1d1e in __gcov_read_counter () at
../../../libgcc/../gcc/gcov-io.c:555
#3  0x00007ffff7fe144d in gcov_get_counter () at ../../../libgcc/libgcov.h:316
#4  __gcov_merge_add (counters=0x7ffff7fe66f8
<__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=<optimized out>)
at ../../../libgcc/libgcov-merge.c:56
#5  0x00007ffff0758f28 in merge_one_data (crc32=3347144653,
eof_pos_p=<synthetic pointer>, summary_pos_p=<synthetic pointer>,
this_prg=0x7fffffff8d60, prg_p=0x7fffffffa530,
    gi_ptr=0x7ffff7fe6340, filename=0x7ffff6f41920
"/aux/hubicka/firefox6-50-lto-fdo3/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda")
at ../../../libgcc/libgcov-driver.c:472
#6  dump_one_gcov (all_prg=<synthetic pointer>, this_prg=0x7fffffff8d60,
crc32=3347144653, run_counted=0, gf=<synthetic pointer>, gi_ptr=0x7ffff7fe6340)
    at ../../../libgcc/libgcov-driver.c:787
#7  gcov_do_dump (list=<optimized out>, run_counted=0) at
../../../libgcc/libgcov-driver.c:846
#8  0x00007ffff0759242 in __gcov_dump_one (root=root@entry=0x7ffff7fe7760
<__gcov_root>) at ../../../libgcc/libgcov-driver.c:858
#9  0x00007ffff0714fe8 in __gcov_dump_int () at
../../../libgcc/libgcov-interface.c:164
#10 0x00007ffff0714e8f in __gcov_flush () at
../../../libgcc/libgcov-interface.c:88
#11 0x00007ffff0714ca6 in __gcov_fork () at
../../../libgcc/libgcov-interface.c:179
#12 0x00007fffeb6bff8e in fire_glxtest_process() () from
/aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so
#13 0x00007fffeb842a61 in XREMain::XRE_mainInit(bool*) () from
/aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so
#14 0x00007fffeb84f339 in XREMain::XRE_main(int, char**, nsXREAppData const*)
() from /aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so
#15 0x00007fffeb84f998 in XRE_main () from
/aux/hubicka/firefox6-50-lto-fdo3/dist/bin/libxul.so
#16 0x000000000042ce70 in do_main(int, char**, nsIFile*) [clone .constprop.24]
()
#17 0x0000000000409725 in main ()

What is however interesting is:
#4  __gcov_merge_add (counters=0x7ffff7fe66f8
<__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=<optimized out>)
at ../../../libgcc/libgcov-merge.c:56

Profiling part of runtime library that is used to implement gcov is not really
intended to work.  Perhaps we somehow broke profiling of Mozilla's malloc?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xur at google dot com

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Rong, this may be related to gcov reorg.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at codesourcery dot com

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The crash happens before gcov_var->file is NULL.  Nathan, I would suspect that
perhaps one of your visibility changes makes us to use gcov_open from wrong
copy of libgcov (there are multiple shared libraries linked with it) that in
turn initializes wong copy of gcov_var->file?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Looking at the backtrace, all functions are 0x00007ffff07
until the __gcov_merge_add which is 0x00007ffff7fe so apparently coming from a
different DSO. This seems to be because the pointer come from gcov_info
desciptor that bids to different hidden instance. How this is supposed to work?

#2  0x00007ffff7fe1d1e in __gcov_read_counter () at
../../../libgcc/../gcc/gcov-io.c:555
#3  0x00007ffff7fe144d in gcov_get_counter () at ../../../libgcc/libgcov.h:316
#4  __gcov_merge_add (counters=0x7ffff7fe66f8
<__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=<optimized out>)
at ../../../libgcc/libgcov-merge.c:56
#5  0x00007ffff0758f28 in merge_one_data (crc32=3347144653,
eof_pos_p=<synthetic pointer>, summary_pos_p=<synthetic pointer>,
this_prg=0x7fffffff8d60, prg_p=0x7fffffffa530,
    gi_ptr=0x7ffff7fe6340, filename=0x7ffff6f41920
"/aux/hubicka/firefox6-50-lto-fdo3/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda")
at ../../../libgcc/libgcov-driver.c:472
#6  dump_one_gcov (all_prg=<synthetic pointer>, this_prg=0x7fffffff8d60,
crc32=3347144653, run_counted=0, gf=<synthetic pointer>, gi_ptr=0x7ffff7fe6340)
    at ../../../libgcc/libgcov-driver.c:787
#7  gcov_do_dump (list=<optimized out>, run_counted=0) at
../../../libgcc/libgcov-driver.c:846
#8  0x00007ffff0759242 in __gcov_dump_one (root=root@entry=0x7ffff7fe7760
<__gcov_root>) at ../../../libgcc/libgcov-driver.c:858
#9  0x00007ffff0714fe8 in __gcov_dump_int () at
../../../libgcc/libgcov-interface.c:164
#

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Nathan Sidwell <nathan at acm dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at acm dot org

--- Comment #10 from Nathan Sidwell <nathan at acm dot org> ---
What's the visibility on __gcov_merge_add?  All those functions should have
hidden visibility. I see:
extern void __gcov_merge_add (gcov_type *, unsigned) ATTRIBUTE_HIDDEN;

Could you give me the recipe for getting and building firefox in this manner?

To answer the 'how's it supposed to work' question.  Each DSO with coverage
needs contains its own set of gcov routines -- all hidden.  The linkage between
each dso is in the data -- each (compatible) dso chains onto the gcov_master
variable.  That is not hidden, and one will win in the resultant process.  Does
that make sense?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yep, I think the problem is that each of DSOs will have its own set of infos
that will point to its own gcov_merge_add that calls its own gcov_io routines.

Now the winning gcov will walk the list but as soon as it will hit entry from
other DSO it will indirectly call the wrong one.

gcov_merge_add is hidden in my setup.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
BTW the following fix the issue for me
Index: gcov-io.c
===================================================================
--- gcov-io.c   (revision 220230)
+++ gcov-io.c   (working copy)
@@ -39,7 +39,7 @@ static void gcov_allocate (unsigned);
 /* Optimum number of gcov_unsigned_t's read from or written to disk.  */
 #define GCOV_BLOCK_SIZE (1 << 10)

-GCOV_LINKAGE ATTRIBUTE_HIDDEN struct gcov_var
+struct gcov_var
 {
   FILE *file;
   gcov_position_t start;       /* Position of first byte of block */

indeed we are mixing up the gcov-io routines from wrong unit via wrong mergers.
I suppose either we need to pass the io routine as parameter by pointer or
modify gcov_io to actually contain indexes into merge routine list instead of
direct pointers?

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #13 from Nathan Sidwell <nathan at acm dot org> ---
No.  Each dso's gcov machinery is individually invoked.  There should be no
cross-dso accessing of data (beyond the global chain of dso)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #14 from Nathan Sidwell <nathan at acm dot org> ---
Jan, I'm fairly sure that even though your fix makes things work, it is wrong. 
You're  at the very least exposing an internal API across the DSO boundary,
which should not be exposed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
> No.  Each dso's gcov machinery is individually invoked.  There should be no
> cross-dso accessing of data (beyond the global chain of dso)
I am not saying my fix is correct, just lets me to continue in training
firefox.
So I have one global chain and one gcov destructor walking it.  What I think is
done is that the file is open by gcov-io copy of the global destructor, but
when
we merge profiles we indirectly call into merge function from other copy.

It should be easy to reproduce by profiling something consisting of two DSOs.

Honza

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #16 from xur at google dot com ---
I did not follow the trunk version closely. But from reading the code, I
think the design is each DSO uses its own copy of gcov_* functions
(including gcov_open and gcov_read_counter) and accesses its own gcov_var.
It seems to me that the global chain (by gcov_master) is merely used in
reset. The actually dump should be invoked by the gcov_exit registered for
each DSO (using its own __gcov_root) (i.e. there are multiple gcov_exit).

It's puzzling why firefox can be accessing NULL gcov_var. A reproducer
would be helpful.

-Rong


On Fri, Jan 30, 2015 at 10:02 AM, hubicka at ucw dot cz <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
> > No.  Each dso's gcov machinery is individually invoked.  There should be
> no
> > cross-dso accessing of data (beyond the global chain of dso)
> I am not saying my fix is correct, just lets me to continue in training
> firefox.
> So I have one global chain and one gcov destructor walking it.  What I
> think is
> done is that the file is open by gcov-io copy of the global destructor, but
> when
> we merge profiles we indirectly call into merge function from other copy.
>
> It should be easy to reproduce by profiling something consisting of two
> DSOs.
>
> Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #17 from Nathan Sidwell <nathan at acm dot org> ---
I'm having difficulty constructing a testcase that fails.  2 DSOs are isolated
as I expect.  (rong, your description is essentially correct).

A recipe would be good.  Also, is this on gcc trunk or gcc 5.0 branch (or
both?)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #18 from Jan Hubicka <hubicka at ucw dot cz> ---
Reducing firefox may be fun, ICE happen during fork, so perhaps adding fork to
your testcase? :)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
I guess the problem is that with fork we invoke dumping by hand instead of
relying on dtors?

honza

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #20 from Nathan Sidwell <nathan at acm dot org> ---
Adding a call to __gcov_fork doesn't cause breakage.  I'd much rather start
from a failing testcase than stab in the dark at various hypotheses.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #21 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, I am currently on a trip with sporadic internet access but I can try to
build the shared libraries.  In meantime you can also just try out firefox
profiledbuild ;)

What happens IMO is that
1) fork calls __gcov_fork
2) __gcov_fork calls __gcov_dump_int
3) gcov_dump_int traverses the global master root and walks into objects from
other DSO and calls __gcov_dump_one
4) __gcov_dump_one eventaully calls dump_one_gcov that calls merge_one_data
5) merge_one_data uses pointer from other DSO to call merge function that calls
wrong copy of gcov-io

So unlike the atexit machinery, IMO the bug is that gcov_dump_int walks the
master_root without dispatching to a proper copy of the gcov_dump_one

Honza

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #22 from Nathan Sidwell <nathan at acm dot org> ---
thanks Honza, that was helpful. I'm an idiot.  Your workaround unhiding
gcov_var is fine for now, while I figure out if there's a better way.  I am
puzzled as to why I can't observe this failure in the testcase I've
constructed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #23 from xur at google dot com ---
I overlooked that gcov_master was also used in gcov_dump_int.
The bug is exactly as Honza described. I can reproduce with a simple example.
Nathan: did you use dlopen? It seems using dlopen will change
gcov_master behavior and hide the issue.
If you call shared library function directly and use fork, you will reproduce.

On Sun, Feb 1, 2015 at 6:57 AM, nathan at acm dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #22 from Nathan Sidwell <nathan at acm dot org> ---
> thanks Honza, that was helpful. I'm an idiot.  Your workaround unhiding
> gcov_var is fine for now, while I figure out if there's a better way.  I am
> puzzled as to why I can't observe this failure in the testcase I've
> constructed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #24 from Nathan Sidwell <nathan at acm dot org> ---
xur, can you provide your testcase?  with a regular use of multiple DSOs, I
can't get a failure. (no dlopen used).

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #25 from xur at google dot com ---
attached the test case. replace CC in build_cmd with your compiler.

On Mon, Feb 2, 2015 at 12:59 PM, nathan at acm dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #24 from Nathan Sidwell <nathan at acm dot org> ---
> xur, can you provide your testcase?  with a regular use of multiple DSOs, I
> can't get a failure. (no dlopen used).

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #26 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Wed Feb  4 23:26:40 2015
New Revision: 220424

URL: https://gcc.gnu.org/viewcvs?rev=220424&root=gcc&view=rev
Log:
    PR gcov/64123
    * gcov-io.c (gcov_var): Export.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcov-io.c

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Fixed, closing.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Similar issue happens when building python with profile feedback enabled, that
is,
./configure; make profile-opt as implemented in python upstream.  Core file
tells me

(gdb) bt
#0  0x00007f890ef2616a in _IO_new_file_overflow (f=0x6052c0 <__gcov_var+32>, 
    ch=1) at fileops.c:824
#1  0x0000000000000000 in ?? ()

not terribly useful but the refered __gcov_var is still all-zeros.