LINUX.ORG.RU
решено Форум — Development  

segfault после new

 , ,


0

3

Здравствуйте.

Имеется приложение, которое после вызова new падает с segfault. Проблема в том, что падает не в одном и том же месте, а в разных местах, но всегда при аллокации памяти.

Как я понимаю, проблема в том, что где-то бьётся куча, и при очередном выделнии памяти становится всё плохо.

Пробовал гонять valgrind - результаты нулевые: всего лишь показывает stacktrace.

Как узнать, в чём причина падений?

Выдача valgrind: 

valgrind --tool=memcheck --leak-check=full  ./yagf
==3388== Memcheck, a memory error detector
==3388== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3388== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==3388== Command: ./yagf
==3388== 
QMetaObject::connectSlotsByName: No matching signal for on_actionSelect_HTML_format_activated()
QMetaObject::connectSlotsByName: No matching signal for on_actionCheck_spelling_activated()
QMetaObject::connectSlotsByName: No matching signal for on_actionSave_block_activated()
QMetaObject::connectSlotsByName: No matching signal for on_actionSave_current_image_activated()
QMetaObject::connectSlotsByName: No matching signal for on_actionRecognize_block_activated()
QMetaObject::connectSlotsByName: No matching signal for on_ActionDeleteBlock_activated()
QMetaObject::connectSlotsByName: No matching signal for on_ActionClearAllBlocks_activated()
We got some errors while running testparm "Load smb config files from /etc/samba/smb.conf\nLoaded services file OK.\nWARNING: The 'netbios name' is too long (max. 15 chars).\n\n"
==3388== Syscall param writev(vector[...]) points to uninitialised byte(s)
==3388==    at 0x6D9296D: ??? (syscall-template.S:84)
==3388==    by 0x9557F28: write_vec (xcb_conn.c:257)
==3388==    by 0x9557F28: _xcb_conn_wait (xcb_conn.c:502)
==3388==    by 0x955831C: _xcb_out_send (xcb_out.c:399)
==3388==    by 0x9558A76: _xcb_out_flush_to (xcb_out.c:423)
==3388==    by 0x9558C43: xcb_flush (xcb_out.c:358)
==3388==    by 0x412AB92: QXcbWindow::setCursor(unsigned int) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x4135EE1: ??? (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x55CCDC9: QWindowPrivate::setCursor(QCursor const*) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x4FC6AEE: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4FD0F78: QWidget::setCursor(QCursor const&) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x1416BC05: ??? (in /usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.28.0)
==3388==    by 0x5CFFBEB: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==  Address 0xd7ea1c6 is 4,582 bytes inside a block of size 21,152 alloc'd
==3388==    at 0x4C2EB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3388==    by 0x95578DB: xcb_connect_to_fd (xcb_conn.c:325)
==3388==    by 0x955B610: xcb_connect_to_display_with_auth_info (xcb_util.c:523)
==3388==    by 0x75FF7E9: _XConnectXCB (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==3388==    by 0x75F0361: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==3388==    by 0x41172F3: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x411A9BD: QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x40294AC: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so)
==3388==    by 0x55ABC3C: QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x55BA2E4: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x55BB0FC: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x5CD86FE: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388== 
("/media/zamazan4ik/For_Linux/Photo/6.png")
QImage(QSize(580, 330),format=5,depth=32,devicePixelRatio=1,bytesPerLine=2320,byteCount=765600)
191400
==3388== Invalid write of size 1
==3388==    at 0x1E7EBA: QIPGrayscaleImage::toGrayscaleMinOrMaxInternal(QImage const&, IntRect const&, bool) (qipgrayscaleimage.cpp:1587)
==3388==    by 0x1E7D90: QIPGrayscaleImage::toGrayscaleMinOrMax(QImage const&, bool) (qipgrayscaleimage.cpp:1564)
==3388==    by 0x1E1743: QIPGrayscaleImage::QIPGrayscaleImage(QImage const&, QIPGrayscaleImage::GrayscaleConversion) (qipgrayscaleimage.cpp:66)
==3388==    by 0x1D2221: ImageProcessor::loadImage(QImage const&) (imageprocessor.cpp:68)
==3388==    by 0x1C677E: Page::loadFile(QString, int, bool) (page.cpp:105)
==3388==    by 0x1CDA66: PageCollection::appendPage(QString const&) (tpagecollection.cpp:57)
==3388==    by 0x17583D: MainForm::loadFile(QString const&, bool) (mainform.cpp:720)
==3388==    by 0x172A3B: MainForm::loadFiles(QStringList const&) (mainform.cpp:294)
==3388==    by 0x17456C: MainForm::loadImage() (mainform.cpp:547)
==3388==    by 0x1FAC8B: MainForm::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_mainform.cpp:357)
==3388==    by 0x5CFFB48: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x4F8C301: QAction::triggered(bool) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==  Address 0x1f43a868 is 0 bytes after a block of size 24 alloc'd
==3388==    at 0x4C2D1AF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3388==    by 0x1E11DA: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) (new_allocator.h:104)
==3388==    by 0x1E1002: std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) (alloc_traits.h:416)
==3388==    by 0x1E0DD9: std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >&) (allocated_ptr.h:103)
==3388==    by 0x1E9DC6: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<unsigned char, std::allocator<unsigned char>, int>(std::_Sp_make_shared_tag, unsigned char*, std::allocator<unsigned char> const&, int&&) (shared_ptr_base.h:613)
==3388==    by 0x1E9D0D: std::__shared_ptr<unsigned char, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<unsigned char>, int>(std::_Sp_make_shared_tag, std::allocator<unsigned char> const&, int&&) (shared_ptr_base.h:1100)
==3388==    by 0x1E9BED: std::shared_ptr<unsigned char>::shared_ptr<std::allocator<unsigned char>, int>(std::_Sp_make_shared_tag, std::allocator<unsigned char> const&, int&&) (shared_ptr.h:319)
==3388==    by 0x1E9439: std::shared_ptr<unsigned char> std::allocate_shared<unsigned char, std::allocator<unsigned char>, int>(std::allocator<unsigned char> const&, int&&) (shared_ptr.h:620)
==3388==    by 0x1E8E44: std::shared_ptr<unsigned char> std::make_shared<unsigned char, int>(int&&) (shared_ptr.h:636)
==3388==    by 0x1E1680: QIPGrayscaleImage::QIPGrayscaleImage(QImage const&, QIPGrayscaleImage::GrayscaleConversion) (qipgrayscaleimage.cpp:53)
==3388==    by 0x1D2221: ImageProcessor::loadImage(QImage const&) (imageprocessor.cpp:68)
==3388==    by 0x1C677E: Page::loadFile(QString, int, bool) (page.cpp:105)
==3388== 
--3388-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--3388-- si_code=1;  Faulting address: 0xFFFFFFFFFFFFFFFF;  sp: 0x802daddf0

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==3388==    at 0x38095231: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==3388==    by 0x3809724A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==3388==    by 0x38051EF4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==3388==    by 0x3805214D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==3388==    by 0x380E05A3: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==3388==    by 0x380EF820: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 3388)
==3388==    at 0x4C2D1AF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3388==    by 0x1E11DA: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) (new_allocator.h:104)
==3388==    by 0x1E1002: std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) (alloc_traits.h:416)
==3388==    by 0x1E0DD9: std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<unsigned char, std::allocator<unsigned char>, (__gnu_cxx::_Lock_policy)2> >&) (allocated_ptr.h:103)
==3388==    by 0x1E0BC4: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<unsigned char, std::allocator<unsigned char>, unsigned int>(std::_Sp_make_shared_tag, unsigned char*, std::allocator<unsigned char> const&, unsigned int&&) (shared_ptr_base.h:613)
==3388==    by 0x1E0A47: std::__shared_ptr<unsigned char, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<unsigned char>, unsigned int>(std::_Sp_make_shared_tag, std::allocator<unsigned char> const&, unsigned int&&) (shared_ptr_base.h:1100)
==3388==    by 0x1E0907: std::shared_ptr<unsigned char>::shared_ptr<std::allocator<unsigned char>, unsigned int>(std::_Sp_make_shared_tag, std::allocator<unsigned char> const&, unsigned int&&) (shared_ptr.h:319)
==3388==    by 0x1E07BB: std::shared_ptr<unsigned char> std::allocate_shared<unsigned char, std::allocator<unsigned char>, unsigned int>(std::allocator<unsigned char> const&, unsigned int&&) (shared_ptr.h:620)
==3388==    by 0x1E05BA: std::shared_ptr<unsigned char> std::make_shared<unsigned char, unsigned int>(unsigned int&&) (shared_ptr.h:636)
==3388==    by 0x1DEDBC: QIPBlackAndWhiteImage::QIPBlackAndWhiteImage(unsigned int, unsigned int) (qipblackandwhiteimage.cpp:37)
==3388==    by 0x1E67AA: QIPGrayscaleImage::otsuBinarizeMA() const (qipgrayscaleimage.cpp:1219)
==3388==    by 0x1E3115: QIPGrayscaleImage::binarize(QIPGrayscaleImage::BinarizationMethod) const (qipgrayscaleimage.cpp:455)
==3388==    by 0x1D203D: ImageProcessor::crop() (imageprocessor.cpp:50)
==3388==    by 0x1C67CC: Page::loadFile(QString, int, bool) (page.cpp:111)
==3388==    by 0x1CDA66: PageCollection::appendPage(QString const&) (tpagecollection.cpp:57)
==3388==    by 0x17583D: MainForm::loadFile(QString const&, bool) (mainform.cpp:720)
==3388==    by 0x172A3B: MainForm::loadFiles(QStringList const&) (mainform.cpp:294)
==3388==    by 0x17456C: MainForm::loadImage() (mainform.cpp:547)
==3388==    by 0x1FAC8B: MainForm::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_mainform.cpp:357)
==3388==    by 0x5CFFB48: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x4F8C301: QAction::triggered(bool) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4F8EEFF: QAction::activate(QAction::ActionEvent) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x5095BBC: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x5095DF3: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x5163709: QToolButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4FDB497: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x51637E8: QToolButton::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4F958AB: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4F9BC06: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x5CD23AF: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x4F9A2D4: QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4FF5AD5: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4FF86D2: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4F958AB: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x4F9AD4E: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.6.1)
==3388==    by 0x5CD23AF: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x55C15F2: QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x55C2E04: QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x55A0B2A: QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.6.1)
==3388==    by 0x414965F: ??? (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x72F97D6: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==3388==    by 0x72F9A3F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==3388==    by 0x72F9AEB: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==3388==    by 0x5D2848E: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x5CD00F9: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x5CD890B: QCoreApplication::exec() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x16F9E2: main (main.cpp:88)

Thread 2: status = VgTs_WaitSys (lwpid 3392)
==3388==    at 0x6D910BD: ??? (syscall-template.S:84)
==3388==    by 0x9557C61: poll (poll2.h:46)
==3388==    by 0x9557C61: _xcb_conn_wait (xcb_conn.c:459)
==3388==    by 0x95598D6: xcb_wait_for_event (xcb_in.c:693)
==3388==    by 0x4113298: ??? (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.6.1)
==3388==    by 0x5AFAC67: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x61D66C9: start_thread (pthread_create.c:333)
==3388==    by 0x6D9D0AE: clone (clone.S:105)

Thread 3: status = VgTs_WaitSys (lwpid 3397)
==3388==    at 0x6D910BD: ??? (syscall-template.S:84)
==3388==    by 0x72F99D5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==3388==    by 0x72F9AEB: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==3388==    by 0x5D2848E: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x5CD00F9: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x5AF5D42: QThread::exec() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x102B4574: ??? (in /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.6.1)
==3388==    by 0x5AFAC67: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.6.1)
==3388==    by 0x61D66C9: start_thread (pthread_create.c:333)
==3388==    by 0x6D9D0AE: clone (clone.S:105)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Исходный код: https://github.com/ZaMaZaN4iK/ufocr

