public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault
@ 2021-12-03  9:11 hedayat.fwd at gmail dot com
  2021-12-03  9:16 ` [Bug middle-end/103537] " pinskia at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-03  9:11 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 103537
           Summary: Using -fstack-protector-strong "without" optimization
                    cause segmentation fault
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hedayat.fwd at gmail dot com
  Target Milestone: ---

When compiling https://github.com/hedayat/powerfake with GCC 11.2.1 with
default settings, which uses -fstack-protector-strong flag but no optimization
flags, if you run the sample executable it crashes with segmentation fault when
accessing a privation member function using its pointer (running with -g only
reveals that it is accessing another member function instead!).

However, running without -fstack-protector-strong, or running with
-fstack-protector-strong AND some optimizations flags (tested with -Og and -O3
flags), make the program to run without any problems. Even using
-fstack-protector works fine. 

This is a sample GDB session (compiled with -g but without any optimization
flags):

Program received signal SIGSEGV, Segmentation fault.
0x000000000040a5b3 in
PowerFake::internal::TagBase<SamplePrivate>::Call<FakeTest::SampleClass2>
(obj=...) at /home/hedayat/Projects/powerfake/powerfake.h:257
257             return (obj.*GetAddress(Tag()))(args...);
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.34-8.fc35.x86_64 libgcc-11.2.1-1.fc35.x86_64
libstdc++-11.2.1-1.fc35.x86_64
(gdb) bt
#0  0x000000000040a5b3 in
PowerFake::internal::TagBase<SamplePrivate>::Call<FakeTest::SampleClass2>
(obj=...) at /home/hedayat/Projects/powerfake/powerfake.h:257
#1  0x00000000004030fa in FakeOverloaded () at
/home/hedayat/Projects/powerfake/sample/faked.cpp:196
#2  0x00000000004024df in main () at
/home/hedayat/Projects/powerfake/sample/faked.cpp:53
(gdb) print GetAddress(Tag())
$1 = {void
(FakeTest::SampleClass::*(OverloadedPrivateFloat))(FakeTest::SampleClass *
const, float)} 0x40a67e
<PowerFake::internal::GetAddress(OverloadedPrivateFloat)>


If the output is to be trusted, the GetAddress(Tag()) function is returning
wrong address. It is actually calling
PowerFake::internal::GetAddress(OverloadedPrivateFloat) while it should call
PowerFake::internal::GetAddress(SamplePrivate)


I'm not sure if the code is having any UB in it, and as it works fine except
with this specific combination of compiler options, I guessed it might be a
compiler bug. 

Note that you can remove all other code in FakeOverloaded() function, and still
see the crash. So, surrounding code doesn't affect the problem.

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
@ 2021-12-03  9:16 ` pinskia at gcc dot gnu.org
  2021-12-03 20:15 ` hedayat.fwd at gmail dot com
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03  9:16 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you try add -fsanitize=undefined and seeing if there is any undefined
behavior there? What about -fsanitize=address?

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
  2021-12-03  9:16 ` [Bug middle-end/103537] " pinskia at gcc dot gnu.org
