produces empty core dumps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
Gutsy |
Fix Released
|
Medium
|
Martin Pitt | ||
gnome-speech (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Gutsy |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: apport
Various reports, like bug 122470 or bug 122511 have an empty CoreDump: and empty Stacktraces.
Changed in apport: | |
assignee: | nobody → pitti |
importance: | Undecided → High |
status: | New → Incomplete |
Roberto Gradini (robertogradini) wrote : | #2 |
Roberto Gradini (robertogradini) wrote : | #3 |
Jordan Hall (jordan-hall) wrote : | #4 |
I will attach the files you requested. It thought it may also be useful to know that your final command ended as follows:
[snip]
Test search_
Test standard_title(). ... ok
=======
FAIL: Test add_gdb_info() with a script.
-------
Traceback (most recent call last):
File "/usr/share/
self.
AssertionError
Jordan Hall (jordan-hall) wrote : | #5 |
Jordan Hall (jordan-hall) wrote : | #6 |
- apport.log.1 Edit (1.5 KiB, text/plain)
It appears after running those commands that /var/log/apport.log does not exist. I have attached the closest match (/var/log/
Kyle Jones (mutiny32) wrote : | #7 |
Kyle Jones (mutiny32) wrote : | #8 |
Martin Pitt (pitti) wrote : | #9 |
Thanks, folks, for the logs so far, this gave me an initial idea. Can you please now do the following:
/usr/
And attach /tmp/test-
There seems to be something fundamentally wrong with gdb & co on i386. However, the tests should get a little further if you install the package 'build-essential' (this will pull in some dependencies like gcc and libc6-dev). After that, can you please do the /usr/share/
Thanks a lot in advance!
Roberto Gradini (robertogradini) wrote : | #10 |
Roberto Gradini (robertogradini) wrote : | #11 |
Martin Pitt (pitti) wrote : | #12 |
not a gnome-speech bug, closing this task.
Changed in gnome-speech: | |
status: | New → Invalid |
Martin Pitt (pitti) wrote : | #13 |
RobertGradini,
sorry, I forgot to mention that you have to clean /var/crash/ before running the test suite. Can you please do
sudo rm /var/crash/*
/usr/
instead? Thank you!
Roberto Gradini (robertogradini) wrote : | #14 |
I'm sorry but there's a problem:
roberto@pearljam:~$ /usr/share/
* Check test process creation/killing with apport
* Check that a subsequent crash does not alter unseen report
* Check that a subsequent crash alters seen report
* Check that report has required fields
* Check that dumped environment only has insensitive variables
* Check that collected system groups has nonempty user groups information
* Check that collected system groups are not those from root
* Check that non-packaged executables do not create a report
* Check that apport ignores SIGQUIT
* Check that existence of user-inaccessible files does not leak
* Check that non-packaged scripts do not create a report
* Test limitation of flooding: iteration 0 1 2 3
Traceback (most recent call last):
File "/usr/share/
'no reports present after deleting (present: %s)' % str(apport.
AssertionError: no reports present after deleting (present: ['/var/
Shirish Agarwal (shirishag75) wrote : | #15 |
- apport-test.out Edit (3.2 KiB, text/plain)
FAIL: Test add_gdb_info() with a script.
-------
Traceback (most recent call last):
File "/usr/share/
self.
AssertionError
-------
Ran 16 tests in 16.125s
FAILED (failures=1)
last output while doing the tests.
useResa (rdrijsen) wrote : | #16 |
- /tmp/apport-test.out Edit (3.2 KiB, text/plain)
Performed the actions as requested in Bug #122771, being:
"Actually apport should work on this kernel again. Can you please do the
following:
sudo rm /var/crash/*
sudo rm /var/log/apport.log
/usr/share/
and attach /tmp/apport-
useResa (rdrijsen) wrote : | #17 |
The second file /var/log/apport.log was not present.
Please find attached the results of the last command as provided in the instructions:
rdrijsen@
+ python -tt /usr/share/
Test adding information to an existing report. ... ok
Test basic creation and operation. ... ok
Test writing and re-decoding a big random file. ... ok
Test non-default constructor arguments. ... ok
Test ProblemReport iteration. ... ok
Test load() with various formatting. ... ok
Test reading, modifying fields, and writing back. ... ok
Test reading a report with binary data. ... ok
Test reading a report with binary data (legacy bzip2 compression). ... ok
Test various error conditions. ... ok
Test writing and a big random file with a size limit key. ... ok
Test new_keys() and write() with only_new=True. ... ok
Test write() and proper formatting. ... ok
Test write() with appending to an existing file. ... ok
Test writing a report with binary file data. ... ok
Test writing a report with a pointer to a file-like object. ... ok
Test write_mime() for binary values and file references. ... ok
Test write_mime() with extra headers. ... ok
Test write_mime() for text values. ... ok
-------
Ran 19 tests in 5.018s
OK
+ python -tt /usr/share/
Test check_files_md5(). ... ok
Test delete_report(). ... ok
Test find_file_
Test find_package_
Test get_all_reports(). ... ok
Test get_recent_
Test get_all_
Test likely_packaged(). ... ok
Test make_report_path(). ... ok
Test get_new_reports() and seen_report(). ... ok
-------
Ran 10 tests in 4.158s
OK
+ python -tt /usr/share/
Test add_gdb_info() with core dump file reference. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
ok
Test add_gdb_info() with inline core dump. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
ok
Test add_gdb_info() with a script. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
FAIL
Test add_hooks_info(). ... ok
Test add_os_info(). ... ok
Test add_package_info(). ... ok
Test add_proc_info(). ... ok
Test add_user_info(). ... ok
Test _check_
Test crash_signature(). ... ok
Test _gen_stacktrace
Test has_useful_
Test mark_ignore() and check_ignored(). ... ok
Test obsolete_
Test search_
Test standard_title(). ... ok
=======
FAIL: Test add_gdb_info() with a script.
-------
Traceback (most r...
Shirish Agarwal (shirishag75) wrote : | #18 |
tried /usr/share/
this happens
shirish@ubuntu:~$ sudo rm /var/crash/*
[sudo] password for shirish:
rm: cannot remove `/var/crash/*': No such file or directory
shirish@ubuntu:~$ /usr/share/
* Check test process creation/killing with apport
Traceback (most recent call last):
File "/usr/share/
check_crash()
File "/usr/share/
assert not os.path.
AssertionError: no core dump in current directory
shirish@ubuntu:~$
and there is a crash report at bug 122819
Shirish Agarwal (shirishag75) wrote : | #19 |
Here is the whole thing in case if people are interested
shirish@ubuntu:~$ /usr/share/
+ python -tt /usr/share/
Test adding information to an existing report. ... ok
Test basic creation and operation. ... ok
Test writing and re-decoding a big random file. ... ok
Test non-default constructor arguments. ... ok
Test ProblemReport iteration. ... ok
Test load() with various formatting. ... ok
Test reading, modifying fields, and writing back. ... ok
Test reading a report with binary data. ... ok
Test reading a report with binary data (legacy bzip2 compression). ... ok
Test various error conditions. ... ok
Test writing and a big random file with a size limit key. ... ok
Test new_keys() and write() with only_new=True. ... ok
Test write() and proper formatting. ... ok
Test write() with appending to an existing file. ... ok
Test writing a report with binary file data. ... ok
Test writing a report with a pointer to a file-like object. ... ok
Test write_mime() for binary values and file references. ... ok
Test write_mime() with extra headers. ... ok
Test write_mime() for text values. ... ok
-------
Ran 19 tests in 4.366s
OK
+ python -tt /usr/share/
Test check_files_md5(). ... ok
Test delete_report(). ... ok
Test find_file_
Test find_package_
Test get_all_reports(). ... ok
Test get_recent_
Test get_all_
Test likely_packaged(). ... ok
Test make_report_path(). ... ok
Test get_new_reports() and seen_report(). ... ok
-------
Ran 10 tests in 2.198s
OK
+ python -tt /usr/share/
Test add_gdb_info() with core dump file reference. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
ok
Test add_gdb_info() with inline core dump. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
ok
Test add_gdb_info() with a script. ... Failed to read a valid object file image from memory.
warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
FAIL
Test add_hooks_info(). ... ok
Test add_os_info(). ... ok
Test add_package_info(). ... ok
Test add_proc_info(). ... ok
Test add_user_info(). ... ok
Test _check_
Test crash_signature(). ... ok
Test _gen_stacktrace
Test has_useful_
Test mark_ignore() and check_ignored(). ... ok
Test obsolete_
Test search_
Test standard_title(). ... ok
=======
FAIL: Test add_gdb_info() with a script.
-------
Traceback (most recent call last):
File "/usr/share/
Shirish Agarwal (shirishag75) wrote : | #20 |
- test-kernel.out Edit (1.0 KiB, text/plain)
After talking with martin pitti I removed the core file :-
shirish@ubuntu:~$ rm core
shirish@ubuntu:~$ /usr/share/
* Check test process creation/killing with apport
* Check that a subsequent crash does not alter unseen report
* Check that a subsequent crash alters seen report
* Check that report has required fields
* Check that dumped environment only has insensitive variables
* Check that collected system groups has nonempty user groups information
* Check that collected system groups are not those from root
* Check that non-packaged executables do not create a report
* Check that apport ignores SIGQUIT
* Check that existence of user-inaccessible files does not leak
* Check that non-packaged scripts do not create a report
* Test limitation of flooding: iteration 0 1 2
* Check that core dump works for non-writable cwds
Traceback (most recent call last):
File "/usr/share/
check_crash()
File "/usr/share/
assert not os.path.
AssertionError: no core dump in current directory
shirish@ubuntu:~$
There is a 1040 bytes test-kernel.out which I am attaching
Shirish Agarwal (shirishag75) wrote : | #21 |
Martin Pitt (pitti) wrote : | #22 |
Thanks for the logs so far. So we just found out that bug 74691 is the reason why 'run-tests' fails on i386. It works fine on amd64 and powerpc (the platforms I'm testing on).
I will install i386 now to have a look at this myself.
Shirish Agarwal (shirishag75) wrote : | #23 |
shirish@ubuntu:~$ LC_ALL=en_US apt-cache policy linux-image-`uname -r`
linux-image-
Installed: 2.6.22-7.14
Candidate: 2.6.22-7.14
Version table:
*** 2.6.22-7.14 0
500 http://
100 /var/lib/
Shirish Agarwal (shirishag75) wrote : | #24 |
- test-kernel.out Edit (232 bytes, text/plain)
this is output from /tmp
shirish@ubuntu:~$ /usr/share/
Traceback (most recent call last):
File "/usr/share/
assert apport.
AssertionError: no reports already present
Shirish Agarwal (shirishag75) wrote : | #25 |
after talking with pitti, I did the following things :-
1. go to /var/crash :- rm *
2. then copied test apport to /tmp
cp /usr/share/
3. ran the test more than 15 times /tmp/test-apport kernel 2>&1 | tee /tmp/test-
I get the same output as in https:/
Martin Pitt (pitti) wrote : | #26 |
BTW, the effect of filing useless bugs is mitigated with
apport (0.86) gutsy; urgency=low
* test-apport: Check that apport does not create reports for emtpy core
dumps.
* problem_report.py: Introduce a fourth optional parameter "fail_on_empty"
to file pointer tuples which causes write() to raise an IOError if no data
was read. Add test cases.
* bin/apport: Enforce non-emptyness of CoreDump.
* problem_report.py: Add test case for delayed piping of data passed as file
object pointers. This was supposed to explain the reason for getting bugs
with zero-byte core dumps, but already works correctly.
* apport/report.py, check_ignored(): round the mtime to an int (just like
mark_ignore() does), to not get wrong results on file systems that support
subsecond file timestamps. This fixes running the test suite on the live
CD.
* test-apport: Clarify assertion message if /var/crash is not empty.
-- Martin Pitt <email address hidden> Thu, 28 Jun 2007 19:14:36 +0200
It does not actually solve the original problem, though, that apport sometimes generates crash reports with empty core dumps.
Martin Pitt (pitti) wrote : | #27 |
Removing milestone, since it does not generate bug spam any more. It does, however, prevent bugs to be filed under some circumstances.
Changed in apport: | |
importance: | High → Medium |
chaseneb (chaseneb) wrote : | #28 |
miked (miked11) wrote : | #29 |
root@2HewittRan
* Check that empty core dumps do not generate a report
* Check test process creation/killing with apport
* Check that a subsequent crash does not alter unseen report
* Check that a subsequent crash alters seen report
* Check that report has required fields
* Check that dumped environment only has insensitive variables
* Check that collected system groups has nonempty user groups information
* Check that collected system groups are not those from root
* Check that only one apport instance is ran at a time
* Check that existing .lock file as dangling symlink does not create the file
* Check that non-packaged executables do not create a report
* Check that apport ignores SIGQUIT
* Check that existence of user-inaccessible files does not leak
* Check that non-packaged scripts do not create a report
* Test limitation of flooding: iteration 0 1 2
* Check that core dump works for non-writable cwds
* Check that non-packaged executables create core dumps on proper ulimits
* Check that non-packaged executables create core dumps on proper ulimits for SIGABRT
* Check that packaged executables create core dumps on proper ulimits
* Check that crashes create core dumps with an existing crash report
* Check that packaged executables create core dumps on proper ulimits for SIGABRT
* Check that core dumps are capped on available memory size....
* Check that binary blacklisting works
root@2HewittRan
root@2HewittRan
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
root@2HewittRan
miked (miked11) wrote : | #30 |
Added Info
Changed in apport: | |
status: | Incomplete → New |
Martin Pitt (pitti) wrote : | #31 |
miked, your run looks good, the test suite passed. I haven't seen this anywhere else on Hardy any more, so I'm closing this.
Changed in apport: | |
status: | Incomplete → Fix Released |
miked (miked11) wrote : | #32 |
cool, thanks.
Changed in apport: | |
status: | New → Fix Released |
linuxatico88 (simo88-47) wrote : | #33 |
- apport-test.out Edit (3.7 KiB, text/plain)
(gdb) info registers
eax 0xfffffdfc -516
ecx 0x6 6
edx 0x63 99
ebx 0x87d1398 142414744
esp 0xbfdeb484 0xbfdeb484
ebp 0xbfdeb4a8 0xbfdeb4a8
esi 0x63 99
edi 0xb6e84ff4 -1226289164
eip 0xb7f29410 0xb7f29410 <__kernel_
eflags 0x200246 [ PF ZF IF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) thread apply all backtrace
Thread 9 (Thread 0xb2fd4b90 (LWP 9479)):
#0 0xb7f29410 in __kernel_vsyscall ()
#1 0xb6e06697 in poll () from /lib/tls/
#2 0xb6f2d176 in ?? () from /usr/lib/
#3 0x0888b0b0 in ?? ()
#4 0x00000005 in ?? ()
#5 0xffffffff in ?? ()
#6 0x0888b0b0 in ?? ()
#7 0x00000005 in ?? ()
#8 0xb6fa05f8 in ?? () from /usr/lib/
#9 0xb6fa0620 in ?? () from /usr/lib/
#10 0xb2fd42d4 in ?? ()
#11 0x00000001 in ?? ()
#12 0x00000001 in ?? ()
#13 0x088599f0 in ?? ()
#14 0x0888b0b0 in ?? ()
#15 0xb6e06620 in ?? () from /lib/tls/
#16 0xb7c98df0 in ?? () from /lib/tls/
#17 0xb7c97520 in ?? () from /lib/tls/
#18 0xb6f51a62 in g_thread_self () from /usr/lib/
#19 0xb6f2d527 in g_main_loop_run () from /usr/lib/
#20 0xb77d2ce0 in ?? () from /usr/lib/
#21 0x088979c0 in ?? ()
#22 0xb6fa0248 in ?? () from /usr/lib/
#23 0xb2fd4358 in ?? ()
#24 0xb6f51fef in ?? () from /usr/lib/
#25 0x00000000 in ?? ()
Thread 7 (Thread 0xb37d5b90 (LWP 9447)):
#0 0xb7f29410 in __kernel_vsyscall ()
#1 0xb7c99aa5 in pthread_
#2 0xb6f04e52 in ?? () from /usr/lib/
#3 0xb38012d0 in ?? ()
#4 0x081fe560 in ?? ()
#5 0xb37d5298 in ?? ()
#6 0xb6fa0248 in ?? () from /usr/lib/
#7 0xb38016d8 in ?? ()
#8 0x00000000 in ?? ()
Thread 1 (Thread 0xb6526720 (LWP 9355)):
#0 0xb7f29410 in __kernel_vsyscall ()
#1 0xb6e06697 in poll () from /lib/tls/
#2 0xb6f2d176 in ?? () from /usr/lib/
#3 0x087d1398 in ?? ()
#4 0x00000006 in ?? ()
#5 0x00000063 in ?? ()
#6 0x087d1398 in ?? ()
#7 0x00000009 in ?? ()
#8 0xb6fa05f8 in ?? () from /usr/lib/
#9 0xb6fa0620 in ?? () from /usr/lib/
#10 0xbfdeb4f4 in ?? ()
#11 0x00000001 in ?? ()
#12 0x00000001 in ?? ()
#13 0x0814e480 in ?? ()
#14 0x087d1398 in ?? ()
#15 0xb6e06620 in ?? () from /lib/tls/
#16 0xb7c98df0 in ?? () from /lib/tls/
#17 0xb7c97520 in ?? () from /lib/tls/
#18 0xb6f51a62 in g_thread_self () from /usr/lib/
#19 0xb6f2d527 in g_main_loop_run () from /usr/lib/
#20 0xb7534044 in gtk_main () from /usr/lib/
#21 0x080627b0 in main ()
linuxatico88 (simo88-47) wrote : | #34 |
Martin Pitt (pitti) wrote : | #35 |
linuxatico88, you attached a test suite run which is invalid because you ran it as root. Please run it as normal user.
Do you also have the problem? Your reply did not have any explanations or context.
Craig Maloney (craig-decafbad) wrote : | #36 |
I can confirm this is an issue with an upgrade from Gutsy to Hardy. I am experiencing exactly the same behavior mentioned above. I'm not receiving any crash reports, even though apport is supposedly running.
Martin Pitt (pitti) wrote : Re: [Bug 122688] Re: produces empty core dumps | #37 |
Hi,
Craig Maloney [2008-05-31 3:34 -0000]:
> I can confirm this is an issue with an upgrade from Gutsy to Hardy. I am
> experiencing exactly the same behavior mentioned above. I'm not
> receiving any crash reports, even though apport is supposedly running.
NB that apport is turned off by default in Hardy final, this time by
completely disabling it in /etc/default/
lot of disk access and delays after a program crashed.
So if you do not get any crash report at all, it is behaving as
intended. If you do get crash reports, but the core dump is empty, you
triggered this bug.
Craig Maloney (craig-decafbad) wrote : | #38 |
I agree, but this is the settings in /etc/default/
# set this to 0 to disable apport, or to 1 to enable it
enabled=1
# set maximum core dump file size (default: 209715200 bytes == 200 MB)
maxsize=209715200
Martin Pitt (pitti) wrote : | #39 |
Craig Maloney [2008-06-03 2:05 -0000]:
> enabled=1
OK, that should work. After you get a crash, what does
/var/log/apport.log contain? You can easily generate a "fake" crash
with opening a Terminal and typing
bash -c 'kill -SEGV $$'
Craig Maloney (craig-decafbad) wrote : | #40 |
OK, that seemed to work. It must be something else then, because I'm trying to get a crash report for Rhythmbox, and while the app disappears repeatedly when I perform a certain task, I can't seem to generate a crash dump off of that.
Thanks for the pointers!
Can people who are affected by this please do the following:
sudo rm /var/crash/* share/apport/ testsuite/ run-tests 2>&1 | tee /tmp/apport- test.out
sudo rm /var/log/apport.log
/usr/
and attach /tmp/apport- test.out and /var/log/apport.log to bug 122688?
Thanks a lot!