Author Topic: crash while parsing source files  (Read 22065 times)

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
crash while parsing source files
« on: March 25, 2009, 03:06:09 pm »
When I save some files codeblocks crashes.
The output is:

Reparsing saved files...
Segmentation fault (core dumped)

The backtrace is:

Code
Thread 1 (process 31031):
#0  0x00007f12c0a2af95 in ?? () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f12c0a2d23a in malloc () from /lib/libc.so.6
No symbol table info available.
#2  0x00007f12c124ea3d in operator new ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6
No symbol table info available.
#3  0x00007f12ba1530db in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230, __x=0x28, __p=0x1)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/ext/new_allocator.h:90
__top = <value optimized out>
#4  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac6322d0, __p=0xad897c0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad897f0
#5  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac62efd0, __p=0xad89790)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad897c0
#6  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac627b30, __p=0xad89760)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad89790
#7  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac618d10, __p=0xad89730)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad89760
#8  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac604fd0, __p=0xad89700)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad89730
#9  0x00007f12ba153115 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0x7fffcedcb230,
    __x=0x7f12ac5f1650, __p=0x7fffcedcb238)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:1232
__top = (class std::_Rb_tree_node<int> *) 0xad89700
#10 0x00007f12ba174bd7 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::operator= (this=0x7fffcedcb230,
    __x=@0x7f12b0747de0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:800
No locals.
#11 0x00007f12ba18dc32 in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_set.h:220
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0x0,
        _M_left = 0x7fffcedcb238, _M_right = 0x7fffcedcb238},
      _M_node_count = 0}}}
idx2 = <value optimized out>
#12 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad88da0, _M_left = 0xad896d0, _M_right = 0xad88f20},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#13 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad88440, _M_left = 0xad88d70, _M_right = 0xad885c0},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#14 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad87ae0, _M_left = 0xad88410, _M_right = 0xad87c60},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#15 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad87180, _M_left = 0xad87ab0, _M_right = 0xad87300},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#16 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad86820, _M_left = 0xad87150, _M_right = 0xad869a0},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#17 0x00007f12ba18dc4b in TokensTree::RemoveToken (this=0x1309310,
    oldToken=0x7f12b0747d00) at parser/token.cpp:601
idx = 21875
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red,
        _M_parent = 0xad85ec0, _M_left = 0xad867f0, _M_right = 0xad86040},
      _M_node_count = 50}}}

This continues to about 58000 deep and the gdb crashes so I can't get a full backtrace.
It doesn't seem to do it on all files either, I can send all my source if you would like too.

Offline rcoll

  • Almost regular
  • **
  • Posts: 150
Re: crash while parsing source files
« Reply #1 on: March 25, 2009, 08:48:08 pm »
I'm not an expert on the C::B parser, but this looks to me like it's trying to parse a library.  This IS a source-code file you are trying to save, right?  Language C++?  Does it compile?

Ringo

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #2 on: March 25, 2009, 10:42:14 pm »
yes it's my own source, it's c++, it compiles fine.

also it's in revision 5486, it also happened on 5482.
« Last Edit: March 25, 2009, 10:43:56 pm by jarro_2783 »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #3 on: March 26, 2009, 10:37:23 am »
yes it's my own source, it's c++, it compiles fine.

also it's in revision 5486, it also happened on 5482.

I stumbled over a similar crash just some days before, that occurs only on my 64-bit linux and only with some sources.
You use a 64-bit unix, too, if I read your backtrace correctly.

Today I found the time to track down a possible problem.

I guess you use a self-compiled C::B, so it would be nice if you can test the following patch:

