Re: Help needed with new segfaults in frame unwinding under gcc8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "JR" == John Reiser <jreiser@xxxxxxxxxxxx> writes:

JR> Please create a bugzilla report, or other well-known tracking
JR> instance.

But where?  I don't even know whose problem this is.  It's taken me days
of what little free time I have just to figure out how to get the
backtrace I was able to provide.

I am certainly conditioned to assume that the compiler is working as
designed and problems like this are due to upstream code issues which
simply weren't exposed with previous versions of the compiler.  And
while tracking this all down, I did find at least one real live bug in
the upstream code.

JR> Non-repeatability due to unspecified or mismatched versions is
JR> frustrating.

Well, sure it is.  I just don't have enough information to do anything
other than spew random things.  I'm still trying to understand what's
gone wrong where, and what information is relevant.

I can certainly list the versions of everything in the buildroot, and
everything in the buildroot of the last successful build.  But I don't
think that's going to be particularly useful.  I only know that it
failed to build during the mass rebuild that happened after gcc (and
plenty of other things) was updated.

JR> What does running under memcheck ("valgrind --track-origins=yes
JR> ...") say?

Well, I can run the test suite under valgrind.  It seems to be able to
trace children, too.  I did:

valgrind --track-origins=yes --trace-children=yes ./testrunner.pl -v -f
pretty SearchFuzzy.xapianv2

and got a pile of output.  Narrowing down to just the indexing process
(called squatter) which actually segfaults gives the output I include at
the end of this message.

JR> The reported behavior is consistent with use of an uninitialized
JR> value.

In whose code?  It sounds like you're saying that the upstream code is
broken, which of course would be something I could understand, but....

JR> Looking at the code: ===== gcc/libgcc/unwind.inc

... here you're talking about gcc code.

JR> This is a giant red flag for unreliable code.

And I'm still confused about whose code is unreliable.

 - J<

Output under valgrind for the process which segfaults:

==22846== Memcheck, a memory error detector
==22846== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22846== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==22846== Command: /builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2352581/conf/imapd.conf
==22846==
2352581/squatter[22846]: SQL backend defaulting to engine 'pgsql'
2352581/squatter[22846]: indexing mailboxes
2352581/squatter[22846]: indexing mailbox user.cassandane...
==22846== Conditional jump or move depends on uninitialised value(s)
==22846==    at 0xBCC2052: _Unwind_Resume (unwind.inc:240)
==22846==    by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==    by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==    by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==    by 0x588D58A: search_update_mailbox (search_engines.c:211)
==22846==    by 0x10C104: index_one (squatter.c:292)
==22846==    by 0x10B773: do_indexer (squatter.c:352)
==22846==    by 0x10B773: main (squatter.c:1004)
==22846==  Uninitialised value was created by a stack allocation
==22846==    at 0x5837ED0: ??? (in /builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/lib64/libcyrus_imap.so.0.0.0)
==22846==
==22846== Use of uninitialised value of size 8
==22846==    at 0xBCC181B: _Unwind_ForcedUnwind_Phase2 (unwind.inc:170)
==22846==    by 0x1FFEFFF76F: ???
==22846==    by 0x1FFEFFF6DF: ???
==22846==    by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
==22846==    by 0xE6F90EF: ???
==22846==    by 0x1FFEFFF77F: ???
==22846==    by 0xE6F5F6F: ???
==22846==    by 0x1FFEFFF74F: ???
==22846==    by 0x1FFEFFF76F: ???
==22846==    by 0xE6F550F: ???
==22846==    by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==    by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==    by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==  Uninitialised value was created by a stack allocation
==22846==    at 0x5837ED0: ??? (in /builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/lib64/libcyrus_imap.so.0.0.0)
==22846==
==22846== Jump to the invalid address stated on the next line
==22846==    at 0x120: ???
==22846==    by 0x1FFEFFF6DF: ???
==22846==    by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
==22846==    by 0xE6F90EF: ???
==22846==    by 0x1FFEFFF77F: ???
==22846==    by 0xE6F5F6F: ???
==22846==    by 0x1FFEFFF74F: ???
==22846==    by 0x1FFEFFF76F: ???
==22846==    by 0xE6F550F: ???
==22846==    by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==    by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==    by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==    by 0x588D58A: search_update_mailbox (search_engines.c:211)
==22846==  Address 0x120 is not stack'd, malloc'd or (recently) free'd
==22846==
==22846==
==22846== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==22846==  Bad permissions for mapped region at address 0x120
==22846==    at 0x120: ???
==22846==    by 0x1FFEFFF6DF: ???
==22846==    by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
==22846==    by 0xE6F90EF: ???
==22846==    by 0x1FFEFFF77F: ???
==22846==    by 0xE6F5F6F: ???
==22846==    by 0x1FFEFFF74F: ???
==22846==    by 0x1FFEFFF76F: ???
==22846==    by 0xE6F550F: ???
==22846==    by 0x5839B8F: stem_version_set (xapian_wrap.cpp:264)
==22846==    by 0x5839B8F: xapian_dbw_open.cold.223 (xapian_wrap.cpp:327)
==22846==    by 0x58AC2EE: begin_mailbox_update (search_xapian.c:1535)
==22846==    by 0x588D58A: search_update_mailbox (search_engines.c:211)
==22846==
==22846== HEAP SUMMARY:
==22846==     in use at exit: 344,795 bytes in 91 blocks
==22846==   total heap usage: 370 allocs, 279 frees, 489,235 bytes allocated
==22846==
==22846== LEAK SUMMARY:
==22846==    definitely lost: 0 bytes in 0 blocks
==22846==    indirectly lost: 0 bytes in 0 blocks
==22846==      possibly lost: 393 bytes in 2 blocks
==22846==    still reachable: 344,402 bytes in 89 blocks
==22846==         suppressed: 0 bytes in 0 blocks
==22846== Rerun with --leak-check=full to see details of leaked memory
==22846==
==22846== For counts of detected and suppressed errors, rerun with: -v
==22846== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux