public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
@ 2022-08-08 21:20 noloader at gmail dot com
  2022-08-08 21:30 ` [Bug middle-end/106568] " ktkachov at gcc dot gnu.org
                   ` (24 more replies)
  0 siblings, 25 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-08 21:20 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 106568
           Summary: -freorder-blocks-algorithm appears to causes a crash
                    in stable code, no way to disable it
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: noloader at gmail dot com
  Target Milestone: ---

Hi Everyone,

This is going to be a shitty bug report because we don't have a reproducer. We
believe we have it narrowed down to a particular optimization, however.

Debian Unstable, Fedora 37 and Gentoo 17.1 are reporting crashes in Crypto++
test program.[1,2] The distros use GCC 12. We found a particular function
crashes without explanation (and a garbage backtrace) at -O2 and -O3. The
function is Ok at -O0, -O1 and -Os.

(The code has been fairly stable for years. It is -Wall, -Wextra, Asan, UBsan
and Valgrind clean. We would be surprised to learn we have undetected UB. But
we don't rule it out).

According to GCC Optimization docs, the difference between -Os (no crash) and
-O2 (crash) are:[3]

    -falign-functions
    -falign-jumps
    -falign-labels
    -falign-loops
    -fprefetch-loop-arrays
    -freorder-blocks-algorithm=stc

We used CFLAGS and CXXFLAGS with -Os plus listed opts less
-freorder-blocks-algorithm=stc. The crash went away.

We are fairly certain the problem is with the -freorder-blocks-algorithm
optimization. The problem we are now having is, we don't know how to disable
it. The following fails to compile:

    -fno-reorder-blocks-algorithm
    -freorder-blocks-algorithm=none
    -freorder-blocks-algorithm=

So, we believe we have a bad option in -freorder-blocks-algorithm, but we can't
disable it for typical opt settings used by distros. The typical opt setting is
-O2 or -O3.

I sincerely apologize for not having a reproducer. I'm not sure where to begin
when it comes to -freorder-blocks-algorithm.

Please advise.

[1] https://github.com/weidai11/cryptopp/issues/1134
[2] https://github.com/weidai11/cryptopp/issues/1141
[3] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug middle-end/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
@ 2022-08-08 21:30 ` ktkachov at gcc dot gnu.org
  2022-08-08 21:34 ` pinskia at gcc dot gnu.org
                   ` (23 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2022-08-08 21:30 UTC (permalink / raw)
  To: gcc-bugs

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---

> We are fairly certain the problem is with the -freorder-blocks-algorithm
> optimization. The problem we are now having is, we don't know how to disable
> it. The following fails to compile:
> 
>     -fno-reorder-blocks-algorithm
>     -freorder-blocks-algorithm=none
>     -freorder-blocks-algorithm=
> 

You should be able to use -fno-reorder-blocks to disable it.
Alternatively, if you use -freorder-blocks-algorithm= you can only pass it the
"simple" or "stc" options as per the documentation. This will pick one of the
two available algorithms.

That said, one major change that happened in GCC 12.1 was enabling
auto-vectorisation by default at -O2. See
https://gcc.gnu.org/gcc-12/changes.html
The vectorisation at -O2 uses less aggressive heuristics than at -O3 so could
trigger different behaviour than -O3 or lower options (where it doesn't
vectorise at all). May be worth investigating.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug middle-end/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
  2022-08-08 21:30 ` [Bug middle-end/106568] " ktkachov at gcc dot gnu.org
@ 2022-08-08 21:34 ` pinskia at gcc dot gnu.org
  2022-08-08 21:36 ` [Bug rtl-optimization/106568] " pinskia at gcc dot gnu.org
                   ` (22 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 21:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I really doubt reorder-blocks would cause any issues unless there is some
other undefined code in there. An example might be even aliasing violations
(where the is no undefined sanitizer yet).

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
  2022-08-08 21:30 ` [Bug middle-end/106568] " ktkachov at gcc dot gnu.org
  2022-08-08 21:34 ` pinskia at gcc dot gnu.org
@ 2022-08-08 21:36 ` pinskia at gcc dot gnu.org
  2022-08-08 21:40 ` pinskia at gcc dot gnu.org
                   ` (21 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 21:36 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization
           Keywords|                            |EH

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Though there might be an EH issue but there has not been an EH issue for a long
time .

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (2 preceding siblings ...)
  2022-08-08 21:36 ` [Bug rtl-optimization/106568] " pinskia at gcc dot gnu.org
@ 2022-08-08 21:40 ` pinskia at gcc dot gnu.org
  2022-08-08 21:52 ` noloader at gmail dot com
                   ` (20 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 21:40 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If there is a throw which is not being caught (correctly).
In gdb you can do:
catch throw

And then find where the throw was that is causing the issue (as this is an
_Unwind_Resume case).

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (3 preceding siblings ...)
  2022-08-08 21:40 ` pinskia at gcc dot gnu.org
@ 2022-08-08 21:52 ` noloader at gmail dot com
  2022-08-08 22:00 ` pinskia at gcc dot gnu.org
                   ` (19 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-08 21:52 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> Though there might be an EH issue but there has not been an EH issue for a
> long time .

This is an interesting observation.

The stack trace shows frame #0 is in pthread_kill_thread (or similar). But up
in our program, around frame #4 or #5, gdb is identifying the line with a catch
(CryptoPP::Exception& ). CryptoPP::Exception is the library's base class
exception, so it should catch everything the library throws.

This is the line gdb faults
(https://github.com/weidai11/cryptopp/blob/master/test.cpp#L442) :

    catch(const Exception &e)  // 442
    {
        std::cout << "\nException caught: " << e.what() << std::endl;
        return -1;
    }

which makes no sense to me.

And the program does not take the exception path. Instead it segfaults.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (4 preceding siblings ...)
  2022-08-08 21:52 ` noloader at gmail dot com
@ 2022-08-08 22:00 ` pinskia at gcc dot gnu.org
  2022-08-08 22:18 ` noloader at gmail dot com
                   ` (18 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 22:00 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>And the program does not take the exception path. Instead it segfaults.

If I read the backtrace correctly, it is trying to resume an unwind because it
didn't find a catch that would hit in main but the following code hits the
assert while unwinding:
  /* Choose between continuing to process _Unwind_RaiseException
     or _Unwind_ForcedUnwind.  */
  if (exc->private_1 == 0)
    code = _Unwind_RaiseException_Phase2 (exc, &cur_context, &frames);
  else
    code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);

  gcc_assert (code == _URC_INSTALL_CONTEXT);

And then abort calls raise which then segfaults.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (5 preceding siblings ...)
  2022-08-08 22:00 ` pinskia at gcc dot gnu.org
@ 2022-08-08 22:18 ` noloader at gmail dot com
  2022-08-08 22:25 ` pinskia at gcc dot gnu.org
                   ` (17 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-08 22:18 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #6)
> >And the program does not take the exception path. Instead it segfaults.
> 
> If I read the backtrace correctly, it is trying to resume an unwind because
> it didn't find a catch that would hit in main but the following code hits
> the assert while unwinding:
>   /* Choose between continuing to process _Unwind_RaiseException
>      or _Unwind_ForcedUnwind.  */
>   if (exc->private_1 == 0)
>     code = _Unwind_RaiseException_Phase2 (exc, &cur_context, &frames);
>   else
>     code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
> 
>   gcc_assert (code == _URC_INSTALL_CONTEXT);
> 
> And then abort calls raise which then segfaults.

Thanks again Andrew.

We have exception handlers for both CryptoPP::Exception& and std::exception&
starting for main() around
https://github.com/weidai11/cryptopp/blob/master/test.cpp#L442 . However, we
should not hit either of them. When they trigger there's a problem that needs
to be fixed.

The code in question tests for good and bad digital signatures. It should catch
a SignatureVerificationFailed exception on occasion and this is expected. But
it should catch closer to the the actual test (and not in main or
Test::scoped_main). Not to mention 'catch throw' is not catching anything under
gdb.

Is there something we should be doing differently?

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (6 preceding siblings ...)
  2022-08-08 22:18 ` noloader at gmail dot com
@ 2022-08-08 22:25 ` pinskia at gcc dot gnu.org
  2022-08-08 23:05 ` noloader at gmail dot com
                   ` (16 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 22:25 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #7)
> 
> Thanks again Andrew.
> 
> We have exception handlers for both CryptoPP::Exception& and std::exception&
> starting for main() around
> https://github.com/weidai11/cryptopp/blob/master/test.cpp#L442 . However, we
> should not hit either of them. When they trigger there's a problem that
> needs to be fixed.
> 
> The code in question tests for good and bad digital signatures. It should
> catch a SignatureVerificationFailed exception on occasion and this is
> expected. But it should catch closer to the the actual test (and not in main
> or Test::scoped_main). Not to mention 'catch throw' is not catching anything
> under gdb.
> 
> Is there something we should be doing differently?



Try putting a breakpoint on the following functions:
_Unwind_RaiseException
_Unwind_ForcedUnwind
_Unwind_Resume
_Unwind_Resume_or_Rethrow
_Unwind_DeleteException

besides _Unwind_Resume which will be hit at least once since the backtrace
shows it was hit, what is the backtrace for these breapoints?

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (7 preceding siblings ...)
  2022-08-08 22:25 ` pinskia at gcc dot gnu.org
@ 2022-08-08 23:05 ` noloader at gmail dot com
  2022-08-08 23:20 ` noloader at gmail dot com
                   ` (15 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-08 23:05 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jeffrey Walton from comment #7)
> 
> Try putting a breakpoint on the following functions:
> _Unwind_RaiseException
> _Unwind_ForcedUnwind
> _Unwind_Resume
> _Unwind_Resume_or_Rethrow
> _Unwind_DeleteException
> 
> besides _Unwind_Resume which will be hit at least once since the backtrace
> shows it was hit, what is the backtrace for these breapoints?

The only breakpoint that hits is _Unwind_Resume.

The backtrace for _Unwind_Resume is:

ECGDSA validation suite running...

Breakpoint 3, _Unwind_Resume (exc=exc@entry=0x978460) at
../../../libgcc/unwind.inc:231
231     {
(gdb) n
236       uw_init_context (&this_context);
(gdb)
237       cur_context = this_context;

(gdb) p this_context
$2 = {reg = {0x7fffffffce88, 0x7fffffffce90, 0x0, 0x7fffffffce98, 0x0, 0x0,
    0x7fffffffcec0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fffffffcea0, 0x7fffffffcea8,
    0x7fffffffceb0, 0x7fffffffceb8, 0x7fffffffcec8, 0x0},
  cfa = 0x7fffffffced0,
  ra = 0x433e56 <CryptoPP::Test::ValidateECGDSAStandard()-1100010>,
  lsda = 0x0, bases = {tbase = 0x0, dbase = 0x0,
    func = 0x7ffff7c965a0 <_Unwind_Resume>}, flags = 4611686018427387904,
  version = 0, args_size = 0, by_value = '\000' <repeats 17 times>}

4611686018427387904 is 4000000000000000.

(gdb) bt full
#0  _Unwind_Resume (exc=exc@entry=0x978460) at ../../../libgcc/unwind.inc:246
        this_context = {reg = {0x7fffffffce88, 0x7fffffffce90, 0x0,
            0x7fffffffce98, 0x0, 0x0, 0x7fffffffcec0, 0x0, 0x0, 0x0, 0x0, 0x0,
            0x7fffffffcea0, 0x7fffffffcea8, 0x7fffffffceb0, 0x7fffffffceb8,
            0x7fffffffcec8, 0x0}, cfa = 0x7fffffffced0,
          ra = 0x433e56 <CryptoPP::Test::ValidateECGDSAStandard()-1100010>,
          lsda = 0x0, bases = {tbase = 0x0, dbase = 0x0,
            func = 0x7ffff7c965a0 <_Unwind_Resume>},
          flags = 4611686018427387904, version = 0, args_size = 0,
          by_value = '\000' <repeats 17 times>}
        cur_context = {reg = {0x7fffffffce88, 0x7fffffffce90, 0x0,
            0x7fffffffd608, 0x0, 0x0, 0x7fffffffd610, 0x0, 0x0, 0x0, 0x0, 0x0,
            0x7fffffffd618, 0x7fffffffd620, 0x7fffffffd628, 0x7fffffffd630,
            0x7fffffffd638, 0x0}, cfa = 0x7fffffffd640,
    ra = 0x45af7c <CryptoPP::Test::scoped_main(int, char**)+6028>, lsda =
0x8929a8,
          bases = {tbase = 0x0, dbase = 0x0,
            func = 0x4597f0 <CryptoPP::Test::scoped_main(int, char**)>},
          flags = 4611686018427387904, version = 0, args_size = 0,
          by_value = '\000' <repeats 17 times>}
        code = _URC_INSTALL_CONTEXT
        frames = 4
#1  0x0000000000433e56 in std::vector<unsigned int, std::allocator<unsigned
int> >::~vector (this=<optimized out>, __in_chrg=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--c
    at /usr/include/c++/12/bits/stl_vector.h:733
No locals.
#2  CryptoPP::OID::~OID (this=<optimized out>, __in_chrg=<optimized out>) at
/home/jwalton/cryptopp/asn.h:267
No locals.
#3  CryptoPP::Test::ValidateECGDSAStandard () at validat9.cpp:370
        e = <optimized out>
        msg = <optimized out>
        len = <optimized out>
        oid = {_vptr.OID = 0x8c4590 <vtable for CryptoPP::OID+16>, m_values =
std::vector of length 10, capacity 10 = {2421, 0, 2890278822, 2134504544, 3, 2,
8, 1, 1, 3}}
        r = <optimized out>
        maxLength = <optimized out>
        params =
{<CryptoPP::DL_GroupParametersImpl<CryptoPP::EcPrecomputation<CryptoPP::ECP>,
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>,
CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint> >> =
{<CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint>> =
{<CryptoPP::CryptoParameters> = {<CryptoPP::GeneratableCryptoMaterial> =
{<CryptoPP::CryptoMaterial> = {<CryptoPP::NameValuePairs> =
{_vptr.NameValuePairs = 0x926060 <vtable for
CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>+112>}, <No data fields>}, <No
data fields>}, <No data fields>}, m_validationLevel = 0}, m_groupPrecomputation
= {<CryptoPP::DL_GroupPrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_GroupPrecomputation = 0x8c5850 <vtable for
CryptoPP::EcPrecomputation<CryptoPP::ECP>+16>}, m_ec =
{<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x977750}, <No data fields>},
m_ecOriginal = {<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x977d00}, <No
data fields>}}, m_gpc =
{<CryptoPP::DL_FixedBasePrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_FixedBasePrecomputation = 0x925a60 <vtable for
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>+16>}, m_base =
{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 4, m_ptr = 0x977ca0}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x977cd0}, sign = CryptoPP::Integer::POSITIVE}, identity =
false}, m_windowSize = 0, m_exponentBase = {<CryptoPP::InitializeInteger> =
{<No data fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8
<vtable for CryptoPP::Integer+16>}, reg = {m_alloc =
{<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x9752b0}, sign =
CryptoPP::Integer::POSITIVE}, m_bases = std::vector of length 1, capacity 1 =
{{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 4, m_ptr = 0x977f60}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x977f90}, sign = CryptoPP::Integer::POSITIVE}, identity =
false}}}}, m_oid = {_vptr.OID = 0x8c4590 <vtable for CryptoPP::OID+16>,
m_values = std::vector of length 10, capacity 10 = {1, 3, 36, 3, 3, 2, 8, 1, 1,
3}}, m_n = {<CryptoPP::InitializeInteger> = {<No data fields>},
<CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x978070}, sign = CryptoPP::Integer::POSITIVE}, m_k =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x975840}, sign =
CryptoPP::Integer::POSITIVE}, m_compress = false, m_encodeAsOID = true}
        signer =
{<CryptoPP::DL_SignerImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> >> =
{<CryptoPP::DL_ObjectImpl<CryptoPP::DL_SignerBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PrivateKey_ECGDSA<CryptoPP::ECP> >> =
{<CryptoPP::DL_ObjectImplBase<CryptoPP::DL_SignerBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PrivateKey_ECGDSA<CryptoPP::ECP> >> =
{<CryptoPP::AlgorithmImpl<CryptoPP::DL_SignerBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int> >> =
{<CryptoPP::DL_SignerBase<CryptoPP::ECPPoint>> =
{<CryptoPP::DL_SignatureSchemeBase<CryptoPP::PK_Signer,
CryptoPP::DL_PrivateKey<CryptoPP::ECPPoint> >> = {<CryptoPP::PK_Signer> =
{<CryptoPP::PK_SignatureScheme> = {_vptr.PK_SignatureScheme = 0x8c7ea0 <vtable
for
CryptoPP::PK_FinalTemplate<CryptoPP::DL_SignerImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> > >+16>},
<CryptoPP::PrivateKeyAlgorithm> = {<CryptoPP::AsymmetricAlgorithm> =
{<CryptoPP::Algorithm> = {<CryptoPP::Clonable> = {_vptr.Clonable = 0x8c7f78
<vtable for
CryptoPP::PK_FinalTemplate<CryptoPP::DL_SignerImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> > >+232>}, <No
data fields>}, <No data fields>}, <No data fields>}, <No data fields>},
<CryptoPP::DL_Base<CryptoPP::DL_PrivateKey<CryptoPP::ECPPoint> >> =
{_vptr.DL_Base = 0x8c7fd0 <vtable for
CryptoPP::PK_FinalTemplate<CryptoPP::DL_SignerImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> > >+320>}, <No
data fields>}, <No data fields>}, <No data fields>}, m_key =
{<CryptoPP::DL_PrivateKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP> >>
= {<CryptoPP::DL_PrivateKey<CryptoPP::ECPPoint>> =
{<CryptoPP::DL_Key<CryptoPP::ECPPoint>> = {_vptr.DL_Key = 0x92c650 <vtable for
CryptoPP::DL_PrivateKey_ECGDSA<CryptoPP::ECP>+24>}, <No data fields>},
<CryptoPP::DL_KeyImpl<CryptoPP::PKCS8PrivateKey,
CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>, CryptoPP::OID>> =
{<CryptoPP::PKCS8PrivateKey> =
{<CryptoPP::ASN1CryptoMaterial<CryptoPP::PrivateKey>> = {<CryptoPP::ASN1Object>
= {_vptr.ASN1Object = 0x92c6f0 <vtable for
CryptoPP::DL_PrivateKey_ECGDSA<CryptoPP::ECP>+184>}, <CryptoPP::PrivateKey> =
{<CryptoPP::GeneratableCryptoMaterial> = {<CryptoPP::CryptoMaterial> =
{<CryptoPP::NameValuePairs> = {_vptr.NameValuePairs = 0x92c7d0 <vtable for
CryptoPP::DL_PrivateKey_ECGDSA<CryptoPP::ECP>+408>}, <No data fields>}, <No
data fields>}, <No data fields>}, <No data fields>}, m_optionalAttributes =
{<CryptoPP::Bufferless<CryptoPP::BufferedTransformation>> =
{<CryptoPP::BufferedTransformation> = {<CryptoPP::Algorithm> =
{<CryptoPP::Clonable> = {_vptr.Clonable = 0x93f940 <vtable for
CryptoPP::ByteQueue+16>}, <No data fields>}, <CryptoPP::Waitable> =
{_vptr.Waitable = 0x93fad0 <vtable for CryptoPP::ByteQueue+416>}, m_buf =
"\200\321\377\377\377\177\000"}, <No data fields>}, m_head = 0x975780, m_tail =
0x975780, m_lazyString = 0x0, m_lazyLength = 0, m_nodeSize = 256,
m_lazyStringModifiable = false, m_autoNodeSize = true}}, m_groupParameters =
{<CryptoPP::DL_GroupParametersImpl<CryptoPP::EcPrecomputation<CryptoPP::ECP>,
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>,
CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint> >> =
{<CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint>> =
{<CryptoPP::CryptoParameters> = {<CryptoPP::GeneratableCryptoMaterial> =
{<CryptoPP::CryptoMaterial> = {<CryptoPP::NameValuePairs> =
{_vptr.NameValuePairs = 0x926060 <vtable for
CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>+112>}, <No data fields>}, <No
data fields>}, <No data fields>}, m_validationLevel = 0}, m_groupPrecomputation
= {<CryptoPP::DL_GroupPrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_GroupPrecomputation = 0x8c5850 <vtable for
CryptoPP::EcPrecomputation<CryptoPP::ECP>+16>}, m_ec =
{<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x9775b0}, <No data fields>},
m_ecOriginal = {<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x977ad0}, <No
data fields>}}, m_gpc =
{<CryptoPP::DL_FixedBasePrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_FixedBasePrecomputation = 0x925a60 <vtable for
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>+16>}, m_base =
{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 4, m_ptr = 0x978230}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x978260}, sign = CryptoPP::Integer::POSITIVE}, identity =
false}, m_windowSize = 0, m_exponentBase = {<CryptoPP::InitializeInteger> =
{<No data fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8
<vtable for CryptoPP::Integer+16>}, reg = {m_alloc =
{<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x9752d0}, sign =
CryptoPP::Integer::POSITIVE}, m_bases = std::vector of length 1, capacity 1 =
{{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 4, m_ptr = 0x978310}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x978340}, sign = CryptoPP::Integer::POSITIVE}, identity =
false}}}}, m_oid = {_vptr.OID = 0x8c4590 <vtable for CryptoPP::OID+16>,
m_values = std::vector of length 10, capacity 10 = {1, 3, 36, 3, 3, 2, 8, 1, 1,
3}}, m_n = {<CryptoPP::InitializeInteger> = {<No data fields>},
<CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x9783a0}, sign = CryptoPP::Integer::POSITIVE}, m_k =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x975d30}, sign =
CryptoPP::Integer::POSITIVE}, m_compress = false, m_encodeAsOID = true}}, m_x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 4, m_ptr = 0x9783d0}, sign =
CryptoPP::Integer::POSITIVE}}, <No data fields>}}, <No data fields>}, <No data
fields>}, <No data fields>}
        verifier =
{<CryptoPP::DL_VerifierImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> >> =
{<CryptoPP::DL_ObjectImpl<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP> >> =
{<CryptoPP::DL_ObjectImplBase<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP> >> =
{<CryptoPP::AlgorithmImpl<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int> >> =
{<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>> =
{<CryptoPP::DL_SignatureSchemeBase<CryptoPP::PK_Verifier,
CryptoPP::DL_PublicKey<CryptoPP::ECPPoint> >> = {<CryptoPP::PK_Verifier> =
{<CryptoPP::PK_SignatureScheme> = {_vptr.PK_SignatureScheme = 0x8c8000 <vtable
for CryptoPP::DL_ObjectImplBase<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP> >+16>},
<CryptoPP::PublicKeyAlgorithm> = {<CryptoPP::AsymmetricAlgorithm> =
{<CryptoPP::Algorithm> = {<CryptoPP::Clonable> = {_vptr.Clonable = 0x8c80e8
<vtable for
CryptoPP::DL_ObjectImplBase<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP> >+248>}, <No data fields>}, <No
data fields>}, <No data fields>}, <No data fields>},
<CryptoPP::DL_Base<CryptoPP::DL_PublicKey<CryptoPP::ECPPoint> >> =
{_vptr.DL_Base = 0x8c8140 <vtable for
CryptoPP::DL_ObjectImplBase<CryptoPP::DL_VerifierBase<CryptoPP::ECPPoint>,
CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1>,
CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP> >+336>}, <No data fields>}, <No
data fields>}, <No data fields>}, m_key =
{<CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP> >>
= {<CryptoPP::DL_PublicKey<CryptoPP::ECPPoint>> =
{<CryptoPP::DL_Key<CryptoPP::ECPPoint>> = {_vptr.DL_Key = 0x928c18
<construction vtable for
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>-in-CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP>+24>}, <No data fields>},
<CryptoPP::DL_KeyImpl<CryptoPP::X509PublicKey,
CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>, CryptoPP::OID>> =
{<CryptoPP::X509PublicKey> =
{<CryptoPP::ASN1CryptoMaterial<CryptoPP::PublicKey>> = {<CryptoPP::ASN1Object>
= {_vptr.ASN1Object = 0x928cb8 <construction vtable for
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>-in-CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP>+184>}, <CryptoPP::PublicKey>
= {<CryptoPP::CryptoMaterial> = {<CryptoPP::NameValuePairs> =
{_vptr.NameValuePairs = 0x928d88 <construction vtable for
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>-in-CryptoPP::DL_PublicKey_ECGDSA<CryptoPP::ECP>+392>}, <No data fields>}, <No
data fields>}, <No data fields>}, <No data fields>}, m_groupParameters =
{<CryptoPP::DL_GroupParametersImpl<CryptoPP::EcPrecomputation<CryptoPP::ECP>,
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>,
CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint> >> =
{<CryptoPP::DL_GroupParameters<CryptoPP::ECPPoint>> =
{<CryptoPP::CryptoParameters> = {<CryptoPP::GeneratableCryptoMaterial> =
{<CryptoPP::CryptoMaterial> = {<CryptoPP::NameValuePairs> =
{_vptr.NameValuePairs = 0x926060 <vtable for
CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>+112>}, <No data fields>}, <No
data fields>}, <No data fields>}, m_validationLevel = 0}, m_groupPrecomputation
= {<CryptoPP::DL_GroupPrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_GroupPrecomputation = 0x8c5850 <vtable for
CryptoPP::EcPrecomputation<CryptoPP::ECP>+16>}, m_ec =
{<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x0}, <No data fields>},
m_ecOriginal = {<CryptoPP::member_ptr<CryptoPP::ECP>> = {m_p = 0x0}, <No data
fields>}}, m_gpc = {<CryptoPP::DL_FixedBasePrecomputation<CryptoPP::ECPPoint>>
= {_vptr.DL_FixedBasePrecomputation = 0x925a60 <vtable for
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>+16>}, m_base =
{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x975d70}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 2, m_ptr = 0x9739d0}, sign = CryptoPP::Integer::POSITIVE}, identity =
true}, m_windowSize = 0, m_exponentBase = {<CryptoPP::InitializeInteger> = {<No
data fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable
for CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 2, m_ptr = 0x9752f0}, sign = CryptoPP::Integer::POSITIVE}, m_bases =
std::vector of length 0, capacity 0}}, m_oid = {_vptr.OID = 0x8c4590 <vtable
for CryptoPP::OID+16>, m_values = std::vector of length 0, capacity 0}, m_n =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x975db0}, sign =
CryptoPP::Integer::POSITIVE}, m_k = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 2, m_ptr = 0x978400}, sign = CryptoPP::Integer::POSITIVE}, m_compress
= false, m_encodeAsOID = true}}, m_ypc =
{<CryptoPP::DL_FixedBasePrecomputation<CryptoPP::ECPPoint>> =
{_vptr.DL_FixedBasePrecomputation = 0x925a60 <vtable for
CryptoPP::DL_FixedBasePrecomputationImpl<CryptoPP::ECPPoint>+16>}, m_base =
{_vptr.ECPPoint = 0x8c5810 <vtable for CryptoPP::ECPPoint+16>, x =
{<CryptoPP::InitializeInteger> = {<No data fields>}, <CryptoPP::ASN1Object> =
{_vptr.ASN1Object = 0x9170f8 <vtable for CryptoPP::Integer+16>}, reg = {m_alloc
= {<CryptoPP::AllocatorBase<unsigned long>> = {<No data fields>}, <No data
fields>}, m_mark = 2305843009213693951, m_size = 2, m_ptr = 0x978420}, sign =
CryptoPP::Integer::POSITIVE}, y = {<CryptoPP::InitializeInteger> = {<No data
fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 2, m_ptr = 0x978440}, sign = CryptoPP::Integer::POSITIVE}, identity =
true}, m_windowSize = 0, m_exponentBase = {<CryptoPP::InitializeInteger> = {<No
data fields>}, <CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable
for CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 2, m_ptr = 0x978460}, sign = CryptoPP::Integer::POSITIVE}, m_bases =
std::vector of length 0, capacity 0}}, <No data fields>}}, <No data fields>},
<No data fields>}, <No data fields>}
        k = <optimized out>
        s = <optimized out>
        sExp = <optimized out>
        x = {<CryptoPP::InitializeInteger> = {<No data fields>},
<CryptoPP::ASN1Object> = {_vptr.ASN1Object = 0x9170f8 <vtable for
CryptoPP::Integer+16>}, reg = {m_alloc = {<CryptoPP::AllocatorBase<unsigned
long>> = {<No data fields>}, <No data fields>}, m_mark = 2305843009213693951,
m_size = 4, m_ptr = 0x975c80}, sign = CryptoPP::Integer::POSITIVE}
        rExp = <optimized out>
        signature = <optimized out>
        fail = <optimized out>
        pass = true
        oid = <optimized out>
        params = <optimized out>
        x = <optimized out>
        signer = <optimized out>
        verifier = <optimized out>
        e = <optimized out>
        k = <optimized out>
        r = <optimized out>
        s = <optimized out>
        rExp = <optimized out>
        sExp = <optimized out>
        msg = <optimized out>
        len = <optimized out>
        maxLength = <optimized out>
        signature = <optimized out>
        oid = <optimized out>
        params = <optimized out>
        x = <optimized out>
        signer = <optimized out>
        verifier = <optimized out>
        e = <optimized out>
        k = <optimized out>
        r = <optimized out>
        s = <optimized out>
        rExp = <optimized out>
        sExp = <optimized out>
        msg = <optimized out>
        len = <optimized out>
        maxLength = <optimized out>
        signature = <optimized out>
        oid = <optimized out>
        params = <optimized out>
        x = <optimized out>
        signer = <optimized out>
        verifier = <optimized out>
        e = <optimized out>
        k = <optimized out>
        r = <optimized out>
        s = <optimized out>
        rExp = <optimized out>
        sExp = <optimized out>
        msg = <optimized out>
        len = <optimized out>
        maxLength = <optimized out>
        signature = <optimized out>
        oid = <optimized out>
        params = <optimized out>
        x = <optimized out>
        signer = <optimized out>
        verifier = <optimized out>
        e = <optimized out>
        k = <optimized out>
        r = <optimized out>
        s = <optimized out>
        rExp = <optimized out>
        sExp = <optimized out>
        msg = <optimized out>
        len = <optimized out>
        maxLength = <optimized out>
        signature = <optimized out>