Code
Index: src/plugins/codecompletion/classbrowserbuilderthread.cpp
===================================================================
--- src/plugins/codecompletion/classbrowserbuilderthread.cpp (Revision 5486)
+++ src/plugins/codecompletion/classbrowserbuilderthread.cpp (Arbeitskopie)
@@ -287,6 +287,11 @@
             {
                 CollapseItem(parent);
                 // tree->SetItemHasChildren(parent, false);
+                // existing is the last item an gets deleted in CollapseItem and at least on 64-bit linux it can
+                // lead to a crash, because we use it again some lines later, but m_pItem is not 0 in some rare cases,
+                // and therefore IsOk returns true !!
+                // so we leave the loop and the function here
+                break;
             }
             else
             {

EDIT:
modified the patch, a simple break to leave the while-loop is enough and decreases unneeded overhead.
« Last Edit: March 26, 2009, 02:09:59 pm by jens »

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #4 on: March 26, 2009, 12:14:44 pm »
first time it failed before it even started, second time it crashed after saving. It also happens on my 32 bit computer, and on the 32 bit uni computers. The bug buddy crash log is pasted after this.

Code
System: Linux 2.6.27-gentoo-r8jarryd #1 SMP Sun Jan 25 19:17:21 EST 2009 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10300000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: Mist

Memory status: size: 535023616 vsize: 535023616 resident: 99794944 share: 30896128 rss: 99794944 rss_rlim: 18446744073709551615
CPU usage: start_time: 1238065274 rtime: 563 utime: 521 stime: 42 cutime:3 cstime: 3 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/local/bin/codeblocks'

[Thread debugging using libthread_db enabled]
[New Thread 0x7f6c72da7700 (LWP 1051)]
[New Thread 0x4414f950 (LWP 1065)]
[New Thread 0x4177f950 (LWP 1058)]
[New Thread 0x4394e950 (LWP 1056)]
[New Thread 0x4314d950 (LWP 1055)]
[New Thread 0x4294c950 (LWP 1054)]
[New Thread 0x4214b950 (LWP 1052)]
0x00007f6c6cec2f0f in waitpid () from /lib/libpthread.so.0
#0  0x00007f6c6cec2f0f in waitpid () from /lib/libpthread.so.0
#1  0x00007f6c6f608974 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
#2  0x00007f6c6f608c98 in g_spawn_command_line_sync ()
   from /usr/lib/libglib-2.0.so.0
#3  0x00007f6c696a1719 in ?? ()
   from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
#4  <signal handler called>
#5  0x00007f6c6c208165 in raise () from /lib/libc.so.6
#6  0x00007f6c6c2094de in abort () from /lib/libc.so.6
#7  0x00007f6c6d1d2871 in wxFatalSignalHandler ()
   from /usr/lib/libwx_baseu-2.8.so.0
#8  <signal handler called>
#9  0x0000000000000000 in ?? ()
#10 0x00007f6c6d1ce88e in wxEvtHandler::ProcessPendingEvents ()
   from /usr/lib/libwx_baseu-2.8.so.0
#11 0x00007f6c6d13480e in wxAppConsole::ProcessPendingEvents ()
   from /usr/lib/libwx_baseu-2.8.so.0
#12 0x00007f6c6db056d6 in wxAppBase::ProcessIdle ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
#13 0x00007f6c6da59f36 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#14 0x00007f6c6f5cbce2 in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#15 0x00007f6c6f5cc525 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007f6c6f5cc81d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0x00007f6c72731512 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00007f6c6da7144d in wxEventLoop::Run ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
#19 0x00007f6c6db055cb in wxAppBase::MainLoop ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
#20 0x000000000042f5fb in CodeBlocksApp::OnRun (this=0x1249358) at app.cpp:760
#21 0x00007f6c6d16b50c in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#22 0x000000000042ed22 in main (argc=1, argv=0x0) at app.cpp:251

Thread 7 (Thread 0x4214b950 (LWP 1052)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6d1cb5a3 in wxConditionInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f6c6d1cc2a7 in wxSemaphoreInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x00007f6c6f07fc6a in BackgroundThread::Entry (this=0x109be28)
    at ../../src/include/backgroundthread.h:151
job = (AbstractJob *) 0x7f6c610ce5d0
#4  0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 6 (Thread 0x4294c950 (LWP 1054)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6d1cb5a3 in wxConditionInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f6c6d1cc2a7 in wxSemaphoreInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x00007f6c6f07fc6a in BackgroundThread::Entry (this=0x109be60)
    at ../../src/include/backgroundthread.h:151
job = (AbstractJob *) 0x109be60
#4  0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 0x4314d950 (LWP 1055)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6d1cb5a3 in wxConditionInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f6c6d1cc2a7 in wxSemaphoreInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x00007f6c6f07fc6a in BackgroundThread::Entry (this=0x109be98)
    at ../../src/include/backgroundthread.h:151
job = (AbstractJob *) 0x109be98
#4  0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 0x4394e950 (LWP 1056)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6d1cb5a3 in wxConditionInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f6c6d1cc2a7 in wxSemaphoreInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x00007f6c6f07fc6a in BackgroundThread::Entry (this=0x109bed0)
    at ../../src/include/backgroundthread.h:151
job = (AbstractJob *) 0x109bed0
#4  0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 0x4177f950 (LWP 1058)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6f5c9622 in g_main_context_wait ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#2  0x00007f6c6f5cc7c0 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#3  0x00007f6c72731512 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#4  0x00007f6c6da7144d in wxEventLoop::Run ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#5  0x00007f6c6dacd9a0 in wxDialog::ShowModal ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#6  0x00007f6c6e4805c9 in wxDebugReportPreviewStd::Show ()
   from /usr/lib/libwx_gtk2u_qa-2.8.so.0
No symbol table info available.
#7  0x000000000042ee50 in CodeBlocksApp::OnFatalException (
    this=<value optimized out>) at app.cpp:796
report = <incomplete type>
preview = <incomplete type>
#8  0x00007f6c6d1d286c in wxFatalSignalHandler ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#9  <signal handler called>
No symbol table info available.
#10 0x00007f6c6d1cd94b in wxEvent::wxEvent ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#11 0x00007f6c6f10bd26 in CodeBlocksEvent::Clone (this=0x4177eff0)
    at /usr/include/wx-2.8/wx/event.h:526
No locals.
#12 0x00007f6c6d1ce8e4 in wxEvtHandler::AddPendingEvent ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#13 0x00007f6c6f002eba in cbThreadPool::TaskDone (this=0x1236fe0,
    thread=<value optimized out>) at /usr/include/wx-2.8/wx/event.h:2565
