We are in the last weeks of testing Carbide 1.3: the code is frozen, the test team is rechecking everything, and the beta testers are trying out the release candidate build. This is usually the time when some bug that has been around all along makes a surprise appearance in a really troubling way.
Last week we started getting some reports of the entire workbench locking up. People who were really beating on the tools all day said that often after a paste or save operation the UI would be unresponsive. Of course we couldn't reproduce the problem but we had two interesting clues: some people said the UI started responding again after a while and one beta tester sent in a screenshot of the frozen workbench.
Everyone has their own personal "time out" setting: the amount of time they are willing to wait for an unresponsive application to start working again before they kill it or restart their computer or chuck it over the cube wall. So that some people said the workbench came back to life after a while probably indicated we had some lengthly process blocking the UI thread, not that Carbide was frozen forever.
The screenshot gave us a few more clues: the progress indicator said the CDT indexer job was just starting and that the text the user was pasting hadn't yet appeared in the editor. I started trying to reproduce the problem by forcing a project to reindex and then repeatedly pasting code.
After a lot of pasting we found that the problem had nothing to do with the paste operation but with the use of the control key (as in ctrl-v to paste or ctrl-s to save). With the control key down CDT was asked to produce a hyperlink. Normally this happens quickly because the file has already been indexed and the results cached, but when it's dirty it proceeds to do some indexing on the UI thread which leaves the workbench completely unresponsive.
It seemed like the right thing to do in this case was to just not do the indexing if the cache was stale. We turned to the CDT team to confirm this and within a few hours we had changes in place to prevent this problem and a couple other related issues too.
So now I'm starting this week like I did the last: hoping Carbide 1.3 can slide out the door without any serious issues popping up.
Subscribe to:
Post Comments (Atom)
3 comments:
I've been using v1.2 for a couple of months now to port a legacy project. I'm curious to know if v1.3 has addressed two particularly vexing problems I've had:
1) I have a large project; 37 static libraries (built as one library per directory). Because of problem #2 below, I have to build on an old Windows 2000 system, and if I press "Debug...", I have to wait a long time for the system to check over all 37 .mmp files' worth of source to see that I changed one line of code. Is there a way to say, "build this .mmp only", in either v1.2 or v1.3?
2) I have to run on the old system because the S60 emulator doesn't run with a WinXP-Pro system and the firewall and A/V settings enforced by my company. But since I have to keep all my tools on the same drive letter, I can't let the faster system do the compile in a seamless way. Will v1.3 allow the workspace to be located on a different drive letter from the base IDE, tools, and SDK install?
Carbide 1.3 does handle the build before debug step much better than 1.2, however we have dropped support for Win 2K and you still need to have your source and the SDK on the same drive. That said, I suggest you try 1.3 when it is released and contact our support team if you need help.
OK - I know this isn't a support channel, but I figure it can't hurt to ask - and this blog entry was clearly sympathetic to "unreproducible" bugs - so here goes.
The A/V or Firewall issue in my point 2 has been reported on forum.nokia by others. (Yes, I am also "UncleOp".)
How can one work to resolve this, either with v1.2 or v1.3? There has been relative silence on forum.nokia regarding a solution to this particular issue.
As to no longer supporting W2K, is that an explicit non-support (i.e., will not permit installation) or is it an implicit non-support (Nokia will ignore bug reports)? If v1.3 doesn't help with the first issue, I'll be left high and dry.
Unless, of course, v1.3 will finally support development under Linux... (please?)
Post a Comment