| _ _ ____ _ |
| ___| | | | _ \| | |
| / __| | | | |_) | | |
| | (__| |_| | _ <| |___ |
| \___|\___/|_| \_\_____| |
| |
| BUGS |
| |
| 1. Bugs |
| 1.1 There are still bugs |
| 1.2 Where to report |
| 1.3 Security bugs |
| 1.4 What to report |
| 1.5 libcurl problems |
| 1.6 Who will fix the problems |
| 1.7 How to get a stack trace |
| 1.8 Bugs in libcurl bindings |
| 1.9 Bugs in old versions |
| |
| 2. Bug fixing procedure |
| 2.1 What happens on first filing |
| 2.2 First response |
| 2.3 Not reproducible |
| 2.4 Unresponsive |
| 2.5 Lack of time/interest |
| 2.6 KNOWN_BUGS |
| 2.7 TODO |
| 2.8 Closing off stalled bugs |
| |
| ============================================================================== |
| |
| 1.1 There are still bugs |
| |
| Curl and libcurl keep being developed. Adding features and changing code |
| means that bugs will sneak in, no matter how hard we try not to. |
| |
| Of course there are lots of bugs left. And lots of misfeatures. |
| |
| To help us make curl the stable and solid product we want it to be, we need |
| bug reports and bug fixes. |
| |
| 1.2 Where to report |
| |
| If you can't fix a bug yourself and submit a fix for it, try to report an as |
| detailed report as possible to a curl mailing list to allow one of us to |
| have a go at a solution. You can optionally also post your bug/problem at |
| curl's bug tracking system over at |
| |
| https://github.com/curl/curl/issues |
| |
| Please read the rest of this document below first before doing that! |
| |
| If you feel you need to ask around first, find a suitable mailing list and |
| post there. The lists are available on https://curl.haxx.se/mail/ |
| |
| 1.3 Security bugs |
| |
| If you find a bug or problem in curl or libcurl that you think has a |
| security impact, for example a bug that can put users in danger or make them |
| vulnerable if the bug becomes public knowledge, then please report that bug |
| using our security development process. |
| |
| Security related bugs or bugs that are suspected to have a security impact, |
| should be reported on the curl security tracker at HackerOne: |
| |
| https://hackerone.com/curl |
| |
| This ensures that the report reaches the curl security team so that they |
| first can be deal with the report away from the public to minimize the harm |
| and impact it will have on existing users out there who might be using the |
| vulnerable versions. |
| |
| The curl project's process for handling security related issues is |
| documented here: |
| |
| https://curl.haxx.se/dev/secprocess.html |
| |
| 1.4 What to report |
| |
| When reporting a bug, you should include all information that will help us |
| understand what's wrong, what you expected to happen and how to repeat the |
| bad behavior. You therefore need to tell us: |
| |
| - your operating system's name and version number |
| |
| - what version of curl you're using (curl -V is fine) |
| |
| - versions of the used libraries that libcurl is built to use |
| |
| - what URL you were working with (if possible), at least which protocol |
| |
| and anything and everything else you think matters. Tell us what you |
| expected to happen, tell use what did happen, tell us how you could make it |
| work another way. Dig around, try out, test. Then include all the tiny bits |
| and pieces in your report. You will benefit from this yourself, as it will |
| enable us to help you quicker and more accurately. |
| |
| Since curl deals with networks, it often helps us if you include a protocol |
| debug dump with your bug report. The output you get by using the -v or |
| --trace options. |
| |
| If curl crashed, causing a core dump (in unix), there is hardly any use to |
| send that huge file to anyone of us. Unless we have an exact same system |
| setup as you, we can't do much with it. Instead we ask you to get a stack |
| trace and send that (much smaller) output to us instead! |
| |
| The address and how to subscribe to the mailing lists are detailed in the |
| MANUAL file. |
| |
| 1.5 libcurl problems |
| |
| When you've written your own application with libcurl to perform transfers, |
| it is even more important to be specific and detailed when reporting bugs. |
| |
| Tell us the libcurl version and your operating system. Tell us the name and |
| version of all relevant sub-components like for example the SSL library |
| you're using and what name resolving your libcurl uses. If you use SFTP or |
| SCP, the libssh2 version is relevant etc. |
| |
| Showing us a real source code example repeating your problem is the best way |
| to get our attention and it will greatly increase our chances to understand |
| your problem and to work on a fix (if we agree it truly is a problem). |
| |
| Lots of problems that appear to be libcurl problems are actually just abuses |
| of the libcurl API or other malfunctions in your applications. It is advised |
| that you run your problematic program using a memory debug tool like |
| valgrind or similar before you post memory-related or "crashing" problems to |
| us. |
| |
| 1.6 Who will fix the problems |
| |
| If the problems or bugs you describe are considered to be bugs, we want to |
| have the problems fixed. |
| |
| There are no developers in the curl project that are paid to work on bugs. |
| All developers that take on reported bugs do this on a voluntary basis. We |
| do it out of an ambition to keep curl and libcurl excellent products and out |
| of pride. |
| |
| But please do not assume that you can just lump over something to us and it |
| will then magically be fixed after some given time. Most often we need |
| feedback and help to understand what you've experienced and how to repeat a |
| problem. Then we may only be able to assist YOU to debug the problem and to |
| track down the proper fix. |
| |
| We get reports from many people every month and each report can take a |
| considerable amount of time to really go to the bottom with. |
| |
| 1.7 How to get a stack trace |
| |
| First, you must make sure that you compile all sources with -g and that you |
| don't 'strip' the final executable. Try to avoid optimizing the code as |
| well, remove -O, -O2 etc from the compiler options. |
| |
| Run the program until it cores. |
| |
| Run your debugger on the core file, like '<debugger> curl core'. <debugger> |
| should be replaced with the name of your debugger, in most cases that will |
| be 'gdb', but 'dbx' and others also occur. |
| |
| When the debugger has finished loading the core file and presents you a |
| prompt, enter 'where' (without the quotes) and press return. |
| |
| The list that is presented is the stack trace. If everything worked, it is |
| supposed to contain the chain of functions that were called when curl |
| crashed. Include the stack trace with your detailed bug report. It'll help a |
| lot. |
| |
| 1.8 Bugs in libcurl bindings |
| |
| There will of course pop up bugs in libcurl bindings. You should then |
| primarily approach the team that works on that particular binding and see |
| what you can do to help them fix the problem. |
| |
| If you suspect that the problem exists in the underlying libcurl, then |
| please convert your program over to plain C and follow the steps outlined |
| above. |
| |
| 1.9 Bugs in old versions |
| |
| The curl project typically releases new versions every other month, and we |
| fix several hundred bugs per year. For a huge table of releases, number of |
| bug fixes and more, see: https://curl.haxx.se/docs/releases.html |
| |
| The developers in the curl project do not have bandwidth or energy enough to |
| maintain several branches or to spend much time on hunting down problems in |
| old versions when chances are we already fixed them or at least that they've |
| changed nature and appearance in later versions. |
| |
| When you experience a problem and want to report it, you really SHOULD |
| include the version number of the curl you're using when you experience the |
| issue. If that version number shows us that you're using an out-of-date |
| curl, you should also try out a modern curl version to see if the problem |
| persists or how/if it has changed in appearance. |
| |
| Even if you cannot immediately upgrade your application/system to run the |
| latest curl version, you can most often at least run a test version or |
| experimental build or similar, to get this confirmed or not. |
| |
| At times people insist that they cannot upgrade to a modern curl version, |
| but instead they "just want the bug fixed". That's fine, just don't count on |
| us spending many cycles on trying to identify which single commit, if that's |
| even possible, that at some point in the past fixed the problem you're now |
| experiencing. |
| |
| Security wise, it is almost always a bad idea to lag behind the current curl |
| versions by a lot. We keeping discovering and reporting security problems |
| over time see you can see in this table: |
| https://curl.haxx.se/docs/vulnerabilities.html |
| |
| 2. Bug fixing procedure |
| |
| 2.1 What happens on first filing |
| |
| When a new issue is posted in the issue tracker or on the mailing list, the |
| team of developers first need to see the report. Maybe they took the day |
| off, maybe they're off in the woods hunting. Have patience. Allow at least a |
| few days before expecting someone to have responded. |
| |
| In the issue tracker you can expect that some labels will be set on the |
| issue to help categorize it. |
| |
| 2.2 First response |
| |
| If your issue/bug report wasn't perfect at once (and few are), chances are |
| that someone will ask follow-up questions. Which version did you use? Which |
| options did you use? How often does the problem occur? How can we reproduce |
| this problem? Which protocols does it involve? Or perhaps much more specific |
| and deep diving questions. It all depends on your specific issue. |
| |
| You should then respond to these follow-up questions and provide more info |
| about the problem, so that we can help you figure it out. Or maybe you can |
| help us figure it out. An active back-and-forth communication is important |
| and the key for finding a cure and landing a fix. |
| |
| 2.3 Not reproducible |
| |
| For problems that we can't reproduce and can't understand even after having |
| gotten all the info we need and having studied the source code over again, |
| are really hard to solve so then we may require further work from you who |
| actually see or experience the problem. |
| |
| 2.4 Unresponsive |
| |
| If the problem haven't been understood or reproduced, and there's nobody |
| responding to follow-up questions or questions asking for clarifications or |
| for discussing possible ways to move forward with the task, we take that as |
| a strong suggestion that the bug is not important. |
| |
| Unimportant issues will be closed as inactive sooner or later as they can't |
| be fixed. The inactivity period (waiting for responses) should not be |
| shorter than two weeks but may extend months. |
| |
| 2.5 Lack of time/interest |
| |
| Bugs that are filed and are understood can unfortunately end up in the |
| "nobody cares enough about it to work on it" category. Such bugs are |
| perfectly valid problems that *should* get fixed but apparently aren't. We |
| try to mark such bugs as "KNOWN_BUGS material" after a time of inactivity |
| and if no activity is noticed after yet some time those bugs are added to |
| KNOWN_BUGS and are closed in the issue tracker. |
| |
| 2.6 KNOWN_BUGS |
| |
| This is a list of known bugs. Bugs we know exist and that have been pointed |
| out but that haven't yet been fixed. The reasons for why they haven't been |
| fixed can involve anything really, but the primary reason is that nobody has |
| considered these problems to be important enough to spend the necessary time |
| and effort to have them fixed. |
| |
| The KNOWN_BUGS are always up for grabs and we will always love the ones who |
| bring one of them back to live and offers solutions to them. |
| |
| The KNOWN_BUGS document has a sibling document known as TODO. |
| |
| 2.7 TODO |
| |
| Issues that are filed or reported that aren't really bugs but more missing |
| features or ideas for future improvements and so on are marked as |
| 'enhancement' or 'feature-request' and will be added to the TODO document |
| instead and the issue is closed. We don't keep TODO items in the issue |
| tracker. |
| |
| The TODO document is full of ideas and suggestions of what we can add or fix |
| one day. You're always encouraged and free to grab one of those items and |
| take up a discussion with the curl development team on how that could be |
| implemented or provided in the project so that you can work on ticking it |
| odd that document. |
| |
| If the issue is rather a bug and not a missing feature or functionality, it |
| is listed in KNOWN_BUGS instead. |
| |
| 2.8 Closing off stalled bugs |
| |
| The issue and pull request trackers on https://github.com/curl/curl will |
| only hold "active" entries (using a non-precise definition of what active |
| actually is, but they're at least not completely dead). Those that are |
| abandoned or in other ways dormant will be closed and sometimes added to |
| TODO and KNOWN_BUGS instead. |
| |
| This way, we only have "active" issues open on github. Irrelevant issues and |
| pull requests will not distract developers or casual visitors. |