evt = {<> = {<No data fields>}, <BlockAllocated<CodeBlocksEvent,75u,false>> = {static allocator = {
      allocBlocks = {<std::_Vector_base<BlockAllocator<CodeBlocksEvent, 75u, false>::LinkedBlock<CodeBlocksEvent>*,std::allocator<BlockAllocator<CodeBlocksEvent, 75u, false>::LinkedBlock<CodeBlocksEvent>*> >> = {
          _M_impl = {<std::allocator<BlockAllocator<CodeBlocksEvent, 75u, false>::LinkedBlock<CodeBlocksEvent>*>> = {<__gnu_cxx::new_allocator<BlockAllocator<CodeBlocksEvent, 75u, false>::LinkedBlock<CodeBlocksEvent>*>> = {<No data fields>}, <No data fields>}, _M_start = 0x123f0e0, _M_finish = 0x123f0e8,
            _M_end_of_storage = 0x123f0e8}}, <No data fields>},
      first = 0x1249780, ref_count = 0, max_refs = 0, total_refs = 0}},
  m_pProject = 0x0, m_pEditor = 0x0, m_pPlugin = 0x0, m_X = 0, m_Y = 0,
  m_TargetName = {<wxStringBase> = {static npos = 18446744073709551615,
      m_pchData = 0x7f6c6d1f64d8}, <No data fields>},
  m_OldTargetName = {<wxStringBase> = {static npos = 18446744073709551615,
      m_pchData = 0x7f6c6d1f64d8}, <No data fields>}, static ms_classInfo = {
    m_className = 0x7f6c6f2d8260, m_objectSize = 152,
    m_objectConstructor = 0x7f6c6f10a920 <CodeBlocksEvent::wxCreateObject()>,
    m_baseInfo1 = 0x7f6c6d444f60, m_baseInfo2 = 0x0,
    static sm_first = 0x7f6c5db17260, m_next = 0x7f6c6f58b000,
    static sm_classTable = 0x6ae010}}
