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-bugzi...@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. >
