c++17 - std::ofstream assignment operator -- segfault only occurs in gdb - Stack Overflow

admin管理员组

文章数量:1420907

I am writing a multithreaded program in which each thread opens its own text file for primitive debug logging. Each thread is represented by a separate instance of a class, which manages both the std::thread object and the std::ofstream object, as well as the main execution loop for the thread.

While debugging other aspects of the program, I noticed that a segfault occurs when opening the log file, but only when the gdb debugger is active. Furthermore, this only seems to occur when there are more threads than CPU cores on the system.

A simple code example is below:

#include <chrono>
#include <fstream>
#include <memory>
#include <thread>
#include <vector>

class Log final{
    private:
        int i_;
    
        std::thread worker_;
        
        std::ofstream log_;
    
    public:
        Log(int i) : i_(i), worker_(&Log::doWork, this) {};
        
        ~Log(){
            worker_.join();
        }
    
    private:
        void doWork(){
            log_ = std::ofstream(
                std::to_string(i_)
                + "_"
                + std::to_string(std::hash<std::thread::id>{}(std::this_thread::get_id()))
                + ".log"
            );
            

            for (int i = 0 ; i < 999999 ; ++i){
                log_ << i << '\n';
            }
            
            log_.close();
        }
};

int main (void){
    std::vector<std::unique_ptr<Log>> vec;
    
    for (int i = 0 ; i < 50 ; ++i){
        auto l = std::make_unique<Log>(i);
        
        vec.emplace_back(std::move(l));
    }
    
    return 0;
}

This is compiled on GCC (g++) 11.4.0, with the following options:

-std=c++17 -g

Running with gdb 12.1 produces the following backtrace:

#0  0x00007ffff7e94f17 in std::basic_ofstream<char, std::char_traits<char> >::operator=(std::basic_ofstream<char, std::char_traits<char> >&&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0000555555556d07 in Log::doWork (this=0x555555571b40) at log:30
#2  0x0000555555558d4f in std::__invoke_impl<void, void (Log::*)(), Log*> (
    __f=@0x555555571d70: (void (Log::*)(Log * const)) 0x555555556bf2 <Log::doWork()>, 
    __t=@0x555555571d68: 0x555555571b40) at /usr/include/c++/11/bits/invoke.h:74
#3  0x0000555555558cd1 in std::__invoke<void (Log::*)(), Log*> (
    __fn=@0x555555571d70: (void (Log::*)(Log * const)) 0x555555556bf2 <Log::doWork()>)
    at /usr/include/c++/11/bits/invoke.h:96
#4  0x0000555555558c31 in std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> >::_M_invoke<0ul, 1ul> (
    this=0x555555571d68) at /usr/include/c++/11/bits/std_thread.h:259
#5  0x0000555555558be6 in std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> >::operator() (this=0x555555571d68)
    at /usr/include/c++/11/bits/std_thread.h:266
#6  0x0000555555558bc6 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> > >::_M_run (this=0x555555571d60) at /usr/include/c++/11/bits/std_thread.h:211
#7  0x00007ffff7e58253 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007ffff7bc7ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9  0x00007ffff7c59850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The same issue occurs on two systems with the same software configuration, but different CPU architectures.

If the opening of the log is moved to the initializer (which requires reordering log_ to be declared before worker_), the error vanishes. However, this prevents using the thread ID as part of the filename.

I am writing a multithreaded program in which each thread opens its own text file for primitive debug logging. Each thread is represented by a separate instance of a class, which manages both the std::thread object and the std::ofstream object, as well as the main execution loop for the thread.

While debugging other aspects of the program, I noticed that a segfault occurs when opening the log file, but only when the gdb debugger is active. Furthermore, this only seems to occur when there are more threads than CPU cores on the system.

A simple code example is below:

#include <chrono>
#include <fstream>
#include <memory>
#include <thread>
#include <vector>

class Log final{
    private:
        int i_;
    
        std::thread worker_;
        
        std::ofstream log_;
    
    public:
        Log(int i) : i_(i), worker_(&Log::doWork, this) {};
        
        ~Log(){
            worker_.join();
        }
    
    private:
        void doWork(){
            log_ = std::ofstream(
                std::to_string(i_)
                + "_"
                + std::to_string(std::hash<std::thread::id>{}(std::this_thread::get_id()))
                + ".log"
            );
            

            for (int i = 0 ; i < 999999 ; ++i){
                log_ << i << '\n';
            }
            
            log_.close();
        }
};

int main (void){
    std::vector<std::unique_ptr<Log>> vec;
    
    for (int i = 0 ; i < 50 ; ++i){
        auto l = std::make_unique<Log>(i);
        
        vec.emplace_back(std::move(l));
    }
    
    return 0;
}

This is compiled on GCC (g++) 11.4.0, with the following options:

-std=c++17 -g

Running with gdb 12.1 produces the following backtrace:

#0  0x00007ffff7e94f17 in std::basic_ofstream<char, std::char_traits<char> >::operator=(std::basic_ofstream<char, std::char_traits<char> >&&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0000555555556d07 in Log::doWork (this=0x555555571b40) at log:30
#2  0x0000555555558d4f in std::__invoke_impl<void, void (Log::*)(), Log*> (
    __f=@0x555555571d70: (void (Log::*)(Log * const)) 0x555555556bf2 <Log::doWork()>, 
    __t=@0x555555571d68: 0x555555571b40) at /usr/include/c++/11/bits/invoke.h:74
#3  0x0000555555558cd1 in std::__invoke<void (Log::*)(), Log*> (
    __fn=@0x555555571d70: (void (Log::*)(Log * const)) 0x555555556bf2 <Log::doWork()>)
    at /usr/include/c++/11/bits/invoke.h:96
#4  0x0000555555558c31 in std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> >::_M_invoke<0ul, 1ul> (
    this=0x555555571d68) at /usr/include/c++/11/bits/std_thread.h:259
#5  0x0000555555558be6 in std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> >::operator() (this=0x555555571d68)
    at /usr/include/c++/11/bits/std_thread.h:266
#6  0x0000555555558bc6 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Log::*)(), Log*> > >::_M_run (this=0x555555571d60) at /usr/include/c++/11/bits/std_thread.h:211
#7  0x00007ffff7e58253 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007ffff7bc7ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9  0x00007ffff7c59850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The same issue occurs on two systems with the same software configuration, but different CPU architectures.

If the opening of the log is moved to the initializer (which requires reordering log_ to be declared before worker_), the error vanishes. However, this prevents using the thread ID as part of the filename.

• gdb
• c++17
• ofstream
• stdthread

Share Improve this question Follow asked Jan 17 at 20:18 user18user18 33111 silver badge1111 bronze badges 4

• 1 You should try out "address sanitizer", "thread sanitizer" and "undefined behaviour sanitizer" - they may very well point out where you have a bug. – Jesper Juhl Commented Jan 17 at 20:22
• 2 log_ is not guaranteed to be constructed before you assign to it. – Howard Hinnant Commented Jan 17 at 20:51
• @JesperJuhl -fsanitize=address gives no help. -fsanitize=thread and -fsanitize=undefined just point me to the same assignment as the gdb trace – user18 Commented Jan 17 at 21:30
• @HowardHinnant Yes, this explains it! Moving the thread creation to the constructor body fixes things. If you write this up as an answer, I will accept it. – user18 Commented Jan 17 at 21:31

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

log_ is not guaranteed to be constructed before you assign to it.

本文标签： c17stdofstream assignment operatorsegfault only occurs in gdbStack Overflow