Report Bugs

The original savannah bug tracker GNUstep Bug Tracking database is considered legacy, it is there only as reference and to gradually close bugs, but please do not add new ones.

Bugs should be reported as issues on GitHub, each sub-project has its own issue tracker.

As a convenience, here some shortcuts to the most used projects:

Core libraries:

• Base Issues
• Gui Issues
• Backend Issues
• Objective-C 2 runtime library Issues

Development tools:

• Gorm issues
• ProjectCenter issues

User tools:

• GWorkspace issues
• SystemPreferences issues

Alternatively, you may report bugs by sending a message to bug-gnustep@gnu.org.

User testing is vital for improving GNUstep, so please report any bugs you find!

What to Report

Please include as much of this information as possible when submitting your report:

• GNUstep version and snapshot date or date of last update from GIT (ideally, on finding a bug you should update your system to the latest version in the GIT repository, in order to avoid reporting problems that have already been fixed).
• Machine/Operating system on which you are running
• Compiler version and Runtime you use (GCC, CLang)
• A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
  • If you have a problem configuring the libraries, please send the config.log file
  • If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: make messages=yes > output.txt 2>&1

The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is. If possible, the test program should be in the form of a testcase (to be built/run using the gnustep-tests script) for inclusion into the testsuites - such testcases can readily be run on MacOS as a reference platform so that we can tell what the correct behavior is.

If your problem is that some API from OSX 10.5 or later is unimplemented, please label it as a 'Feature Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.

Sending Fixes

Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (diff -u oldfile newfile > file.patch) program to do this. For new APIs, provide header changes as well as source code changes, with macros bracketing the changes to specify which version of OSX they correspond to (see existing headers or examples) and comments in the headers documenting the behaviors of new methods etc. For both bugfixes and new functionality, please, please, PLEASE provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code. Without testcases it's much harder to review patches, so if you don't provide testcases, your patch may simply be ignored. Testcases are executed using the gnustep-tests script from the gnustep-make package. Add a ChangeLog entry in front of the diff file, and send the whole thing (patch plus testcases) to the bug database.

If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type M-x add-change-log-entry and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]):
Remove double_release checking. Increment released_count after
setting released array. 
([NSAutoreleasePool -dealloc]): Catch release errors. 
([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method.

* src/NSObject.h ([NSObject -autorelease], [NSObject -release]): 
Add double_release checking. 
([NSObject +enableDoubleReleaseCheck:]): New method.

* src/Foundation/NSAutoreleasePool.h: Remove 
+enableDoubleReleaseCheck:, add +autoreleaseCountForObject:.

* src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:.

* src/Foundation/objc-load.h: Include objc-api file.

One thing at a time

Please try to ensure that, you only address one issue at a time (ie try to ensure that different issues are kept clearly separate, not bundled together) and address complex issues in stages, completing one stage before going on to the next. This keeps things managable, and allows other people to understand/address the issues efficiently and quickly.