Reporting a bug
If you find any bugs, or if you experience any crashes, then we would very much like to hear about the issue. Here are some detailed information on how to submit useful bug reports.
Follow the bugs policy.
Is it truly a new bug?
It may sound strange, but many of the bug reports we get are not really bugs at all, or have been know for months, and/or already fixed.
Please check the following:
Are you using the latest version of RetroShare? Bug reports on older versions of RetroShare are likely to be ignored, because changes in the program may make it impossible to reproduce the bug, or may even have fixed it. Always make sure the issue you want to report is still present in the current version of RetroShare.
Some things are simply NOT implemented at RetroShare. We have a RoadMap we would like to implement in the future. If your suggestion is not on this list, you might want to make a feature request in the Requests Forum or add your Feature Requests on Feature Requests Tracker too, to ask the developers to support this. Remember that we all do this in our spare time. There is no timeline whatsoever for the implementation of these enhancements and we do not make ANY promises as to when we will add them to RetroShare, if ever. If you really want something right now, you had best implement it yourself. Join us on the Developers Corner
Many bugs are already known. Sometimes they are already fixed for the next version of RetroShare. Please look here the list of known and fixed issues. If you find your issue, see if it is already closed. The page of the issue will then show something like:
Still a bug?
So you still think you found a bug? Great!
What If I Have a Crash/Bug?
The developers need your feedback. On Gnu/Linux, you can do this by;
1. build RetroShare as describe elsewhere.2. Run RetroShare in a special way by
gdb ./RetroShare3. If and when it crashes, ask for a full stack trace
bt trace full
If the problem is that your retroshare hangs (due to a deadlock), you might want to:
- either stop it, using Ctrl+C in gdb
- or attach to it with gdbFind the process id, then launch
gdband then type in gdb command line
attach [pid]replacing [pid] with the process id of RetroShare.
Then you can display all threads at once (necessary for detecting deadlocks) using:
thread apply all bt full
Read online about advanced gdb usage at https://sourceware.org/gdb/current/onlinedocs/gdb/index.html
If you want a gui for gdb try QtCreator. In QtCreator you don't have to remember line numbers to set breakpoints, you can set them with a single click.
Search on this wiki and on the forums and see if someone else has asked a similar question or has seen a similar bug.
Ask for your problem in the relevant forum and make sure you include as much information as possible (see also the pointers below). Of course you can also mail us with your problems to the mailinglist.
Enter the bug in tracker
If you are sure that you found a bug and that you have all information needed, you can enter a bug in our Tracker. You will need to register here, if you want to receive notifications when your bug is handled.
Give a report
When you post on the forum, email us or enter a bug report, please provide as much information as possible in your report. We try to answer all your mails, posts and reports, but there are so many that sometimes we simply don't have the time to do so. The more sound details you provide about your issue, the better the chance that we will investigate it fully.
Make sure you have read the Developers_Corner. Give the full log showing the problem