Bug 288224 - kdevelop crashes when renaming class (python)
Summary: kdevelop crashes when renaming class (python)
Status: RESOLVED FIXED
Alias: None
Product: kdev-python
Classification: Developer tools
Component: general (show other bugs)
Version: git master
Platform: Gentoo Packages Linux
: NOR crash
Target Milestone: 1.2.3
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-04 17:49 UTC by pavel kropitz
Modified: 2012-01-06 01:34 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
backtrace (17.91 KB, application/octet-stream)
2011-12-04 19:36 UTC, Miquel Canes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pavel kropitz 2011-12-04 17:49:37 UTC
Version:           git master (using KDE 4.7.3) 
OS:                Linux

...

Reproducible: Always

Steps to Reproduce:
open file with existing class, try to rename class

Actual Results:  
crash while typing or shortly after it

Expected Results:  
should not crash
Comment 1 Sven Brauch 2011-12-04 18:39:18 UTC
Hi,

can you please pastebin a code example (minimal would be great) which crashes for you? I cannot reproduce this.

Cheers
Comment 2 pavel kropitz 2011-12-04 19:14:57 UTC
(In reply to comment #1)
> can you please pastebin a code example (minimal would be great) which crashes
> for you? I cannot reproduce this.

hmm, weird. in my case even one from python tutorial http://pastebin.com/0hp7xwmc

(http://docs.python.org/tutorial/classes.html)

i closed all of my projects, just created new file from kdevelop menu, paste code, save as python file and then rename class. btw, it's not new bug but in the past i didn't consider it too disturbing. 

kdevelop don't generate crashdump in this case, but from console i see:

******************************************* 
re-compiling "/home/univerz/tmp/test.py" 
******************************************* 
ASSERT: "listIndex != -1" in file /tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/language/duchain/codemodel.cpp, line 310

with current changes in your plugin and kdevelop, kdevplatform... i have another problem, but in duchain too. sadly i can't provide source code (closed source), but i will try to investigate it deeper, maybe it's related. it happens when source is parsed after opening the project. only after restarting kdevelop multiple times, project finally opens.

 ====> PARSING ====>  KUrl("file:///home/univerz/projects/****.py") 
<nil>ASSERT: "bucket < m_bucketCount" in file /tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/language/duchain/repositories/itemrepository.h, line 1858
Comment 3 Sven Brauch 2011-12-04 19:21:27 UTC
The latter is because the repository is corrupted; delete the ~/.kdevduchain directory to fix this.

I tried with the pastebinned script, still no successin crashing it. Maybe this is also resolved by wiping the duchain cache?
Comment 4 Miquel Canes 2011-12-04 19:36:08 UTC
Created attachment 66376 [details]
backtrace

I can reproduce it. Only if the class has some methods defined.
Comment 5 pavel kropitz 2011-12-04 19:41:11 UTC
(In reply to comment #3)
> The latter is because the repository is corrupted; delete the ~/.kdevduchain
> directory to fix this.

wow, it works, thank you :)

> I tried with the pastebinned script, still no successin crashing it. Maybe this
> is also resolved by wiping the duchain cache?

sadly, no. i emerged kdevplatform kdevelop kdevelop-pg-qt kdevelop-python -9999
ebuilds again to ensure latest and mutually compatible versions, but with no
success
Comment 6 pavel kropitz 2011-12-04 19:45:15 UTC
(In reply to comment #4)
> Created an attachment (id=66376) [details]
> backtrace
> 
> I can reproduce it. Only if the class has some methods defined.

yes, empty class is ok, but adding variable produces the same behaviour too
Comment 7 Sven Brauch 2011-12-04 19:46:48 UTC
Okay, now I can also reproduce it, with methods being defined. I'll see what causes that.
Comment 8 Sven Brauch 2011-12-04 20:20:03 UTC
I find this very difficult to trigger, I need dozens of tries usually...
I'm pretty sure this is a concurrency issue. I could never reproduce it with only one parser thread.

The situation with locks around that class declaration stuff was pretty complicated. I simplified it, and couldn't reproduce the issue after that. Maybe you want to try again?
Comment 9 pavel kropitz 2011-12-07 22:03:50 UTC
(In reply to comment #8)
> I find this very difficult to trigger, I need dozens of tries usually...
> I'm pretty sure this is a concurrency issue. I could never reproduce it with
> only one parser thread.
> 
> The situation with locks around that class declaration stuff was pretty
> complicated. I simplified it, and couldn't reproduce the issue after that.
> Maybe you want to try again?

sadly, problem still persists on my machine. i can reproduce it every time even with one parser thread and clean ~ directory
Comment 10 Sven Brauch 2011-12-07 22:12:36 UTC
Okay, then I'll have another look at it.
Comment 11 pavel kropitz 2011-12-07 22:16:40 UTC
one observation, when i started with "class MyClass", then messed up class identifier, for example "Xclass MyClass", then renamed it to "Xclass MyClassX" and then changed it to "class MyClassX", it crashes too. but when it doesn't recognize content, it should trash the data about file, but data are still there, so it has same behaviour as direct renaming.
Comment 12 Sven Brauch 2011-12-18 11:52:23 UTC
This is always reproducable when kdevplatform is compiled in debug mode, it asserts then.
Comment 13 Sven Brauch 2011-12-22 23:05:16 UTC
Git commit dcad929ca0acbadfeb8230a71d929540c9ec6566 by Sven Brauch.
Committed on 23/12/2011 at 00:03.
Pushed by brauch into branch 'master'.

fix a crash bug when renaming classes

I don't like the fix, as I don't know why it works. Apparently dec->inSymbolTable()
is true, but the item isn't really in the symbol table while creating the declaration
after the class has been renamed. It can be worked around by unsetting inSymbolTable
while creating the declaration and setting it again later. It might be that this is
in fact a bug in the duchain. Anyway; it works like this.
BUG:288224

M  +3    -1    duchain/declarationbuilder.cpp
M  +2    -1    duchain/pythonducontext.h

http://commits.kde.org/kdev-python/dcad929ca0acbadfeb8230a71d929540c9ec6566
Comment 14 pavel kropitz 2012-01-05 17:59:00 UTC
on my home computer (slower) it works ok; on my dev machine i'm not able to test it now due to "set plugin version to 13 in preparation of 4.3 release".
Comment 15 Sven Brauch 2012-01-06 01:34:21 UTC
The plugin version should now match the current kdevelop head, so you might want to try again. :)
I'm pretty sure it's fixed, tough.