[fixed] Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 15:15
Оценка:
fixed
Автор: Sheridan
Дата: 20.12.18


  Вопрос тут
Камрады, ай нид хелп. Не могу понять в чом дело. У меня тут есть логгер, который крашится в рантайме но в дебаге но полезного нет почти.
При запущенной валгринд с мемчеком — не крашится.
Принцип такой: при добавлении строки оно открывает ofstream в файл, пишет туда строку, закрывает.
Крашится как раз на открытии ofstream
m_logstream.open(m_filename, std::ofstream::out | std::ofstream::ate | std::ofstream::app);


m_filename — std::string
m_logstream — std::ofstream

Через раз показывает причину: 
malloc_consolidate(): invalid chunk size


Я предполагал что это краш в другом потоке, но уже дважды всё там переписал — не должно
Ну и крашится на вызове логгера из деструктора объекта. При этом оно к объекту самому разрушаемому не обращается
сам логгер — синглтон, создаётся при первом обращении, удаляется при выходе из приложения

Полный стек вызовов, крашится в Thread 1:

Thread 7 (Thread 0x7fffc68e1700 (LWP 31402)):
#0  0x00007ffff595b6c6 in ppoll () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff36ab901 in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
No symbol table info available.
#2  0x00007ffff36abf10 in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
No symbol table info available.
#3  0x00007ffff780c2a7 in PULSEAUDIO_WaitDevice () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#4  0x00007ffff779442e in SDL_RunAudio () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#5  0x00007ffff779375c in SDL_RunThread () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#6  0x00007ffff7809ac9 in RunThread () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#7  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8  0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 6 (Thread 0x7fffd72e2700 (LWP 31401)):
#0  0x00007ffff5c3d30c in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00007ffff5c357a2 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2  0x00007ffff73401cf in Urho3D::WorkQueue::ProcessItems(unsigned int) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#3  0x00007ffff7339f1a in Urho3D::ThreadFunctionStatic(void*) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#4  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 5 (Thread 0x7fffd7ae3700 (LWP 31400)):
#0  0x00007ffff5c3d30c in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00007ffff5c357a2 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2  0x00007ffff73401cf in Urho3D::WorkQueue::ProcessItems(unsigned int) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#3  0x00007ffff7339f1a in Urho3D::ThreadFunctionStatic(void*) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#4  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 4 (Thread 0x7fffd82e4700 (LWP 31399)):
#0  0x00007ffff5c3d30c in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00007ffff5c357a2 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2  0x00007ffff73401cf in Urho3D::WorkQueue::ProcessItems(unsigned int) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#3  0x00007ffff7339f1a in Urho3D::ThreadFunctionStatic(void*) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#4  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 3 (Thread 0x7fffdbfff700 (LWP 31398)):
#0  0x00007ffff5c3e138 in nanosleep () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00000000004b0f90 in std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > (__rtime=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/thread:376
        __s = {__r = 0}
        __ns = {__r = 100000000}
        __ts = {tv_sec = 0, tv_nsec = 36163799}
