[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-20 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #22 from Aetf <7437...@gmail.com> ---
For a simplest session:

$ lldb-mi /path/to/executable
-break-insert main.cpp:30
-exec-run

There are also commands like -exec-continue, -exec-next. Reference: 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html#GDB_002fMI-Program-Execution

I don't have enough knowledge about how actually a debugger scans app's memory
space or the overcommit thing. But my intuition is, just attaching a debugger
to the app shouldn't dramatically increases its memory usage... 

AFAIK, starting a complex app in debugger takes longer simply because the
program is being instrumented and thus runs much slower.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-18 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #20 from Aetf <7437...@gmail.com> ---
Pushed to master with commit 262bf5dddf2aef991c66fdc484c58daf32eaa348, so I'm
going to close this, reopen it if you have any further problems.

A debugger shouldn't take too much memory. It looks like a bug. Did you try to
manually debug using lldb 3.9? And please open another report if that only
happens in KDevelop.

Well, the working directory changing does require another patch[1] ... And I've
created a RR in their Phabricator[2], which seems to be more active than their
bug tracker.

[1] https://llvm.org/bugs/show_bug.cgi?id=30265
[2] https://reviews.llvm.org/D24711

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-16 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #18 from Aetf <7437...@gmail.com> ---
I'm glad you found the reason. So the patch itself works for you now? If so,
I'm going to close this and push the change to master.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-16 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #16 from Aetf <7437...@gmail.com> ---
Could you start KDevelop from the console and check the output when starting
the debug session on Linux? You can enable debug output from KDevelop by
launching it with the command

env QT_LOGGING_CONF='logging.conf' kdevelop

where the content of logging.conf is

[Rules]
kdevelop.debuggers.lldb.debug=true
kdevelop.debuggers.common.debug=true

Also, even if the debug session ends, there should be an output panel titled
"Debug" being raised. See if there's any relevant output in that.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-14 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Attachment #101058|0   |1
is obsolete||

--- Comment #14 from Aetf <7437...@gmail.com> ---
Created attachment 101088
  --> https://bugs.kde.org/attachment.cgi?id=101088&action=edit
Add propper detection of version string on OS X

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368603] crash when starting an lldb debug session

2016-09-14 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #13 from Aetf <7437...@gmail.com> ---
Sorry for the delay. I don't have enough time to do any actual coding due to my
course work for a few days.

That looks good to me. The reason I didn't add the check for OS X was I can't
find the mapping between Linux version string and OS X version string.

the lldb plugin on Linux didn't work for you after applied my latest patch? Is
it the case that you clicked 'don't ask again' and answered no? There should be
some output in the Debug output panel saying that session stopped due to
unsupported lldb version.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kde] [Bug 368603] crash when starting an lldb debug session

2016-09-12 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Attachment #101057|0   |1
is obsolete||

--- Comment #10 from Aetf <7437...@gmail.com> ---
Created attachment 101058
  --> https://bugs.kde.org/attachment.cgi?id=101058&action=edit
Add the option "Don't ask again" to warning dialog

Okay, here's the one with option "Don't ask again".

Currently KDevelop doesn't provide a way to reset these warnings. So you can't
change your answer afterwards.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kde] [Bug 368603] crash when starting an lldb debug session

2016-09-12 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

   Assignee|unassigned-b...@kde.org |7437...@gmail.com
 Status|NEEDSINFO   |ASSIGNED
 Resolution|WAITINGFORINFO  |---
 Ever confirmed|0   |1

--- Comment #8 from Aetf <7437...@gmail.com> ---
Created attachment 101057
  --> https://bugs.kde.org/attachment.cgi?id=101057&action=edit
Fix Bug 268603, warn the user about unsupported lldb version

I'm not sure it's a good idea to direct link to liblldb (I'm not aware any
major IDE doing that). And building yet another proxy executable from scratch
would be reinventing the wheel compared to lldb-mi, which is exactly a proxy
already.

Anyway, there's the first attempt to fix this bug, the patch does the
following:

- warn the user about unsupported lldb version
- reject user command if an unsupported version is found (to prevent crash on
invalid message)

Could you try if this works for you?

But I have no idea how to make the warning with an option to "Don't show it
again". I suppose there should be some library function that I should call. Do
you know any warnings shown by KDevelop already has this feature? Maybe I can
look at that code to see how to implement this.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kde] [Bug 368603] crash when starting an lldb debug session

2016-09-12 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #9 from Aetf <7437...@gmail.com> ---
Oops, it should be Bug 368603 in the description of the attachment.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kde] [Bug 368603] crash when starting an lldb debug session

2016-09-11 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #5 from Aetf <7437...@gmail.com> ---
Okay, that patch is required, otherwise lldb-mi doesn't produce correct spec
confirming output. That's why handleVersion is getting empty lists.

And the version output is quite different, is that what you get on OS X?

Seems I still need to find a more robust way to detect lldb version.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kde] [Bug 368603] crash when starting an lldb debug session

2016-09-11 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368603

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #3 from Aetf <7437...@gmail.com> ---
The 'version' command is issued after lldb-mi has already been started.  And
commit 102f673c6ff1afe5b1ca9cb6faa0503663b96e16 was intended to fix the
previous way to check version (invoking lldb-mi directly which might not be in
path). Strange enough, the output shouldn't be empty.

Did you applied this patch? https://llvm.org/bugs/show_bug.cgi?id=28026

Could you do the following and paste the output here?
1. lldb-mi --versionLong
2. lldb-mi and then type version

