SVN REV 4760 hangs in OpenSuse

[codetoad]

If I set any breakpoint, anywhere, CL stops execution as expected.

When I hit f11 or try to resume any other way, it just hangs, and I have to terminate the application

[eranif]

Please provide a detailed step-by-step for how to reproduce this (I cant seem to make it happen here linux (ubuntu 10.10 32/64bit)/win 7/OSX)

Also, if you can attach a debugger to codelite while it hangs and run the following:

Code: Select all

set pagination off
thread apply all bt

Eran

[codetoad]

update:

I think its gdb thats crashing. Its hard to do anything with it, because the whole process is borked, I cannot copy and paste the debugger output.
Here's what I have: (I dont like: 'RuntimeError: Attempt to dereference a generic pointer') ??

DEBUG>>00000008^done,BreakpointTable={nr_rows="3",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0804ad9e",func="schedulerlib(dpslibrary&)",file="/home/steve/devel/cmdsched/main.cpp",fullname="/home/steve/devel/cmdsched/main.cpp",line="149",times="0",original-location="\"/home/steve/devel/cmdsched/main.cpp:149"},bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804ae73",func="schedulerlib(dpslibrary&)",file="/home/steve/devel/cmdsched/main.cpp",fullname="/home/steve/devel/cmdsched/main.cpp",line="158",times="0",original-location="\"/home/steve/devel/cmdsched/main.cpp:158"},bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x0804cc64",func="menu(dpslibrary&)",file="/home/steve/devel/cmdsched/main.cpp",fullname="/home/steve/devel/cmdsched/main.cpp",line="392",times="1",original-location="\"/home/steve/devel/cmdsched/main.cpp:392"}]}
DEBUG>>00000009-stack-list-locals 2
DEBUG>>00000010-stack-list-arguments 2 0 0
DEBUG>>00000009^done,locals=[{name="selection",type="std::string"}]
DEBUG>>00000011-var-create - @ "selection._M_dataplus._M_p"
DEBUG>>00000011-var-create - @ "selection._M_dataplus._M_p"
DEBUG>>~"Traceback (most recent call last):\n"
Traceback (most recent call last):
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 353, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 353, in next
DEBUG>>~" n = self.rbiter.next()\n"
n = self.rbiter.next()
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 297, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 297, in next
DEBUG>>~" if node.dereference()['_M_right']:\n"
if node.dereference()['_M_right']:
DEBUG>>~"RuntimeError: Attempt to dereference a generic pointer.\n"
RuntimeError: Attempt to dereference a generic pointer.
DEBUG>>~"Traceback (most recent call last):\n"
Traceback (most recent call last):
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 353, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 353, in next
DEBUG>>~" n = self.rbiter.next()\n"
n = self.rbiter.next()
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 297, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 297, in next
DEBUG>>~" if node.dereference()['_M_right']:\n"
if node.dereference()['_M_right']:
DEBUG>>~"RuntimeError: Attempt to dereference a generic pointer.\n"
RuntimeError: Attempt to dereference a generic pointer.
DEBUG>>~"Traceback (most recent call last):\n"
Traceback (most recent call last):
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 353, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 353, in next
DEBUG>>~" n = self.rbiter.next()\n"
n = self.rbiter.next()
DEBUG>>~" File \"/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py\", line 297, in next\n"
File "/usr/lib/../share/gdb/python/libstdcxx/v6/printers.py", line 297, in next
DEBUG>>~" if node.dereference()['_M_right']:\n"

Thanks

[codetoad]

*bump* still unresolved...(

[eranif]

Have you tried to downgrade / upgrade gdb version?

Eran

[DavidGH]

Hi,

I just tried out debugging in CodeLite version 2.9.0.4684, on a virtualbox guest running openSUSE 11.3 x86_64 under kde. One of the CodeLite 'Hello world' projects, built debug against wxGTK-2.8.11, runs, breaks and resumes successfully.

The gdb version is GNU gdb (GDB) SUSE (7.1-3.12).

If your SUSE version is significantly different let me know and, if I have a guest, I'll try that one.

Regards,

David

[codetoad]

Thanks for the help. I have the latest stable release of Suse.

I think I may have a clue: my project is ok in "hello world" mode; its only when I have a huge vector populated that the hang on break problem appears.

In fact, the program does _eventually_ wake up (after about 10 mins)

Im guessing the debug command is somehow trying to iterate the whole vector list when it goes into break mode. The vector is about 18k in memory, and consists of a custom struct, full of all sorts of data. And its not only the first time. It will "go to sleep" for 10 mins whenever I stop at a breakpoint whilst the vector is in memory.

I think its likely a scalability issue. I would imagine its quite common to, at least temporarily, have this much data in RAM for spitting out to a file, etc.

Is there any way to prevent this? Its making my project un-debuggable?!

Thanks

[eranif]

I am pretty much guessing it is related to the python pretty printers of gdb and codelite can't do much about that.
I can assure you that codelite does not try to iterate into the entire vector...

Eran

[codetoad]

"python pretty printers"

What's that? Can it be disabled? The project is currently un-debuggable like this!

Perhaps I should try it in code::blocks?

That way, if its the same, we'll know its gdb.

[DavidGH]

Perhaps I should try it in code::blocks?
That way, if its the same, we'll know its gdb.

Faster, and arguably more sensible, would be to try using gdb direct, in a terminal.