#2  0x00000000004b06b5 in eing::world::CWorld::worldThread (this=0x7b4640) at ../../../src/world/cworld.cpp:89
No locals.
#3  0x00000000004b2e41 in std::__invoke_impl<void, void (eing::world::CWorld::*)(), eing::world::CWorld*> (__f=@0x839ac0: (void (eing::world::CWorld::*)(eing::world::CWorld * const)) 0x4b0660 <eing::world::CWorld::worldThread()>, __t=@0x839ab8: 0x7b4640) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/bits/invoke.h:73
No locals.
#4  0x00000000004b2d52 in std::__invoke<void (eing::world::CWorld::*)(), eing::world::CWorld*> (__fn=@0x839ac0: (void (eing::world::CWorld::*)(eing::world::CWorld * const)) 0x4b0660 <eing::world::CWorld::worldThread()>, __args=@0x839ab8: 0x7b4640) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/bits/invoke.h:95
No locals.
#5  0x00000000004b2d12 in std::thread::_Invoker<std::tuple<void (eing::world::CWorld::*)(), eing::world::CWorld*> >::_M_invoke<0ul, 1ul> (this=0x839ab8) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/thread:234
No locals.
#6  0x00000000004b2cc5 in std::thread::_Invoker<std::tuple<void (eing::world::CWorld::*)(), eing::world::CWorld*> >::operator() (this=0x839ab8) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/thread:243
No locals.
#7  0x00000000004b2a99 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (eing::world::CWorld::*)(), eing::world::CWorld*> > >::_M_run (this=0x839ab0) at /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/thread:186
No locals.
#8  0x00007ffff6142f0e in std::execute_native_thread_routine (__p=0x839ab0) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/src/c++11/thread.cc:83
        __t = {_M_t = {_M_t = {<std::_Tuple_impl<0, std::thread::_State*, std::default_delete<std::thread::_State> >> = {<std::_Tuple_impl<1, std::default_delete<std::thread::_State> >> = {<std::_Head_base<1, std::default_delete<std::thread::_State>, true>> = {<std::default_delete<std::thread::_State>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0, std::thread::_State*, false>> = {_M_head_impl = 0x839ab0}, <No data fields>}, <No data fields>}}}
#9  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 2 (Thread 0x7ffff7fed700 (LWP 31397)):
#0  0x00007ffff595b6c6 in ppoll () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff36ab901 in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
No symbol table info available.
#2  0x00007ffff36abf10 in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
No symbol table info available.
#3  0x00007ffff36abfa0 in pa_mainloop_run () from /usr/lib64/libpulse.so.0
No symbol table info available.
#4  0x00007ffff780c40f in HotplugThread () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#5  0x00007ffff779375c in SDL_RunThread () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#6  0x00007ffff7809ac9 in RunThread () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#7  0x00007ffff5c3296a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8  0x00007ffff59671af in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 1 (Thread 0x7ffff7f830c0 (LWP 31391)):
#0  0x00007ffff589976b in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff589afb1 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ffff58e02e7 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007ffff58e8038 in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007ffff58e83be in malloc_consolidate () from /lib64/libc.so.6
No symbol table info available.
#5  0x00007ffff58eb1d8 in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#6  0x00007ffff58eceaa in malloc () from /lib64/libc.so.6
No symbol table info available.
#7  0x00007ffff6116418 in operator new (sz=8192) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/libsupc++/new_op.cc:50
        p = <optimized out>
#8  0x00007ffff61164c5 in operator new[] (sz=<optimized out>) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/libsupc++/new_opv.cc:32
No locals.
#9  0x00007ffff617b6f8 in std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer (this=0x794ec8) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:55
        this = 0x794ec8
#10 0x00007ffff617fd12 in std::basic_filebuf<char, std::char_traits<char> >::open (this=0x794ec8, __s=0x795800 "logs/cube_helper/2018-12-16_18-12-02.application.log", __mode=19) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:187
        __ret = 0x0
        __s = 0x795800 "logs/cube_helper/2018-12-16_18-12-02.application.log"
        __mode = 19
        this = 0x794ec8
        __ret = <optimized out>
        __ret = 0x0
#11 0x00007ffff617fe43 in std::basic_filebuf<char, std::char_traits<char> >::open (__mode=<optimized out>, __s=..., this=0x794ec8) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/fstream:308
No locals.
#12 std::basic_ofstream<char, std::char_traits<char> >::open (this=0x794ec0, __s=..., __mode=<optimized out>) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/fstream:823
No locals.
#13 0x00000000004aef98 in eing::tools::logger::CLogger::start (this=0x794e80) at ../../../src/tools/logger/clogger.cpp:63
        time = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7958d0 "P\223\330\367\377\177"}, _M_string_length = 7949920, {_M_local_buf = "\320\\y\000\000\000\000\000\200\006\365\000\000\000\000", _M_allocated_capacity = 7953616}}
#14 0x00000000004cc16d in eing::graphic::world::CDynamicMesh::~CDynamicMesh (this=0x1073aa0) at ../../../src/graphic/world/cdynamicmesh.cpp:40
No locals.
#15 0x000000000049692e in eing::graphic::world::CBlock::~CBlock (this=0x105d070) at ../../../src/graphic/world/cblock.cpp:48
No locals.
#16 0x0000000000496c89 in eing::graphic::world::CBlock::~CBlock (this=0x105d070) at ../../../src/graphic/world/cblock.cpp:41
No locals.
#17 0x000000000045c05f in eing_helper::cube::AppCubeHelper::redrawTestCube (this=0x77cee0) at ../../../src/applications/cube_helper/main.cpp:350
        e = @0xae6100: {_vptr.exception = 0xae61b0}
