GNU Info

(nasm.info)Section 10.2

---

Next: Appendix A Prev: Section 10.1.4 Up: Chapter 10

---

Enter node , (file) or (file)node

10.2. Bugs
==========

   We have never yet released a version of NASM with any _known_ bugs.
That doesn't usually stop there being plenty we didn't know about,
though.  Any that you find should be reported firstly via the
`bugtracker' at `https://sourceforge.net/projects/nasm/' (click on
"Bugs"), or if that fails then through one of the contacts in *Note
Section 1.2::.

   Please read *Note Section 2.2:: first, and don't report the bug if
it's listed in there as a deliberate feature. (If you think the feature
is badly thought out, feel free to send us reasons why you think it
should be changed, but don't just send us mail saying `This is a bug'
if the documentation says we did it on purpose.) Then read *Note
Section 10.1::, and don't bother reporting the bug if it's listed there.

   If you do report a bug, _please_ give us all of the following
information:

   * What operating system you're running NASM under. DOS, Linux,
     NetBSD, Win16, Win32, VMS (I'd be impressed), whatever.

   * If you're running NASM under DOS or Win32, tell us whether you've
     compiled your own executable from the DOS source archive, or
     whether you were using the standard distribution binaries out of
     the archive. If you were using a locally built executable, try to
     reproduce the problem using one of the standard binaries, as this
     will make it easier for us to reproduce your problem prior to
     fixing it.

   * Which version of NASM you're using, and exactly how you invoked
     it. Give us the precise command line, and the contents of the
     `NASMENV' environment variable if any.

   * Which versions of any supplementary programs you're using, and how
     you invoked them. If the problem only becomes visible at link
     time, tell us what linker you're using, what version of it you've
     got, and the exact linker command line. If the problem involves
     linking against object files generated by a compiler, tell us what
     compiler, what version, and what command line or options you used.
     (If you're compiling in an IDE, please try to reproduce the
     problem with the command-line version of the compiler.)

   * If at all possible, send us a NASM source file which exhibits the
     problem.  If this causes copyright problems (e.g. you can only
     reproduce the bug in restricted-distribution code) then bear in
     mind the following two points: firstly, we guarantee that any
     source code sent to us for the purposes of debugging NASM will be
     used _only_ for the purposes of debugging NASM, and that we will
     delete all our copies of it as soon as we have found and fixed the
     bug or bugs in question; and secondly, we would prefer _not_ to be
     mailed large chunks of code anyway. The smaller the file, the
     better.  A three-line sample file that does nothing useful
     _except_ demonstrate the problem is much easier to work with than
     a fully fledged ten-thousand- line program. (Of course, some
     errors _do_ only crop up in large files, so this may not be
     possible.)

   * A description of what the problem actually _is_. `It doesn't work'
     is _not_ a helpful description! Please describe exactly what is
     happening that shouldn't be, or what isn't happening that should.
     Examples might be: `NASM generates an error message saying Line 3
     for an error that's actually on Line 5'; `NASM generates an error
     message that I believe it shouldn't be generating at all'; `NASM
     fails to generate an error message that I believe it _should_ be
     generating'; `the object file produced from this source code
     crashes my linker'; `the ninth byte of the output file is 66 and I
     think it should be 77 instead'.

   * If you believe the output file from NASM to be faulty, send it to
     us. That allows us to determine whether our own copy of NASM
     generates the same file, or whether the problem is related to
     portability issues between our development platforms and yours. We
     can handle binary files mailed to us as MIME attachments,
     uuencoded, and even BinHex. Alternatively, we may be able to
     provide an FTP site you can upload the suspect files to; but
     mailing them is easier for us.

   * Any other information or data files that might be helpful. If, for
     example, the problem involves NASM failing to generate an object
     file while TASM can generate an equivalent file without trouble,
     then send us _both_ object files, so we can see what TASM is doing
     differently from us.