#14 0x00007f6c6f003651 in cbThreadPool::cbWorkerThread::Entry (this=0x1233330)
    at cbthreadpool.cpp:236
element = {task = 0x7f6c610d4120, autodelete = true}
workingThread = <value optimized out>
#15 0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#16 0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#17 0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#18 0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 0x4414f950 (LWP 1065)):
#0  0x00007f6c6cebf9b9 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6d1cb5a3 in wxConditionInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f6c6d1cc2a7 in wxSemaphoreInternal::Wait ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x00007f6c6597170f in ClassBrowserBuilderThread::Entry (this=0x14a6a00)
    at classbrowserbuilderthread.cpp:121
No locals.
#4  0x00007f6c6d1ccc3a in wxThreadInternal::PthreadStart ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f6c6cebb097 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f6c6c29cccd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 0x7f6c72da7700 (LWP 1051)):
#0  0x00007f6c6cec2f0f in waitpid () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f6c6f608974 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#2  0x00007f6c6f608c98 in g_spawn_command_line_sync ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#3  0x00007f6c696a1719 in ?? ()
   from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
No symbol table info available.
#4  <signal handler called>
No symbol table info available.
#5  0x00007f6c6c208165 in raise () from /lib/libc.so.6
No symbol table info available.
#6  0x00007f6c6c2094de in abort () from /lib/libc.so.6
No symbol table info available.
#7  0x00007f6c6d1d2871 in wxFatalSignalHandler ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#8  <signal handler called>
No symbol table info available.
#9  0x0000000000000000 in ?? ()
No symbol table info available.
#10 0x00007f6c6d1ce88e in wxEvtHandler::ProcessPendingEvents ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#11 0x00007f6c6d13480e in wxAppConsole::ProcessPendingEvents ()
   from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#12 0x00007f6c6db056d6 in wxAppBase::ProcessIdle ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#13 0x00007f6c6da59f36 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#14 0x00007f6c6f5cbce2 in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#15 0x00007f6c6f5cc525 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#16 0x00007f6c6f5cc81d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#17 0x00007f6c72731512 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#18 0x00007f6c6da7144d in wxEventLoop::Run ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#19 0x00007f6c6db055cb in wxAppBase::MainLoop ()
   from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#20 0x000000000042f5fb in CodeBlocksApp::OnRun (this=0x1249358) at app.cpp:760
retval = <value optimized out>
#21 0x00007f6c6d16b50c in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#22 0x000000000042ed22 in main (argc=1, argv=0x0) at app.cpp:251
No locals.
#0  0x00007f6c6cec2f0f in waitpid () from /lib/libpthread.so.0
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors ---------------------
Top Editor: /home/jarryd/programming/programs/tl/include/tl/parser.hpp
Add project tl in parsing queue
Caching result of `pkg-config --cflags glibmm-2.4`
Cached
Caching result of `pkg-config --libs glibmm-2.4`
Cached
Caching internal gcc dirs for adding to parser...
Caching GCC dir: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4
Caching GCC dir: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/x86_64-pc-linux-gnu
Caching GCC dir: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include
Caching GCC dir: /usr/include
Passing list of files to parse
Starting batch parsing
--------------------------------------------------

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #5 on: March 26, 2009, 01:06:47 pm »
No idea at the moment.