#18 0x000000000045d2af in eing_helper::cube::AppCubeHelper::HandleUpdate (this=0x77cee0, eventType=..., eventData=...) at ../../../src/applications/cube_helper/main.cpp:289
        yaw_ = 0
        pitch_ = 0
        timeStep = 0.00499999989
        MOVE_SPEED = 10
        MOUSE_SENSITIVITY = 0.100000001
#19 0x0000000000460bc7 in Urho3D::EventHandlerImpl<eing_helper::cube::AppCubeHelper>::Invoke (this=0x106aff0, eventData=...) at /usr/include/Urho3D/Physics/../Core/Object.h:315
        receiver = 0x77cee0
#20 0x00007ffff732d642 in Urho3D::Object::OnEvent(Urho3D::Object*, Urho3D::StringHash, Urho3D::HashMap<Urho3D::StringHash, Urho3D::Variant>&) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#21 0x00007ffff732e93f in Urho3D::Object::SendEvent(Urho3D::StringHash, Urho3D::HashMap<Urho3D::StringHash, Urho3D::Variant>&) () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#22 0x00007ffff734d1d7 in Urho3D::Engine::Update() () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#23 0x00007ffff735013a in Urho3D::Engine::RunFrame() () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#24 0x00007ffff7342e45 in Urho3D::Application::Run() () from /usr/lib/Urho3D/libUrho3D.so.0
No symbol table info available.
#25 0x000000000045d44a in main (argc=1, argv=0x7fffffffe018) at ../../../src/applications/cube_helper/main.cpp:378
        graphic_result = 0


Накидайте идей что это может быть? Может уже встречалось такое?...
Matrix has you...
Отредактировано 20.12.2018 19:54 Sheridan . Предыдущая версия .
Re: Крашит в дебрях std при работе с ofstream
От: lpd Черногория  
Дата: 16.12.18 15:38
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Через раз показывает причину:
S>
S>malloc_consolidate(): invalid chunk size
S>



S>Полный стек вызовов, крашится в Thread 1:
S>

Thread 1 (Thread 0x7ffff7f830c0 (LWP 31391)):
#0  0x00007ffff589976b in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff589afb1 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ffff58e02e7 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007ffff58e8038 in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007ffff58e83be in malloc_consolidate () from /lib64/libc.so.6
No symbol table info available.
#5  0x00007ffff58eb1d8 in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#6  0x00007ffff58eceaa in malloc () from /lib64/libc.so.6
No symbol table info available.
#7  0x00007ffff6116418 in operator new (sz=8192) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/libsupc++/new_op.cc:50
        p = <optimized out>
#8  0x00007ffff61164c5 in operator new[] (sz=<optimized out>) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/libsupc++/new_opv.cc:32
No locals.
#9  0x00007ffff617b6f8 in std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer (this=0x794ec8) at /data/tmp/portage/sys-devel/gcc-7.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:55
        this = 0x794ec8S>


S>Накидайте идей что это может быть? Может уже встречалось такое?...

Скорее всего, где-то проехал по памяти. Или записал в невыделенный/освобожденный участок, или два раза удалил один объект.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re: Крашит в дебрях std при работе с ofstream
От: reversecode google
Дата: 16.12.18 16:29
Оценка:
valgrind для слабаков, давайте будем угадывать
любой мемори трейсер даст ответ что вы там с памятью накрутили
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 17:39
Оценка:
Здравствуйте, reversecode, Вы писали:

R>valgrind для слабаков, давайте будем угадывать
R>любой мемори трейсер даст ответ что вы там с памятью накрутили

При запущенной валгринд с мемчеком — не крашится.

Matrix has you...
Re[3]: Крашит в дебрях std при работе с ofstream
От: reversecode google
Дата: 16.12.18 17:44
Оценка:
задача valgrind не крошится а показать проблемы с памятью
Re: Крашит в дебрях std при работе с ofstream
От: kov_serg Россия  
Дата: 16.12.18 19:15
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Крашится как раз на открытии ofstream
S>
S>m_logstream.open(m_filename, std::ofstream::out | std::ofstream::ate | std::ofstream::app);
S>

...
S>Накидайте идей что это может быть? Может уже встречалось такое?...
попробуй заменить строку m_filename на m_filename.c_str() или на std::string(m_filename)
Re[4]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 20:21
Оценка:
Здравствуйте, reversecode, Вы писали:


