Testing the Drawing Module: Part 1

After initial round of testing, we discovered a re-occurring crash when you tried to open a newly created page. The result of last nights work this is now fixed. For those unfamiliar, in the FreeCAD_sf_master directory run 'git pull'.

If you have any comments after testing the drawing module, please also consult this forum topic

-------------------------------------------------------

I haven't managed to do much recently. Work has snowballed and I've been having to work on a binary file converter for an Additive Manufacturing Machine. The experience from that I can imagine may be quite useful for writing and parsing other file formats if we ever need to in FreeCAD. I never would have thought I would read binary numbers as an engineer...

It appears there is a demand for testing the Drawing Module. It's in the stage where I any testing would be quite helpful, mainly to get feedback on the user interface and push this into the master for testing. I am aware there are some deficiencies both in missing features and bugs, but I need some motivation to finish up the GUI to make it more user friendly. Input on this would be helpful. In particular GUI mocks - hand drawings on tissue paper are accepted!

Note: Windows testers would be helpful!

 The idea of this post is to give a brief overview building FreeCAD to test out the Drawing Module.

mkdir test && cd test

The run "git clone http:://repositoryaddress" like the below to clone my Github repository into your testing directory.

git clone https://github.com/mrlukeparry/FreeCAD_sf_master.git

It should look like below. Cloning FreeCAD shouldn't take too long (it's about a 70mb download).

Ensure you have the prerequisites for compiling and building FreeCAD - consult either the wiki

or if you are really ensure ask on the forums. 

You now need to checkout out the drawing branch 

cd FreeCAD_sf_master && git checkout origin/drawing

You should now be on the drawing branch in a detached state. 

Now we create a build directory outside of the source directory and then we configure using CMake

You now need to checkout out the drawing branch 

cd ../ && mkdir build && cd build

Now we build using CMake. The options that you pass may depend on your platform or distribution. If you have problems please consult the forums. Configure the build using debug options for testing:

cmake - DCMAKE_BUILD_TYPE=Debug ../FreeCAD_sf_master

Eventually you should be configured and ready to build. All you then have to do is run make. To build faster, the option 'j' is the number of make jobs to run in parallel - set this to CPU cores + 1

make -j 7

The build procedure can take between 10-30 minutes depending on your computer specification. An SSD helps considerably more so than memory. Once built you can easily test FreeCAD without having to make an installation. 

In the build directory you can simply run FreeCAD

./bin/FreeCAD

To use the Drawing Module change the workbench once you have a part.

Part 2 to follow! 

I think I will try and record a screen-cast for the next guide.

A bit of fun on the side: Compiling with Clang

In the other bit of spare time I have considered looking at compiling FreeCAD using Clang. The end result is that only a few changes are needed to be made to the FreeCAD source so that it compiles with Clang.It doesn't seem to affect building using g++ either. I haven't measured the performance yet, but noticeably compiling takes less time.

I still need to collect these changes and post a patch for this and allow other people to test it out for themselves. I also have to find how I can debug FreeCAD after compiling with Clang - it appears to be incompatible with GNU's gdb.

Other Progress (slightly off-topic):

Workload seems to have increased once again at University. I spent a bit more time at the weekend on the Drawing Module: the majority of the work is looking at projecting faces onto the drawing plane. This is relatively similar to before but requires further work to sort edges into order, store these in a general format and then drawing using Qt's painter system. There's still work to do, but when I get that complete can hopefully share it.

What is Clang?

Clang is an alternative compiler that use LLVM to compile a variety of programming langaguesusing runtime optimisation methods. LLVM is used heavily in Mac OS X to improve graphics performance applications, but is also used in a handful of open source projects - in particular Open Source graphics drivers. LLVM provides the possibility to compile many different programming languages from Python, Fotran, OpenCL and importantly for this post c / c++.

Clang provides the infrastructure for compiling c++ and aims to offer a better alternative to gnu's gcc in terms of performance, better usability to developers and other advanced features such as static code checking. I won't say much more, but it seems a good alternative and therefore I decided to look at compiling FreeCAD using Clang.

What I did?

1. Install Clang
2. Change default compiler for make tool chain
3. Change some of the check inside CMakeList.txt file
4. (Ubuntu) Add a symlink for libgfortran for the linker to correctly work

Selecting the default compiler for your system (Ubuntu)

