std :: thread вызывает ошибку сегментации в Raspbian с использованием gcc-linaro-4.9.4 - PullRequest
Новая
       33

std :: thread вызывает ошибку сегментации в Raspbian с использованием gcc-linaro-4.9.4

9 голосов
/ 14 марта 2019

Я получаю ошибку сегментации в коде, который выглядит для меня совершенно правильным.

Вот минимальный воссоздающий пример: 

#include <iostream>
#include <thread>

void func()
{
    /* do nothing; thread contents are irrelevant */
}

int main()
{
    for (unsigned idx = 0; idx < 1000; idx++)
    {
        std::thread t(func);
        void* buffer = malloc(1000);
        free(buffer);
        t.join();
    }
    return 0;
}

Я сделал пробежку с отпечатками, чтобы проверить, какая итерация не удалась; Я получил ошибку сегментации на итерации # 292.

Я использовал gcc-linaro-4.9.4 (взято отсюда: https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/arm-linux-gnueabihf/).

Я скомпилировал программу следующим образом: 

arm-linux-gnueabihf-g++ -std=c++11 -std=gnu++11 -lpthread -pthread main.cpp -o main.out

Я пытался воссоздать это в gcc-linaro-6.5, и у меня там не было проблем.

Есть идеи, почему это происходит?

Редактировать 1

При компиляции этого кода нет предупреждений / ошибок.

Запуск его под strace ничего особенного не открывает.

Запуск его под GDB показывает, что ошибки сегментации происходят в функции free: 

Thread 1 "main.out" received signal SIGSEGV, Segmentation fault.
_int_free (av=0x76d84794 <main_arena>, p=0x1e8bf, have_lock=0) at malloc.c:4043
4043    malloc.c: No such file or directory.
(gdb) bt
#0  _int_free (av=0x76d84794 <main_arena>, p=0x1e8bf, have_lock=0) at malloc.c:4043
#1  0x00010bfa in main ()

Запуск его под Valgrind показывает следующее: 

==361== Thread 2:
==361== Invalid read of size 4
==361==    at 0x4951D64: ??? (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==361==  Address 0x4becf74 is 0 bytes after a block of size 28 alloc'd
==361==    at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361==    by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361== 
==361== Invalid write of size 4
==361==    at 0x4951D6C: ??? (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==361==  Address 0x4becf74 is 0 bytes after a block of size 28 alloc'd
==361==    at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361==    by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361== 
==361== 
==361== HEAP SUMMARY:
==361==     in use at exit: 28,000 bytes in 1,000 blocks
==361==   total heap usage: 2,002 allocs, 1,002 frees, 1,048,368 bytes allocated
==361== 
==361== Thread 1:
==361== 28,000 bytes in 1,000 blocks are definitely lost in loss record 1 of 1
==361==    at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361==    by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361== 
==361== LEAK SUMMARY:
==361==    definitely lost: 28,000 bytes in 1,000 blocks
==361==    indirectly lost: 0 bytes in 0 blocks
==361==      possibly lost: 0 bytes in 0 blocks
==361==    still reachable: 0 bytes in 0 blocks
==361==         suppressed: 0 bytes in 0 blocks
==361== 
==361== For counts of detected and suppressed errors, rerun with: -v
==361== ERROR SUMMARY: 2017 errors from 3 contexts (suppressed: 6 from 3)

редактировать 2

Я по-прежнему получаю ошибку сегментации после удаления флагов компиляции -lpthread и -std=c++11. Вот как я это скомпилировал на этот раз: 

arm-linux-gnueabihf-g++ -std=gnu++11 -pthread main.cpp -o main.out

1 Ответ

0 голосов
/ 20 июня 2019

Я думаю, что проблема заключается в несоответствии между вашим кодом и библиотекой libstdc++.so, на которую вы ссылаетесь.

Одна из возможностей заключается в том, что во время выполнения используется неправильный libstdc++.so, который вы можете проверитьс помощью утилиты ldd.Верной версией для GCC 4.9.4 является libstdc++.so.6.0.20, поэтому, если вы видите, что она связана с другой версией, это проблема.

Вторая возможность - это правильная libstdc++.so, но она компилируется с другиминастройки из вашего кода, и поэтому std::thread в вашем коде использует атомарные операции для shared_ptr подсчета ссылок, но std::thread в библиотеке использует мьютекс (что является такой же проблемой, как описано в GCC Bug 42734)).Если сбой и ошибки valgrind исчезнут при компиляции вашей программы с помощью -march=armv5t, это подтвердит, что это проблема.

...