At build time, did you use a clean source-tree ?

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #6 on: March 26, 2009, 01:33:15 pm »
one of the computers did, I'll redo the others and see what happens.
I'll try breaking at that function that gets called lots so that you can get a backtrace of what it was doing before it died.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #7 on: March 26, 2009, 02:09:02 pm »
backtrace stopping at the point where it goes crazy

edit: I just noticed going a few functions down that the oldToken pointer starts being the same.

Code
#0  TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c6b0240)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_tree.h:411
idx = 18279
parentToken = (Token *) 0x1
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x7fff6b02a458, _M_right = 0x7fff6b02a458},
      _M_node_count = 0}}}
idx2 = <value optimized out>
#1  0x00007f3555a1ec5b in TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c94ccf0) at parser/token.cpp:601
idx = 6422
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x1d49b30, _M_left = 0x1f7e790, _M_right = 0x1adf3c0},
      _M_node_count = 50}}}
idx2 = <value optimized out>
#2  0x00007f3555a1ec5b in TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c75e290) at parser/token.cpp:601
idx = 392
---Type <return> to continue, or q <return> to quit---
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x20a4950, _M_left = 0x19f27e0, _M_right = 0x20a48f0},
      _M_node_count = 59}}}
idx2 = <value optimized out>
#3  0x00007f3555a1ebf0 in TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c75caf0) at parser/token.cpp:594
idx = 374
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x20a3de0, _M_left = 0x1e79bd0, _M_right = 0x20a4170},
      _M_node_count = 32}}}
idx2 = <value optimized out>
#4  0x00007f3555a1ebf0 in TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c7411f0) at parser/token.cpp:594
idx = 38
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = ---Type <return> to continue, or q <return> to quit---
{<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x1e92bf0, _M_left = 0x23dcad0, _M_right = 0x1b90000},
      _M_node_count = 505}}}
idx2 = <value optimized out>
#5  0x00007f3555a1ebf0 in TokensTree::RemoveToken (this=0x12dc990, oldToken=0x7f354c7410a0) at parser/token.cpp:594
idx = 37
parentToken = <value optimized out>
nodes = {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x200cad0, _M_left = 0x16c29c0, _M_right = 0x1ee2570},
      _M_node_count = 3}}}
idx2 = <value optimized out>
#6  0x00007f3555a1efd0 in TokensTree::RemoveFile (this=0x12dc990, index=5) at parser/token.cpp:709
idx = <value optimized out>
the_token = (Token *) 0x1
match1 = <value optimized out>
match2 = 176
the_list = (TokenIdxSet &) @0x7f35504cc768: {_M_t = {
    _M_impl = {<std::allocator<std::_Rb_tree_node<int> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<int> >> = {<No data fields>}, <No data fields>},
---Type <return> to continue, or q <return> to quit---
      _M_key_compare = {<std::binary_function<int,int,bool>> = {<No data fields>}, <No data fields>}, _M_header = {
        _M_color = std::_S_red, _M_parent = 0x7f35503e4100, _M_left = 0x7f35503d5ee0, _M_right = 0x7f35503cf140},
      _M_node_count = 21}}}
#7  0x00007f3555a0a989 in Parser::ReparseModifiedFiles (this=0x12d4ef8) at parser/parser.cpp:939
filename = {<wxStringBase> = {static npos = 18446744073709551615,
    m_pchData = 0x49cb7b19}, <No data fields>}
files_list = {c = {<std::_Deque_base<wxString,std::allocator<wxString> >> = {
      _M_impl = {<std::allocator<wxString>> = {<__gnu_cxx::new_allocator<wxString>> = {<No data fields>}, <No data fields>}, _M_map = 0x1ed5d80, _M_map_size = 8, _M_start = {_M_cur = 0x1e92900, _M_first = 0x1e92900,
          _M_last = 0x1e92b00, _M_node = 0x1ed5d98}, _M_finish = {_M_cur = 0x1e92900, _M_first = 0x1e92900,
          _M_last = 0x1e92b00, _M_node = 0x1ed5d98}}}, <No data fields>}}