R>задача valgrind не крошится а показать проблемы с памятью
Ну так и не показывает
Matrix has you...
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 20:24
Оценка:
Здравствуйте, kov_serg, Вы писали:

S>>Накидайте идей что это может быть? Может уже встречалось такое?...
_>попробуй заменить строку m_filename на m_filename.c_str() или на std::string(m_filename)
Пробовал, не помогает. По разному пробовал.
Matrix has you...
Re: Крашит в дебрях std при работе с ofstream
От: rg45 СССР  
Дата: 16.12.18 20:41
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ну и крашится на вызове логгера из деструктора объекта. При этом оно к объекту самому разрушаемому не обращается
S>сам логгер — синглтон, создаётся при первом обращении, удаляется при выходе из приложения

А этот объект, в деструкторе которого все происходит, сам часом не является объектом со статическим временем жизни, живущим дольше логгера, по закону подлости? Общей константой, например, или просто глобальным объектом? Может, находится во владении какого-то другого статика?
--
Не можешь достичь желаемого — пожелай достигнутого.
Отредактировано 16.12.2018 21:16 rg45 . Предыдущая версия . Еще …
Отредактировано 16.12.2018 21:15 rg45 . Предыдущая версия .
Отредактировано 16.12.2018 21:13 rg45 . Предыдущая версия .
Отредактировано 16.12.2018 21:07 rg45 . Предыдущая версия .
Отредактировано 16.12.2018 20:46 rg45 . Предыдущая версия .
Re[3]: Крашит в дебрях std при работе с ofstream
От: tdiff  
Дата: 16.12.18 21:17
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>

S>При запущенной валгринд с мемчеком — не крашится.
asan?
Re[5]: Крашит в дебрях std при работе с ofstream
От: reversecode google
Дата: 16.12.18 21:18
Оценка:
пустой вывод и все идеально ? не верю
Re: Крашит в дебрях std при работе с ofstream
От: Erop Россия  
Дата: 16.12.18 22:40
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>сам логгер — синглтон, создаётся при первом обращении, удаляется при выходе из приложения

S>Накидайте идей что это может быть? Может уже встречалось такое?...


А объект логгера на момент крэша ещё жив?
Вообще, идея делать логгер синглетоном, создающимся по требованию, делает плохо контролируемым момент его разрушения.

При этом то, что логгеру нужно, инициализироваться по требованию, наводит на мысль, что его зовут из конструкторов статических объектов...
За одно и из деструкторов его не могут звать, часом?

Кстати, а зачем его вообще разрушают?

Можно попробовать или сделать логгер глобальным статическим объектом, задав ему высокий приоритет инициализации.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:05
Оценка:
Здравствуйте, rg45, Вы писали:

R>А этот объект, в деструкторе которого все происходит, сам часом не является объектом со статическим временем жизни, живущим дольше логгера, по закону подлости? Общей константой, например, или просто глобальным объектом? Может, находится во владении какого-то другого статика?
Нет. )
Matrix has you...
Re[4]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:06
Оценка:
Здравствуйте, tdiff, Вы писали:

T>asan?

-fsanitize=address ? Ешо не пробовал, спасибо, покручу.
Matrix has you...
Re[6]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:07
Оценка: :))
Здравствуйте, reversecode, Вы писали:

R>пустой вывод и все идеально ? не верю

Проблемы есть, но не в моём коде.
Matrix has you...
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:11
Оценка:
Здравствуйте, Erop, Вы писали:

S>>сам логгер — синглтон, создаётся при первом обращении, удаляется при выходе из приложения
S>>Накидайте идей что это может быть? Может уже встречалось такое?...


E>А объект логгера на момент крэша ещё жив?
Да.

E>Вообще, идея делать логгер синглетоном, создающимся по требованию, делает плохо контролируемым момент его разрушения.
Он не разрушается. Точнее разрушается когда сам синглтон разрушается. Всмысле есть один большой синглтон, который в себе хранит указатели на объекты, которые должны быть в единственном экземпляре. Создаёт эти объекты при первом запросе и удаляет в своём деструкторе.

E>При этом то, что логгеру нужно, инициализироваться по требованию, наводит на мысль, что его зовут из конструкторов статических объектов...
E>За одно и из деструкторов его не могут звать, часом?
Нет, первый вызов из main() вообще.