Most importantly install clang on your system. It seems that with Ubuntu installing clang introduces a an unwanted dependency of  gcc 4.6. Once installed, depending on your system you can inform Cmake explicitly to use clang or alternatively you can change the system wide default for make to use the clang compiler.The first option is obviously the most sensible, but I am not sure of the command.

The only help I have seen on setting the compiler is the following stackoverflow question:

In Ubuntu, it is straighforward to update the system wide compiler use for c++, simply run

sudo update-alternatives --config c++

This will bring up an interface to select the compiler you wish to use:

I need to post the patches to CMake, hopefully soon and these can be verified by other users. 

Following this, configure using cmake and then attempt to build using clang. You may notice that there is a linking error for lgfortran and then the build system fails. I think this is an issue with Ubuntu, but to solve this I had to create a symlink to gfortran library which isn't very convenient.

sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.so libgfortran.so

Hopefully FreeCAD should happily compile very fast now at blinding speed!

----Update---

I have spent some time last week to look at some further details.

Compiling using Clang per project:

There is an advanced option within CMake to specify what compiler to use for c and c++ per project build. Fortunately KDevelop makes this rather easy: Open Project Configuration by right clicking on the project to open the following dialog:

Click 'Show Advanced Values' and then set the following variable:

• CMAKE_CXX_COMPILER  = /usr/bin/clang++ 
• CMAKE_C_COMPILER to /usr/bin/clang

Compiler flags can be conveniently set in CMAKE_CXX_FLAGS, where for both gnu compiler and clang -g is for full debug.

Specifying Variables in the command line