#8  0x00007f3555a0ad39 in Parser::OnTimer (this=0x7f3550000020, event=@0x7f355c52c2b8) at parser/parser.cpp:898
No locals.
#9  0x00007f355d41108f in wxEvtHandler::ProcessEventIfMatches () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#10 0x00007f355d4112a2 in wxEvtHandler::SearchDynamicEventTable () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#11 0x00007f355d411352 in wxEvtHandler::ProcessEvent () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#12 0x00007f355ddc8ee6 in wxTimerBase::Notify () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#13 0x00007f355dcbd334 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#14 0x00007f355f80e20b in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#15 0x00007f355f80ece2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#16 0x00007f355f80f525 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#17 0x00007f355f80f81d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#18 0x00007f3562974512 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#19 0x00007f355dcb444d in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#20 0x00007f355dd485cb in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#21 0x000000000042f5fb in CodeBlocksApp::OnRun (this=0x7f3550000020) at app.cpp:760
retval = <value optimized out>
#22 0x00007f355d3ae50c in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#23 0x000000000042ed22 in main (argc=1, argv=0x7f355c52c2b8) at app.cpp:251
No locals.
« Last Edit: March 26, 2009, 02:12:06 pm by jarro_2783 »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #8 on: March 26, 2009, 03:39:28 pm »
Are you able to create a demo-project (as small as possible), that leads to the crash ?

I see why it crashs (most likely):
Code
parentToken = (Token *) 0x1
in RemoveToken will reliable lead to a crash, because it should either be a vaild pointer or 0.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #9 on: March 27, 2009, 12:17:41 am »
www.cse.unsw.edu.au/~jarrydb/cbcrash.tar.bz2