@ 2021-12-03 20:15 ` hedayat.fwd at gmail dot com
  2021-12-03 20:30 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-03 20:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Hedayat Vatankhah <hedayat.fwd at gmail dot com> ---
With these options, the code runs a bit more but still crashes. The output of
each option is given below:

Output with -fsanitize=undefined:
/home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of
misaligned address 0x00000044c556 for type '<unknown> *', which requires 8 byte
alignment
0x00000044c556: note: pointer points here
 00 e8 ac 5a 00 00  84 c0 74 17 48 8d 55 f4  48 8d 45 f8 48 89 c6 bf  00 5c 4b
00 e8 17 5b 00  00 eb
             ^ 
zsh: segmentation fault (core dumped)  ./sample/samples


Output with -fsanitize=address:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==261345==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x000000412704
bp 0x7ffcdfbd4c10 sp 0x7ffcdfbd4c00 T0)
==261345==The signal is caused by a READ memory access.
==261345==Hint: this fault was caused by a dereference of a high value address
(see register values below).  Dissassemble the provided pc to learn which
register was used.
    #0 0x412704 in decltype(auto)
PowerFake::internal::TagBase<OverloadedPrivateInt>::Call<FakeTest::SampleClass2,
int>(FakeTest::SampleClass2&, int)
(/home/hedayat/Projects/powerfake/build.o/sample/samples+0x412704)
    #1 0x404c14 in FakeOverloaded()
(/home/hedayat/Projects/powerfake/build.o/sample/samples+0x404c14)
    #2 0x40364e in main
(/home/hedayat/Projects/powerfake/build.o/sample/samples+0x40364e)
    #3 0x7ff8f02a055f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #4 0x7ff8f02a060b in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d60b)
    #5 0x403584 in _start
(/home/hedayat/Projects/powerfake/build.o/sample/samples+0x403584)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/home/hedayat/Projects/powerfake/build.o/sample/samples+0x412704) in
decltype(auto)
PowerFake::internal::TagBase<OverloadedPrivateInt>::Call<FakeTest::SampleClass2,
int>(FakeTest::SampleClass2&, int)
==261345==ABORTING

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
  2021-12-03  9:16 ` [Bug middle-end/103537] " pinskia at gcc dot gnu.org
  2021-12-03 20:15 ` hedayat.fwd at gmail dot com
@ 2021-12-03 20:30 ` pinskia at gcc dot gnu.org
  2021-12-04 23:04 ` hedayat.fwd at gmail dot com
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 20:30 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2021-12-03

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hedayat Vatankhah from comment #2)
> With these options, the code runs a bit more but still crashes.

Right those options are supposed to be used to catch issues in your code.

> The output
> of each option is given below:
> 
> Output with -fsanitize=undefined:
> /home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of
> misaligned address 0x00000044c556 for type '<unknown> *', which requires 8
> byte alignment
> 0x00000044c556: note: pointer points here
>  00 e8 ac 5a 00 00  84 c0 74 17 48 8d 55 f4  48 8d 45 f8 48 89 c6 bf  00 5c
> 4b 00 e8 17 5b 00  00 eb
>              ^ 
> zsh: segmentation fault (core dumped)  ./sample/samples

Can you check the above part of the problem.



template <typename FuncType>
remove_func_cv_t<FuncType> unify_pmf(FuncType f)
{
    return reinterpret_cast<remove_func_cv_t<FuncType>>(f);
}


This looks like it could cause issues.
So does:

            return std::make_pair(reinterpret_cast<void *>(func_ptr),
                std::type_index(typeid(FuncType)));


I get the feeling you don't understand how pointer to member functions work in
some cases.

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
                   ` (2 preceding siblings ...)
  2021-12-03 20:30 ` pinskia at gcc dot gnu.org
@ 2021-12-04 23:04 ` hedayat.fwd at gmail dot com
  2021-12-04 23:17 ` hedayat.fwd at gmail dot com
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-04 23:04 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Hedayat Vatankhah <hedayat.fwd at gmail dot com> ---
Well, sorry if I should gave more logs to make it more clear.

Note that the crash happens here:
https://github.com/hedayat/powerfake/blob/a4c80d6628816656796d2e85b4422218da05ce00/powerfake.h#L257

And the problematic code doesn't use any of the parts of the code you
mentioned. 

To make the scope of the problem much less, I replaced main() function as
follows and commented out all other unrelated code:

int main()
{
    SampleClass2 sc2;
    SamplePrivate::Call(sc2);
}

This code certainly doesn't use any of the code you mentioned. It only uses
TAG_PRIVATE_MEMBER macro, which in turn uses TagBase and
PrivateFunctionExtractor structs, and no other code. 

The behavior is as follows:

* without -fstack-protector-strong, with or without any of the sanitize options
the code runs normally. No crash, and not any messages from any of the
sanitizers.

* with -fstack-protector-strong, with or without -fsanitize=undefined, you got
a segmentation fault. Logs when running with -fsanitize=undefined:

/home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of
misaligned address 0x7f64004083fc for type '<unknown> *', which requires 8 byte
alignment
0x7f64004083fc: note: pointer points here
<memory cannot be printed>
zsh: segmentation fault (core dumped)  ./sample/samples

* with -fstack-protector-strong and with -fsanitize=address, you don't get a
crash, so -fsanitizer=address somehow fixes the problem caused with
-fstack-protector-strong. (Using address sanitizer only causes a crash when I
use OverloadedPrivateFloat::Call(sc2, 5);, which I will investigate. But that
issue seems completely unrelated to this bug. address sanitizer causes a crash
with that function even when -fstack-protector-strong is not used).

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
                   ` (3 preceding siblings ...)
  2021-12-04 23:04 ` hedayat.fwd at gmail dot com
@ 2021-12-04 23:17 ` hedayat.fwd at gmail dot com
  2021-12-04 23:37 ` hedayat.fwd at gmail dot com
  2021-12-05  0:19 ` hedayat.fwd at gmail dot com
  6 siblings, 0 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-04 23:17 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Hedayat Vatankhah <hedayat.fwd at gmail dot com> ---