It can also be done in the command line - I found really straightforward Guide for setting Variables in Cmake from (http://www.llvm.org/docs/CMake.html#id8)

Variables are set quite easily - simply prepend -D before the variable name and assign the value like so

cmake -DVARIABLE=value

Alternatively, you can specify the type of the variable below:

cmake -DVARIABLE:TYPE=value

Debugging with Clang:

Unfortunatly there is currently a bug that is preventing gdb being used with clang, which is apparently fixed in the latest release. I tried to get this too compile but I encountered errors. Hopefully with the next release of LLVM and Clang 3.3, the issue will be resolved. 

Compile OpenCASCADE Community Edition the Easy Way! (Update)

Introduction:

After a very late last night as a result from the following: splitting my head for three hours on Finite Element Modelling and for some reason watching Back to the Future:Part II whilst figuring out some code for the section plane, unbelievably I managed to wake up reasonably fresh.

Before starting on the chore of further University work this afternoon. I've been playing with compiling OpenCascade Community Edition in attempt to remove the shackles of Ubuntu's dictated policy of offering old packages.

All of this was inspired by a message on IRC #freecad over the past week about compiling OpenCascade with debug flags, so we actually have useful output when OpenCascade crashes without a warning (mostly from an unhandled exceptions on our part).

Benefits:

• The other benefits are testing some new features - only recently has a commit been made to improve performance of boolean operations that will soon be merged - see discussusion
• Full debug build so we can trace crashes correctly
• Living life on the edge of your seat!

The first compile went really well, however, after attempting to compile FreeCAD I found that there were a few missing libraries that prevent FreeCAD from building. These were the visualisation and Model Exachange packages used by SMESH and Part for the IGES and STEP formats import.  I am not sure if these should have been detected by FreeCAD's cmake but anyway, trial and error prevails.

I also attempted to build OCE using TBB which is a threading library that can be used to speed up operations, however from what I read this is only used in a few algorithms.

Note:

Compiling OpenCascade does take a long time, around probably 50% longer than FreeCAD for a clean build. On my six core AMD Bulldozer computer, it took in the region of 18 minutes in total to compile with each core at 100%. Also remember that you will need additional time to compile FreeCAD again. Once this has been done, recompiling is very quick.

Be prepared to find something useful to do in the mean and drink tea or even a beer for a good half an hour.

Compiling OCE OpenCascade Community Edition (Easy Guide):

Reminder: expect 20-30 Minutes to compile:

Clone the repository:

Grab the latest git source from the official Open Cascascade Community Edition from the github page. The source is around 240mb when fully expanded and may take a while to download on a slow internet connection.

git clone https://github.com/tpaviot/oce.git

Create a build directory:

Create a suitable build directory, this can be in the main source folder but preferably outside to prevent potential conflicts

mkdir oceBuild && cd oceBuild

Install libftgl-dev in Package Manager:

You need to install following development package for libftgl to compile the Visualisation Package in OCE. This will depend on your Distribution. 

Install libtb2 & libtbb-dev in Package Manager:

For enabling TBB - Threaded Building Blocks Library to be used in multithreading, you will need to ensure that these are installed on your system. Below are the package names in Ubuntu.

Remove any previous Opencascade libraries provided by distro:

I don't think OpenCascade and OCE can be run in parallel on the same machine - correct me if I'm wrong. Therefore you will need to remove any of these on your system.  

Configure the sources using CMake

Configure the OCE sources running the following cmake command in the current directory. This will install OCE to your /usr directory. 

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/ \
      -DOCE_INSTALL_PREFIX:PATH=/usr/ \
      -DOCE_WITH_FREEIMAGE=OFF \
      -DOCE_WITH_GL2PS=OFF \
      -DOCE_VISUALISATION=ON \
      -DOCE_DATAEXCHANGE=ON \
      -DOCE_MULTITHREAD_LIBRARY=TBB \
      -DCMAKE_BUILD_TYPE=Debug \
      ../oce

If you're installing on Ubuntu or Debian based distribution, it's advisable to change the install directory to /usr/local to isolate user compiled packages (@yorik) - (I need to confirm if FreeCAD can detect the location of the OCE header files from the location)

-DCMAKE_INSTALL_PREFIX:PATH=/usr/local \

You may find that there are some missing development dependencies, so if there are you will have to install these using your package manager. I found generally if you could install FreeCAD you wouldn't experience any problems atleast on Ubuntu.

Create a release build (Improve Performance):

You may not want debug flags enabled so that you can have full compiler optimisations and full performance when using FreeCAD: change the line previously from

DCMAKE_BUILD_TYPE=Debug \

to

DCMAKE_BUILD_TYPE=Release \ 

Begin Compiling:

When you start compiling OCE  be prepared to wait a while. Replace 6 with the number of cores or independent threads that can be run on your computer to speed up compiling by running concurrent make operations.

make -j6 -pipe

There has been some discussion whether the '-pipe' argument can reduce compiling times. If someone has enough time to make a comparison with OCE it would be interesting to see the difference.

Install:

Usually I install any compiled software to my user directory, but that wouldn't be straightforward. Therefore CMake was configured to install to /usr directory for simplicity later on. 

sudo make install

Installing on Debain / Ubuntu Systems:

Another helpful hint from @yorik is to install using the built in utility checkinstall. This provides a convenient method of uninstalling OCE using the system's package manager. Once you have finished compiling, run the following command:

sudo checkinstall

Type (y) to accept the defaults, then you will be presented with a menu to further describe the package - do this at your own leisure:

Once checkinstall is completed - this will take a while, it will produce a .deb package and OCE will have been installed to your system and registered in your system package manager.

Recompile FreeCAD:

There will be changes to the development sources since we are using a different edition of OpenCascade with FreeCAD. You will need to clean all the sources. From your previous FreeCAD build directory make sure run the following before recompiling (see previous post on compiling FreeCAD :

sudo make clean

If OCE was compiled and installed correctly, whilst configuring FreeCAD you will find the following log message (OpenCASCADE Community Edition has been found):

Recompile once again and you should have FreeCAD working with the latest OCE!

Hopefully people will have understand the guide and will now have a working version of OCE that is is used by FreeCAD. If there seems to be problems or something isn't clear, please let me know and I will update the guide. 

Back to University. Back to FreeCAD. Updates

After my intermission of going on holiday in Europe (if you could call it that) , I am now back at University and have some free time to work on FreeCAD.

Coding Improvements to the Render Module:

The past few days I've tidied up the Render Module and improve the QML code to improve the quality of the UI presentation. In addition I have now implemented the saving and restoration of material properties, so this means for example you can save the 'colour' within the Matte material.

During mid-September inside the Render Module, I tidied up some QT and Coin3D GUI dependencies that existed in the core application functionality. These were trivial changes and other small coding improvements were made to the Render Module.

Building on Windows:

To give the Render Module a greater spectrum of Testers, we would like to get the Render Module compile on Windows. Work was done to implement class definitions that were missing.

There was a brief discussion on building using QT 4.5/ QT 4.6, which the current Windows Libpack includes. Unfortunately this doesn't include QML or/ QtDeclarative Modules, therefore it isn't possible to build the render module on Windows yet. In practice this means that the Render Module will not be available till the 0.14 release, when we can guarantee that most Linux distributions will include this. However, this will give another 6 months of testing to ensure that this module contains more features and improve the quality through testing.

GIT Housekeeping:

Having been working solely on the Render Module over the past three months, in my own ignorance, I have refrained from keeping an updated revision of the FreeCAD source. I've now forked and cloned from the FreeCAD source mirror on github and have set up a new repository and merged the Render Module into a new branch:

This somewhat both complicates and simplifies keeping upto date with the FreeCAD repository and there is always the added difficulty of learning something new!

CAM Module:

I am looking into helping start an initiative to implement CAM functionality into FreeCAD with guidance from Daniel Falck and Brad Collette. Currently trying to work out how this system will work and draw up a structure for this. I will report back on this in short time.

Building a Computer and upgrading to OpenSUSE 12.2

Slightly offtopic.

Despite returning home over the past two weeks, my computer has been ill. It suffered from complete system crashes, which became apparent when making a video and compiling FreeCAD. I thought this was a memory problem because it was happening in Linux and Windows.

I decided that for 5 years, my computer has served me well through College and three years of University on heavy CAD and FE simulations and it was time for an upgrade.

I've been an Intel user all my life. Looking at the prices of i3-i5 processors, I didn't think they were worth it. I got marginal performance over my quadcore Q6600 for £100 spent. I decided instead to brave a new world of AMD. I purchased a 6 Core FX 6100 with 12mb cache, 8GB DDR 3 Memory and a Motherboard for £175. I consider that a bargain.

Setup was straightforward and I was upgraded within an hour. Windows worked fine after updating and so was OpenSUSE 12.1. I decided to do a live upgrade to 12.2 following these instructions This took a good two hours to find for some reason, but the process went very smoothly unlike terrible experiences I had with Ubuntu derivatives in the past.

Compiling FreeCAD:

Whilst upgrading, external repositories had to be removed. To my suprise FreeCAD nearly compiled straightaway. All the FreeCAD dependencies are now included in the default repo: I just had to include swig, python-qt4

# install needed packages for development
sudo zypper install gcc cmake OpenCASCADE-devel libXerces-c-devel \
python-devel libqt4-devel python-qt4 Coin-devel SoQt-devel boost-devel \
libode-devel libQtWebKit-devel libeigen3-devel gcc-fortran git swig

OpenSUSE 12.2 automatically installed python3-devel but this needs to be removed to successfully compile FreeCAD. We are hoping that we will update FreeCAD to use this with the successive 0.14 release.

FreeCAD now compiles blindingly fast: under ten minutes for a full compile and my system stays responsive in the background.

What will be interestesting next is to profile FreeCAD on so many cores. 

Debugging C++ using KDevelop

This is leading on from another post. Without being able to debug a program, it's very difficult to get anywhere or learn mostly from stupid mistakes and is a quintessential for making progress. Thankfully having a good IDE makes all the difference and I present to you how I use KDevelop to debug FreeCAD during development.

Debugging with KDevelop:

First ensure that you are compiling with debug symbols / information and set up KDevelop so that you can compile and launch FreeCAD successfully. Please see my previous post for information.

Open up KDevelop and then you can hit Debug.

The KDevelop workspace will now change to Debug Mode. It is more convenient to present tool panels that are more relevant to debugging than programming. The only frustration is that the Editor will not remember which file you have currently opened from the normal mode.

You can customise which tool panels are available by right clicking and selecting like so:

Useful tool panels for debugging are:

• Variables
• Breakpoints
• Frame Stack

Creating and using breakpoints using KDevelop:

FreeCAD will load, but can take slightly longer since the GDB debugger is launched and use to monitor the FreeCAD executable. Breakpoints allow you to control the flow of program at any point in time where you can:

• Pause on a line / statement (A statement is usually terminated by a semicolon, e.g. int i = 0;)
• Run each statement one by one
• Continue to the next breakpoint

By setting breakpoints, it allows the programmer to control to examine segments of code and check the behaviour of the program or complex algorithms. 

Setting a Break Point:

In the code editor window, look for an area of code that you want to examine and isolate a line where you want to pause the execution of the program. In KDevelop, click on the furthest area adjacent to the line to create a breakpoint.  KDevelop indicates when a break point is set by displaying a ladybird / ladybug.

Sometimes it is useful to set the editor to visualise the line numbers which can be done by enabling the option at Editor->View->Show Line Numbers

Now, run the program normally and attempt to 'trigger' the break point by performing an action that will cause the segment of code you want to be executed - sometimes that's not always straightforward! When a break point is hit, KDevelop will highlight this.

We have paused the execution of the program. We can control the flow by using the debug toolbar at the top.

Importantly, Step Over will run to the next statement on line 43 - this would be std::string path = hGrp...

Continue will run till it reaches the next Break Point, this could be set in the same segment of code, or in another completely different area of the program. So in the example below clicking continue would run all the program till it reaches line 48 - args.push_back(QString...

The other two I rarely use, but they will enter a function or exit a function, but often I found going directly into these function sources and setting my own break points are easier. All break points are shown in the Break Points tool view. These can be toggle on or off and can be deleted. 

*Useful hints:

• Remove all previous break points if you have recompiled FreeCAD with modifications to the code, or even just launching the program. I find it much quicker to launch FreeCAD in debug mode by doing this.
• The more editors tabs you have open, it appears to take longer to launch and consumes more memory.

Making use of Break Points:

When we stop the flow of the program, we can examine the current state of the 'stack'. KDevelop makes this exceptionally easy. We can find the current values of variables or properties of classes/objects. This can be done by highlighting over a variable or object using your cursor:

Alternatively you may use the Variables Tool View to examine all the variables accessible within the 'current scope' or on the stack. It presents a hierarchical tree and can present meaningful data for known variables types and classes within the project tree:

All it takes now is some logic and wit to figure out what is causing the problem. Sometimes it can be blindingly obvious and for other times it can take hours :( The more practice you get the easier it seems to become.

The Frame Stack:

This is most useful when you have a sudden crash.

 Conventionally a stack can be imagine like a stack of  dirty plates at a restaurant. When you enter a new program scope (e.g. run a body of a function) you add on a dirty plate (so the dirty food represents variables). Conversely, exiting a program scope you clean the plate and take off the stack of dirt dishes. I tend to imagine it like an onion, you must peel a layer to access the inner layer. 

You can view the current state of the stack using the Frame Stack Tool View, when a program crashes GDB will display the state of the frame stack to help identify where the crash occurred. This will be at Depth 0, but logically you may have to look higher up to understand why. Usually the current state of the stack variables can also be accessed using the Variables tool view. (*precaution GDB will crash if you attempt to access a null pointer)

Below the current program is on line 49 within the LuxRenderProcess::initialiseSettings method. This method was called in Renderer.cpp on line 363. It is simple as that. 

Hopefully this guide will help you get debugging and make learning how to program c++ within FreeCAD that much easier!

Using KDevelop to develop FreeCAD

Some hard core people bring themselves to use just a text editor, whether its VIM, or a standard desktop editor from Kate, GEdit. These have their places but when you're learning programming or working with large project, it's much quicker to have syntax highlighting/checking and code hinting so that you don't have to trudge through programming documentation. The additional tools for compiling make life much easier too.

One option is to look at the DOXYGEN documentation for FreeCAD. It's seldom used because its both incomplete and it's difficult to navigate without knowing what you're explicitly looking for.

For c++ programming, there are two alternatives, either QtCreator or KDevelop atleast on Linux unless someone can name some viable alternatives. Admittedly QtCreator is very good and is feature complete, for some reason it is incompatible (at least momentarily) importing projects using CMake (a build system). This essentially means you cannot read the source project tree and get useful programming hints, which without I think makes learning FreeCAD much more difficult.

Once you've installed KDevelop, it's very easy to configure the compiler settings. It's in built debugger is extraordinary especially for a newbie to diagnose crashes and above all is built in. The syntax highlighting and code hinting is generally good too. My only dissatisfaction is that sometimes it gets into the habit of crashing, but it's not a problem since it can recover unsaved files.

Here's a quick guide to help you getting it up and running to make your own opinion!

Using KDevelop to develop FreeCAD:

 Firstly ensure that KDevelop is installed and you've got a copy of the FreeCAD source to work with. Load up KDevelop as follows:

Click on Import Project to import the FreeCAD sources.

A dialog will appear. Go to the root directory within the source and then browse for the CMake project file CMakeLists.txt and click 'next'

In the next section you can specify where the FreeCAD sources are built under Build Directory. You can also set the build type. I would always recommend using the Debug build type so that you can easily debug the program for any faults later. Selecting the Release option will provide extra compiler optimisations that will improve FreeCAD's performance, but only significantly in certain areas such as the Sketch Solver. The other two options I wouldn't recommend.

Click OK and KDevelop will start importing the whole project. Further compiler and project settings can be changed under Open Configuration.

If you click under Classes tool bar you can browse the whole source tree which including other library headers. The Flying pink bricks indicate public methods. Icons with Pad Locks are 'private' class members and icons with keys are 'protected methods'.

Open  up a source file (.cpp) and try out the code hinting by pressing CONTROL + SPACEBAR. This will bring up a list of methods below which the class provides. How easy is that?

It can even help suggest the variables, objects that can be passed as arguments into a method:

Make a few little changes and the proceed to click Build Selection. 

This should start configuring your project and it may hint problems. Otherwise normally it will show the build progress in the Build Window as below:

Remember to speed up the build by using multiple cores, append -j4 under the Additional Make Options found in Project->Open Configuration->Make. Compiling usually takes between 15-25 minutes on a good day. However sit back, grab a cup of tea or continuing programming.

Finally Running FreeCAD from Kdevelop

Before running you need to configure the launches. This can be found under Run-> Configure Launches. A new dialog will appear. Choosing the executable FreeCADMain is really straightforward

Now back in the main window you can hit Execute to run normally. Alternativly you can hit Debug to run the application through the GDB debugger. I'll describe how to use the debug tools later!

Hopefully that might help you get started to make tweaks and changes to FreeCAD!

Help us test FreeCAD!

Last Updated: 06.04.2014

We need testers to give useful information back to us FreeCAD developers.  We know there are missing features and we wish we could grow additional limbs to increase productivity. Nevertheless, we want to produce something hight quality and when FreeCAD crashes we want to fix it. 

The more descriptive the information you can provide, the more easier and faster we can fix it. So here's a few hints to help test FreeCAD.

How to test a branch using GIT:

FreeCAD is now using GIT which is allowing more rapid development of features from contributors FreeCAD has mainline branches on source forge and from individuals. Firstly to test a feature, find the branch you want to test which can be found on the forums.

First ensure that you have git installed and also the correct development libraries - help is available on the FreeCAD wiki and Forum, but feel free to ask on the IRC channel #freecad

These will be 

Checking out a branch

Developers use github to track and share development more easily. Various modules I am developing can be found here on Github

When you've found the git address (at the top) in your console or terminal application create a testing directory and change into the directory.

mkdir test && cd test

The run "git clone http:://repositoryaddress" like the below to clone this repository into your testing directory.

git clone https://github.com/mrlukeparry/FreeCAD_sf_master.git

It should look like below. Cloning FreeCAD shouldn't take too long (it's about a 70mb download).

When it's finished it will create a free-cad directory. Change to this and you will be in the source directory. To switch to a specific branch (e.g. render) run the command below:

git checkout -b render

Now you can begin compiling!

Compile with Debug Information:

Compiling with debug information is more useful to report errors and doesn't cause too much slowdown. It is first a good idea to build outside the source directory. So make a new build directory like...

mkdir Build && cd Build

In the build directory we configure to build a debug version and we need to append "../" or equivalent to point to the source directory like

cmake - DCMAKE_BUILD_TYPE=Debug ../

Now you can run make and let it build.

make

If you have multiple CPU cores or have hyperthreading available, take advantage of this and build even faster by creating parallel build jobs. Add the argument -jN where N is the number of cores

make -j4

FreeCAD will begin compiling: A full compile of FreeCAD for me takes around 20-30 minutes.

Testing: when something goes wrong

If you find a problem. First try and find a definite way to replicate it. Otherwise it's very difficult to isolate the behavior. Once its repeatable, you can run a debugger like so: Browse to the bin directory and run the command from terminal / console:

gdb FreeCAD

This will use the GNU debugger and load the program symbols and present to you a console. Next run the command to disable real time messages

handle SIG33 noprint nostop

Then type 'run' to start debugging FreeCAD. 

run

Replicate the crash and when it becomes unresponsive, back in the debugger you can run 

stacktrace

Use a pastebin site and then give this back to the developers to figure out with additional information on IRC or the forums. 

Additionally take a look my valgrind post to help further.