Если кому захочется поковыряться, то засылайте пулл-реквест.

UPD: теперь падает и на gcc и на clang

★★

Последнее исправление: zamazan4ik (всего исправлений: 4)

 ← 1 2 →
Ответ на: комментарий от zamazan4ik

Может быть тем, что в коде где-то UB, в одном компиляторе одно поведение, в другом — другое.

Возможно, какая-то переменная, которая не инициализируется при объявлении, затем используется в качестве индекса для модификации данных. В зависимости от компилятора у нее могут быть разные начальные значения.

Еще ошибки с new/delete часто провоцируются неправильным освобождением оной. Повторный delete или delete для невалидного указателя и потом на любой операции new/delete можно ожидать проблем.

eao197 ★★★★★
()

По описанию это heap corruption.

Нужно пробовать -fsanitize=undefined -fsanitize=address и -D_GLIBCXX_DEBUG.

asaw ★★★★★
()

Пробовал гонять valgrind - результаты нулевые: всего лишь показывает stacktrace.

В gcc и clang есть всякие санитайзеры (см . -fsanitize), мб помогут address и thread

mashina ★★★★★
()
Ответ на: комментарий от i_gnatenko_brain

https://github.com/ZaMaZaN4iK/ufocr Конкретно проблемы начинаются в bool Page::loadFile(QString fileName, int tiled, bool loadIntoView);

