More debugger bugs

I try to use this stuff and document the bugs now (also on 
bugs.kde.org). The first part is reported as bug #138040,
the second 
part is #138041. 
I consider them serious bugs and regressions. If they are
not fixed, I 
heavily object to release KDevelop 3.4.

The bugs themselves:

The debugger fails to display the content QStringList (Qt3)
correctly.
The code is something like this:
PluginController::getInstance()->unloadPlugins(
m_info->m_ignoreParts );

m_info->m_ignoreParts is the QStringList, and has one
element (node).

If I watch the variable, it shows:
There is no member or method named
QValueList<QString>. for the "data" 
field of the nodes, 
but it correctly show that the list has 1 nodes.

Furthermore in the unlodPlugins we have:
void PluginController::unloadPlugins( QStringList const
& unloadParts )
{
	QStringList::ConstIterator it = unloadParts.begin();
	while ( it != unloadParts.end() )
	{
...
}

unloadParts should be the same as m_info->m_ignoreParts.
Well, at this 
stage the debugger doesn't even 
show *any* value for the "nodes" entry (should be
1), and of course the 
above problem is present here as well.

A frame handling bug:
if I want to go back to inspect m_info->m_ignoreParts
again, I click on 
the #1 frame in the frame stack. It 
goes back to the correct line (the above one), gives me some
errors:
Can't take address of "this" which isn't an
lvalue.
Can't take address of "this" which isn't an
lvalue.
Address requested for identifier "part" which is
in register $rbp
Variable object not found
No symbol "m_info" in current context.
Variable object not found
There is no member or method named QValueList.
There is no member or method named QValueList.

and I end with a disabled m_info->m_ignoreParts under
Watch. I *cannot* 
remove it, but
I can add again the same m_info->m_ignoreParts under
Watch, ending with 
two entries.
 Doing so more errors appear:
No symbol "m_info" in current context.
mi_cmd_var_create: unable to create variable object
Variable object not found
Variable object not found
No symbol "m_info" in current context
Variable object not found
Variable object not found
No symbol "m_info" in current context.

The new entry is added, but I still cannot inspect the
variable's value.


The double error messages might come because I had two
entries for 
m_info->m_ignoreParts.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 22:06, Andras Mantia wrote:
> I try to use this stuff and document the bugs now (also
on
> bugs.kde.org). The first part is reported as bug
#138040, the second
> part is #138041.
> I consider them serious bugs and regressions. If they
are not fixed, I
> heavily object to release KDevelop 3.4.

It would be much more helpful if you provide me with a way
to reproduce the 
bugs -- I can't quite debug anything if all I know is a
single line of code.

I have 3.4 checkout, what steps do I have to make to
reproduce what you see? I 
don't care what extra things I have to
checkout/build/whatever, as long as 
all the steps are there and the problem reproduces.

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 21:21, Vladimir Prus wrote:
> On Tuesday 28 November 2006 22:06, Andras Mantia wrote:
> > I try to use this stuff and document the bugs now
(also on
> > bugs.kde.org). The first part is reported as bug
#138040, the
> > second part is #138041.
> > I consider them serious bugs and regressions. If
they are not
> > fixed, I heavily object to release KDevelop 3.4.
>
> It would be much more helpful if you provide me with a
way to
> reproduce the bugs -- I can't quite debug anything if
all I know is a
> single line of code.

The description  is quite detailed if you ask me, and it is
taken from 
KDevelop's code.  

> I have 3.4 checkout, what steps do I have to make to
reproduce what
> you see?

Create a project in KDevelop which has some disabled plugins
(load the 
project, disable a plugin, close the project - after closing
reenable 
the plugin).
Create a project (or open if you have one) for the KDevelop
3.4 sources. 
Set a breakpoint to the line I gave:
PluginController::getInstance()->unloadPlugins(
m_info->m_ignoreParts );
in src/projectmanager.cpp (should be line 574).

Run KDevelop inside the debugger and load the project you've
created. 
m_info->m_ignoreParts should have the disabled plugin
names. The 
QStringList bug is visible from now on. After this step into
the 
unloadPlugins method. You will see the second part of the
QStringList 
issue. Now in the framestack try to go back one level. You
will see the 
framestack bug.
And of course you should see those error dialogs as well.
After steping 
even more in the code inside unloadPlugins I just had to
abort the 
debugging due to the big amount of error dialogs I got. :-(


> I don't care what extra things I have to 
> checkout/build/whatever, as long as all the steps are
there and the
> problem reproduces.


I hope with this information it is reproducible. I really
want to have a 
good KDevelop 3.4, as unfortunately 3.3 cannot be used for
KDE 4 at all 
(again because of debugging problems there). And I am a
heavy KDevelop 
user, and also try to fix bugs there, but if debugger is
broken I 
cannot even get close to fix the bugs either in KDevelop or
my own 
application. :-( (I am not experienced nor motivated enough
to do the 
debugging from console.)

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 22:34, Andras Mantia wrote:
> On Tuesday 28 November 2006 21:21, Vladimir Prus wrote:
> > On Tuesday 28 November 2006 22:06, Andras Mantia
wrote:
> > > I try to use this stuff and document the bugs
now (also on
> > > bugs.kde.org). The first part is reported as
bug #138040, the
> > > second part is #138041.
> > > I consider them serious bugs and regressions.
If they are not
> > > fixed, I heavily object to release KDevelop
3.4.
> >
> > It would be much more helpful if you provide me
with a way to
> > reproduce the bugs -- I can't quite debug anything
if all I know is a
> > single line of code.
>
> The description  is quite detailed if you ask me, and
it is taken from
> KDevelop's code.  
>
> > I have 3.4 checkout, what steps do I have to make
to reproduce what
> > you see?
>
> Create a project in KDevelop which has some disabled
plugins (load the
> project, disable a plugin, close the project - after
closing reenable
> the plugin).
> Create a project (or open if you have one) for the
KDevelop 3.4 sources.
> Set a breakpoint to the line I gave:
> PluginController::getInstance()->unloadPlugins(
m_info->m_ignoreParts );
> in src/projectmanager.cpp (should be line 574).
>
> Run KDevelop inside the debugger and load the project
you've created.
> m_info->m_ignoreParts should have the disabled
plugin names. The
> QStringList bug is visible from now on. 

Reproduces. As usual, blame it on gdb :-( I'll think about
how we can 
workaround it.

I actually have sent a patch to gdb that would have fixed
this problem, but it 
was not reviewed and I did not pinged.

> After this step into the 
> unloadPlugins method. You will see the second part of
the QStringList
> issue. 

Reproduced. Again, clearly a gdb bug, but in this case:

	- no workaround is possible
	- I think I can fix this in gdb

> Now in the framestack try to go back one level. You
will see the 
> framestack bug.

I can't reproduce it. 

> And of course you should see those error dialogs as
well. After steping
> even more in the code inside unloadPlugins I just had
to abort the
> debugging due to the big amount of error dialogs I got.
:-(

I can't reproduce this either. I've stepped though the
function till exit with 
no errors. Let me check -- are you using make, with
debugging enabled?
If not, please tell how exactly you've built kdevelop.

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 23:09, Vladimir Prus wrote:
> On Tuesday 28 November 2006 22:34, Andras Mantia wrote:
> > On Tuesday 28 November 2006 21:21, Vladimir Prus
wrote:
> > > On Tuesday 28 November 2006 22:06, Andras
Mantia wrote:
> > > > I try to use this stuff and document the
bugs now (also on
> > > > bugs.kde.org). The first part is
reported as bug #138040, the
> > > > second part is #138041.
> > > > I consider them serious bugs and
regressions. If they are not
> > > > fixed, I heavily object to release
KDevelop 3.4.
> > >
> > > It would be much more helpful if you provide
me with a way to
> > > reproduce the bugs -- I can't quite debug
anything if all I know is a
> > > single line of code.
> >
> > The description  is quite detailed if you ask me,
and it is taken from
> > KDevelop's code.  
> >
> > > I have 3.4 checkout, what steps do I have to
make to reproduce what
> > > you see?
> >
> > Create a project in KDevelop which has some
disabled plugins (load the
> > project, disable a plugin, close the project -
after closing reenable
> > the plugin).
> > Create a project (or open if you have one) for the
KDevelop 3.4 sources.
> > Set a breakpoint to the line I gave:
> > PluginController::getInstance()->unloadPlugins(
m_info->m_ignoreParts );
> > in src/projectmanager.cpp (should be line 574).
> >
> > Run KDevelop inside the debugger and load the
project you've created.
> > m_info->m_ignoreParts should have the disabled
plugin names. The
> > QStringList bug is visible from now on.
>
> Reproduces. As usual, blame it on gdb :-( I'll think
about how we can
> workaround it.
>
> I actually have sent a patch to gdb that would have
fixed this problem, but
> it was not reviewed and I did not pinged.
>
> > After this step into the
> > unloadPlugins method. You will see the second part
of the QStringList
> > issue.
>
> Reproduced. Again, clearly a gdb bug, but in this case:
>
> 	- no workaround is possible
> 	- I think I can fix this in gdb

I've diagnosed this. The following program reproduces the
bug:

struct S { int i; int j; };
struct S2 : S {};

int foo(S2& s)
{
    return s.i;
}

int main()
{
    S2 s;
    s.i = 1;
    s.j = 2;
    return foo(s);
}

Inside foo, no field of the baseclass is accessible. I have
preliminary gdb 
patch, I'll finish it tomorrow and let you know when it goes
upstream.

Thanks,
Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 22:09, Vladimir Prus wrote:
> > After this step into the
> > unloadPlugins method. You will see the second part
of the
> > QStringList issue.
>
> Reproduced. Again, clearly a gdb bug, but in this case:
>
> 	- no workaround is possible
> 	- I think I can fix this in gdb

Good that you can reproduce it, but it is a bad sign that it
may require 
a patched gdb. Mine is 6.5 from the not-yet-release SUSE
10.2.

> > Now in the framestack try to go back one level.
You will see the
> > framestack bug.
>
> I can't reproduce it.
>
> > And of course you should see those error dialogs
as well. After
> > steping even more in the code inside unloadPlugins
I just had to
> > abort the debugging due to the big amount of error
dialogs I got.
> > :-(
>
> I can't reproduce this either. I've stepped though the
function till
> exit with no errors. Let me check -- are you using
make, with
> debugging enabled? If not, please tell how exactly
you've built
> kdevelop.

My KDevelop (both that I run and what I debug as they are
the same) were 
compiled with unsermake. The configuration options used:
--disable-rpath --disable-closure --enable-libsuffix=64
--enable-debug--enable-gcc-hidden-visibility

unsermake shouldn't matter, about the rest I doubt, only
--enable-debug 
(without full) messes up the debugging a little. I built it
with the 
kdesvn-build script.


The system is a AMD 64, g++ 4.1.2, ld 2.17.50.0.5, KDE from
3.5 branch, 
Qt 3.3.7.

This is not the first time I see the error messages, but
IIRC stepping 
through the frames worked relatively well (it had other bugs
fixed 
meantime) during August/September when I used KDevelop 3.4
for KDE4 
development.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 29 November 2006 00:27, Andras Mantia wrote:
> On Tuesday 28 November 2006 22:09, Vladimir Prus wrote:
> > > After this step into the
> > > unloadPlugins method. You will see the second
part of the
> > > QStringList issue.
> >
> > Reproduced. Again, clearly a gdb bug, but in this
case:
> >
> > 	- no workaround is possible
> > 	- I think I can fix this in gdb
>
> Good that you can reproduce it, but it is a bad sign
that it may require
> a patched gdb. Mine is 6.5 from the not-yet-release
SUSE 10.2.

Hardly anything we can do about it -- KDevelop 3.4 is not
released either, 
anyway.

> > > Now in the framestack try to go back one
level. You will see the
> > > framestack bug.
> >
> > I can't reproduce it.
> >
> > > And of course you should see those error
dialogs as well. After
> > > steping even more in the code inside
unloadPlugins I just had to
> > > abort the debugging due to the big amount of
error dialogs I got.
> > >
> > > :-(
> >
> > I can't reproduce this either. I've stepped though
the function till
> > exit with no errors. Let me check -- are you using
make, with
> > debugging enabled? If not, please tell how exactly
you've built
> > kdevelop.
>
> My KDevelop (both that I run and what I debug as they
are the same) were
> compiled with unsermake. The configuration options
used:
> --disable-rpath --disable-closure --enable-libsuffix=64
> --enable-debug--enable-gcc-hidden-visibility

I think we've discovered some time ago on IRC, that
unsermake does not compile 
with -O0 -g -- which leads to exactly the problems you see.
Which is not to 
say that those problems should not be fixed. Is it easy to
get unsermake up 
and running?

- Volodya



_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 23:33, Vladimir Prus wrote:
> Hardly anything we can do about it -- KDevelop 3.4 is
not released
> either, anyway.

I know, but I wonder if at that time we will have a new gdb
release and 
if that release will be available for the common
distributions and 
platforms KDevelop is running.

> I think we've discovered some time ago on IRC, that
unsermake does
> not compile with -O0 -g -- which leads to exactly the
problems you
> see. 

This is what I meant with --enable-debug without full. I
found the whole 
flag line used to compile:

CXXFLAGS 
= -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wcast-align
 -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith
-fno-builtin -g -O2 
-fno-schedule-insns -fno-inline -pipe -Wformat-security
-Wmissing-format-attribute 
-Wno-non-virtual-dtor -fno-reorder-blocks -fno-exceptions
-fno-check-new -fno-common 
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT
 -DQT_NO_TRANSLATION


I checked and --enable-debug=full gives us:
CXXFLAGS 
= -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wcast-align 
-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith
-fno-builtin -g3 -fno-inline -pipe 
-Wformat-security -Wmissing-format-attribute
-Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common 
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION

So -O2, -fno-schedule-insns is missing.

> Which is not to say that those problems should not be
fixed. Is 
> it easy to get unsermake up and running?

Sure. If your distribution doesn't have it, check out from
the KDE SVN
(/home/kde/trunk/kdenonbeta/unsermake), create a link to the
unsermake 
executable into /usr/local/bin .

Run unsermake -f Makefile.cvs for KDevelop and later instead
of make 
always use makeobj.

Be sure to not mix automake and unsermake builds (so clean
your build 
dir before switching or use different build dirs for them).

Now what's interesting is that I cannot reproduce anymore
the frame bug 
with the same code. :-( I will try to get you a 100% useful
testcase.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 28 November 2006 22:09, Vladimir Prus wrote:
> I can't reproduce it.

Let's try again. The same system with --enable-debug 
(not --enable-debug=full yet):

- KDevelop loads the kdevelop-3.4.kdevelop project
automatically on 
startup
- there are two breakpoints set in the project (loaded from
the session 
file):
 projectmanager.cpp:576
 plugincontroller.cpp:193

I have one change compared to the svn version:
PluginController::getInstance()->unloadPlugins(
m_info->m_ignoreParts );
is the last called after 
PluginController::getInstance()->loadProjectPlugins( 
m_info->m_ignoreParts );
PluginController::getInstance()->loadGlobalPlugins( 
m_info->m_ignoreParts );
inside ProjectManager::loadLocalParts().

- start the KDevelop (from KDevelop) inside the debugger
- when it hits the breakpoint I get an error:
Address requested for identifier "this" which is
in register $r12
- I select "m_info->m_ignoreParts",
right-click, watch
- I open the watched variable until I see the
"data" part
- step into the next statement (F11), using the mouse => 
PluginController:getInstance
- error message:
No symbol "m_info" in current context. (m_info
gets grayed out)
- step over (F10):
No symbol "m_info" in current context.
- step over 2x => exit current method, go back to 
ProjectManager::loadLocalParts()
- error message:
Address requested for identifier "this" which is
in register $r12
- m_info is enabled
- step into (F11): cursor remains on the same line (I think
this is 
because of -O2 there)
- step into again:
Address requested for identifier "this" which is
in register $r12
- cursor moves to the next line
- step into again:
GDB exited abnormally
This is likely a bug in GDB. Examine the gdb output window
and then stop 
the debugger

Ok, this was another scenario, but still something is wrong
there. I run 
this two twice and with some difference in the end (I see
the "lvalue 
error" once) it went the same route and ended with an
exit of gdb.

If I don't restart KDevelop, just start the debugger again I
don't get 
some of the "address requested" error, but still
ends at the same 
place.

Second test:
- add a breakpoint to plugincontroller.cpp:286 (the
beginning of 
PluginController::unloadPlugins( QStringList const &
unloadParts ) )
- run in debugger
- when it stops at the breakpoint: frame stack, click on #1.
Can't take address of "this" which isn't an
lvalue.
- select "unload", Watch it
- click #0, #1, #0 in the framestack:
No symbol "newProfile" in current context
- click #1, #0:
Address requested for identifier "this" which is
in register $rdi
No symbol "newProfile" in current context
- click #1, #0 but quickly: #0 is selected, but the page for
#1 is 
visible and the debug cursor is also there.
- click #0 again: now no errors appear (timing issue??)
- F10: cursor goes 2 lines up
- F10: cursor comes back to the breakpoint
-  #1, #0 switch is OK now.
- F10:
No symbol "newProfile" in current context.
- F10:
No symbol "unload" in current context.
No symbol "newProfile" in current context.
No symbol "oldProfile" in current context.
- F10 (leaves the method):
Address requested for identifier "this" which is
in register $r13
Address requested for identifier "this" which is
in register $r13
- continue to run (hm, why is the buttom called Restart?)
- breaks in projectmanage:
Address requested for identifier "this" which is
in register $r12
Address requested for identifier "this" which is
in register $r12
No symbol "unload" in current context.
No symbol "newProfile" in current context.
No symbol "oldProfile" in current context.
- watch m_info->m_ignoreParts
- continue to run (breaks in unloadPlugins again)
Address requested for identifier "this" which is
in register $rdi
Address requested for identifier "this" which is
in register $rdi
- switch to #1
Can't take address of "this" which isn't an
lvalue.
Can't take address of "this" which isn't an
lvalue.
No symbol "unload" in current context.
(after the framestack is refreshed)
No symbol "m_info" in current context.
Address requested for identifier "this" which is
in register $rdi
Variable object not found
Variable object not found
No symbol "m_info" in current context.
Address requested for identifier "this" which is
in register $rdi
Variable object not found
No symbol "unload" in current context.
Variable object not found
No symbol "m_info" in current context.
(13 error dialogs in a row!)
- #0 remain selected altough I switched to #1
- #1 is not the correct one. I should be in 
ProjectManager::loadLocalParts from where the unloadPlugins
is called, 
but instead I'm in ProjectManager::slotLoadProject !
This might be again -O2 or something like that (bt in the
gdb windows 
gives the same stack trace)
- go back to #0.
- step out (F12)
- continue

The second scenario doesn't crash, but can easily drive me
crazy with 
the dialogs. 


I hope you can reproduce something with this.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 29 November 2006 00:26, Andras Mantia wrote:
> - step into (F11): cursor remains on the same line (I
think this is
> because of -O2 there)

Some more test, now with --enable-debug=full (I reverted the
change I 
made to pluginmanager, did new configure, makeobj clean in
src, then 
makeobj, makeobj install).

Test 1:
- while opening the m_info structure:
There is no member or method named QValueList. (but not for
the second 
try)
- no crazy cursor jumping problem backward/forward
- after returning to loadLocalParts() a step over (F10)
continues the 
program... This *IS* reproducible for me.

So gdb survives, but simply runs the application instead of
stepping 
over a line.


Test 2:
- no error messages when switching frames
- fast switching still broken
- during stepping, when I reached the end of the
unloadPlugins method, I 
got the first error:
No symbol "oldProfile" in current context.
- after continue, breaks in projectmanager:
No symbol "newProfile" in current context
- no erros again when switching to #1
- #1 is the correct one now (but remember, I moved the line
from the end 
of the method, so I'm not sure this or the =full made the
difference)
- after step out from  unloadPlugins: 
No symbol "unload" in current context.

Bonus test:
- once it continues Test2, load another project in the
debugged KDevelop
- it will break inside unloadPlugins:
No symbol "unload" in current context
- step out:
No symbol "m_info" in current context. (still in
unloadPlugins hit the 
other breakpoint)
- step out until it really steps out: unload becomes
enabled.
- remove the unload watch variable
- continue to run, break in unloadPlugins
- switch to #1: some errors, including
mi_cmd_var_create: unable to create variable object ( a new
one)
Variable object not found
Variable object not found

And a crash (what you probably cannot easily reproduce):
- program run and hang (my problem with KDevelop I tried to
debug)
- interrupt
- switch between frames: errors and KDevelop crashes:

Using host libthread_db library
"/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47778140127872 (LWP 23468)]
[New Thread 1082132800 (LWP 23483)]
[KCrash handler]
#5  QString::operator+= (this=0x7fff7d9291c0, str=0x8291bd0)
    at tools/qstring.cpp:5553
#6  0x00002b742d4040cc in kdbgstream::operator<<
(this=0x7fff7d9291c0, 
    string=0x8291bd0) at /opt/kde-35/include/kdebug.h:218
#7  0x00002b743fe9b5db in
GDBDebugger::VarItem::handleSpecialTypes (
    this=0x8291b10)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/variablewidget.cpp:1646
#8  0x00002b743fe9b860 in GDBDebugger::VarItem::updateValue
(
    this=0x7fff7d9291c0)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/variablewidget.cpp:1527
#9  0x00002b743fe9f4c0 in
GDBDebugger::VariableTree::handleVarUpdate (
    this=0x1d01eb0, r=<value optimized out>)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/variablewidget.cpp:856
#10 0x00002b743fe93a56 in
GDBDebugger::GDBCommand::invokeHandler (
    this=0x282f790, r=0x6986680)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/gdbcommand.cpp:36
#11 0x00002b743fe8fc7e in 
GDBDebugger::GDBController::processMICommandResponse
    (this=0x1ce19f0, result=0x6986680)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/gdbcontroller.cpp:1413
#12 0x00002b743fe900b1 in
GDBDebugger::GDBController::slotDbgStdout (
    this=0x1ce19f0, buf=<value optimized out>,
buflen=<value optimized 
out>)
    
at
/data/development/sources/kde-3.5/kdevelop-3.4/languages/cpp
/debugger/gdbcontroller.cpp:1534
#13 0x00002b743fe8c4e0 in
GDBDebugger::GDBController::qt_invoke (
    this=0x1ce19f0, _id=<value optimized out>,
_o=0x7fff7d929760)
    at ./languages/cpp/debugger/gdbcontroller.moc:248
#14 0x00002b7433081adc in QObject::activate_signal
(this=0x2a203e0, 
    clist=<value optimized out>, o=0x7fff7d929760) at 
kernel/qobject.cpp:2356
#15 0x00002b7431cfc37b in KProcess::receivedStdout (
    this=<value optimized out>, t0=0x2a203e0, 
    
t1=0x7fff7d929800
"^done,changelist=[{name="KDEV47",in_scope=
"true",type_changed="false"}]n(gdb)

n", t2=79) at ./kdecore/kprocess.moc:152
#16 0x00002b7431cfcfee in KProcess::childOutput
(this=0x2a203e0, 
    fdno=<value optimized out>)
    
at
/data/development/sources/kde-3.5/kdelibs/kdecore/kprocess.c
pp:853
#17 0x00002b7431cfd019 in KProcess::slotChildOutput 
(this=0x7fff7d9291c0, 
    fdno=136911824)
    
at
/data/development/sources/kde-3.5/kdelibs/kdecore/kprocess.c
pp:733
#18 0x00002b7431cfd364 in KProcess::qt_invoke
(this=0x2a203e0, _id=2, 
    _o=0x7fff7d929ce0) at ./kdecore/kprocess.moc:201
#19 0x00002b7433081adc in QObject::activate_signal
(this=0x20bd240, 
    clist=<value optimized out>, o=0x7fff7d929ce0) at 
kernel/qobject.cpp:2356
#20 0x00002b74330826df in QObject::activate_signal
(this=0x7fff7d9291c0, 
    signal=<value optimized out>, param=<value
optimized out>)
    at kernel/qobject.cpp:2449
#21 0x00002b743309c2cb in QSocketNotifier::event
(this=0x20bd240, 
    e=0x7fff7d929fc0) at kernel/qsocketnotifier.cpp:258
#22 0x00002b743302aeb5 in QApplication::internalNotify (
    this=<value optimized out>, receiver=0x20bd240,
e=0x7fff7d929fc0)
    at kernel/qapplication.cpp:2636
#23 0x00002b743302bc40 in QApplication::notify
(this=0x7fff7d92a250, 
    receiver=0x20bd240, e=0x7fff7d929fc0) at 
kernel/qapplication.cpp:2359
#24 0x00002b7431ccdd82 in KApplication::notify
(this=0x7fff7d92a250, 
    receiver=0x20bd240, event=0x7fff7d929fc0)
    
at
/data/development/sources/kde-3.5/kdelibs/kdecore/kapplicati
on.cpp:550
#25 0x00002b743302061b in
QEventLoop::activateSocketNotifiers 
(this=0x66ebc0)
    at kernel/qapplication.h:520
#26 0x00002b7432fe15f0 in QEventLoop::processEvents
(this=0x66ebc0, 
    flags=<value optimized out>) at
kernel/qeventloop_x11.cpp:383
#27 0x00002b743303f963 in QEventLoop::enterLoop
(this=0x7fff7d9291c0)
    at kernel/qeventloop.cpp:198
#28 0x00002b743303f812 in QEventLoop::exec
(this=0x7fff7d9291c0)
    at kernel/qeventloop.cpp:145
#29 0x000000000040891c in main (argc=3, argv=0x7fff7d92a6d8)
    at
/data/development/sources/kde-3.5/kdevelop-3.4/src/main.cpp:
149

I saw crashes when deleting watched variables previously as
well, and 
I'll try to find how to easily reproduce.

Conclusions (from my POV):
- --enable-debug=full (-g3 , without -O2) helps to have less
error 
messages, better stepping, but still gives errors and
introduces a new 
bug (run instead of step)
- as --enabel-debug=full is not that well known and as I saw
SUSE for 
example uses -O2 for debug packages as well, at least the
error 
reporting part should be fixed. I believe the stepping issue
cannot be 
fixed in KDevelop
- watched variable handling needs improvements: no need to
warn if they 
are not available in the current context and it should be
possible to 
remove them even if they are disabled.

Unfortunately I still couldn't reproduce the framestack bug
as I 
reported. :-( 

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel