Problem resolved with NetBeans+gdb

Apparently NetBeans is still burdened with some issues when it comes to C++ and gdb integration. I previously described changing the project tool suite from Cygwin to MinGW and back to Cygwin. This came about when gdb just mysteriously stopped working. Then I completely rebuilt my project from scratch. gdb working again. Adding files back to the project one-by-one and checking in changes to source control. Oh no gdb not working again. Back out the last set of changes. gdb still not working !@#$@!#$@!#$#$#@$. Try a new simple project.. gdb working. It must be something I've screwed up in my real project settings. I'm new to NB so looking at the project.xml isn't helping much, but strangely enough I can't even find anything change in my project xml files.  OK, do a clean checkout from source control, even my comments in the log say proudly "gdb is working". But gdb is not working even on a fresh checkout. WTF WTF WTF. OK ... nothing works right on Windows. Set everything up in Ubuntu. gdb working! Curse you Windows you have cost me a week on this stupid issue. Happily debugging my project now. WTF WTF WTF gdb is not working. Try cleaning out the project again. Restart NB. Restart Ubuntu. No joy. Open up  Debugger Console in NB. There's that message again "internal-error: is_thread_state: Assertion `tp' failed" Back to the web.... when I read the phrase 're-add all my watches" in the bug report, it suddenly struck me that it was setting the watches that was killing gdb. (I never made the connection before because I had actually been able to get through a couple runs of the program with the watches working before gdb croaked.)

I guess the upside of all this I got REAL familiar with the project files and settings in NB. Actually, while I was running in Ubuntu, I noticed the ".netbeans" in my home directory, which must be where NB would have stored the debugger configuration i.e. breakpoints, watches, etc. Thus explaining why the gdb fault condition could not be fixed by checking out a fresh copy of the project.

One thing I haven't determined if any of this is related to the fact that I am using the capability of NB to integrate with CUnit.

Cygwin or MinGW with Netbeans?

On Windows, there are two options to use the GNU build system: with Cygwin and MinGW.

There are valid technical reasons why one might prefer MinGW over Cygwin. In fact, there even seems to be some issues with NB and gdb in the Cygwin environment. My first experience with NB seemed to go pretty well - I was able to debug into unit test modules created with the CUnit framework. I did however observe one odd thing in that I was not able to use the Debug 'Run to Cursor' (F4) feature - I get a popup box with the warning message "No source file named D.". I believe this is related to the bug. On my system, gdb -v shows the following:

$ gdb -v
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)

I went ahead and switched the project to Mingw.


Follow instructions to setup MinGW Compilers and Tools.

Now the problems start.

Our project code (target is dsPIC30) is not compatible with gcc 3.4.x.whatever in MinGW for a couple of reasons. One is the use of newer compiler directive "-Wno-attributes". Another is the use of binary literal constants in the code.

Anyway, I  installed GCC 4.3.3 for Windows and it seemed to take care of those issues.

As I mentioned previously, it is necessary to revert to CUnit-2.1-0 to achieve complete integration with NB.

You might think you could try to simply download a pre-built binary of a CUNIT build for windows ... but it is probably linked against different libc libraries that won't be compatible with the MinGW you have installed.

Building CUnit from the sources is straightforward (the "configure-make-install" process) but that does require availability of automake/autoconf tools on your build system. I had to go ahead and Install MSYS DTK 1.0 as per instructions on the MinGW site.  (If you followed the instructions from NetBeans to the letter then you probably did not  "install the DTK or the core files mentioned in the wiki page").

Here we go ... Oh goody, more errors:
configure.in:4: error: Autoconf version 2.58 or higher is required

I found some advice on the web about updating packages in MinGW.

Installed msys-autoconf-2.59.tar.bz2 (updated autoconf to version 2.59. ). In MSYS window:

cd /
tar xvjfp /d/dload/msys-autoconf-2.59.tar.bz2


Compiled and installed CUnit from source (configure --debug)

Add the paths for CUNIT library and headers to my project:
../../../../msys/1.0/local/include
../../../../msys/1.0/local/lib

Now I can debug into the Unit Test module. However, the test runner seems to go out into the weeds. After debugging into CUnit, I find that the code hangs up on the following:

"fprintf(stdout,  ..." f_pTestStartMessageHandler

At this point, I am pretty disgusted with MinGW, give up and go back to Cygwin!

It seems that I have somehow deleted the CUnit libraries and header files that I had previously installed into my Cygwin environment. After rebuilding and reinstalling CUnit, and rebuilding my code, I find that I have some compilation errors in my project which hadn't been there before when trying to run the unit test module (Alt+F6):

build/Debug/Cygwin_4.x-Windows/main_nomain.o: In function `bswap_16':
/usr/include/byteswap.h:20: multiple definition of `_bswap_16'


The errors aren't there when running the main project (F6).

I find that the error is precipitated by the presence of the standard  #include :

#include 

... so if I need to print or open files I'm screwed!.

Better way to access share folder in VirtualBox

I should make an addendum to comments I made some time ago regarding setting up a VirtualBox share folder. At the time, I had found a work around was to simply remount the share folder with the uid/guid of my user account. However, I realized recently that the more better righter way to do this would be add my user to the vboxsf group. This is easy to do:

sudo usermod -a -G vboxsf myuser

The result: VBox can automatically mount the Share Folder, as shown here...

Factoring out some drudgery from Unit Testing

I discovered that there is a nice set of features in NetBeans to automate some (but not nearly all!) of the grunt work associated with software Unit Testing. This is my first experience with NB, and I am very impressed with the degree to which Unit Testing work flow is incorporated into theNetBeans IDE. NB provides built in support for the C Unit Testing Framework (in addition to its own built in "Simple" Unit Testing framework).

Unfortunately, NB doesn't completely work with the latest C Unit (version 2.1.2). I got past this issue by building CUnit 2.1.0 from source code, which may introduce yet another issue. If NB complains that the cunit library is not detected, it is because the C Unit library and/or header files have not been found in the expected locations. The C Unit source is set up to install C Unit libraries and header files under /usr/local by default. Rather than changing the default CU install locations or changing the default path settings in my NB project,  I simply made a couple of sym links to fix things up:

ln -s /usr/local/lib/libcunit.a /lib 
ln -s /usr/local/include/CUnit /usr/include

(or alternatively, just add the lib and include paths under Project Properties C Compiler and Linker configurations, and ignore the warning from NB that cunit library is not detected).

The result...

C Unit reports out through NetBeans!

Update 9/18/2013:
Found this post  advising the use of CUnit 2.1.0 due to incompatibility of output format with NB 7.0
Now running CUnit 2.1.2.with NB 7.3 without issue. CUnit and CPPUnit both installed from Cygwin.

Simulink Fun

In my day job I write software for embedded control systems - actually most of my time in the last few months has been spent spent working with Simulink Coder. I put a question out there several weeks ago, to which a usable answer was provided within a surprisingly short time. However, only in the last few days has my Simulink expertise advanced to the point to where I actually understood how to get this to work. I already knew how to define mpt.Signal objects with attribute ImportedExtern which would pick up the actual definition from legacy code. But objects defined that way would not be accepted by Simulink as inputs to a Table Lookup block. What I finally realized was that those objects must be defined as mpt.Parameter instead. I also discovered that using n-D Lookup Table (instead of the simplified 2-D Lookup Table) offered some additional flexibility, such as allowing input table data of integer type (as opposed to the default double precision type).