Version: SVN (using KDE 4.3.1) Compiler: gcc 4.3.2 OS: Linux Installed from: SuSE RPMs If I set "Settings -> Configure KDevelop -> Background Parser -> Maximum Number of Threads" to 2 (I'm using a dual-core cpu), KDevelop segfaults when loading unparsed PHP projects. Tested with phpMyAdmin. Note that C++ projects don't cause this behaviour and the speedup is really noticeable. There is no segfault with PHP if using 1 thread only. I'll attach gdb and valgrind outputs (note that KDE crash handler didn't display any information at all, so I had to do it manually with gdb).
Created attachment 37389 [details] GDB backtrace
Created attachment 37390 [details] Valgrind output (starting KDevelop with unparsed phpMyAdmin project)
Can you please update your copies of kdevplatform, kdevelop and the PHP plugin? Your backtrace indicates that you are not using the latest version. If the problem persists, please attach updated backtraces. Thanks. PS: I use two threads myself with PHP and I have never encountered crashes because of that.
(In reply to comment #3) > Can you please update your copies of kdevplatform, kdevelop and the PHP plugin? > Your backtrace indicates that you are not using the latest version. Hmm, that was actually the yesterday's version. I'm attaching the new gdb and valgrind outputs (today's SVN of all three). The GDB output was obtained by running KDevelop with no project loaded and a clean ~/.kdevduchain. A phpMyAdmin project file was loaded into the running instance. The crash usually happens at 0-1% of parsing. For some reason, I cannot reproduce the crash with valgrind today (not unexpected since threading errors are usually timing-dependent). However, there seems to be a deadlock and while the GUI is operational, the parsing bar stays at 0 and KDevelop won't quit completely if I close it (I had to interrupt it with ctrl-C). I forgot to mention that I'm on openSUSE 11.1 x86_64. > PS: I use two threads myself with PHP and I have never encountered crashes > because of that. Do you have a dual- (or more-) core cpu? Some threading bugs don't manifest themselves on single-cpu systems.
Created attachment 37405 [details] gdb output (2009-10-06)
Created attachment 37406 [details] Valgrind output (2009-10-06), KDevelop's parser was hung, had to ctrl-C it
The only difference I see is that you use 64bit. I actually have no _single_ core to test on ;-) Afaik there was actually another bug report (maybe via mail or IRC only), where something similar was said. I.e. crash with 64bit. I fear I'll have to get a 64bit PC to test that myself. Well, wanted to do that anyways, so stay tuned. I see where it crashes now in the backtrace, but it looks like the first valgrind output will be more useful. If someone is good with valgrind, please give me hints.
(In reply to comment #7) > Afaik there was actually another bug report (maybe via mail or IRC only), where > something similar was said. I.e. crash with 64bit. That was probably me in your blog post comments :) I'm attaching helgrind (a threading error detector) output, just in case. Again, it didn't crash but just stopped at 0%, with me having to close KDevelop and ctrl-C it eventually.
Created attachment 37409 [details] Helgrind output (2009-10-06) Line 861 - that's when I closed KDevelop window because it was stuck at parsing 0%. Line 1222 - that's when I interrupted it with ctrl-C because it wouldn't exit (the window was closed though).
Ah it was you :) Now, are you sure you really have a deadlock, and not only kdevelop taking ages in valgrind? Regarding your helgrind output: Again, a tool I have not yet used myself, so I'm not really sure what it tells me. Looking at the "Possible data race during write of size 1 at 0xb4d97f0 by thread #24" messages, I rechecked: We always lock the DUChain for writing beforehand, so I'm a bit lost here... Maybe I'll try to ask zwabel, could be that he knows what the issue is. Thank you very much so far though!
(In reply to comment #10) > Now, are you sure you really have a deadlock, and not only kdevelop taking ages > in valgrind? Well, it did crash yesterday in ~1 minute after launching, with 1% parsing progress IIRC. Today, I waited for about 10 minutes and it didn't get past 0%, so I assumed it was a deadlock or something. Plus, a hang when quitting (I waited for ~5min) was also too long. Thanks a lot!
Should be fixed in trunk. If not, please reopen and provide new howto for reproducing. Interesting that this did not lead to crashes on my 32Bit systems! It was really a quite serious bug in the PHP parser...
Looks like it's fixed. I just loaded phpMyAdmin project without crashes or hangs. Thanks!