#4  0x00000000005409c4 in CryptoPP::Test::ValidateECGDSA (thorough=<optimized
out>) at validat9.cpp:663
No locals.
#5  0x0000000000452477 in CryptoPP::Test::Validate (alg=<optimized out>,
thorough=<optimized out>) at test.cpp:995
        result = <optimized out>
#6  0x000000000045aca3 in CryptoPP::Test::scoped_main (argc=3,
argv=0x7fffffffe268) at test.cpp:401
        cipher = <optimized out>
        command = "vv"
        executableName = ""
        macFilename = ""
#7  0x00007ffff7aca550 in __libc_start_call_main (main=main@entry=0x4510b0
<main(int, char**)>, argc=argc@entry=3, argv=argv@entry=0x7fffffffe268) at
../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737488347752,
1293472827491661223, 0, 140737488347784, 9153400, 140737354125312,
-1293472826606176857, -1293454519445965401}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x7fffffffe268, 0x3}, data = {prev = 0x0, cleanup = 0x0,
canceltype = -7576}}}
        not_first_call = <optimized out>
#8  0x00007ffff7aca609 in __libc_start_main_impl (main=0x4510b0 <main(int,
char**)>, argc=3, argv=0x7fffffffe268, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe258) at
../csu/libc-start.c:381
No locals.
#9  0x00000000004518c5 in _start ()
No symbol table info available.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (8 preceding siblings ...)
  2022-08-08 23:05 ` noloader at gmail dot com
@ 2022-08-08 23:20 ` noloader at gmail dot com
  2022-08-08 23:22 ` pinskia at gcc dot gnu.org
                   ` (14 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-08 23:20 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from Jeffrey Walton <noloader at gmail dot com> ---
I'm not sure if this is helpful, but Valgrind is showing invalid reads in the
unwind gear:

$ valgrind ./cryptest.exe vv 51
==27339== Memcheck, a memory error detector
==27339== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==27339== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==27339== Command: ./cryptest.exe vv 51
==27339==
Using seed: 1660000617

ECGDSA validation suite running...

==27339== Invalid read of size 8
==27339==    at 0x4B8D673: _Unwind_Resume (unwind.inc:241)
==27339==    by 0x433E55: ~vector (stl_vector.h:733)
==27339==    by 0x433E55: ~OID (asn.h:267)
==27339==    by 0x433E55: CryptoPP::Test::ValidateECGDSAStandard() [clone
.cold] (validat9.cpp:370)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==  Address 0x4db3c00 is 0 bytes after a block of size 16 alloc'd
==27339==    at 0x4847A83: memalign (vg_replace_malloc.c:1517)
==27339==    by 0x5E4630: CryptoPP::AlignedAllocate(unsigned long)
(allocate.cpp:49)
==27339==    by 0x5D723C: allocate (secblock.h:215)
==27339==    by 0x5D723C: SecBlock (secblock.h:767)
==27339==    by 0x5D723C: CryptoPP::Integer::Integer() (integer.cpp:2967)
==27339==    by 0x49AB74: DL_FixedBasePrecomputationImpl (eprecomp.h:133)
==27339==    by 0x49AB74:
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>::DL_PublicKeyImpl() (pubkey.h:1335)
==27339==    by 0x540971: DL_PublicKey_ECGDSA (eccrypto.h:500)
==27339==    by 0x540971: DL_ObjectImplBase (pubkey.h:1956)
==27339==    by 0x540971: DL_ObjectImpl (pubkey.h:1996)
==27339==    by 0x540971: DL_VerifierImpl (pubkey.h:2035)
==27339==    by 0x540971: PK_FinalTemplate (pubkey.h:2209)
==27339==    by 0x540971: CryptoPP::Test::ValidateECGDSAStandard()
(validat9.cpp:340)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==
==27339== Invalid read of size 8
==27339==    at 0x4B8CD14: _Unwind_RaiseException_Phase2 (unwind.inc:54)
==27339==    by 0x4B8D6CC: _Unwind_Resume (unwind.inc:242)
==27339==    by 0x433E55: ~vector (stl_vector.h:733)
==27339==    by 0x433E55: ~OID (asn.h:267)
==27339==    by 0x433E55: CryptoPP::Test::ValidateECGDSAStandard() [clone
.cold] (validat9.cpp:370)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==  Address 0x4db3c08 is 8 bytes after a block of size 16 alloc'd
==27339==    at 0x4847A83: memalign (vg_replace_malloc.c:1517)
==27339==    by 0x5E4630: CryptoPP::AlignedAllocate(unsigned long)
(allocate.cpp:49)
==27339==    by 0x5D723C: allocate (secblock.h:215)
==27339==    by 0x5D723C: SecBlock (secblock.h:767)
==27339==    by 0x5D723C: CryptoPP::Integer::Integer() (integer.cpp:2967)
==27339==    by 0x49AB74: DL_FixedBasePrecomputationImpl (eprecomp.h:133)
==27339==    by 0x49AB74:
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>::DL_PublicKeyImpl() (pubkey.h:1335)
==27339==    by 0x540971: DL_PublicKey_ECGDSA (eccrypto.h:500)
==27339==    by 0x540971: DL_ObjectImplBase (pubkey.h:1956)
==27339==    by 0x540971: DL_ObjectImpl (pubkey.h:1996)
==27339==    by 0x540971: DL_VerifierImpl (pubkey.h:2035)
==27339==    by 0x540971: PK_FinalTemplate (pubkey.h:2209)
==27339==    by 0x540971: CryptoPP::Test::ValidateECGDSAStandard()
(validat9.cpp:340)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==
==27339== Invalid read of size 8
==27339==    at 0x4B8D673: _Unwind_Resume (unwind.inc:241)
==27339==    by 0x425BAB: CryptoPP::Test::scoped_main(int, char**) [clone
.cold] (test.cpp:442)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==  Address 0x4db3c00 is 0 bytes after a block of size 16 alloc'd
==27339==    at 0x4847A83: memalign (vg_replace_malloc.c:1517)
==27339==    by 0x5E4630: CryptoPP::AlignedAllocate(unsigned long)
(allocate.cpp:49)
==27339==    by 0x5D723C: allocate (secblock.h:215)
==27339==    by 0x5D723C: SecBlock (secblock.h:767)
==27339==    by 0x5D723C: CryptoPP::Integer::Integer() (integer.cpp:2967)
==27339==    by 0x49AB74: DL_FixedBasePrecomputationImpl (eprecomp.h:133)
==27339==    by 0x49AB74:
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>::DL_PublicKeyImpl() (pubkey.h:1335)
==27339==    by 0x540971: DL_PublicKey_ECGDSA (eccrypto.h:500)
==27339==    by 0x540971: DL_ObjectImplBase (pubkey.h:1956)
==27339==    by 0x540971: DL_ObjectImpl (pubkey.h:1996)
==27339==    by 0x540971: DL_VerifierImpl (pubkey.h:2035)
==27339==    by 0x540971: PK_FinalTemplate (pubkey.h:2209)
==27339==    by 0x540971: CryptoPP::Test::ValidateECGDSAStandard()
(validat9.cpp:340)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==
==27339== Invalid read of size 8
==27339==    at 0x4B8CD14: _Unwind_RaiseException_Phase2 (unwind.inc:54)
==27339==    by 0x4B8D6CC: _Unwind_Resume (unwind.inc:242)
==27339==    by 0x425BAB: CryptoPP::Test::scoped_main(int, char**) [clone
.cold] (test.cpp:442)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==  Address 0x4db3c08 is 8 bytes after a block of size 16 alloc'd
==27339==    at 0x4847A83: memalign (vg_replace_malloc.c:1517)
==27339==    by 0x5E4630: CryptoPP::AlignedAllocate(unsigned long)
(allocate.cpp:49)
==27339==    by 0x5D723C: allocate (secblock.h:215)
==27339==    by 0x5D723C: SecBlock (secblock.h:767)
==27339==    by 0x5D723C: CryptoPP::Integer::Integer() (integer.cpp:2967)
==27339==    by 0x49AB74: DL_FixedBasePrecomputationImpl (eprecomp.h:133)
==27339==    by 0x49AB74:
CryptoPP::DL_PublicKeyImpl<CryptoPP::DL_GroupParameters_EC<CryptoPP::ECP>
>::DL_PublicKeyImpl() (pubkey.h:1335)
==27339==    by 0x540971: DL_PublicKey_ECGDSA (eccrypto.h:500)
==27339==    by 0x540971: DL_ObjectImplBase (pubkey.h:1956)
==27339==    by 0x540971: DL_ObjectImpl (pubkey.h:1996)
==27339==    by 0x540971: DL_VerifierImpl (pubkey.h:2035)
==27339==    by 0x540971: PK_FinalTemplate (pubkey.h:2209)
==27339==    by 0x540971: CryptoPP::Test::ValidateECGDSAStandard()
(validat9.cpp:340)
==27339==    by 0x5409C3: CryptoPP::Test::ValidateECGDSA(bool)
(validat9.cpp:663)
==27339==    by 0x452476: CryptoPP::Test::Validate(int, bool) (test.cpp:995)
==27339==    by 0x45ACA2: CryptoPP::Test::scoped_main(int, char**)
(test.cpp:401)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==
==27339==
==27339== Process terminating with default action of signal 6 (SIGABRT):
dumping core
==27339==    at 0x4C1ED0C: __pthread_kill_implementation (pthread_kill.c:44)
==27339==    by 0x4BCEAE5: raise (raise.c:26)
==27339==    by 0x4BB87FB: abort (abort.c:79)
==27339==    by 0x4B796D9: _Unwind_Resume.cold (unwind.inc:246)
==27339==    by 0x425BAB: CryptoPP::Test::scoped_main(int, char**) [clone
.cold] (test.cpp:442)
==27339==    by 0x4BB954F: (below main) (libc_start_call_main.h:58)
==27339==
==27339== HEAP SUMMARY:
==27339==     in use at exit: 113,286 bytes in 801 blocks
==27339==   total heap usage: 1,723 allocs, 922 frees, 145,415 bytes allocated
==27339==
==27339== LEAK SUMMARY:
==27339==    definitely lost: 1,720 bytes in 28 blocks
==27339==    indirectly lost: 2,304 bytes in 41 blocks
==27339==      possibly lost: 0 bytes in 0 blocks
==27339==    still reachable: 109,262 bytes in 732 blocks
==27339==         suppressed: 0 bytes in 0 blocks

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (9 preceding siblings ...)
  2022-08-08 23:20 ` noloader at gmail dot com
@ 2022-08-08 23:22 ` pinskia at gcc dot gnu.org
  2022-08-08 23:23 ` pinskia at gcc dot gnu.org
                   ` (13 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 23:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Jeffrey Walton from comment #7)
> > 
> > Try putting a breakpoint on the following functions:
> > _Unwind_RaiseException
> > _Unwind_ForcedUnwind
> > _Unwind_Resume
> > _Unwind_Resume_or_Rethrow
> > _Unwind_DeleteException
> > 
> > besides _Unwind_Resume which will be hit at least once since the backtrace
> > shows it was hit, what is the backtrace for these breapoints?
> 
> The only breakpoint that hits is _Unwind_Resume.
> 
> The backtrace for _Unwind_Resume is:

Well at least this narrows down which function is messing up.
The _Unwdind_Resume is at the end of the 1st inner scope of
ValidateECGDSAStandard.

This is definitely some kind of EH issue (I am saying GCC is miscompiling
either the try/finally for the deconstructor call of oid in
ValidateECGDSAStandard).

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (10 preceding siblings ...)
  2022-08-08 23:22 ` pinskia at gcc dot gnu.org
@ 2022-08-08 23:23 ` pinskia at gcc dot gnu.org
  2022-08-09  0:56 ` noloader at gmail dot com
                   ` (12 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-08 23:23 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you try -fno-reorder-blocks-and-partition adding to the options?
This would not be the first time this option caused issues with EH.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (11 preceding siblings ...)
  2022-08-08 23:23 ` pinskia at gcc dot gnu.org
@ 2022-08-09  0:56 ` noloader at gmail dot com
  2022-08-09  1:09 ` noloader at gmail dot com
                   ` (11 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  0:56 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #12)
> Can you try -fno-reorder-blocks-and-partition adding to the options?
> This would not be the first time this option caused issues with EH.

No joy with -fno-reorder-blocks-and-partition . We still saw the crash with
CXXFLAGS="-DNDEBUG -g2 -O3 -fno-reorder-blocks-and-partition".

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (12 preceding siblings ...)
  2022-08-09  0:56 ` noloader at gmail dot com
@ 2022-08-09  1:09 ` noloader at gmail dot com
  2022-08-09  1:35 ` noloader at gmail dot com
                   ` (10 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  1:09 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #14 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Jeffrey Walton from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Can you try -fno-reorder-blocks-and-partition adding to the options?
> > This would not be the first time this option caused issues with EH.
> 
> No joy with -fno-reorder-blocks-and-partition . We still saw the crash with
> CXXFLAGS="-DNDEBUG -g2 -O3 -fno-reorder-blocks-and-partition".

I did notice that using -fno-reorder-functions results in "terminate called
without an active exception". That's unusual because we have exception handlers
in place.

$ ./cryptest.exe vv 51
Using seed: 1660007252

ECGDSA validation suite running...

passed    brainpoolP192r1 using SHA-1
passed    signature key validation
passed    signature and verification
passed    checking invalid signature
passed    brainpoolP320r1 using SHA-224
passed    signature key validation
passed    signature and verification
passed    checking invalid signature
passed    brainpoolP320r1 using SHA-256
passed    signature key validation
passed    signature and verification
passed    checking invalid signature
passed    brainpoolP512r1 using SHA-384
passed    signature key validation
passed    signature and verification
passed    checking invalid signature
passed    brainpoolP512r1 using SHA-512
passed    signature key validation
passed    signature and verification
passed    checking invalid signature
terminate called without an active exception
Aborted (core dumped)

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (13 preceding siblings ...)
  2022-08-09  1:09 ` noloader at gmail dot com
@ 2022-08-09  1:35 ` noloader at gmail dot com
  2022-08-09  1:45 ` pinskia at gcc dot gnu.org
                   ` (9 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  1:35 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #15 from Jeffrey Walton <noloader at gmail dot com> ---
It looks like -fno-strict-aliasing cleared the crash. This is bad because I
thought we did not violate aliasing rules.

Let me try to find it.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (14 preceding siblings ...)
  2022-08-09  1:35 ` noloader at gmail dot com
@ 2022-08-09  1:45 ` pinskia at gcc dot gnu.org
  2022-08-09  1:46 ` pinskia at gcc dot gnu.org
                   ` (8 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-09  1:45 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #15)
> It looks like -fno-strict-aliasing cleared the crash. This is bad because I
> thought we did not violate aliasing rules.
> 
> Let me try to find it.

Well since the way -fno-strict-aliasing disables a lot of memory based
optimizations, it does not mean there is an aliasing violation. Just the
different internal representation is different later on causing other issues.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (15 preceding siblings ...)
  2022-08-09  1:45 ` pinskia at gcc dot gnu.org
@ 2022-08-09  1:46 ` pinskia at gcc dot gnu.org
  2022-08-09  2:05 ` noloader at gmail dot com
                   ` (7 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-09  1:46 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The other thing to try is -fstack-reuse=none.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (16 preceding siblings ...)
  2022-08-09  1:46 ` pinskia at gcc dot gnu.org
@ 2022-08-09  2:05 ` noloader at gmail dot com
  2022-08-09  4:22 ` noloader at gmail dot com
                   ` (6 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  2:05 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #18 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Andrew Pinski from comment #17)
> The other thing to try is -fstack-reuse=none.

No joy with -fstack-reuse=none. The crash is still present.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (17 preceding siblings ...)
  2022-08-09  2:05 ` noloader at gmail dot com
@ 2022-08-09  4:22 ` noloader at gmail dot com
  2022-08-09  4:22 ` noloader at gmail dot com
                   ` (5 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  4:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #19 from Jeffrey Walton <noloader at gmail dot com> ---
Created attachment 53427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53427&action=edit
Test script to build library at -O2 with -fno-xxx

Test script to build library at -O2 with -fno-xxx

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (18 preceding siblings ...)
  2022-08-09  4:22 ` noloader at gmail dot com
@ 2022-08-09  4:22 ` noloader at gmail dot com
  2022-08-09  7:57 ` rguenth at gcc dot gnu.org
                   ` (4 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: noloader at gmail dot com @ 2022-08-09  4:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #20 from Jeffrey Walton <noloader at gmail dot com> ---
Hi Andrew.

I went through the list of options that are enabled at -O2 from [1]. I built
the library with each option separately at "-DNDEBUG -g2 -O2 -fno-xxx".

Here is the list of suspects. I seem to recall having trouble with
-fdevirtualize in the past:

  -fno-devirtualize
  -fno-indirect-inlining
  -fno-devirtualize

Here are the full results:

Failed to execute with -fno-align-functions
Failed to execute with -fno-align-jumps
Failed to execute with -fno-align-labels
Failed to execute with -fno-align-loops
Failed to execute with -fno-caller-saves
Failed to execute with -fno-code-hoisting
Failed to execute with -fno-crossjumping
Failed to execute with -fno-cse-follow-jumps
Failed to execute with -fno-cse-skip-blocks
Failed to execute with -fno-delete-null-pointer-checks
Ok! Ok! Ok! Ok! Ok! -fno-devirtualize
Failed to execute with -fno-devirtualize-speculatively
Failed to execute with -fno-expensive-optimizations
Failed to execute with -fno-finite-loops
Failed to execute with -fno-gcse
Failed to execute with -fno-gcse-lm
Failed to execute with -fno-hoist-adjacent-loads
Failed to execute with -fno-inline-functions
Failed to execute with -fno-inline-small-functions
Ok! Ok! Ok! Ok! Ok! -fno-indirect-inlining
Failed to execute with -fno-ipa-bit-cp
Failed to execute with -fno-ipa-cp
Failed to execute with -fno-ipa-icf
Failed to execute with -fno-ipa-ra
Failed to execute with -fno-ipa-sra
Failed to execute with -fno-ipa-vrp
Failed to execute with -fno-isolate-erroneous-paths-dereference
Failed to execute with -fno-lra-remat
Failed to execute with -fno-optimize-sibling-calls
Failed to execute with -fno-optimize-strlen
Failed to execute with -fno-partial-inlining
Failed to execute with -fno-peephole2
Failed to build with -fno-reorder-blocks-algorithm=stc
Failed to execute with -fno-reorder-blocks-and-partition
Failed to execute with -fno-reorder-functions
Failed to execute with -fno-rerun-cse-after-loop
Failed to execute with -fno-schedule-insns
Failed to execute with -fno-schedule-insns2
Failed to execute with -fno-sched-interblock
Failed to execute with -fno-sched-spec
Failed to execute with -fno-store-merging
Ok! Ok! Ok! Ok! Ok! -fno-strict-aliasing
Failed to execute with -fno-thread-jumps
Failed to execute with -fno-tree-builtin-call-dce
Failed to execute with -fno-tree-loop-vectorize
Failed to execute with -fno-tree-pre
Ok! Ok! Ok! Ok! Ok! -fno-tree-slp-vectorize
Failed to execute with -fno-tree-switch-conversion
Failed to execute with -fno-tree-tail-merge
Failed to execute with -fno-tree-vrp
Failed to build with -fno-vect-cost-model=very-cheap

Attached is the script I used to repeatedly build the library.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (19 preceding siblings ...)
  2022-08-09  4:22 ` noloader at gmail dot com
@ 2022-08-09  7:57 ` rguenth at gcc dot gnu.org
  2024-02-06 20:20 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-09  7:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Try -fsanitize=unreachable - when reordering BBs makes crashes appear/disappear
the most likely culprit is we run into a path deemed unreachable which means we
fall through to random code.

You can also try looking at the -fdump-tree-optimized dump and find the
function that's not catching what it is supposed to catch to see if there's any
__builtin_unreachable () calls around.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (20 preceding siblings ...)
  2022-08-09  7:57 ` rguenth at gcc dot gnu.org
@ 2024-02-06 20:20 ` redi at gcc dot gnu.org
  2024-02-06 20:28 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  24 siblings, 0 replies; 26+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-06 20:20 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 57344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57344&action=edit
Gzipped preprocessed source

With -O2 -fsantiize=unreachable this prints an error:

pubkey.h:2209:32: runtime error: execution reached an unreachable program point

That happens from the constructor at validat9.cpp:455 

#0 
CryptoPP::PK_FinalTemplate<CryptoPP::DL_VerifierImpl<CryptoPP::DL_SignatureSchemeOptions<CryptoPP::DL_SS<CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_Algorithm_ECGDSA<CryptoPP::ECP>,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> >
>::PK_FinalTemplate (algorithm=..., this=0x7fffffffc7d0) at
/tmp/cryptopp/cryptlib.h:2626
#1  CryptoPP::Test::ValidateECGDSA (thorough=thorough@entry=true) at
validat9.cpp:455
#2  0x000000000043448f in CryptoPP::Test::Validate (alg=<optimized out>,
thorough=thorough@entry=true) at test.cpp:995
#3  0x000000000043a303 in CryptoPP::Test::scoped_main (argc=3,
argv=0x7fffffffd6b8) at test.cpp:401
#4  0x000000000043aaf3 in main (argc=<optimized out>, argv=<optimized out>) at
test.cpp:1094


I don't see anything obviously wrong with the code.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (21 preceding siblings ...)
  2024-02-06 20:20 ` redi at gcc dot gnu.org
@ 2024-02-06 20:28 ` pinskia at gcc dot gnu.org
  2024-02-06 21:50 ` pinskia at gcc dot gnu.org
  2024-02-06 22:21 ` [Bug ipa/106568] " pinskia at gcc dot gnu.org
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-06 20:28 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This might be a divirtualization issue.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (22 preceding siblings ...)
  2024-02-06 20:28 ` pinskia at gcc dot gnu.org
@ 2024-02-06 21:50 ` pinskia at gcc dot gnu.org
  2024-02-06 22:21 ` [Bug ipa/106568] " pinskia at gcc dot gnu.org
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-06 21:50 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
                   |a/show_bug.cgi?id=106057    |a/show_bug.cgi?id=101839

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Sorry I meant to link to PR 101839 instead. The commit for it has the wrong bug
#  in it :).

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bug ipa/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
  2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
                   ` (23 preceding siblings ...)
  2024-02-06 21:50 ` pinskia at gcc dot gnu.org
@ 2024-02-06 22:21 ` pinskia at gcc dot gnu.org
  24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-06 22:21 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
PK_FinalTemplate constructor is doing:
this->AccessKey()

Where AccessKey is virtual function.

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2024-02-06 22:21 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-08 21:20 [Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it noloader at gmail dot com
2022-08-08 21:30 ` [Bug middle-end/106568] " ktkachov at gcc dot gnu.org
2022-08-08 21:34 ` pinskia at gcc dot gnu.org
2022-08-08 21:36 ` [Bug rtl-optimization/106568] " pinskia at gcc dot gnu.org
2022-08-08 21:40 ` pinskia at gcc dot gnu.org
2022-08-08 21:52 ` noloader at gmail dot com
2022-08-08 22:00 ` pinskia at gcc dot gnu.org
2022-08-08 22:18 ` noloader at gmail dot com
2022-08-08 22:25 ` pinskia at gcc dot gnu.org
2022-08-08 23:05 ` noloader at gmail dot com
2022-08-08 23:20 ` noloader at gmail dot com
2022-08-08 23:22 ` pinskia at gcc dot gnu.org
2022-08-08 23:23 ` pinskia at gcc dot gnu.org
2022-08-09  0:56 ` noloader at gmail dot com
2022-08-09  1:09 ` noloader at gmail dot com
2022-08-09  1:35 ` noloader at gmail dot com
2022-08-09  1:45 ` pinskia at gcc dot gnu.org
2022-08-09  1:46 ` pinskia at gcc dot gnu.org
2022-08-09  2:05 ` noloader at gmail dot com
2022-08-09  4:22 ` noloader at gmail dot com
2022-08-09  4:22 ` noloader at gmail dot com
2022-08-09  7:57 ` rguenth at gcc dot gnu.org
2024-02-06 20:20 ` redi at gcc dot gnu.org
2024-02-06 20:28 ` pinskia at gcc dot gnu.org
2024-02-06 21:50 ` pinskia at gcc dot gnu.org
2024-02-06 22:21 ` [Bug ipa/106568] " pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).