public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3
@ 2023-03-09  6:56 murugesandins at gmail dot com
  2023-03-09 10:20 ` [Bug c++/109074] " rguenth at gcc dot gnu.org
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-09  6:56 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 109074
           Summary: SIGABRT signal without using -lpthread at Linux RHEL
                    7.3
           Product: gcc
           Version: 4.8.5
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: murugesandins at gmail dot com
  Target Milestone: ---

Hi G++ bugzilla,

$ /usr/bin/g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/bin/cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)


I don't have root access and sudo access.
I tried following sample thread.cpp program:
[code]
/*
 * Creating thread using "class thread" at C++
 * Sample C++ program using the "class thread".
 * Once an object is created, it used to create a thread.
 * When creating object, we need to pass the name of the function as parameter
to that object.
 * Once creating the object, that function used to be called by the thread.
 * I will write mutex comments later.
 * Example:
 *      thread t1(ThreadMethod);
 *      Here t1 is creating the new thread.
 *      I have not tested following code at other operating
systems(UNIX/AIX/SunOS/HP-UX/...) excluding Linux, CYGWIN_NT and MINGW
*/
#include <unistd.h>
#if defined(LINUX)
        #include <sys/syscall.h>        // syscall(SYS_gettid)
        #ifdef SYS_gettid
                #define gettid() ((pid_t)syscall(SYS_gettid))
        #endif
#elif defined(CYGWIN_NT) || defined (MINGW)
        #define gettid() (unsigned long)pthread_self()
#endif
#include <iostream>
#include <thread>
#include <unistd.h>
using namespace std;
int TotalThreadCount = 0;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void ThreadMethod()
{
        while(true)
        {
                if( 2 <= TotalThreadCount )
                {
                        break;
                }
                pthread_mutex_lock(&mutex);
                string DispTID = "";
                DispTID = string("TotalThreadCount :") +
to_string(TotalThreadCount) + " TID: " + to_string(gettid()) + "\n";
                cout << DispTID;
                cout.flush();
                sleep(1);
                ++TotalThreadCount;
                pthread_mutex_unlock(&mutex);
        }
}
int main()
{
        // class thread available from C++11
        // initialize the object using related thread function.
        thread t1(ThreadMethod);
        thread t2(ThreadMethod);
        t1.join();
        t2.join();
        // cout << "mutex.__data: " << (unsigned long long)&mutex.__data <<
"\n";
        return 0;
}
/*
 pthread_mutex_t is a union having one struct one char array[40] and one long.
 union pthread_mutex_t
 {
        pthread_mutex_t::__pthread_mutex_s      == double linked list
        {
                int __lock;                     == 04 bytes
                unsigned int __count;           == 04 bytes
                int __owner;                    == 04 bytes
                unsigned int __nusers;          == 04 bytes
                int __kind;                     == 04 bytes
                int __spins;                    == 04 bytes
                __pthread_list_t __list;        == 16 bytes
                {
                        *prev;
                        *next;
                }
        } __data;                               == 40 bytes
        char __size[40];                        == 40 bytes
        long __align;                           == 08 bytes
 }                                              == 40 bytes since this is union
taking maximum bytes.
 Hence size of this union is 40 bytes.
*/
[/code]
$ /usr/bin/g++ -DLINUX -g -Wall thread.cpp -o ./a.out -std=c++11
$ ./a.out
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)

$ gdb a.out core.27255
Reading symbols from ./a.out...done.
[New LWP 27255]
Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0  0x00007f1125cdd1d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7.x86_64
libgcc-4.8.5-11.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64
(gdb) #0  0x00007f1125cdd1d7 in raise () from /lib64/libc.so.6
#1  0x00007f1125cde8c8 in abort () from /lib64/libc.so.6
#2  0x00007f11265e1ab5 in __gnu_cxx::__verbose_terminate_handler() () from
/lib64/libstdc++.so.6
#3  0x00007f11265dfa26 in ?? () from /lib64/libstdc++.so.6
#4  0x00007f11265dfa53 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00007f11265dfc73 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x00007f11266364b9 in
std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) ()
   from /lib64/libstdc++.so.6
#7  0x00000000004020d2 in std::thread::thread<void (&)()> (this=0x7ffebb32ae60,
    __f=@0x4017cd: {void (void)} 0x4017cd <ThreadMethod()>) at
/usr/include/c++/4.8.2/thread:135
#8  0x0000000000401a89 in main () at thread.cpp:50
(gdb) quit

If I add -lpthread, it is working fine.
$ /usr/bin/g++ -lpthread -DLINUX -std=c++11 -g -Wall thread.cpp -o
./a.out;./a.out
TotalThreadCount :0 TID: 29678
TotalThreadCount :1 TID: 29678
TotalThreadCount :2 TID: 29679

$ /usr/bin/g++ -DLINUX -std=c++11 -g -Wall thread.cpp -o ./a.out
$ /usr/bin/ldd ./a.out
        linux-vdso.so.1 =>  (0x00007fff597bb000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f36c0c49000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f36c0946000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f36c0730000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f36c036f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f36c0f6f000)

$ /usr/bin/g++ -lpthread -DLINUX -std=c++11 -g -Wall thread.cpp -o ./a.out
$ /usr/bin/ldd ./a.out
        linux-vdso.so.1 =>  (0x00007ffec3d29000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f00b9000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f70efdb0000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f70efaae000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70ef898000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f70ef4d6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f70f02f3000)

If dependency /lib64/libpthread.so.0 is missing how the compiler show SIGABRT
signal inside "class thread" ?
I cannot download and install g++ latest version at current host.
Can I download g++ binary alone at my home directory like the way I am using
openssl at my home directory ?

cygwin usage:
$ /usr/bin/g++ -DCYGWIN_NT -g -Wall thread.cpp -o ./a.out -std=c++11
$ /usr/bin/ldd ./a.out | grep -v -i WINDOWS
/usr/bin/cygwin1.dll (0x61000000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffb5d4b0000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3e90a0000)
/usr/bin/cygstdc++-6.dll (0x6d310000)
        cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3d11d0000)
$ ./a.out
TotalThreadCount :0 TID: 42949749056
TotalThreadCount :1 TID: 42949749344
TotalThreadCount :2 TID: 42949749056
$ /usr/bin/g++ -lpthread -DCYGWIN_NT -g -Wall thread.cpp -o ./a.out -std=c++11
$ /usr/bin/ldd ./a.out | grep -v -i WINDOWS
/usr/bin/cygwin1.dll (0x61000000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffb5d4b0000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3e90a0000)
/usr/bin/cygstdc++-6.dll (0x6d310000)
        cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3d11d0000)

I need to know if this bug later resolved using upgraded versions of g++?
if yes, I need that version number of that g++ at RHEL.

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

* [Bug c++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
@ 2023-03-09 10:20 ` rguenth at gcc dot gnu.org
  2023-03-09 11:28 ` pinskia at gcc dot gnu.org
                   ` (11 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-09 10:20 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |MOVED

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please file this bug with RedHat, GCC 4.8.5 is no longer maintained at our
ends.

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

* [Bug c++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
  2023-03-09 10:20 ` [Bug c++/109074] " rguenth at gcc dot gnu.org
@ 2023-03-09 11:28 ` pinskia at gcc dot gnu.org
  2023-03-09 11:30 ` pinskia at gcc dot gnu.org
                   ` (10 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-09 11:28 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|MOVED                       |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually there is no bug here. With older versions of glibc, you need to link
against libpthread to get threads in general. This is true with any version of
gcc.

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

* [Bug c++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
  2023-03-09 10:20 ` [Bug c++/109074] " rguenth at gcc dot gnu.org
  2023-03-09 11:28 ` pinskia at gcc dot gnu.org
@ 2023-03-09 11:30 ` pinskia at gcc dot gnu.org
  2023-03-10  4:34 ` [Bug libstdc++/109074] " murugesandins at gmail dot com
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-09 11:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The reason for the abort is because you didn't catch the exception as libstc++
is throwing one because threads are not enabled at runtime via the linking of
libpthread.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (2 preceding siblings ...)
  2023-03-09 11:30 ` pinskia at gcc dot gnu.org
@ 2023-03-10  4:34 ` murugesandins at gmail dot com
  2023-03-10  4:53 ` murugesandins at gmail dot com
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-10  4:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
Thank you for your comment.
I feel that there WAS a bug in old libc library.
I am not sure if current libc version having this bug or not.
-----------------------------------------
01. external library /lib64/libc.so.6 => /lib64/libc-2.17.so
$ /usr/bin/g++ -g -Wall libcversion.cpp -o ./a.out
$  ./a.out
GNU libc version: 2.17
This should have been fixed in later versions of libc.
I need to know related libc version without this bug 109074.
-----------------------------------------
02. Bug related information from core file:
$ /usr/bin/g++ -DLINUX -g -Wall thread.cpp -o ./a.out -std=c++11
$ gdb a.out
Reading symbols from /home/murugesan_openssl/a.out...done.
(gdb) run
Starting program: /home/murugesan_openssl/a.out
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Program received signal SIGABRT, Aborted.
0x00007ffff72311d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7.x86_64
libgcc-4.8.5-11.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64
(gdb) where
#0  0x00007ffff72311d7 in raise () from /lib64/libc.so.6
#1  0x00007ffff72328c8 in abort () from /lib64/libc.so.6
#2  0x00007ffff7b35ab5 in __gnu_cxx::__verbose_terminate_handler() () from
/lib64/libstdc++.so.6
#3  0x00007ffff7b33a26 in ?? () from /lib64/libstdc++.so.6
#4  0x00007ffff7b33a53 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00007ffff7b33c73 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x00007ffff7b8a4b9 in
std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) ()
   from /lib64/libstdc++.so.6
#7  0x00000000004020d2 in std::thread::thread<void (&)()> (this=0x7fffffffdc90,
    __f=@0x4017cd: {void (void)} 0x4017cd <ThreadMethod()>) at
/usr/include/c++/4.8.2/thread:135
#8  0x0000000000401a89 in main () at thread.cpp:50
(gdb)
-----------------------------------------

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (3 preceding siblings ...)
  2023-03-10  4:34 ` [Bug libstdc++/109074] " murugesandins at gmail dot com
@ 2023-03-10  4:53 ` murugesandins at gmail dot com
  2023-03-10  5:01 ` pinskia at gcc dot gnu.org
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-10  4:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
(In reply to Murugesan Nagarajan from comment #4)
> Thank you for your comment.
> I feel that there WAS a bug in old libc library.
> I am not sure if current libc version having this bug or not.
> -----------------------------------------
> 01. external library /lib64/libc.so.6 => /lib64/libc-2.17.so
> $ /usr/bin/g++ -g -Wall libcversion.cpp -o ./a.out
> $  ./a.out
> GNU libc version: 2.17
> This should have been fixed in later versions of libc.
> I need to know related libc version without this bug 109074.
> -----------------------------------------
> 02. Bug related information from core file:
> $ /usr/bin/g++ -DLINUX -g -Wall thread.cpp -o ./a.out -std=c++11
> $ gdb a.out
> Reading symbols from /home/murugesan_openssl/a.out...done.
> (gdb) run
> Starting program: /home/murugesan_openssl/a.out
> terminate called after throwing an instance of 'std::system_error'
>   what():  Enable multithreading to use std::thread: Operation not permitted
> Program received signal SIGABRT, Aborted.
> 0x00007ffff72311d7 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.17-157.el7.x86_64 libgcc-4.8.5-11.el7.x86_64
> libstdc++-4.8.5-11.el7.x86_64
> (gdb) where
> #0  0x00007ffff72311d7 in raise () from /lib64/libc.so.6
> #1  0x00007ffff72328c8 in abort () from /lib64/libc.so.6
> #2  0x00007ffff7b35ab5 in __gnu_cxx::__verbose_terminate_handler() () from
> /lib64/libstdc++.so.6
> #3  0x00007ffff7b33a26 in ?? () from /lib64/libstdc++.so.6
> #4  0x00007ffff7b33a53 in std::terminate() () from /lib64/libstdc++.so.6
> #5  0x00007ffff7b33c73 in __cxa_throw () from /lib64/libstdc++.so.6
> #6  0x00007ffff7b8a4b9 in
> std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) ()
>    from /lib64/libstdc++.so.6
> #7  0x00000000004020d2 in std::thread::thread<void (&)()>
> (this=0x7fffffffdc90,
>     __f=@0x4017cd: {void (void)} 0x4017cd <ThreadMethod()>) at
> /usr/include/c++/4.8.2/thread:135
> #8  0x0000000000401a89 in main () at thread.cpp:50
> (gdb)
> -----------------------------------------
Actually I am from India. wait for my reply(if required) on next day.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (4 preceding siblings ...)
  2023-03-10  4:53 ` murugesandins at gmail dot com
@ 2023-03-10  5:01 ` pinskia at gcc dot gnu.org
  2023-03-10  5:26 ` murugesandins at gmail dot com
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-10  5:01 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> what():  Enable multithreading to use std::thread:

It explicitly says what needs to be done. And to enable multithreading on
gnu/Linux you use -pthread option or link against libpthread.

Newer gnu/Linux distros enable multithreading by default so you don't need to
link against libpthread.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (5 preceding siblings ...)
  2023-03-10  5:01 ` pinskia at gcc dot gnu.org
@ 2023-03-10  5:26 ` murugesandins at gmail dot com
  2023-03-10 10:32 ` redi at gcc dot gnu.org
                   ` (5 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-10  5:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> The reason for the abort is because you didn't catch the exception as
> libstc++ is throwing one because threads are not enabled at runtime via the
> linking of libpthread.

Thank you again.
Handled using try catch exception.
However this exception not from my compilation issue.
I feel that issue from libstdc++ library(older version)
Updated code using try catch exception:


/*
 * Creating thread using "class thread" at C++
 * Sample C++ program using the "class thread".
 * Once an object is created, it used to create a thread.
 * When creating object, we need to pass the name of the function as parameter
to that object.
 * Once creating the object, that function used to be called by the thread.
 * I will write mutex comments later.
 * Example:
 *      thread t1(ThreadMethod);
 *      Here t1 is creating the new thread.
 *      I have not tested following code at other operating
systems(UNIX/AIX/SunOS/HP-UX/...) excluding Linux, CYGWIN_NT and MINGW
*/
#include <unistd.h>
#if defined(LINUX)
        #include <sys/syscall.h>        // syscall(SYS_gettid)
        #ifdef SYS_gettid
                #define gettid() ((pid_t)syscall(SYS_gettid))
        #endif
#elif defined(CYGWIN_NT) || defined (MINGW)
        #define gettid() (unsigned long)pthread_self()
#endif
#include <iostream>
#include <thread>
#include <unistd.h>
using namespace std;
int TotalThreadCount = 0;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void ThreadMethod()
{
        while(true)
        {
                if( 2 <= TotalThreadCount )
                {
                        break;
                }
                pthread_mutex_lock(&mutex);
                string DispTID = "";
                DispTID = string("TotalThreadCount :") +
to_string(TotalThreadCount) + " TID: " + to_string(gettid()) + "\n";
                cout << DispTID;
                cout.flush();
                sleep(1);
                ++TotalThreadCount;
                pthread_mutex_unlock(&mutex);
        }
}
int main()
{
        // class thread available from C++11
        // initialize the object using related thread function.
        try
        {
                thread t1(ThreadMethod);
                thread t2(ThreadMethod);
                t1.join();
                t2.join();
        }
        catch( std::exception &e)
        {
                cout << "Unable to create thread using class thread\n";
                cout << "Caught thread exception: " << e.what() << "\n";
                cout << "Re-compile your program using -lpthread\n";
        }
        cout << "mutex.__data: " << (unsigned long long)&mutex.__data << "\n";
        cout << "mutex.__data.__lock: " << (unsigned long
long)&mutex.__data.__lock << "\n";
        cout << "mutex.__data.__count: " << (unsigned long
long)&mutex.__data.__count << "\n";
        cout << "mutex.__data.__owner: " << (unsigned long
long)&mutex.__data.__owner << "\n";
        cout << "mutex.__data.__nusers: " << (unsigned long
long)&mutex.__data.__nusers << "\n";
        cout << "mutex.__data.__kind: " << (unsigned long
long)&mutex.__data.__kind << "\n";
        cout << "mutex.__data.__spins: " << (unsigned long
long)&mutex.__data.__spins << "\n";
        cout << "mutex.__data.__list: " << (unsigned long
long)&mutex.__data.__list << "\n";
        cout << "mutex.__data.__list.__prev: " << (unsigned long
long)&mutex.__data.__list.__prev << "\n";
        cout << "mutex.__data.__list.__next: " << (unsigned long
long)&mutex.__data.__list.__next << "\n";
        cout << "mutex.__size: " << (unsigned long long)&mutex.__size << "\n";
        cout << "mutex.__align: " << (unsigned long long)&mutex.__align <<
"\n";
        return 0;
}
/*
 pthread_mutex_t is a union having one struct one char array[40] and one long.
 union pthread_mutex_t
 {
        pthread_mutex_t::__pthread_mutex_s      == double linked list
        {
                int __lock;                     == 04 bytes
                unsigned int __count;           == 04 bytes
                int __owner;                    == 04 bytes
                unsigned int __nusers;          == 04 bytes
                int __kind;                     == 04 bytes
                int __spins;                    == 04 bytes
                __pthread_list_t __list;        == 16 bytes
                {
                        *prev;
                        *next;
                }
        } __data;                               == 40 bytes
        char __size[40];                        == 40 bytes
        long __align;                           == 08 bytes
 }                                              == 40 bytes since this is union
taking maximum bytes.
 Hence size of this union is 40 bytes.
*/


/*
$ /usr/bin/g++ -DLINUX -g -Wall thread.cpp -o ./a.out -std=c++11
$ # Tested this code on padding no wastage of memory using mutex.
Unable to create thread using class thread
Caught thread exception: Enable multithreading to use std::thread: Operation
not permitted
Re-compile your program using -lpthread
mutex.__data: 6316960                                                          
      => union
mutex.__data.__lock: 6316960        => 6316960, 6316961 6316962 6316963        
      => union
mutex.__data.__count: 6316964       => 6316964, 6316965 6316966 6316967
mutex.__data.__owner: 6316968       => 6316968, 6316969 6316970 6316971
mutex.__data.__nusers: 6316972      => 6316972, 6316973 6316974 6316975
mutex.__data.__kind: 6316976        => 6316976, 6316977 6316978 6316979
mutex.__data.__spins: 6316980       => 6316980, 6316981 6316982 6316983
mutex.__data.__list: 6316984
mutex.__data.__list.__prev:6316984 => 6316984,6316985 6316986 6316987 6316988
6316989 6316990 6316991
mutex.__data.__list.__next:6316992 => 6316992,6316993 6316994 6316995 6316996
6316997 6316998 6316999
mutex.__size: 6316960                                                          
      => union
mutex.__align: 6316960                                                         
      => union
*/

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (6 preceding siblings ...)
  2023-03-10  5:26 ` murugesandins at gmail dot com
@ 2023-03-10 10:32 ` redi at gcc dot gnu.org
  2023-03-10 21:30 ` murugesandins at gmail dot com
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2023-03-10 10:32 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You need to use -pthread to use std::thread.

That's what the exception is telling you.

Catching the exception doesn't solve the problem.

Use -pthread.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (7 preceding siblings ...)
  2023-03-10 10:32 ` redi at gcc dot gnu.org
@ 2023-03-10 21:30 ` murugesandins at gmail dot com
  2023-03-10 23:20 ` murugesandins at gmail dot com
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-10 21:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
Thank you again. Reason for Porting this comment:
Libc Library having core dump issue.hence thought of sharing this bug at Libc
Library.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (8 preceding siblings ...)
  2023-03-10 21:30 ` murugesandins at gmail dot com
@ 2023-03-10 23:20 ` murugesandins at gmail dot com
  2023-03-10 23:30 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-10 23:20 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
(In reply to Murugesan Nagarajan from comment #9)
> Thank you again. Reason for Porting this comment:
> Libc Library having core dump issue.hence thought of sharing this bug at
> Libc Library.

Hence sigabrt signal needs to be handler at libc.so.6 Library
or this could have been fixed at other library. If so (like libc.so:))I need to
know which version of that library fixed this issue.
I'm not changing the status.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (9 preceding siblings ...)
  2023-03-10 23:20 ` murugesandins at gmail dot com
@ 2023-03-10 23:30 ` pinskia at gcc dot gnu.org
  2023-03-12 20:52 ` redi at gcc dot gnu.org
  2023-03-13  3:30 ` murugesandins at gmail dot com
  12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-10 23:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Murugesan Nagarajan from comment #10)
> (In reply to Murugesan Nagarajan from comment #9)
> > Thank you again. Reason for Porting this comment:
> > Libc Library having core dump issue.hence thought of sharing this bug at
> > Libc Library.
> 
> Hence sigabrt signal needs to be handler at libc.so.6 Library
> or this could have been fixed at other library. If so (like libc.so:))I need
> to know which version of that library fixed this issue.
> I'm not changing the status.

Again there is no fix to libc needed. The problem is you need to enable
threading and you are not doing that and you don't want to admit that is the
issue.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (10 preceding siblings ...)
  2023-03-10 23:30 ` pinskia at gcc dot gnu.org
@ 2023-03-12 20:52 ` redi at gcc dot gnu.org
  2023-03-13  3:30 ` murugesandins at gmail dot com
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2023-03-12 20:52 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Murugesan Nagarajan from comment #10)
> Hence sigabrt signal needs to be handler at libc.so.6 Library

Stop trying to "handle" the error and FIX IT. The error is that you didn't link
to libpthread.

Build your program with -pthread and there will be no error, so you don't need
to handle it.

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

* [Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
  2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
                   ` (11 preceding siblings ...)
  2023-03-12 20:52 ` redi at gcc dot gnu.org
@ 2023-03-13  3:30 ` murugesandins at gmail dot com
  12 siblings, 0 replies; 14+ messages in thread
From: murugesandins at gmail dot com @ 2023-03-13  3:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Murugesan Nagarajan <murugesandins at gmail dot com> ---
MY LAST COMMENT:
I agree.
Normally I used to handle bug fix using following ways:
1. Steps to reproduce to issue creating core dump files.
   There are some other ways which may work(Example: -pthread or
-lmurugesanopenssl or -lrfcsdk or -lnwrfcsdk or ... options)
After this I used to receive/send that test result to/from test/development
team.
Few libraries I faced a lot of errors during 2008 to 2013 and FEW of them(I
guess 4 out of six) were fixed during.
2. Hence I reported this error at current(old version) library. I agree that it
is working when we use -pthread.
However, this may report some other issue in future.

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

end of thread, other threads:[~2023-03-13  3:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-09  6:56 [Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3 murugesandins at gmail dot com
2023-03-09 10:20 ` [Bug c++/109074] " rguenth at gcc dot gnu.org
2023-03-09 11:28 ` pinskia at gcc dot gnu.org
2023-03-09 11:30 ` pinskia at gcc dot gnu.org
2023-03-10  4:34 ` [Bug libstdc++/109074] " murugesandins at gmail dot com
2023-03-10  4:53 ` murugesandins at gmail dot com
2023-03-10  5:01 ` pinskia at gcc dot gnu.org
2023-03-10  5:26 ` murugesandins at gmail dot com
2023-03-10 10:32 ` redi at gcc dot gnu.org
2023-03-10 21:30 ` murugesandins at gmail dot com
2023-03-10 23:20 ` murugesandins at gmail dot com
2023-03-10 23:30 ` pinskia at gcc dot gnu.org
2023-03-12 20:52 ` redi at gcc dot gnu.org
2023-03-13  3:30 ` murugesandins 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).