Lx-Viewer logo
06:55, 22nd December 2024

Page Index

  1. Perl script for testing with
  2. Compiler verification
  3. GDB
  4. Unit testing
  5. Valgrind
  6. FlawFinder
  7. Program modifications for testing
  8. RPM building

Perl Script

This script needs assistance A Perl script is currently being written to allow the simplification of repeated tests on Lx-Viewer. You can download the latest version of the file testscript.pl from the sourceforge CVS, but it isn't terribly helpful at the moment. If you're a Perl wizard I'd love to hear your suggestions for improvement.

nb: need to add the following to the script: sucessful load yes/no, time spent testing, number of files tested, file opening time. To do - make how to use guide for tool

Various CAD format files are also downloadable as test data from the testing directory. E.g. DXF, DWG, SVG and RML files

Compiler verification

GCC can be set to ANSI standards mode with verbose reporting using commands such as:

gcc -pedantic -ansi -std=c89 filename or another example:
GCC -pedantic -std=iso9899:199x filename

This isn't very useful due to the Qt libs we link to generating heaps of errors but if you want to try this follow these steps:

This technique is hence currently useless. If you know how to resolve it, let us know.

GDB

GDB IBM does a great tutorial Linux software debugging with GDB

As explained by a member of my local LUG t (NB: You'll need ElectricFence install for the -lefence)

Put -lefence as the first argument to ld/gcc when linking your program, and run it in gdb. e.g.
export CFLAGS="-pedantic -ansi -std=c89"
export LDFLAGS="-lefence"
Any overruns will cause SIGSEGV during the memory write.

After that you can run with $EF_PROTECT_FREE=1 to cause a segv when writing to free()ed areas of memory and $EF_PROTECT_BELOW=1 to catch underruns (but not overruns).

Just be warned that it uses up huge amounts of memory and the core files can be hundreds of megs if you don't run it in gdb.

need step by step instructions here that anyone can folow

Unit tester

Is this relevent to the program? - need to research further - can you help?

Example command using cpp unit tester
cpp-3.2 -E -std=c89 main.cpp

Valgrind

From the Valgrind website

Valgrind is a GPL'd tool to help you find memory-management problems in your programs. When a program is run under Valgrind's supervision, all reads and writes of memory are checked, and calls to malloc/new/free/delete are intercepted. As a result, Valgrind can detect problems such as:

For testing Lx-Viewer the following should be appropriate: (Thanks to Paul Robertson for the information in this section)

In order to get really useful feedback you need to run a version of the program built with debug information.

  1. If you build from source using the project file then you need to change the CONFIG line in the .pro file to say "debug" instead of "release"
  2. Run "qmake", then "make clean", then "make"
  3. If you build from a makefile then just add "-g" to the CFLAGS or CPPFLAGS or whatever sets all the compiler switches need to explain this better
  4. Execute valgrind with something such as
    valgrind --leak-check=yes -v viewer 2> errors.txt
  5. Then look at the valgrind output for references to our own source code, rather than obscure stuff buried deep within Qt or X, eg:
    grep -i -A 2 "viewer" error.txt
    Which will show 2 lines after the viewer binary is mentioned could also give a downloadable suppression file for valgrind here

need step by step instructions here that anyone can folow

Flaw Finder

From the Flaw Finder Website:

[...] a program that examines source code and reports possible security weaknesses ("flaws") sorted by risk level. It's very useful for quickly finding and removing at least some potential security problems before a program is widely released to the public.

Usage: $> flawfinder dirname_of_source
e.g. $> flawfinder /home/me/viewer1.0.2

Example output from the 1.0.2 Lx-Viewer code is available

Modifications for testing output

The CVS contains a modified version of the file drawingboard.cpp in the testing directory. This contains a slightly modified file output when a file refuses to load which can be used in a testing script. This is intended to be used with the testing shell script

RPM building

To build you own RPM for your distribution you need the complete sources (including the OpenDWG libraries) and a file called a spec file which gives all the settings required for installing and uninstalling an RPM.

First download the lx-viewer source file. untar and unzip it with

tar -zxf lx-viewer-1.0.2.tar.gz

Then download the OpenDWG viewkit and toolkit, place them in the newly created viewer0.99e/viewer/OpenDWG directory and unzar and unzip them both. We only actually need a couple of the files but the others just won't be included in the compile.

Now thats done, drop down to your base directory and zip the sources all back up again with

tar -zcf lx-viewer.tar.gz lx-viewer1.0.2

Where lx-viewer.tar.gz is the outputed file and viewer1.0.2 is your directory created when unzipping the sources.

Now get the spec file (the spec file is not perfect) and download it to your directory. Now you're ready to go. Su to root and use the following command:

rpmbuild -ba spec lx-viewer1.0.2.tar.gz

where spec is the spec file with all the settings and the lx-viewer file containsall the sources (including the OpenDWG libraries)

The screen will fill with messages and at the end (30mins) you will have an RPM package appear in /usr/src/RPM/RPMS/i586 or whatever your gcc compiles for.

Note: If you get lots of error messages, you probably need to alter the spec file. Let us know you had to do this and what distribution you're running.

References:

t Cheers Adam Langley - have a link on us.

Page last modified: 1 January 1970 00:00