|
7018
|
1 @c Copyright (C) 1996, 1997, 1999, 2000, 2002, 2004, 2007 John W. Eaton |
|
|
2 @c |
|
|
3 @c This file is part of Octave. |
|
|
4 @c |
|
|
5 @c Octave is free software; you can redistribute it and/or modify it |
|
|
6 @c under the terms of the GNU General Public License as published by the |
|
|
7 @c Free Software Foundation; either version 3 of the License, or (at |
|
|
8 @c your option) any later version. |
|
|
9 @c |
|
|
10 @c Octave is distributed in the hope that it will be useful, but WITHOUT |
|
|
11 @c ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
|
|
12 @c FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
|
|
13 @c for more details. |
|
|
14 @c |
|
|
15 @c You should have received a copy of the GNU General Public License |
|
|
16 @c along with Octave; see the file COPYING. If not, see |
|
|
17 @c <http://www.gnu.org/licenses/>. |
|
3294
|
18 |
|
7018
|
19 @c The text of this file appears in the file BUGS in the Octave |
|
|
20 @c distribution, as well as in the Octave manual. |
|
3294
|
21 |
|
|
22 @ifclear BUGSONLY |
|
4167
|
23 @node Trouble |
|
3294
|
24 @appendix Known Causes of Trouble |
|
|
25 @end ifclear |
|
|
26 |
|
|
27 @ifset BUGSONLY |
|
|
28 @include conf.texi |
|
|
29 |
|
|
30 This file documents known bugs in Octave and describes where and how to |
|
|
31 report any bugs that you may find. |
|
|
32 |
|
6778
|
33 Copyright (C) 1996, 1997, 2007 John W. Eaton. You may copy, distribute, and |
|
3294
|
34 modify it freely as long as you preserve this copyright notice and |
|
|
35 permission notice. |
|
|
36 |
|
4167
|
37 @node Trouble |
|
3294
|
38 @chapter Known Causes of Trouble with Octave |
|
|
39 @end ifset |
|
|
40 |
|
|
41 @cindex bugs, known |
|
|
42 @cindex installation trouble |
|
|
43 @cindex known causes of trouble |
|
|
44 @cindex troubleshooting |
|
|
45 |
|
|
46 This section describes known problems that affect users of Octave. Most |
|
|
47 of these are not Octave bugs per se---if they were, we would fix them. |
|
|
48 But the result for a user may be like the result of a bug. |
|
|
49 |
|
|
50 Some of these problems are due to bugs in other software, some are |
|
|
51 missing features that are too much work to add, and some are places |
|
|
52 where people's opinions differ as to what is best. |
|
|
53 |
|
|
54 @menu |
|
|
55 * Actual Bugs:: Bugs we will fix later. |
|
|
56 * Reporting Bugs:: |
|
|
57 * Bug Criteria:: |
|
|
58 * Bug Lists:: |
|
|
59 * Bug Reporting:: |
|
|
60 * Sending Patches:: |
|
|
61 * Service:: |
|
|
62 @end menu |
|
|
63 |
|
4167
|
64 @node Actual Bugs |
|
3294
|
65 @appendixsec Actual Bugs We Haven't Fixed Yet |
|
|
66 |
|
|
67 @itemize @bullet |
|
|
68 @item |
|
|
69 Output that comes directly from Fortran functions is not sent through |
|
|
70 the pager and may appear out of sequence with other output that is sent |
|
|
71 through the pager. One way to avoid this is to force pending output to |
|
|
72 be flushed before calling a function that will produce output from |
|
|
73 within Fortran functions. To do this, use the command |
|
|
74 |
|
|
75 @example |
|
|
76 fflush (stdout) |
|
|
77 @end example |
|
|
78 |
|
|
79 Another possible workaround is to use the command |
|
|
80 |
|
|
81 @example |
|
|
82 page_screen_output = "false" |
|
|
83 @end example |
|
|
84 |
|
|
85 @noindent |
|
|
86 to turn the pager off. |
|
|
87 @end itemize |
|
|
88 |
|
|
89 A list of ideas for future enhancements is distributed with Octave. See |
|
|
90 the file @file{PROJECTS} in the top level directory in the source |
|
|
91 distribution. |
|
|
92 |
|
4167
|
93 @node Reporting Bugs |
|
3294
|
94 @appendixsec Reporting Bugs |
|
|
95 @cindex bugs |
|
|
96 @cindex reporting bugs |
|
|
97 |
|
|
98 Your bug reports play an essential role in making Octave reliable. |
|
|
99 |
|
|
100 When you encounter a problem, the first thing to do is to see if it is |
|
|
101 already known. @xref{Trouble}. If it isn't known, then you should |
|
|
102 report the problem. |
|
|
103 |
|
|
104 Reporting a bug may help you by bringing a solution to your problem, or |
|
|
105 it may not. In any case, the principal function of a bug report is |
|
|
106 to help the entire community by making the next version of Octave work |
|
|
107 better. Bug reports are your contribution to the maintenance of Octave. |
|
|
108 |
|
|
109 In order for a bug report to serve its purpose, you must include the |
|
|
110 information that makes it possible to fix the bug. |
|
|
111 |
|
|
112 @findex bug_report |
|
|
113 |
|
|
114 If you have Octave working at all, the easiest way to prepare a complete |
|
|
115 bug report is to use the Octave function @code{bug_report}. When you |
|
|
116 execute this function, Octave will prompt you for a subject and then |
|
|
117 invoke the editor on a file that already contains all the configuration |
|
|
118 information. When you exit the editor, Octave will mail the bug report |
|
|
119 for you. |
|
|
120 |
|
6551
|
121 @DOCSTRING(bug_report) |
|
|
122 |
|
3294
|
123 @menu |
|
|
124 * Bug Criteria:: |
|
|
125 * Where: Bug Lists. Where to send your bug report. |
|
|
126 * Reporting: Bug Reporting. How to report a bug effectively. |
|
|
127 * Patches: Sending Patches. How to send a patch for Octave. |
|
|
128 @end menu |
|
|
129 |
|
4167
|
130 @node Bug Criteria |
|
3294
|
131 @appendixsec Have You Found a Bug? |
|
|
132 @cindex bug criteria |
|
|
133 |
|
|
134 If you are not sure whether you have found a bug, here are some guidelines: |
|
|
135 |
|
|
136 @itemize @bullet |
|
|
137 @cindex fatal signal |
|
|
138 @cindex core dump |
|
|
139 @item |
|
|
140 If Octave gets a fatal signal, for any input whatever, that is |
|
|
141 a bug. Reliable interpreters never crash. |
|
|
142 |
|
|
143 @cindex incorrect output |
|
|
144 @cindex incorrect results |
|
|
145 @cindex results, incorrect |
|
|
146 @cindex answers, incorrect |
|
|
147 @cindex erroneous results |
|
|
148 @cindex wrong answers |
|
|
149 @item |
|
|
150 If Octave produces incorrect results, for any input whatever, |
|
|
151 that is a bug. |
|
|
152 |
|
|
153 @cindex undefined behavior |
|
|
154 @cindex undefined function value |
|
|
155 @item |
|
|
156 Some output may appear to be incorrect when it is in fact due to a |
|
|
157 program whose behavior is undefined, which happened by chance to give |
|
|
158 the desired results on another system. For example, the range operator |
|
|
159 may produce different results because of differences in the way floating |
|
|
160 point arithmetic is handled on various systems. |
|
|
161 |
|
|
162 @cindex erroneous messages |
|
|
163 @cindex incorrect error messages |
|
|
164 @cindex error messages, incorrect |
|
|
165 @item |
|
|
166 If Octave produces an error message for valid input, that is a bug. |
|
|
167 |
|
|
168 @cindex invalid input |
|
|
169 @item |
|
|
170 If Octave does not produce an error message for invalid input, that is |
|
|
171 a bug. However, you should note that your idea of ``invalid input'' |
|
|
172 might be my idea of ``an extension'' or ``support for traditional |
|
|
173 practice''. |
|
|
174 |
|
|
175 @cindex improving Octave |
|
|
176 @cindex suggestions |
|
|
177 @item |
|
|
178 If you are an experienced user of programs like Octave, your suggestions |
|
|
179 for improvement are welcome in any case. |
|
|
180 @end itemize |
|
|
181 |
|
4167
|
182 @node Bug Lists |
|
3294
|
183 @appendixsec Where to Report Bugs |
|
|
184 @cindex bug report mailing lists |
|
|
185 @cindex reporting bugs |
|
|
186 @cindex bugs, reporting |
|
|
187 |
|
|
188 @findex bug_report |
|
|
189 |
|
|
190 If you have Octave working at all, the easiest way to prepare a complete |
|
|
191 bug report is to use the Octave function @code{bug_report}. When you |
|
|
192 execute this function, Octave will prompt you for a subject and then |
|
|
193 invoke the editor on a file that already contains all the configuration |
|
|
194 information. When you exit the editor, Octave will mail the bug report |
|
|
195 for you. |
|
|
196 |
|
|
197 If for some reason you cannot use Octave's @code{bug_report} function, |
|
5041
|
198 send bug reports for Octave to @email{bug@@octave.org}. |
|
3294
|
199 |
|
|
200 @strong{Do not send bug reports to @samp{help-octave}}. Most users of |
|
|
201 Octave do not want to receive bug reports. Those that do have asked to |
|
|
202 be on the mailing list. |
|
|
203 |
|
|
204 As a last resort, send bug reports on paper to: |
|
|
205 |
|
|
206 @example |
|
|
207 Octave Bugs c/o John W. Eaton |
|
|
208 University of Wisconsin-Madison |
|
|
209 Department of Chemical Engineering |
|
|
210 1415 Engineering Drive |
|
|
211 Madison, Wisconsin 53706 USA |
|
|
212 @end example |
|
|
213 |
|
4167
|
214 @node Bug Reporting |
|
3294
|
215 @appendixsec How to Report Bugs |
|
|
216 @cindex bugs, reporting |
|
|
217 |
|
|
218 Send bug reports for Octave to one of the addresses listed in |
|
|
219 @ref{Bug Lists}. |
|
|
220 |
|
|
221 The fundamental principle of reporting bugs usefully is this: |
|
|
222 @strong{report all the facts}. If you are not sure whether to state a |
|
|
223 fact or leave it out, state it! |
|
|
224 |
|
|
225 Often people omit facts because they think they know what causes the |
|
|
226 problem and they conclude that some details don't matter. Thus, you might |
|
|
227 assume that the name of the variable you use in an example does not matter. |
|
|
228 Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a |
|
|
229 stray memory reference which happens to fetch from the location where that |
|
|
230 name is stored in memory; perhaps, if the name were different, the contents |
|
|
231 of that location would fool the interpreter into doing the right thing |
|
|
232 despite the bug. Play it safe and give a specific, complete example. |
|
|
233 |
|
|
234 Keep in mind that the purpose of a bug report is to enable someone to |
|
|
235 fix the bug if it is not known. Always write your bug reports on |
|
|
236 the assumption that the bug is not known. |
|
|
237 |
|
|
238 Sometimes people give a few sketchy facts and ask, ``Does this ring a |
|
|
239 bell?'' This cannot help us fix a bug. It is better to send a complete |
|
|
240 bug report to begin with. |
|
|
241 |
|
|
242 Try to make your bug report self-contained. If we have to ask you for |
|
|
243 more information, it is best if you include all the previous information |
|
|
244 in your response, as well as the information that was missing. |
|
|
245 |
|
|
246 To enable someone to investigate the bug, you should include all these |
|
|
247 things: |
|
|
248 |
|
|
249 @itemize @bullet |
|
|
250 @item |
|
|
251 The version of Octave. You can get this by noting the version number |
|
|
252 that is printed when Octave starts, or running it with the @samp{-v} |
|
|
253 option. |
|
|
254 |
|
|
255 @item |
|
|
256 A complete input file that will reproduce the bug. |
|
|
257 |
|
|
258 A single statement may not be enough of an example---the bug might |
|
|
259 depend on other details that are missing from the single statement where |
|
|
260 the error finally occurs. |
|
|
261 |
|
|
262 @item |
|
|
263 The command arguments you gave Octave to execute that example |
|
|
264 and observe the bug. To guarantee you won't omit something important, |
|
|
265 list all the options. |
|
|
266 |
|
|
267 If we were to try to guess the arguments, we would probably guess wrong |
|
|
268 and then we would not encounter the bug. |
|
|
269 |
|
|
270 @item |
|
|
271 The type of machine you are using, and the operating system name and |
|
|
272 version number. |
|
|
273 |
|
|
274 @item |
|
|
275 The command-line arguments you gave to the @code{configure} command when |
|
|
276 you installed the interpreter. |
|
|
277 |
|
|
278 @item |
|
|
279 A complete list of any modifications you have made to the interpreter |
|
|
280 source. |
|
|
281 |
|
|
282 Be precise about these changes---show a context diff for them. |
|
|
283 |
|
|
284 @item |
|
|
285 Details of any other deviations from the standard procedure for installing |
|
|
286 Octave. |
|
|
287 |
|
|
288 @cindex incorrect output |
|
|
289 @cindex incorrect results |
|
|
290 @cindex results, incorrect |
|
|
291 @cindex answers, incorrect |
|
|
292 @cindex erroneous results |
|
|
293 @cindex wrong answers |
|
|
294 @item |
|
|
295 A description of what behavior you observe that you believe is |
|
|
296 incorrect. For example, "The interpreter gets a fatal signal," or, "The |
|
|
297 output produced at line 208 is incorrect." |
|
|
298 |
|
|
299 Of course, if the bug is that the interpreter gets a fatal signal, then |
|
|
300 one can't miss it. But if the bug is incorrect output, we might not |
|
|
301 notice unless it is glaringly wrong. |
|
|
302 |
|
|
303 Even if the problem you experience is a fatal signal, you should still |
|
|
304 say so explicitly. Suppose something strange is going on, such as, your |
|
|
305 copy of the interpreter is out of synch, or you have encountered a bug |
|
|
306 in the C library on your system. Your copy might crash and the copy |
|
|
307 here would not. If you said to expect a crash, then when the |
|
|
308 interpreter here fails to crash, we would know that the bug was not |
|
|
309 happening. If you don't say to expect a crash, then we would not know |
|
|
310 whether the bug was happening. We would not be able to draw any |
|
|
311 conclusion from our observations. |
|
|
312 |
|
|
313 Often the observed symptom is incorrect output when your program is run. |
|
|
314 Unfortunately, this is not enough information unless the program is |
|
|
315 short and simple. It is very helpful if you can include an explanation |
|
|
316 of the expected output, and why the actual output is incorrect. |
|
|
317 |
|
|
318 @item |
|
|
319 If you wish to suggest changes to the Octave source, send them as |
|
|
320 context diffs. If you even discuss something in the Octave source, |
|
|
321 refer to it by context, not by line number, because the line numbers in |
|
|
322 the development sources probably won't match those in your sources. |
|
|
323 @end itemize |
|
|
324 |
|
|
325 Here are some things that are not necessary: |
|
|
326 |
|
|
327 @itemize @bullet |
|
|
328 @cindex bugs, investigating |
|
|
329 @item |
|
|
330 A description of the envelope of the bug. |
|
|
331 |
|
|
332 Often people who encounter a bug spend a lot of time investigating which |
|
|
333 changes to the input file will make the bug go away and which changes |
|
|
334 will not affect it. Such information is usually not necessary to enable |
|
|
335 us to fix bugs in Octave, but if you can find a simpler example to |
|
|
336 report @emph{instead} of the original one, that is a convenience. |
|
|
337 Errors in the output will be easier to spot, running under the debugger |
|
|
338 will take less time, etc. Most Octave bugs involve just one function, so |
|
|
339 the most straightforward way to simplify an example is to delete all the |
|
|
340 function definitions except the one in which the bug occurs. |
|
|
341 |
|
|
342 However, simplification is not vital; if you don't want to do |
|
|
343 this, report the bug anyway and send the entire test case you |
|
|
344 used. |
|
|
345 |
|
|
346 @item |
|
|
347 A patch for the bug. Patches can be helpful, but if you find a bug, you |
|
|
348 should report it, even if you cannot send a fix for the problem. |
|
|
349 @end itemize |
|
|
350 |
|
4167
|
351 @node Sending Patches |
|
3294
|
352 @appendixsec Sending Patches for Octave |
|
|
353 @cindex improving Octave |
|
|
354 @cindex diffs, submitting |
|
|
355 @cindex patches, submitting |
|
|
356 @cindex submitting diffs |
|
|
357 @cindex submitting patches |
|
|
358 |
|
|
359 If you would like to write bug fixes or improvements for Octave, that is |
|
|
360 very helpful. When you send your changes, please follow these |
|
|
361 guidelines to avoid causing extra work for us in studying the patches. |
|
|
362 |
|
|
363 If you don't follow these guidelines, your information might still be |
|
|
364 useful, but using it will take extra work. Maintaining Octave is a lot |
|
|
365 of work in the best of circumstances, and we can't keep up unless you do |
|
|
366 your best to help. |
|
|
367 |
|
|
368 @itemize @bullet |
|
|
369 @item |
|
|
370 Send an explanation with your changes of what problem they fix or what |
|
|
371 improvement they bring about. For a bug fix, just include a copy of the |
|
|
372 bug report, and explain why the change fixes the bug. |
|
|
373 |
|
|
374 @item |
|
|
375 Always include a proper bug report for the problem you think you have |
|
|
376 fixed. We need to convince ourselves that the change is right before |
|
|
377 installing it. Even if it is right, we might have trouble judging it if |
|
|
378 we don't have a way to reproduce the problem. |
|
|
379 |
|
|
380 @item |
|
|
381 Include all the comments that are appropriate to help people reading the |
|
|
382 source in the future understand why this change was needed. |
|
|
383 |
|
|
384 @item |
|
|
385 Don't mix together changes made for different reasons. |
|
|
386 Send them @emph{individually}. |
|
|
387 |
|
|
388 If you make two changes for separate reasons, then we might not want to |
|
|
389 install them both. We might want to install just one. |
|
|
390 |
|
|
391 @item |
|
|
392 Use @samp{diff -c} to make your diffs. Diffs without context are hard |
|
|
393 for us to install reliably. More than that, they make it hard for us to |
|
|
394 study the diffs to decide whether we want to install them. Unidiff |
|
|
395 format is better than contextless diffs, but not as easy to read as |
|
|
396 @samp{-c} format. |
|
|
397 |
|
|
398 If you have GNU diff, use @samp{diff -cp}, which shows the name of the |
|
|
399 function that each change occurs in. |
|
|
400 |
|
|
401 @item |
|
|
402 Write the change log entries for your changes. |
|
|
403 |
|
|
404 Read the @file{ChangeLog} file to see what sorts of information to put |
|
|
405 in, and to learn the style that we use. The purpose of the change log |
|
|
406 is to show people where to find what was changed. So you need to be |
|
|
407 specific about what functions you changed; in large functions, it's |
|
|
408 often helpful to indicate where within the function the change was made. |
|
|
409 |
|
|
410 On the other hand, once you have shown people where to find the change, |
|
|
411 you need not explain its purpose. Thus, if you add a new function, all |
|
|
412 you need to say about it is that it is new. If you feel that the |
|
|
413 purpose needs explaining, it probably does---but the explanation will be |
|
|
414 much more useful if you put it in comments in the code. |
|
|
415 |
|
|
416 If you would like your name to appear in the header line for who made |
|
|
417 the change, send us the header line. |
|
|
418 @end itemize |
|
|
419 |
|
4167
|
420 @node Service |
|
3294
|
421 @appendixsec How To Get Help with Octave |
|
|
422 @cindex help, where to find |
|
|
423 |
|
5041
|
424 The mailing list @email{help@@octave.org} exists for the discussion of |
|
|
425 matters related to using and installing Octave. If would like to join |
|
|
426 the discussion, please send a short note to |
|
|
427 @email{help@strong{-request}@@octave.org}. |
|
3294
|
428 |
|
|
429 @strong{Please do not} send requests to be added or removed from the |
|
|
430 mailing list, or other administrative trivia to the list itself. |
|
|
431 |
|
|
432 If you think you have found a bug in the installation procedure, |
|
|
433 however, you should send a complete bug report for the problem to |
|
5041
|
434 @email{bug@@octave.org}. @xref{Bug Reporting}, for |
|
3294
|
435 information that will help you to submit a useful report. |
