|
» Subscribe » Favorite Links » What is S60? » Freeware & Trials » S60 devices » Hints and tips » About this blog |
» Blognotes (15) » Bugs and Workarounds (4) » Build tools (5) » Carbide.c++ 1.1 (4) » Carbide.c++ 1.2 (8) » Carbide.c++ 1.3.x (8) » Carbide.c++ 2.0.x (1) » Carbide Plug-Ins (4) » CodeWarrior (2) » FAQ (6) » Future directions (24) » General (46) » Off-topic (4) » On-device debugging (13) » Performance Investigator (2) » Product features (16) » Product releases (16) » Screencast (12) » Support (30) » Tool setup (5) » UI Designer (8) » Usability (15) » Work in Progress (13) » Write-build-debug (4) |
|
Subscribe to RSS feed For email notification, please click here » |
Frequently when customers contact us in support due to problems debugging with TRK, a fair amount of time is spent gathering the information needed to diagnose the problem. One of the most common requests by us is to see the TRK communications log from the offending project.
Is the Installations folder of your emulator cluttered with old applications that you don't use any more? Most of them can't just be uninstalled from the UI, and hunting down and deleting the various executable and resource files is time-consuming and also a bit dangerous.
Continue reading "Keeping Your Emulator Beautiful" »CodeWarrior had a nifty feature where you could drag the program counter arrow up and down in the editor while in a debug session. This is a very powerful and very dangerous feature that people have been asking for in Carbide.
You can do something similar in Carbide by using the Resume At Line command (in the Run menu or the context menu when you click in the editor). This will move the program counter to that line and resume execution. So this works like the CodeWarrior feature except for the "resume" part. Carbide will automatically resume after moving the PC location instead of giving you the option to step etc.
I'd like to improve this feature in a future version of Carbide but for now the best work around I can think of is to set a breakpoint at the desired new PC location and then do the Resume At Line command on the line before that. Far from ideal but it will give you the option to step without auto resuming.
Some of my fellow support co-workers have blogged about the fact that we now have a great way for customers to file issues and stay informed of the progress: Bugzilla!
I thought I'd go one step further and create a screencast that covers the process, enjoy:
You can find this and other videos at: http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos
Got ideas for screencasts you'd like to see? Leave us some feedback here and we'll get on it!
The executables view was a great addition to the tool by providing a dymanic list of executables and their source files in an easily accesible area. We've had a few customers who asked for some clarifications on how they can use this view to help them hit breakpoints in DLL's that are launched by their executable.
Continue reading "Quick tip: DLL debugging on device with the Executables view." »Today I received a comment from "Bill Gates" to the first part of this topic that states that since we don't have a simulator in our tools therefore Symbian and Nokia are low-tech. Some people simply like to troll. We had a simulator in our toolset (CodeWarrior) since 2003.
So the fact that the tools have a simulator available to developers doesn't make it higher-tech. Simulator in the CodeWarrior for Symbian was very slow to simulate Symbian running environment and I don't know anybody who used it. Subsequently in 2004-2005 the support for it was discontinued...
The development team here is always looking for ways to make using Carbide.c++ easier and faster, and this has brought another new feature to the tool. With the 1.3.1 release, there will be a way for customers to submit support issues directly from Carbide.
When we first released Carbide we quickly learned from users that the concept of a "launch configuration" was pretty obscure to most folks. A UI evaluation team even came in and looked at us really weird when we brought the concept up. Carbide inherited the concept from Eclipse and we been refining it ever since. Basically, its a set of external data not required by the program but essential in setting the conditions so Carbide can launch and debug it. It contains information like which emulator to launch, which COM port ID to use, and other information.
In Carbide 1.2 we introduced the New Launch Configuration Wizard for on-device TRK debugging, JTAG debugging, and attaching to processes. In Carbide 1.3.1 we've gone back, reevaluated the entire launch configuration wizard process and refined it a bit to make it more useful to all users. Basically, unless your program has special customization requirements, you really should never have to go to the Debug window again.
Continue reading "A new day for launching" »The team spent last week wrapping up development of the first patch to Carbide 1.3. We're locking down the code now and focusing on testing for the next few weeks. We resolved around 170 issues for the update: you can see a list of some of the bugs we worked on here, just search for the target "v1.3.1" and a status of RESOLVED, VERIFIED, or CLOSED. We worked on issues all over the product: some were things we missed in 1.3 but most emerged after more feedback from all of you out there using Carbide. So thanks for all of your comments and keep them coming. We can't fix everything each time but we're listening to all of it as we make plans for the next release.
I have been developing tools for Symbian OS or 6 year now and think that debugging is one area of most interest to Symbian developers. Carbide C++ currently has 3 levels of debugging available:
1 - Emulation
2 - Run mode debugging with Trk
3 - Stop mode debugging with JTAG devices (currently Lauterbach and Sophia hardware emulators)
Since some customers have encountered problems in setting up the build environment for Carbide.c++, we created a screencast to demonstrate this process:
You can find this and other videos at: http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos
Got ideas for screencasts you'd like to see? Leave us some feedback here and we'll get on it!
The Console view may be one of the most overused views in Carbide. So we know a lot of information is output to the Console view, but did you know there are at least 10 different consoles to look at? I didn't know until I started to add their names to the Console view page in the Carbide manual.
I spent last week visiting the Symbian offices in London to talk to them about their upcoming internal rollout of Carbide.c++ version 1.3, meet with some of their engineers, and just generally see how they are using the tool. It was a good visit -- not only are they a really nice group of people, but I came back with a notebook crammed full of suggestions to make the tool better and new configurations to add to our testing procedures.
Continue reading "Pond-Hopping to Symbian" »Recently we've had some customers request that we provide a way of displaying the function that the cursor is currently in. Luckily, this feature already exists in the Outline View but you have to enable it first. To do this, simply click on the dropdown arrow in the outline view and make sure "Link with Editor" is checked. Here is a screenshot:
I heard another comment yesterday about perspective switching in Carbide: when you begin a debug session we automatically switch to the debug perspective but what should we do when the session ends? We've got a bug about this where people have requested we switch back to the Carbide perspective after a debug session. What do you think? Is this something you commonly do now? Would you like Carbide to do it automatically? Should that be the default behavior?
Carbide has a couple default ways of launching a debug session with the emulator: one is to simply launch the emulator (epoc.exe), the other is to launch your executable directly. Doing the second will start the emulator and open your application, saving you the trouble of navigating to it and opening it yourself.
In Carbide 1.3 people asked us to change the default behavior so that it would launch your executable directly. Since then we've found that this only seems to work on some versions of the S60 emulator. Also if you plan to rebuild your app while the emulator is running this won't work because the emulator will exit as soon as your app does.
In Carbide 1.3.1 we'll be looking into better ways to adjust the default behavior and determine when it is OK to offer this launch option. Let us know if you would like to see Carbide offer any other options when launch an emulator debug session.
If you are a power user of Carbide or simply poking around the tools, you will notice the new window that is available and functional for emulation debugging in Carbide v1.3. You can access it via the toolbar 'Window'->Open View->Modules View. Once open it will appear by default in the lower pane of the carbide, tabbed together with 'Console', 'Executables' view, etc. During a debug session it will be filled with the executables that are currently loaded into the emulator and you have the projects that build these executables in your workspace or added them to the "Executables" tab of your launch configuration.
Some people may be confused by this window, since it resembles the 'Executables' window functionality, that was well described in the blog by Ken in this entry.
The difference between these windows is that 'Executables' window has the list of all executables that are known to the Carbide, no matter whether they are loaded into the emulator or not and it is always filled and independent of the debug session. 'Modules' view will only be filled with the information during the debug session. This is so called run-time information about the debugging target. And the purpose of it is to show what is running on target that the debugger knows about and has control over. It will not show you the list of files, beloning to the executable but rather the list of methods and other symbols. Ever wondered why your breakpoints are not being hit?
When debugging with TRK you will not get this information in v1.3. I am adding this support now. And it should be there in v1.3.1. Please, let us know if you are confused or not sure if this view is really necessary or helpful or creates more confusion rather then provides useful info.
They say that a picture is worth a thousand words. So to help customers in renewing support contracts and upgrading licenses, we've created a screencast for such problems:
You can find this and other videos at: http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos
Got ideas for screencasts you'd like to see? Leave us some feedback here and we'll get on it!
It was mentioned previously that pressing CTRL+3 is the key to finding information in Carbide. If you haven't used it yet then you are missing out on a major Carbide capability that makes finding views, commands, menus, and so much more quick and easy.
Press CTRL+3 to open the Quick Access dialog shown below.
Though Carbide C++ is a C++ development environment, I am sure that many developers develop Java apps for s60 as well. We had a weird problem when reading a large file into a java byte array. Despite the fact that I had 1 GB allocated to Java VM, I was getting 'Out of memory' exception when trying to create 100MB byte array. The solution to this problem is to use a MappedMemoryBuffer class from nio package. It doesn't allocate the memory but instead maps the memory buffer to the file in the file systems. It is even more useful for the s60 development, since the available memory on the devices is really small. It is nice to use nio APIs for s60 Java development!
A new bug came in this week that described a problem where breakpoints were not working in Carbide's debugger. These problems can sometimes be difficult to describe and reproduce so I started by carefully reading the detailed description. Then I noticed that the bug had a movie attached: This was great! I got some snacks then sat back and watched the whole breakpoint problem happen. I picked up a couple helpful extra details from the video and spent the next couple days fixing the problem. So feel free to attach repro movies to your bug reports, especially if you are trying to describe a sequence of events that lead to the problem. But please keep your entries in the short film category, if everyone starts posting lengthy epics we'll quickly run out of server space.
Okay, now that you have the correct set of key bindings in place its time to move on to customizing some perspectives. You did read the One key binding to rule them all entry, correct? Of course, the intent was to get you thinking about what else might be customized in Carbide to better suit your work environment. Well, read on to find out more.
Continue reading "Someone needs a new perspective" »I was down in Houston a couple of days ago to renew my passport and had some time to reflect on the right and wrong ways to deal with bureaucracies while I was standing in line. I was able to watch supplicants both prepared and unprepared as they wended their way through the system. Those who knew what was needed and had gathered everything ahead of time handed all their info over at the front and were zipped through the process quickly. The others tended to leave unhappy, to return hours or days later and start all over again. Those who fought the system trying for special treatment tended to make things even worse for themselves. The passport workers weren't vengeful or arbitrary about it, but they had a known, established way of doing things and anything that upset that routine affected their efficiency and made them fall behind, so it was in their best interest to route everyone through the same channel.
It seemed somehow familiar to me, and then I noticed the similarities to developer support. Just like the passport office we have a recommended procedure, there are ways to do a bit of advance prep to get faster responses, and attempts to circumvent the system frequently end in tragedy.
Continue reading "Working the Bureaucracy" »Some customers have experienced problems with not being able to hit their breakpoints in the server side of their application on the device. They sometimes see their breakpoints marked as unresolved in the server process and the server program does not stop at the breakpoints. Conversly, they've noticed that debugging the same program in the emulator works properly.
The fix to this problem often has to do with the setup of how they are trying debug the server process. If debugging a server launched by a client, you must attach to the server process using the Symbian OS Data view in order to hit the breakpoints in the server. Alternately, you can launch the server and client as two independent EXEs using the same COM port and debug them that way.
The main reason that it works in the emulator is because there is only one process (i.e the emulator and all the other exes running in the emulator are actually libraries). So this explains why the process of accomplishing this is different on the emulator vs on-device debugging.
We use the Eclipse platform and the Eclipse C/C++ Tools project (CDT) as the base platform for Carbide. Both of those projects have their own release schedules that are different that Carbide’s so when we have a major release of Carbide we get to move up to the newest versions of Eclipse and CDT. The next version of the Eclipse platform has just finished a development milestone (3.4M6) and you can see the new stuff here.
We hear two conflicting desires from our customers regarding the Eclipse projects: one is to use the latest release builds without modification and the other is to fix the issues they care about.
So far we have been able to find a balance: we usually don’t modify any of the Eclipse platform but we have released Carbide with a modified version of CDT. This means that we may have to live with issues in the platform longer than we would like but these are usually are not as serious for us as the things we want to fix in CDT. Each time we have found a compelling reason to make some late changes to CDT but we’re doing less of this with each Carbide release so eventually we hope to be able to ship CDT unmodified as well.
Without doubt, besides the eclipse editor, the Team features (version control) are the most often used features in my daily development grind. Given that, I am doing mostly java development these days writing Carbide plugins and test suites. For java development, version control is pretty straight forward. It's not quite so simple for Carbide development, but it can be done with just a little more effort. So at the risk of over simplifying or generalizing I'll give you a couple of ways of working with version controls systems and some things to look out for. I can't speak for all version control systems (we use CVS) but I think once you get version control going under an eclipse environment you'll wonder how you lived without it.
While our main focus is on our most recent Carbide.c++ 1.3 release, we still have some customers using our version 1.2 tool. Some of those customers who are using the Express product are coming across an issue where it reports the error:
----------------------
Operation failed:
Carbide feature: Carbide_Sys_TRK
Carbide description: System TRK Debugging
Cannot find license file.
-----------------------
Along with all the other updates in the new tool, this has been fixed in v1.3.0. So to get around this issue or to check out the new features, download the new version from: http://www.forum.nokia.com/carbide_cpp.
Old habits are hard to break, especially the use of favorite key bindings that people use in their current IDE to create, build, edit, and debug Symbian programs. In many cases the muscle memory has had years of repetitive use to reinforce certain actions. Being forced to change those habits can add an additional layer of frustration when trying to learn a new tool. We've stepped up to this challenge for users who are coming to Carbide from other tools by adding familiar key binding schemes that won't force you to abandon your old habits.
For a while now we've gotten occasional reports from developers that couldn't get Carbide to launch. When they try, they see an error like this:
JVM terminated.Exit code=-1 -Xms40m -Xmx1024m -XX:MaxPermSize=98M -Djava.class.path=c:\ProgramFiles\Nokia\Carbide.c++\plugins\org.eclipse.eguinox.launcher_1.0.1.R33x_v20070828.jar -os win32 -ws win32 -arch x86 -showsplash -launcher C:\ProgramFiles\Nokia\Carbide.c++ v1.3\carbide.c++.1.3.exe -name Carbide.c++.1.3 --launcher.lidrary C:\Program Files\Nokia\Carbide.c++ v1.3_2\plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.0.1.R33x_v20071019\eclips_1021.dll -startup C:\Program Files\Nokia\Carbide.c++ v1.3_2\plugins\org.eclipse.equinox.launcher_1.0.1R33x_v20070828.jar -vm C:\ProgramFiles\Nokia\Carbide.c++ v13\jre\bin\client\jvm.dll -vmargs -Xms40m -Xmx1024m -XX:MaxPermSize=96M -Djava.class.path=c:\ProgramFiles\Nokia\Carbide.c++\plugins\org.eclipse.eguinox.launcher_1.0.1.R33x_v20070828.jar
The workaround is documented in the online help, but if Carbide can't be launched that makes reading the release notes somewhat challenging. Given that, I wanted to throw this out here so that developers with decent Google skills can find the solution.
We have not been able to reproduce this problem in-house, but there is a way around it. In the main Carbide.c++ directory there is a file named carbide.c++.ini. It contains some parameters that manage the Java heap size. The one you're interested in is the -Xmx parameter, which by default is set to 1024M (1GB of memory.) If you get the JVM error, try reducing this in increments of 128: -Xmx896M, -Xmx768M, etc. That should get you running. One thing to keep in mind is that if you reduce this parameter too much it could degrade Carbide's performance and could also cause out of memory errors in memory-intensive components like the Performance Investigator.
This is one of the features on which I get the least amount of support questions. It is either working great and nobody has any problem using it, or people don't use it often or somebody else in the company handles all the support questions and don't like to share it with the rest of the team:) Honestly, we'd like to get some more feedback on this feature and I'll try to explain here things that we are planning or considering for the next update.
Right now, Performance Investigator generates a trace sampling output file on target device and users have to somehow transfer this file from the target to their PC and then import it into Carbide C++ part of Performance Investigator to see process/thread/function/etc. execution info and graphs.
We would like to make this process more user-friendly where target agent of PI would communicate directly to Carbide side of PI and possibly use the same communication channel that TRK is using for communication with the PC side Carbide debugger. This way user could see run-time profiling info. Ideally this could happen at the same time user has a debugging session going, despite the fact that stopping at a breakpoint will cause an interruption in user program execution.
Some other interesting ideas are related to general profiling:
- Enable PI to detect deadlock/starvation situation in a user program (my favorite)
- Enable PI to detect memory leaks
If you have a great idea to improve PI or simply would like to use it in your development with Carbide, please tell us what you think.
The Carbide.c++ SDK provides Eclipse plug-in developers access and control of the Carbide.c++/SymbianOS project and build environment. Check the Carbide.c++ Help contents under Carbide.c++ Plug-in Developer Guide / Getting Started for information on setting up an Eclipse development environment for building upon the Carbide.c++ SDK. Because Carbide.c++ is based on Eclipse and Java, a large library of plug-ins and libraries are available to assist Carbide.c++ plug-in development.
As an automated test developer for Carbide.c++, I am essentially a Carbide.c++ plug-in developer. Using the Carbide.c++ SDK, Abbot.swt, Eclipse and its libraries, I write Carbide.c++ plug-ins that, when installed, can run Carbide.c++ through a grueling hours-long automated validation. There is almost no limit to what can be accomplished from within an Carbide.c++/Eclipse plug-in.
I know of efforts outside our group, within Nokia and outside, to create Carbide.c++ plug-ins to integrate necessary tools into Carbide.c++ or to better integrate Carbide.c++ into thier build environment. I hope to cover Carbide.c++ plug-in development more in future entries, to encourage more Carbide.c++ plug-in authoring, and to ask for feedback on what type of plug-ins customers wish Carbide.c++ had available.
