Jason L Tibbitts III wrote:
"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.
For any SIGSEGV, file bugzilla against the package that contains the
program counter at the time of the fault. In this case, libgcc
(which bugzilla might say, "libgcc is part of gcc, so use gcc.")
Then post here the URL of the bugzilla report.
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.
Include the versions of the packages for these pieces, please:
cyrus-imapd and any package that it BuildRequires or Requires
gcc, libgcc
gcc-c++, libstdc++
glibc
binutils (for /usr/bin/ld)
mock
kernel
The idea is: I want to run _exactly_ "the same thing" as you did.
valgrind --track-origins=yes --trace-children=yes ./testrunner.pl -v -f
pretty SearchFuzzy.xapianv2
This is good progress!
> ==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== by 0xBCA8C7F: ??? (in /usr/lib64/libstdc++.so.6.0.25)
Those one-line tracebacks, with no source file and no line number,
are a clue that valgrind could find no corresponding degbuginfo.
Please install the debuginfo for libcyrus_imap.so.0.0.0 and libstdc++.so.6.0.25,
then re-run valgrind. This is very close to pin-pointing the bug.
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....
In the unwind code, which is used by exception handling.
JR> Looking at the code: ===== gcc/libgcc/unwind.inc
... here you're talking about gcc code.
libgcc.
JR> This is a giant red flag for unreliable code.
And I'm still confused about whose code is unreliable.
libgcc, because it does not check its input (the unwind tables) enough.
Perhaps gcc generated incorrect data into the tables,
but it is the fault of libgcc for not avoiding SIGSEGV.
SIGSEGV is *ALWAYS* the fault of the package that contains $pc
until that package proves otherwise.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
