summaryrefslogtreecommitdiff
path: root/plugins/FTPFileYM/curl/docs/BUGS
diff options
context:
space:
mode:
Diffstat (limited to 'plugins/FTPFileYM/curl/docs/BUGS')
-rw-r--r--plugins/FTPFileYM/curl/docs/BUGS148
1 files changed, 148 insertions, 0 deletions
diff --git a/plugins/FTPFileYM/curl/docs/BUGS b/plugins/FTPFileYM/curl/docs/BUGS
new file mode 100644
index 0000000000..c0c6fa82a9
--- /dev/null
+++ b/plugins/FTPFileYM/curl/docs/BUGS
@@ -0,0 +1,148 @@
+ _ _ ____ _
+ ___| | | | _ \| |
+ / __| | | | |_) | |
+ | (__| |_| | _ <| |___
+ \___|\___/|_| \_\_____|
+
+BUGS
+
+ 1. Bugs
+ 1.1 There are still bugs
+ 1.2 Where to report
+ 1.3 What to report
+ 1.4 libcurl problems
+ 1.5 Who will fix the problems
+ 1.6 How to get a stack trace
+ 1.7 Bugs in libcurl bindings
+
+==============================================================================
+
+1.1 There are still bugs
+
+ Curl and libcurl have grown substantially since the beginning. At the time
+ of writing (January 2013), there are about 83,000 lines of source code, and
+ by the time you read this it has probably grown even more.
+
+ 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://sourceforge.net/p/curl/bugs/
+
+ Please read the rest of this document below first before doing that! Also,
+ you need to login to your sourceforge account before being able to submit a
+ bug report (necessary evil done to avoid spam).
+
+ If you feel you need to ask around first, find a suitable mailing list and
+ post there. The lists are available on http://curl.haxx.se/mail/
+
+1.3 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.4 libcurl problems
+
+ First, post all libcurl problems on the curl-library mailing list.
+
+ 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.5 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.6 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.7 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.