The output should be something like
$ lldb-mi --versionLong
LLDB Machine Interface Driver (MI) All rights reserved
Version: 1.0.0.9
Version: GNU gdb (GDB) 7.4
(This is a MI stub on top of LLDB and not GDB)
All rights reserved.

$ lldb-mi
(gdb)
version
~"lldb version 4.0.0 ( http://llvm.org/svn/llvm-project/lldb/trunk revision
279424 clang revision 279424 llvm revision 279424)\n"
^done
(gdb)

Thank you for trying this out ;)

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 357779] Crash When Debugging [GDBDebugger::DebugSession::interruptDebugger]

2016-09-08 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357779

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Status|CONFIRMED   |NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #3 from Aetf <7437...@gmail.com> ---
I can't reproduce this with new KDevelop 5 with Qt5. And looking at the code, I
have no idea why it would segment fault when calling ::kill(pid, SIGINT);

Russell, could you try with the latest KDevelop 5.0.0 and if the bug still
exists, upload a test project so that I can reproduce and debug with?

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevplatform] [Bug 368322] Job not fully stopped when starting non-existing debugger executable

2016-09-08 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368322

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Aetf <7437...@gmail.com> ---
Fixed in commit b72ece8

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevplatform] [Bug 368322] Job not fully stopped when starting non-existing debugger executable

2016-09-06 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368322

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

   Assignee|kdevelop-bugs-n...@kde.org  |7437...@gmail.com
 Status|CONFIRMED   |ASSIGNED

--- Comment #2 from Aetf <7437...@gmail.com> ---
It's due to LLDB plugin uses a different code path for error reporting. Working
on a fix now.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 368162] LLDB: Working directory is not changed to the one specified in configuration

2016-09-02 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=368162

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Resolution|--- |UPSTREAM
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Aetf <7437...@gmail.com> ---
Fixed with commit 3bf6698e63a7b65984cb7d0cc87fa764b654ae0e, but won't work
unless upstream bug fixed: https://llvm.org/bugs/show_bug.cgi?id=30265

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view

2016-05-05 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=333759

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view

2016-04-13 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=333759

--- Comment #8 from Aetf <7437...@gmail.com> ---
(In reply to Kevin Funk from comment #7)
I am still not quite convinced (see below) but maybe the removal deserves it
own patch. So, simpler fix submitted to Phabricator. 

For the "cache/duplicate" thing: I understand that we should avoid updating
variables as much as possible due to communication costs. And that's what
exactly the *thread_or_frame_changed* event handler for. Is there such a case
that this handler is called without an actual change in active thread/frame?
Given we now only check cached active thread/frame in this event handler, it
looks duplicate to me.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view

2016-04-07 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=333759

--- Comment #5 from Aetf <7437...@gmail.com> ---
Posted on Phabricator now: https://phabricator.kde.org/D1351

Well, yes, it can be done by just make IVariableController::handleEvent
correctly updates m_active{Frame,Thread} even if
IVariableController::autoUpdate is UpdateNone. No need to touch
IVariableController::setAutoUpdate though.

But I think there is duplication. Maybe my wording isn't clear, but the patch
isn't removing the "only update when active frame/thread chagnes"
functionality, as we only call IVariableController::update when handling
IDebugSession::thread_or_frame_changed event. So no need to do the duplicate
check (The update in IVariableController::setAutoUpdate handles different
situations and is irrelevant here. However, I do wonder if it is needed all the
time)

Besides, m_active{Frame,Thread} only mirror the same value in
FrameStackModel::current{Frame,Thread} and it requires extra effort to keep
them synced. So in my opinion we should remove m_active{Frame,Thread} to
simplify the logic.

I understand removing them breaks binary compatibility. If that's what you are
concerned, then I'm OK to change to the simpler workaround.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view

2016-04-07 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=333759

--- Comment #2 from Aetf <7437...@gmail.com> ---
Hi, I'm looking into this bug right now. It seems the bug still exists in the
latest version.

The exact steps to reproduce is as follow:
1. Debug some application
2. Pause the debugger
3. Collapse the variable list or hide the variables tool view
4. Switch to another frame, i.e. frame 1
5. Expand the variable list or show the variables tool view
6. *Important*: switch back to the same frame as in step 2

Actual Results:
Variables for frame 1 are shown

Expected Results:
Variables of the currently selected frame should be shown


The reason for this is that internally `IVariableController` keeps track of the
current active frame/thread and only updates variables when active frame/thread
changes. However, when variables list is hidden, the active frame/thread is not
updated. Thus if the user changes frame in this case, the active frame/thread
value remains what it was before the variables list is hidden. Then after
making variables list visible and changing the frame again to the previous
frame, `IVariableController` thinks there is not change at all and skips the
update.


The attached patch fixes this issue by removing the whole tracking active
frame/thread logic. This logic was introduced in 57b2d64f to make sure locals
are updated only once. However, with the code evolving, other situations where
update might be called with frame/thread unchanged are gone and the above is
the only one left, which in fact also doesn't require such logic. Given this
tracking logic makes no benefits but bugs only, I removed it in the patch which
also fixes the bug.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view

2016-04-07 Thread Aetf via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=333759

Aetf <7437...@gmail.com> changed:

   What|Removed |Added

 CC||7437...@gmail.com

--- Comment #1 from Aetf <7437...@gmail.com> ---
Created attachment 98282
  --> https://bugs.kde.org/attachment.cgi?id=98282&action=edit
Fix variable toolview not sync with framestack toolview

-- 
You are receiving this mail because:
You are watching all bug changes.