From Fedora Project Wiki

(convert to new category system)
(abrt 2 changes)
Line 1: Line 1:
{{QA/Test_Case
{{QA/Test_Case
|description=This test case tests the functionality of the [[Features/ABRT|ABRT]] feature.
|description=This test case tests the functionality of the ABRT kerneloops feature.
|actions=
|actions=
# We will check that the ''dumpoops works and provides correct amount of crashes detected.
# We will check that the {{command|abrt-dump-oops}} works and provides correct amount of crashes detected.
# Download files:
# Download files:
#* [http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=examples/oops1.test;hb=HEAD oops1.test]
#* [http://git.fedorahosted.org/git/?p=abrt.git;a=blob_plain;f=examples/cut_here.test;hb=HEAD cut_here.test]
#* [http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=examples/oops3.test;hb=HEAD oops3.test]
#* [http://git.fedorahosted.org/git/?p=abrt.git;a=blob_plain;f=examples/not_oops3.test;hb=HEAD not_oops3.test]
#* [http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=examples/not_oops1.test;hb=HEAD not_oops1.test]
# Test that stand-alone detector tool works properly; Do as a root for both files:
#* [http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=examples/not_oops2.test;hb=HEAD not_oops2.test]
#: $ abrt-dump-oops -d -o cut_here.test
#* [http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=examples/not_oops3.test;hb=HEAD not_oops3.test]
#: Version: 2.6.32-19.el6.x86_64
# Test that stand-alone detector tool is working properly:  
#: WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:467
<pre>
#: generic_get_mtrr+0x11e/0x140() (Not tainted)
$ dumpoops -s examples_oops1.test
#: ...
dumpoops: found oopses: 1
#: [<ffffffff810abcff>] sys_init_module+0xdf/0x250
Version: 2.6.27.9-159.fc10.i686 #1
#: [<ffffffff81013172>] system_call_fastpath+0x16/0x1b
BUG: unable to handle kernel NULL pointer dereference at 00000000
#: abrt-dump-oops: Creating dump directories
...</pre>
# Open abrt-gui and look for the crash.
 
# And now test if ABRT's scanning of /var/log/messages works, you'll need a root privs for this
 
# Make sure {{filename|/etc/abrt/abrt_event.conf}} contains <tt>EVENT=post-create analyzer=Kerneloops  abrt-action-analyze-oops</tt> and <tt>EVENT=report          analyzer=Kerneloops  abrt-action-kerneloops</tt>. If changed anything, restart abrtd:<tt> service abrtd restart</tt>.
 
# cat the downloaded file to {{filename|/var/log/messages}} e.g.:<pre>cat cut_here.test >> /var/log/messages</pre>
# And now test if ABRT's ''KernelOopsScanner'' is working, you'll need root privs for this
# If you are logged as a root: Wait for abrt-applet (make sure it's running) and notification to popup to show the notification about the detected kerneloops. Otherwise open abrt-gui as a root instead.
# Edit /etc/abrt/abrt.conf so it says: <pre>10 = KerneloopsScanner</pre> This makes abrtd scan /var/log/messages more often, every 10 secs. Then restart abrtd:<pre># service abrtd restart</pre>
# cat the downloaded file to /var/log/messages e.g.:<pre>cat examples_oops1.test >> /var/log/messages</pre>
# Wait for abrt-applet (make sure it's running) to show the notification about the detected kerneloops
# Open the abrt-gui and check if you can see the oops


|results=
|results=
# After running dumpoops: oops1.test and oops3.test should contain one and three oopses respectively. not_oopsN.test should not be detected as containing oops.
# After running {{command|abrt-dump-oops}} on {{filename|cut_here.test}} crash should be craeted nad visible via abrt-gui and in the terminal. Running the same command on {{filename|not_oops3.test}} should not create crash case.
# After finishing the second part: oopses detected and visible in abrt-gui
# After finishing the second part: oops was detected and is visible in abrt-gui.
}}
}}
[[Category:Package_abrt_test_cases]]
[[Category:Package_abrt_test_cases]]

Revision as of 09:47, 15 March 2011

Description

This test case tests the functionality of the ABRT kerneloops feature.


How to test

  1. We will check that the abrt-dump-oops works and provides correct amount of crashes detected.
  2. Download files:
  3. Test that stand-alone detector tool works properly; Do as a root for both files:
    $ abrt-dump-oops -d -o cut_here.test
    Version: 2.6.32-19.el6.x86_64
    WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:467
    generic_get_mtrr+0x11e/0x140() (Not tainted)
    ...
    [<ffffffff810abcff>] sys_init_module+0xdf/0x250
    [<ffffffff81013172>] system_call_fastpath+0x16/0x1b
    abrt-dump-oops: Creating dump directories
  4. Open abrt-gui and look for the crash.
  5. And now test if ABRT's scanning of /var/log/messages works, you'll need a root privs for this
  6. Make sure /etc/abrt/abrt_event.conf contains EVENT=post-create analyzer=Kerneloops abrt-action-analyze-oops and EVENT=report analyzer=Kerneloops abrt-action-kerneloops. If changed anything, restart abrtd: service abrtd restart.
  7. cat the downloaded file to /var/log/messages e.g.:
    cat cut_here.test >> /var/log/messages
  8. If you are logged as a root: Wait for abrt-applet (make sure it's running) and notification to popup to show the notification about the detected kerneloops. Otherwise open abrt-gui as a root instead.

Expected Results

  1. After running abrt-dump-oops on cut_here.test crash should be craeted nad visible via abrt-gui and in the terminal. Running the same command on not_oops3.test should not create crash case.
  2. After finishing the second part: oops was detected and is visible in abrt-gui.