changing the file parser.hpp and saving it causes the crash.
It also needs boost 1.38, and I couldn't get it to crash without having that in my search path, so when it asks for the boost global variable you'll have to give it the path to 1.38.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #10 on: March 27, 2009, 06:52:53 am »
Thanks I will install boost later the day.
I hope it crashes also with 1.37 (that's the newest version in debian), but I will also download more actual sources to compile it myself.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: crash while parsing source files
« Reply #11 on: March 27, 2009, 11:49:53 am »
www.cse.unsw.edu.au/~jarrydb/cbcrash.tar.bz2
Works just fine here (on Windows, Boost 1.38).

But: I have a modified version of CC... so probably this crash has been fixed meanwhile. Can you try another nighly?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #12 on: March 27, 2009, 12:25:53 pm »
www.cse.unsw.edu.au/~jarrydb/cbcrash.tar.bz2
Works just fine here (on Windows, Boost 1.38).

But: I have a modified version of CC... so probably this crash has been fixed meanwhile. Can you try another nighly?

I was able to make it crash with an unmodified C::B from trunk (r 5486) on my debian laptop 64-bit and boost 1.38.
1.37 does not crash !

So I see the possibility to find the issue this weekend.
Might be fixed with the cc-changes, because a modified version (trunk with new/changed cc seems not to crash).
But the other issue I found (see patch some posts before) does also only occur more or less randomly, depending on what the OS does with the unused memory, if we accidently reuse it.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #13 on: March 27, 2009, 12:54:46 pm »
I just tried it with no source code, just the includes, and it still crashed. So I guess it's something in boost. I also got a different crash which hadn't happened before, but I didn't save the backtrace. It may have been the one you said you fixed so I'll post if it happens again.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #14 on: March 28, 2009, 07:23:35 pm »
Might be fixed with the cc-changes, because a modified version (trunk with new/changed cc seems not to crash).

The only difference in token.cpp (where the crash appears is in TokenExists(...).

With the following patch, the crash should not appear:

Code
Index: src/plugins/codecompletion/parser/token.cpp
===================================================================
--- src/plugins/codecompletion/parser/token.cpp (Revision 5486)
+++ src/plugins/codecompletion/parser/token.cpp (Arbeitskopie)
@@ -463,7 +463,7 @@
         Token* curtoken = m_Tokens[result];
         if(!curtoken)
             continue;
-        if((parent<0 || curtoken->m_ParentIndex == parent) && curtoken->m_TokenKind & kindMask)
+        if((curtoken->m_ParentIndex == parent) && curtoken->m_TokenKind & kindMask)
             return result;
     }
     return -1;

The problem is, that I still do not know what causes the crash in
Code
RemoveToken(...)
.
I don't like a crash go away without really knowing the cause for it, so I will try to investigate further.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #15 on: March 28, 2009, 11:58:34 pm »
That seems to have fixed it, thanks.
I'm curious to know if you know which part of boost was causing the crash.
The complications of boost strike again, it finds all sorts of problems in gcc, but now it's crashing IDEs too.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #16 on: March 29, 2009, 01:35:20 pm »
I added my first patch to trunk.
Not the one that works for you, because it is part of a codecompletion update, that is in testing phase.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #17 on: April 04, 2009, 01:51:00 am »
I've actually started getting another crash. Unfortunately the backtrace is a little useless.

Code
Thread 1 (Thread 0xb639f8e0 (LWP 22973)):
#0  0xb66520bc in ?? () from /lib/libc.so.6
Cannot access memory at address 0xbf242fe8

have you seen anything like this with your tests?

How's the progress on getting the other fix into trunk?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #18 on: April 04, 2009, 09:32:03 am »
I've actually started getting another crash. Unfortunately the backtrace is a little useless.

Code
Thread 1 (Thread 0xb639f8e0 (LWP 22973)):
#0  0xb66520bc in ?? () from /lib/libc.so.6
Cannot access memory at address 0xbf242fe8

have you seen anything like this with your tests?

How's the progress on getting the other fix into trunk?

No, did this also happen with boost-library ?
Can you reproduce it ?

If yes,  do you have a simple test-case ?

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #19 on: April 07, 2009, 01:25:15 am »
www.cse.unsw.edu.au/~jarrydb/tl-0.1.4.tar.bz2

on 64 bit it seems to be crashing in RemoveToken, my 32 bit computer doesn't say anything useful in the backtrace.
change include/tl/types.hpp and save it and it should crash.

You will probably need boost 1.38 as from last time.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #20 on: April 07, 2009, 07:09:34 am »
www.cse.unsw.edu.au/~jarrydb/tl-0.1.4.tar.bz2

on 64 bit it seems to be crashing in RemoveToken, my 32 bit computer doesn't say anything useful in the backtrace.
change include/tl/types.hpp and save it and it should crash.

You will probably need boost 1.38 as from last time.

I just downloaded your project, and will have a look into it later.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #21 on: April 07, 2009, 07:35:19 am »
Try the following patch and remove the comments around parent < 0 in TokenExists(...), that means revert the patch posted before:

Code
Index: src/plugins/codecompletion/parser/token.cpp
===================================================================
--- src/plugins/codecompletion/parser/token.cpp (Revision 5519)
+++ src/plugins/codecompletion/parser/token.cpp (Arbeitskopie)
@@ -598,7 +598,14 @@
     // Step 4: Remove descendants
     nodes = oldToken->m_Descendants; // Copy the list to avoid interference
     for(it = nodes.begin();it!=nodes.end(); it++)
+    {
+        if(*it == idx) // that should not happen, we can not be our own descendant, but in fact that can happen with boost
+        {
+            Manager::Get()->GetLogManager()->DebugLog(_T("Break out the loop to remove descendants, to avoid a crash. We can not be our own descendant !!"));
+            break;
+        }
         RemoveToken(*it);
+    }
     // m_Descendants SHOULD be empty by now - but clear anyway.
     oldToken->m_Descendants.clear();
 

We seem to run in an endless recursive call of RemoveToken as you can see on the call-stack if it crashes.
It tries to remove the same Token over and over (same idx).
And so most likely corrupting our memory.
Why this only happens on 64-bit, I don't know.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #22 on: April 07, 2009, 02:05:19 pm »
it appears to work now, thanks.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: crash while parsing source files
« Reply #23 on: April 19, 2009, 02:38:23 pm »
Try the following patch and remove the comments
Try the following patch
I got another example that (Jens: as discussed) probably has the same root. Luckily it's way simpler and smaller that boost. ;-)

Attached is a project that consists just of header files. For me (on Windows) if I do:
- open any of these files
- change something (I do space + delete all the time - so I *don't* change content)
- save
- change again something like above
- save again
--> C::B crashes.

It seems probably be to be related to:
- the folder structure and the class "C" appearing in different namespaces
- the live parser...?!

Strangely it happens only at the second save to me.

[attachment deleted by admin]
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #24 on: April 19, 2009, 02:53:40 pm »
Strangely it happens only at the second save to me.

For me it happens at first save after the parser has finished for the first time.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: crash while parsing source files
« Reply #25 on: April 19, 2009, 06:32:10 pm »
The funny thing is, that if I also log the Tokens name
Code
Manager::Get()->GetLogManager()->DebugLog(F(_T("oldToken->m_Name = %s"), oldToken->m_Name.c_str()));
I see that not always the same recursion happens.

Another thing:

how does CC decide which class is the parent-class, if no header files are explicitly included.
For example the parent class "C" that is used by CC in "M_C.h" is in the same namespace, but there are no includes, so it is not in the scope and should lead to an error when compiling.
I think that CC should only use tokens (as base class in this case) that are visible for "M_C" (in this case).
Everything else is a guess and therefore error-prone.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #26 on: April 20, 2009, 04:26:35 pm »
I'm still getting crashes, the stack trace looks like this:

#14 0x00007f1e07a648f9 in TokensTree::RemoveToken (this=0x1307c50, oldToken=0x7f1e024715a0) at parser/token.cpp:607
#15 0x00007f1e07a648f9 in TokensTree::RemoveToken (this=0x1307c50, oldToken=0x7f1e0279e650) at parser/token.cpp:607
#16 0x00007f1e07a648f9 in TokensTree::RemoveToken (this=0x1307c50, oldToken=0x7f1e024715a0) at parser/token.cpp:607
#17 0x00007f1e07a648f9 in TokensTree::RemoveToken (this=0x1307c50, oldToken=0x7f1e0279e650) at parser/token.cpp:607
#18 0x00007f1e07a648f9 in TokensTree::RemoveToken (this=0x1307c50, oldToken=0x7f1e024715a0) at parser/token.cpp:607

Unfortunately the crash only seems to happen in my code which is now even bigger and makes it hard to track down. But notice that the values of oldToken seem to be alternating if that helps.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: crash while parsing source files
« Reply #27 on: April 20, 2009, 04:54:51 pm »
Strangely it happens only at the second save to me.

For me it happens at first save after the parser has finished for the first time.

The same to me, CB crashed after first save.

By the way, I'm not sure how to see the stack track.(windows XP)
« Last Edit: April 20, 2009, 04:57:10 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #28 on: April 21, 2009, 12:38:27 am »
if you have mingw you can run it through gdb.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: crash while parsing source files
« Reply #29 on: April 21, 2009, 02:18:43 am »
if you have mingw you can run it through gdb.
Thank for the hint :D
I'm not sure that when Code:blocks crashes(not running in gdb), will it create a dump file in the installed directory?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline jarro_2783

  • Multiple posting newcomer
  • *
  • Posts: 99
    • Project Freedom
Re: crash while parsing source files
« Reply #30 on: May 03, 2009, 03:04:38 am »
Is there any progress on this. It's getting so bad that it's unusable. I'm getting crashes quite frequently, and I'm also getting freezes with 100% cpu usage while it's trying to code complete sometimes.
I can post my project if you want, but it's >4000 lines now so I don't know how useful that's going to be.