Difference between revisions of "Report a Bug"

From Linux-VServer

Jump to: navigation, search
(Estate 678 Martial arts223-0)
(Where to send bug reports?: Add github URL for util-vserver)
 
(12 intermediate revisions by 8 users not shown)
Line 34: Line 34:
 
* Other notes, patches, fixes, workarounds
 
* Other notes, patches, fixes, workarounds
  
http://www.lustrumlaurentius.nl/forum/showthread.php?t=893 Buy Plavix online no prescription http://www.lustrumlaurentius.nl/forum/showthread.php?t=906 Buy Effexor online no prescription http://adderall.nolodin.cn/adderall-cod-accepted.html adderall cod accepted http://adderall.nolodin.cn/buy-fda-adderall-no-presription.html buy fda adderall no presription http://www.lustrumlaurentius.nl/forum/showthread.php?t=912 Buy Klonopin online no prescription http://www.lustrumlaurentius.nl/forum/showthread.php?t=876 Buy Fioricet online no prescription http://www.lustrumlaurentius.nl/forum/showthread.php?t=847 Buy ambien online http://www.lustrumlaurentius.nl/forum/showthread.php?t=874 Buy Ultram online no prescription
+
=== Test scripts ===
 +
 
 +
To ensure that your (VServer) setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.
 +
 
 +
<pre>
 +
# get the script
 +
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh
 +
 
 +
# make it executable
 +
chmod +x testme.sh
 +
 
 +
# become root
 +
su
 +
 
 +
# run the test script
 +
./testme.sh
 +
</pre>
 +
 
 +
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''
 +
 
 +
<pre>
 +
# get the script
 +
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh
 +
 
 +
# make it executable
 +
chmod +x testfs.sh
 +
 
 +
# make a loopback file (created as a sparse file to save time)
 +
touch 1gb.tesfile
 +
dd if=/dev/zero of=1gb.testfile bs=1 count=0 seek=1G
 +
 
 +
# become root
 +
su
 +
 
 +
# setup the loopback
 +
losetup /dev/loop0 1gb.testfile
 +
 
 +
# run the test script for new-style config
 +
./testfs.sh -t -x -y -z -D /dev/loop0 -M /mnt
 +
</pre>
 +
 
 +
Attach the output of these two scripts to your bug report.
 +
 
 +
'''If you need to figure out which line of code is causing an OOPS/RIP, the following script will parse your dmesg and output the lines and addresses formatted as shown below:'''
 +
<pre>
 +
#!/bin/bash
 +
# output looks like: ffffffff80502a23:/usr/src/linux-2.6.25-vs/net/ipv4/raw.c:936
 +
# only arg is path to vmlinux (/usr/src/linux/vmlinux)
 +
CMD=`dmesg | egrep '<[[:xdigit:]]{16}>' | sed -r -e 's,^[^<]+?<,,g' -e 's,>[^<]+?<, ,g' -e 's,>.*$,,g'`
 +
if [ ${1} ]; then
 +
for i in ${CMD}; do echo -n $i: && addr2line -e $1 $i;done
 +
else
 +
echo please give me the path to your vmlinux
 +
fi
 +
</pre>
  
 
== Where to send bug reports? ==
 
== Where to send bug reports? ==
  
Bug reports should be submitted to the mailing list or directly to one of our developers in IRC.
+
Bug reports about the kernel patch should be submitted to the mailing list or directly to one of our developers in IRC.
 +
 
 +
Bug reports against util-vserver should be filed on [https://github.com/linux-vserver/util-vserver/ github].
  
 
See the [[Communicate]] page to learn how to use the mailing list and/or IRC.
 
See the [[Communicate]] page to learn how to use the mailing list and/or IRC.
 +
 +
[[Category:Community]]

Latest revision as of 22:21, 15 December 2015


There is a large number of Linux-VServer users. There is a much small number of people who actually develop Linux-VServer and fix bugs.

What does this mean for you, an aspiring bug reporter? In order to catch the eye of one of these few volunteers, you'll need to take to heart a few tips on how to report a bug so that they can and will help you.

By following these guidelines, you can help ensure that your bugs stay at the top of the developers' heap, and get fixed.

[edit] How to report bugs

The people who are going to help you with a bug report are volunteers. Not only are you not paying them to help you, but nobody else is either. So, be nice to them.

Beyond that golden rule, what follows are some additional tips on ways to make your bug report better so that someone will be able to help you.

[edit] Basics: what you did, what you wanted to happen, and what actually happened.

Those are the three basic elements of a bug report. You need to tell us exactly what you did (for example, "I right-clicked on "make happy meal"), what you expected to have happened (to continue the example, "I expected the kernel to serve me a happy meal with a hamburger and onion rings"), and what actually happened ("It gave me a happy meal with french fries.").

Yes, the example is silly. But if your bug report simply said "The make_happy_meal function doesn't work," you will very likely get a reply saying "It works fine for me", because we can't guess what you were expecting to happen. By giving all the information you might get a reply like "That's because you can't have onion rings in a happy meal, you can only have french fries or curly fries." By telling us what you asked for, what you expected to get, and what you actually got, we don't have to guess what you mean.

[edit] Useful information

The following list gives an overview of information useful in bug reports. Note that you don't have to submit all information listed below, but you should do as long as it helps to discover the root of all evil.

  • One line summary of the problem
  • Full description of the problem
  • Kernel version (from /proc/version)
  • Output of test scripts (see below)
  • Output of the Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt in the kernel source)
  • A small shell script or example program which triggers the problem (if possible)
  • Processor information (from /proc/cpuinfo)
  • Module information (from /proc/modules)
  • Other information that might be relevant to the problem
  • Other notes, patches, fixes, workarounds

[edit] Test scripts

To ensure that your (VServer) setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.

# get the script
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh

# make it executable
chmod +x testme.sh

# become root
su

# run the test script
./testme.sh

Be careful! The testfs.sh script might easily reformat your hard disk :)

# get the script
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh

# make it executable
chmod +x testfs.sh

# make a loopback file (created as a sparse file to save time)
touch 1gb.tesfile
dd if=/dev/zero of=1gb.testfile bs=1 count=0 seek=1G

# become root
su

# setup the loopback
losetup /dev/loop0 1gb.testfile

# run the test script for new-style config
./testfs.sh -t -x -y -z -D /dev/loop0 -M /mnt

Attach the output of these two scripts to your bug report.

If you need to figure out which line of code is causing an OOPS/RIP, the following script will parse your dmesg and output the lines and addresses formatted as shown below:

#!/bin/bash
# output looks like: ffffffff80502a23:/usr/src/linux-2.6.25-vs/net/ipv4/raw.c:936
# only arg is path to vmlinux (/usr/src/linux/vmlinux)
CMD=`dmesg | egrep '<[[:xdigit:]]{16}>' | sed -r -e 's,^[^<]+?<,,g' -e 's,>[^<]+?<, ,g' -e 's,>.*$,,g'`
if [ ${1} ]; then
for i in ${CMD}; do echo -n $i: && addr2line -e $1 $i;done
else
echo please give me the path to your vmlinux
fi

[edit] Where to send bug reports?

Bug reports about the kernel patch should be submitted to the mailing list or directly to one of our developers in IRC.

Bug reports against util-vserver should be filed on github.

See the Communicate page to learn how to use the mailing list and/or IRC.

Personal tools