E>Кстати, а зачем его вообще разрушают?
Его не разрушают, точнее разрушают при дестрое снглтона, который дестроится при выходе из приложения. ))

E>Можно попробовать или сделать логгер глобальным статическим объектом, задав ему высокий приоритет инициализации.
Ну, собственно, так сейчас и есть. И до креша логгер успевает много чего понаписать.
Matrix has you...
Re[3]: Крашит в дебрях std при работе с ofstream
От: Erop Россия  
Дата: 16.12.18 23:26
Оценка:
Здравствуйте, Sheridan, Вы писали:

E>>За одно и из деструкторов его не могут звать, часом?
S>Нет, первый вызов из main() вообще.
А зачем тогда вся химия с синглетонами? Почему не просто статический объект?

E>>Кстати, а зачем его вообще разрушают?
S>Его не разрушают, точнее разрушают при дестрое снглтона, который дестроится при выходе из приложения. ))
Выход из приложение -- это очень долго. В частности это вызов деструкторов всех статических объектов...

S>Ну, собственно, так сейчас и есть. И до креша логгер успевает много чего понаписать.

Так значит крэш таки на этапе деструкторов статических объектов? Или в main()?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Крашит в дебрях std при работе с ofstream
От: Слава  
Дата: 16.12.18 23:33
Оценка: +1 :)
Здравствуйте, Sheridan, Вы писали:

S>Камрады, ай нид хелп. Не могу понять в чом дело. У меня тут есть логгер, который крашится в рантайме но в дебаге но полезного нет почти.
S>При запущенной валгринд с мемчеком — не крашится.

Теперь тебе понятно, почему люди сделали Java и C#, и стали писать на них?

PS: переходи на Rust.
Re[4]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:39
Оценка:
Здравствуйте, Erop, Вы писали:

E>>>За одно и из деструкторов его не могут звать, часом?
S>>Нет, первый вызов из main() вообще.
E>А зачем тогда вся химия с синглетонами? Почему не просто статический объект?
Неважно. По факту есть всего один синглтон, который один раз создаётся, один раз удаляется за время жизни приложения. Неважно как.

E>>>Кстати, а зачем его вообще разрушают?
S>>Его не разрушают, точнее разрушают при дестрое снглтона, который дестроится при выходе из приложения. ))
E>Выход из приложение -- это очень долго. В частности это вызов деструкторов всех статических объектов...
Ы том то и дело что крешится не тогда когда выход из приложения.

S>>Ну, собственно, так сейчас и есть. И до креша логгер успевает много чего понаписать.
E>Так значит крэш таки на этапе деструкторов статических объектов? Или в main()?
Не статических. Я создаю и удаляю объект.... Крч.

class CLogger
{
public:
    CLogger() {m_filename = ".application.log"; start() << "Opening log."; stop();};
    ~CLogger(){ start() << "Closing log."; stop(); };

    CLogger &start() { m_mutex.lock(); m_logstream.open(m_filename, std::ofstream::out | std::ofstream::ate | std::ofstream::app); return *this; }
    void      stop() { m_logstream << std::endl; m_logstream.close(); m_mutex.unlock();}
    template <class T> CLogger &operator<<(const T &value) { m_logstream << value; return *this; }
private:
    std::string   m_filename;
    std::ofstream m_logstream;
    std::mutex    m_mutex;
};

class CSingleTone
{
public:
  CLogger *logger() { if(!m_logger) {m_logger = new CLogger(); } return m_logger; };
  static CSingleTone *instance();
private:
  CLogger *m_logger;
}

Someclass
{
  Someclass() { CSingleTone::instance()->logger()->start() << "construct"; CSingleTone::instance()->logger()->stop(); }
  ~Someclass() { CSingleTone::instance()->logger()->start() << "destruct"; CSingleTone::instance()->logger()->stop(); }
}

void somewhere()
{
 for(...)
 {
   Someclass *sc = new Someclass();
   ...
   delete sc;
 }
}
Matrix has you...
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 16.12.18 23:41
Оценка:
Здравствуйте, Слава, Вы писали:

С>Теперь тебе понятно, почему люди сделали Java и C#, и стали писать на них?
Потому что не осилили разобраться с достаточно простой проблемой? Заплакали, бросили но полпути и к жабе за решотку?

С>PS: переходи на Rust.
Надо будет — и на ём буду писать. Но шас не хочу.
Matrix has you...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.