Annotation of embedaddon/curl/docs/BUGS, revision 1.1.1.1
1.1 misho 1: _ _ ____ _
2: ___| | | | _ \| |
3: / __| | | | |_) | |
4: | (__| |_| | _ <| |___
5: \___|\___/|_| \_\_____|
6:
7: BUGS
8:
9: 1. Bugs
10: 1.1 There are still bugs
11: 1.2 Where to report
12: 1.3 Security bugs
13: 1.4 What to report
14: 1.5 libcurl problems
15: 1.6 Who will fix the problems
16: 1.7 How to get a stack trace
17: 1.8 Bugs in libcurl bindings
18: 1.9 Bugs in old versions
19:
20: 2. Bug fixing procedure
21: 2.1 What happens on first filing
22: 2.2 First response
23: 2.3 Not reproducible
24: 2.4 Unresponsive
25: 2.5 Lack of time/interest
26: 2.6 KNOWN_BUGS
27: 2.7 TODO
28: 2.8 Closing off stalled bugs
29:
30: ==============================================================================
31:
32: 1.1 There are still bugs
33:
34: Curl and libcurl keep being developed. Adding features and changing code
35: means that bugs will sneak in, no matter how hard we try not to.
36:
37: Of course there are lots of bugs left. And lots of misfeatures.
38:
39: To help us make curl the stable and solid product we want it to be, we need
40: bug reports and bug fixes.
41:
42: 1.2 Where to report
43:
44: If you can't fix a bug yourself and submit a fix for it, try to report an as
45: detailed report as possible to a curl mailing list to allow one of us to
46: have a go at a solution. You can optionally also post your bug/problem at
47: curl's bug tracking system over at
48:
49: https://github.com/curl/curl/issues
50:
51: Please read the rest of this document below first before doing that!
52:
53: If you feel you need to ask around first, find a suitable mailing list and
54: post there. The lists are available on https://curl.haxx.se/mail/
55:
56: 1.3 Security bugs
57:
58: If you find a bug or problem in curl or libcurl that you think has a
59: security impact, for example a bug that can put users in danger or make them
60: vulnerable if the bug becomes public knowledge, then please report that bug
61: using our security development process.
62:
63: Security related bugs or bugs that are suspected to have a security impact,
64: should be reported on the curl security tracker at HackerOne:
65:
66: https://hackerone.com/curl
67:
68: This ensures that the report reaches the curl security team so that they
69: first can be deal with the report away from the public to minimize the harm
70: and impact it will have on existing users out there who might be using the
71: vulnerable versions.
72:
73: The curl project's process for handling security related issues is
74: documented here:
75:
76: https://curl.haxx.se/dev/secprocess.html
77:
78: 1.4 What to report
79:
80: When reporting a bug, you should include all information that will help us
81: understand what's wrong, what you expected to happen and how to repeat the
82: bad behavior. You therefore need to tell us:
83:
84: - your operating system's name and version number
85:
86: - what version of curl you're using (curl -V is fine)
87:
88: - versions of the used libraries that libcurl is built to use
89:
90: - what URL you were working with (if possible), at least which protocol
91:
92: and anything and everything else you think matters. Tell us what you
93: expected to happen, tell use what did happen, tell us how you could make it
94: work another way. Dig around, try out, test. Then include all the tiny bits
95: and pieces in your report. You will benefit from this yourself, as it will
96: enable us to help you quicker and more accurately.
97:
98: Since curl deals with networks, it often helps us if you include a protocol
99: debug dump with your bug report. The output you get by using the -v or
100: --trace options.
101:
102: If curl crashed, causing a core dump (in unix), there is hardly any use to
103: send that huge file to anyone of us. Unless we have an exact same system
104: setup as you, we can't do much with it. Instead we ask you to get a stack
105: trace and send that (much smaller) output to us instead!
106:
107: The address and how to subscribe to the mailing lists are detailed in the
108: MANUAL file.
109:
110: 1.5 libcurl problems
111:
112: When you've written your own application with libcurl to perform transfers,
113: it is even more important to be specific and detailed when reporting bugs.
114:
115: Tell us the libcurl version and your operating system. Tell us the name and
116: version of all relevant sub-components like for example the SSL library
117: you're using and what name resolving your libcurl uses. If you use SFTP or
118: SCP, the libssh2 version is relevant etc.
119:
120: Showing us a real source code example repeating your problem is the best way
121: to get our attention and it will greatly increase our chances to understand
122: your problem and to work on a fix (if we agree it truly is a problem).
123:
124: Lots of problems that appear to be libcurl problems are actually just abuses
125: of the libcurl API or other malfunctions in your applications. It is advised
126: that you run your problematic program using a memory debug tool like
127: valgrind or similar before you post memory-related or "crashing" problems to
128: us.
129:
130: 1.6 Who will fix the problems
131:
132: If the problems or bugs you describe are considered to be bugs, we want to
133: have the problems fixed.
134:
135: There are no developers in the curl project that are paid to work on bugs.
136: All developers that take on reported bugs do this on a voluntary basis. We
137: do it out of an ambition to keep curl and libcurl excellent products and out
138: of pride.
139:
140: But please do not assume that you can just lump over something to us and it
141: will then magically be fixed after some given time. Most often we need
142: feedback and help to understand what you've experienced and how to repeat a
143: problem. Then we may only be able to assist YOU to debug the problem and to
144: track down the proper fix.
145:
146: We get reports from many people every month and each report can take a
147: considerable amount of time to really go to the bottom with.
148:
149: 1.7 How to get a stack trace
150:
151: First, you must make sure that you compile all sources with -g and that you
152: don't 'strip' the final executable. Try to avoid optimizing the code as
153: well, remove -O, -O2 etc from the compiler options.
154:
155: Run the program until it cores.
156:
157: Run your debugger on the core file, like '<debugger> curl core'. <debugger>
158: should be replaced with the name of your debugger, in most cases that will
159: be 'gdb', but 'dbx' and others also occur.
160:
161: When the debugger has finished loading the core file and presents you a
162: prompt, enter 'where' (without the quotes) and press return.
163:
164: The list that is presented is the stack trace. If everything worked, it is
165: supposed to contain the chain of functions that were called when curl
166: crashed. Include the stack trace with your detailed bug report. It'll help a
167: lot.
168:
169: 1.8 Bugs in libcurl bindings
170:
171: There will of course pop up bugs in libcurl bindings. You should then
172: primarily approach the team that works on that particular binding and see
173: what you can do to help them fix the problem.
174:
175: If you suspect that the problem exists in the underlying libcurl, then
176: please convert your program over to plain C and follow the steps outlined
177: above.
178:
179: 1.9 Bugs in old versions
180:
181: The curl project typically releases new versions every other month, and we
182: fix several hundred bugs per year. For a huge table of releases, number of
183: bug fixes and more, see: https://curl.haxx.se/docs/releases.html
184:
185: The developers in the curl project do not have bandwidth or energy enough to
186: maintain several branches or to spend much time on hunting down problems in
187: old versions when chances are we already fixed them or at least that they've
188: changed nature and appearance in later versions.
189:
190: When you experience a problem and want to report it, you really SHOULD
191: include the version number of the curl you're using when you experience the
192: issue. If that version number shows us that you're using an out-of-date
193: curl, you should also try out a modern curl version to see if the problem
194: persists or how/if it has changed in appearance.
195:
196: Even if you cannot immediately upgrade your application/system to run the
197: latest curl version, you can most often at least run a test version or
198: experimental build or similar, to get this confirmed or not.
199:
200: At times people insist that they cannot upgrade to a modern curl version,
201: but instead they "just want the bug fixed". That's fine, just don't count on
202: us spending many cycles on trying to identify which single commit, if that's
203: even possible, that at some point in the past fixed the problem you're now
204: experiencing.
205:
206: Security wise, it is almost always a bad idea to lag behind the current curl
207: versions by a lot. We keeping discovering and reporting security problems
208: over time see you can see in this table:
209: https://curl.haxx.se/docs/vulnerabilities.html
210:
211: 2. Bug fixing procedure
212:
213: 2.1 What happens on first filing
214:
215: When a new issue is posted in the issue tracker or on the mailing list, the
216: team of developers first need to see the report. Maybe they took the day
217: off, maybe they're off in the woods hunting. Have patience. Allow at least a
218: few days before expecting someone to have responded.
219:
220: In the issue tracker you can expect that some labels will be set on the
221: issue to help categorize it.
222:
223: 2.2 First response
224:
225: If your issue/bug report wasn't perfect at once (and few are), chances are
226: that someone will ask follow-up questions. Which version did you use? Which
227: options did you use? How often does the problem occur? How can we reproduce
228: this problem? Which protocols does it involve? Or perhaps much more specific
229: and deep diving questions. It all depends on your specific issue.
230:
231: You should then respond to these follow-up questions and provide more info
232: about the problem, so that we can help you figure it out. Or maybe you can
233: help us figure it out. An active back-and-forth communication is important
234: and the key for finding a cure and landing a fix.
235:
236: 2.3 Not reproducible
237:
238: For problems that we can't reproduce and can't understand even after having
239: gotten all the info we need and having studied the source code over again,
240: are really hard to solve so then we may require further work from you who
241: actually see or experience the problem.
242:
243: 2.4 Unresponsive
244:
245: If the problem haven't been understood or reproduced, and there's nobody
246: responding to follow-up questions or questions asking for clarifications or
247: for discussing possible ways to move forward with the task, we take that as
248: a strong suggestion that the bug is not important.
249:
250: Unimportant issues will be closed as inactive sooner or later as they can't
251: be fixed. The inactivity period (waiting for responses) should not be
252: shorter than two weeks but may extend months.
253:
254: 2.5 Lack of time/interest
255:
256: Bugs that are filed and are understood can unfortunately end up in the
257: "nobody cares enough about it to work on it" category. Such bugs are
258: perfectly valid problems that *should* get fixed but apparently aren't. We
259: try to mark such bugs as "KNOWN_BUGS material" after a time of inactivity
260: and if no activity is noticed after yet some time those bugs are added to
261: KNOWN_BUGS and are closed in the issue tracker.
262:
263: 2.6 KNOWN_BUGS
264:
265: This is a list of known bugs. Bugs we know exist and that have been pointed
266: out but that haven't yet been fixed. The reasons for why they haven't been
267: fixed can involve anything really, but the primary reason is that nobody has
268: considered these problems to be important enough to spend the necessary time
269: and effort to have them fixed.
270:
271: The KNOWN_BUGS are always up for grabs and we will always love the ones who
272: bring one of them back to live and offers solutions to them.
273:
274: The KNOWN_BUGS document has a sibling document known as TODO.
275:
276: 2.7 TODO
277:
278: Issues that are filed or reported that aren't really bugs but more missing
279: features or ideas for future improvements and so on are marked as
280: 'enhancement' or 'feature-request' and will be added to the TODO document
281: instead and the issue is closed. We don't keep TODO items in the issue
282: tracker.
283:
284: The TODO document is full of ideas and suggestions of what we can add or fix
285: one day. You're always encouraged and free to grab one of those items and
286: take up a discussion with the curl development team on how that could be
287: implemented or provided in the project so that you can work on ticking it
288: odd that document.
289:
290: If the issue is rather a bug and not a missing feature or functionality, it
291: is listed in KNOWN_BUGS instead.
292:
293: 2.8 Closing off stalled bugs
294:
295: The issue and pull request trackers on https://github.com/curl/curl will
296: only hold "active" entries (using a non-precise definition of what active
297: actually is, but they're at least not completely dead). Those that are
298: abandoned or in other ways dormant will be closed and sometimes added to
299: TODO and KNOWN_BUGS instead.
300:
301: This way, we only have "active" issues open on github. Irrelevant issues and
302: pull requests will not distract developers or casual visitors.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to BUGS CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / curl / docs