Если что, это форк yagf. По CmakeLists.txt думаю понятно, что нужно для того, чтобы сбилдить: требуется aspell + Qt5

zamazan4ik ★★
() автор топика
Последнее исправление: zamazan4ik (всего исправлений: 1)
Ответ на: комментарий от zamazan4ik

if (fileName == "")

if (fileName.isEmpty())?

if (!fileName.endsWith(".ygf", Qt::CaseInsensitive))

QFileInfo::suffix()

Вы не проверяете существует ли ccbuilder в деструкторе.

Код конечно жесть. Понять, что вы делаете и в чём проблема - очень сложно. Есть же valgrind, он должен подсказать вам об проблемах с памятью.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

код не мой - и то, что он жесть, я полностью согласен. Там ОЧЕНЬ страшный код. Я его причешу, но для начал стоит сделать его более-менее рабочим.

Проблема вроде как не в ccbuilder.

а valgrind --tool=memcheck --leak-check=full что-то мне только stacktrace показывает, и ничего более полезного.

zamazan4ik ★★
() автор топика
Последнее исправление: zamazan4ik (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

да, у меня тут тоже иногда падает. Но не всегда. Бывает чуть раньше и чуть позже по коду. Но всегда на аллокациях или обращении к памяти.

И вот как править это, понятия не имею. Бьюсь уже четвёртый день.

zamazan4ik ★★
() автор топика
Последнее исправление: zamazan4ik (всего исправлений: 1)

Странно както, вообще валгринд места которые ломают кучу отлавливает всегда (по крайней мере я не помню случаев когда он не ловил). Да у вас тут и не куча (иначе бы new ушел бы в malloc и там упал). Тут либо совсем жесть какаято (вроде кривой матемитики с поитерами которые в stl алокаторы заходят)

Либо (что более вероятно) проект собирается / линкуется с разными версиями STL (например часть собрана как с++0 а часть как с++14).

zaz ★★★★
()
Ответ на: комментарий от zamazan4ik

Собираете основным дистрибутивным GCC которым и QT/система собрана ? Так как в моей генте GCC 4.9.3 эти сорци собирать не хочет ...

zaz ★★★★
()

такое овно хорошо отлавливали интелловские утильки для проверки памяти, которые с Intel Parallel Studio шли. но сейчас они вроде небесплатные, точнее, бесплатные отнюдь не для всех, нужны какие-то подтверждения. но тулзы там мощные.

но вообще лучше с таким кодом не связываться. это очень нехорошие тараканы.

Iron_Bug ★★★★★
()
Ответ на: комментарий от zamazan4ik

а в чём может быть, что причины все снимаются сразу же тем, что я меняю компил на clang?

Возможно, ты наткнулся на очередной баг в GCC. Такое бывает. Но гораздо более вероятно, что тебе всё таки надо взять GDB, сделать bt, посмотреть при каком обращении к памяти всё валится и оттуда уже копать.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Iron_Bug

но вообще лучше с таким кодом не связываться. это очень нехорошие тараканы.

Обычный говнокод на C++ от обычных говнокодеров. В мире C++ таких 92.5%.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Про баг в GCC я не верю - компиляторы нужно ругать в последнюю очередь.

Так проблема в том, что нет того единого обращения к памяти, при котором ломается всё. Программа при одних и тех же входных данных валится в разных местах. Но всегда на аллокациях памяти или обращении к памяти через указатель.

zamazan4ik ★★
() автор топика
Ответ на: комментарий от hateyoufeel

неа, это код какого-то необычного говнокодера. Это просто феерический код.

zamazan4ik ★★
() автор топика
Ответ на: комментарий от zamazan4ik

У вас явно QT (или какаято друга С++ либа) собрана с STL не той версии который в GCC 6.2.0, похоже что в clang STL более совместим. Попробуйте все C++ либы (как минимум QT) собрать отдельно статикой (нужным компилером, с одинаковыми ключами) и линковатся с ними - должно помочь

zaz ★★★★
()
Ответ на: комментарий от zamazan4ik

Можете, только какие ?

Для большей надежности лутчше пересобрать QT рабочим компилером.

zaz ★★★★
()
Ответ на: комментарий от zamazan4ik

Про баг в GCC я не верю - компиляторы нужно ругать в последнюю очередь.

Зря.

Но всегда на аллокациях памяти или обращении к памяти через указатель.

Возможно, кто-то засирает память аллокатора и после этого тот либо сам валится, либо выдаёт левый указатель вместо очередного чанка.

hateyoufeel ★★★★★
()
Ответ на: комментарий от zaz

У вас явно QT ... собрана с STL не той версии который в GCC 6.2.0, похоже что в clang STL более совместим.

clang, внезапно, использует stl из gcc, нужно провести несколько акрабатических этюдов чтобы подсунуть ему другой STL.

mashina ★★★★★
()
Ответ на: комментарий от mashina

Я подозреваю что QT пришел в бинарном виде из реп дистра, и не факт что он собран с темиже ключами и тойже версией GCC которой пользуется ТС. Там внутри STL куча #if поэтому даже если сорцы били физически одни и теже, не факт что бинарники будут совместимы.

Вообще с вводом новых стандартов (11,14,17) опять началась каша с бинарной совместимостью, вспоминаются времена GCC 2.9x / 3.x когда меняли ABI и на каждом абдейте GCC приходилось пересобирать все плюсовое в системе.

Может быть расширяли дефайнами или самим компиллером STD неймспейс до какойто версионности (вроде std_g11, std_g17). Или в бинарник пихали марку с какой версией STL он собран чтоб проблемы можно было проще отслеживать ...

zaz ★★★★
()
Ответ на: комментарий от Iron_Bug

мне кажется, что это не совсем тот случай.

zamazan4ik ★★
() автор топика

теперь программа падает и на clang. Чертовщина какая-то

zamazan4ik ★★
() автор топика
Ответ на: комментарий от x905

Уоу, проблема решена. Скажите пожалуйста, в чём причина? Выделяя же память через std::make_shared я по сути тоже буфер делаю и всё.

zamazan4ik ★★
() автор топика
Последнее исправление: zamazan4ik (всего исправлений: 1)

в порядке, взял gpl код, вытер всю предыдущую историю, переименовал, вытер все копирайты и приписал на себя, еще бы лицензию изменил

hizel ★★★★★
()
Ответ на: комментарий от hizel

Историю никто не вытирал. В репу пока что не положил просто ссылку на информацию о предыдущем проекте. Копирайты потёрты лишь для того, потому что это курсач. Позже верну. Но полностью согласен - так делать нельзя. Но ссылку на проект я оставлю обязательно.

zamazan4ik ★★
() автор топика
Последнее исправление: zamazan4ik (всего исправлений: 1)
Ответ на: комментарий от zamazan4ik

а по-моему так вот прямо именно он. там у них внутрях тупо размер евента меньше 32, а xcb ожидает 32 байта по определению, это размер евента X11.

естественно, копируется непроинициализированный кусок памяти. с произвольными последствиями.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Проблема решена с помощью замены std::shared_ptr на QByteArray. Почему этот фикс работает - это ещё надо посмотреть.

zamazan4ik ★★
() автор топика
Ответ на: комментарий от zamazan4ik

Скажите пожалуйста, в чём причина?

я точно не скажу, но возможно двойное удаление

QByteArray обеспечивает implicit sharing и copy on write, так что потерь производительности быть не должно

x905 ★★★★★
()
Ответ на: комментарий от x905

Странно, что двойное удаление, так как копирующие конструкторы и операторы присваивания не менял. То есть как копировались указатели по значению, так копируются и массивы (ну если COW есть, то вообще всё супер). То есть по логике вещей при каждом копировании указателя просто должен увеличиваться счётчик и никакого преждевременного удаления быть не должно. Циклических ссылок тоже вроде не получалось (хотя тут могу ошибаться).

zamazan4ik ★★
() автор топика
Ответ на: комментарий от anonymous

надо же название придумать какое-то. Первое, что в голову пришло.

zamazan4ik ★★
() автор топика
Ответ на: комментарий от Iron_Bug

ну а что делать, если прогу нужно заставить работать? :)

zamazan4ik ★★
() автор топика
Ответ на: комментарий от zamazan4ik

Почему этот фикс работает

Возможно, потому, что ты не подсунул shared_ptr'у кастомный deleter. Умолчательный удаляет объект оператором delete, а массивы надо удалять оператором delete[].

Если хочешь shared_prt с массивом, делай так:

std::shared_ptr<uint8_t> data;
data = {new uint8_t[n], std::default_delete<uint8_t[]>()};

В gcc 7 должны добавить специализацию shared_ptr<T[]>, может, она уже есть в каком нибудь <experimental/memory> в неймспейсе std::experimental.

Я код не читал, мне страшно, так что это только предположения.

Esper ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Development