Oops, maybe I'm wrong. I forgot that I've also wrapped
SampleClass::SamplePrivate, so let me investigate further. Sorry for the
inconvenience.

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
                   ` (4 preceding siblings ...)
  2021-12-04 23:17 ` hedayat.fwd at gmail dot com
@ 2021-12-04 23:37 ` hedayat.fwd at gmail dot com
  2021-12-05  0:19 ` hedayat.fwd at gmail dot com
  6 siblings, 0 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-04 23:37 UTC (permalink / raw)
  To: gcc-bugs

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

Hedayat Vatankhah <hedayat.fwd at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #6 from Hedayat Vatankhah <hedayat.fwd at gmail dot com> ---
About the unify_pmf and reinterpret_cast<void *>(func_ptr) parts you mentioned,
I will re-investigate them too. However, they are already working as intended
for non-private methods, so I guess they should be fine. unify_pmf only removes
extra qualifiers from the type of the PMF, and the void * cast is based on
"Extracting the Function Pointer from a Bound Pointer to Member Function"
extension of GCC. And the result is only used as a std::map key, and never
dereferenced there. But, it can cause duplicates if there is a problem with it.
I'll see. 

Now, I'm also getting the feeling that something is wrong with my code
actually, so I close this for now. Sorry for bothering you, and thanks for your
answers.

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

* [Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault
  2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
                   ` (5 preceding siblings ...)
  2021-12-04 23:37 ` hedayat.fwd at gmail dot com
@ 2021-12-05  0:19 ` hedayat.fwd at gmail dot com
  6 siblings, 0 replies; 8+ messages in thread
From: hedayat.fwd at gmail dot com @ 2021-12-05  0:19 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Hedayat Vatankhah <hedayat.fwd at gmail dot com> ---
An interesting part of the problem is that following calls:
    sc2.CallSamplePrivate();
    sc2.CallOverloadedPrivate(4);
    sc2.CallOverloadedPrivate(4.0f);

both before and after using MakeFake<>() calls, and the MakeFake<>() calls
themselves, which are the things which actually use the PMF related code you
mentioned, are working completely fine if the XXX::Call() calls are not there
or doesn't crash; but those XXX::Call() functions which are expected to only
use the address of wrapped function, which is handled by the linker not my
code, are crashing. While something like sc2.CallSamplePrivate(), which is also
calling my wrapped functions, is working fine. 

So, while it has something to do with what I do, it is weird and doesn't look
like a simple PMF conversion error or something.

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

end of thread, other threads:[~2021-12-05  0:19 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-03  9:11 [Bug c++/103537] New: Using -fstack-protector-strong "without" optimization cause segmentation fault hedayat.fwd at gmail dot com
2021-12-03  9:16 ` [Bug middle-end/103537] " pinskia at gcc dot gnu.org
2021-12-03 20:15 ` hedayat.fwd at gmail dot com
2021-12-03 20:30 ` pinskia at gcc dot gnu.org
2021-12-04 23:04 ` hedayat.fwd at gmail dot com
2021-12-04 23:17 ` hedayat.fwd at gmail dot com
2021-12-04 23:37 ` hedayat.fwd at gmail dot com
2021-12-05  0:19 ` hedayat.fwd at gmail dot com

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).