abrt 1.0.6 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: dc component: bc executable: /usr/bin/dc kernel: 2.6.31.12-174.2.3.fc12.x86_64 package: bc-1.06.95-1.fc12 rating: 4 reason: Process was terminated by signal 3 (Quit) release: Fedora release 12 (Constantine)
Created attachment 390138 [details] File: backtrace
Could you please comment how to reproduce that dc crash? I tried few things based on the backtrace, but I'm not able to reproduce it. Thanks in advance...
The output of what was typed is below. Might be a little hard to replicate. 256 2 ^ 30 * p 1966080 256 2 30 ^ * p 274877906944 8 / p 34359738368 ? help dc: 'h' (0150) unimplemented dc: 'e' (0145) unimplemented dc: register 'p' (0160) is empty ^C^C^C^[[1;5Dq dc: 033 unimplemented q ^C^\Quit (core dumped)
ok, just ctrl+'\' seems to be enough to dump core with dc reading stdin, reproducible for me, thanks for the steps to reproduce.
I think it is not caused by dc, but more by change either in kernel or glibc. I found similar report about ctrl+\ (SIGQUIT) in Ubuntu - https://bugs.launchpad.net/ubuntu/+source/apport/+bug/62511 ... the core dump was generated by cat command (when ctrl+\ was hit). Don't know whether it's notabug or it should be reassigned, but not dc/bc issue.
Ok, after discussing issue a bit with colleagues, I decided to reassign the bugzilla against abrt. [root@prdell kernel]# service abrtd stop Stopping abrt daemon: [ OK ] [root@prdell kernel]# ulimit -c 0 [root@prdell kernel]# ulimit -c 0 [root@prdell kernel]# cat ^\Quit [root@prdell kernel]# service abrtd start Starting abrt daemon: [ OK ] [root@prdell kernel]# ulimit -c 0 [root@prdell kernel]# cat ^\Quit (core dumped) I'm completely ok with abrt informations, I'm completely ok, that SIGQUIT generates core with ulimit -c unlimited (or whatever set). But abrt in the case of ulimit -c 0 just confuses user with (core dumped) message and additionally - SIGQUIT in most cases gives confusing traceback - which isn't really helpful. I suggest to just ignore SIGQUIT signal in ABRT completely.
Ah this old chestnut. See a related issue I had at: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/62511 I would like nothing to happen when cores are disabled. I'm not even sure if fedora have this wired up the same way, but I have a stopwatch script for example that responds to Ctrl+\ and starting a user space prog when this happens even if it just ignores the signal, introduces very noticeable delay.
(In reply to comment #7) > Ah this old chestnut. See a related issue I had at: > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/62511 > > I would like nothing to happen when cores are disabled. > I'm not even sure if fedora have this wired up the same way, > but I have a stopwatch script for example that responds to Ctrl+\ > and starting a user space prog when this happens even if it > just ignores the signal, introduces very noticeable delay. Actually this is something neither ABRT nor APPORT can control, the hook that gathers coredumps kicks-in even if ulimit -c is set to 0 (that's it purpose, if you don't want to detect C/C++ crashes, you can remove abrt-plugin-ccpp). What I'm not sure about is throwing coredumps at SIGQUIT, but I don't see in glibc so there might be a reason for this. Jirka
abrt (sufficiently new one) checks ulimit -c. If it is smaller than coredump size, abrt does not create core[.NNNN] file. If it is larger, abrt checks /etc/abrt/plugins/CCpp.conf MakeCompatCore = yes/no directive. If it is set to "yes", then abrt creates core[.NNNN] file. In both cases, abrt will also create its own crash dump in /var/cache/abrt. It cannot be disabled by ulimit -c 0 as of now. The message you are complaining about, ^\ -> "(core dumped)", is not produced by abrt. It is the result of process exit code having "core has been dumped" bit set. When shell sees it, it says "Quit (core dumped)". If it is not set, shell says just "Quit". The bit will always be set for processes killed by SIGQUIT while "pipe" coredump handler is installed, no matter what coredump handler will do (whether it will or will not write coredump to disk). In what way do you want current behavior to be improved?
(In reply to comment #9) > In what way do you want current behavior to be improved? 1) I guess abrt should not monitor and report SIGQUIT reports by default. Maybe as optional things and only with reproducer, but definitely not by default. 2) I'm sure that "(core dumped)" message is not produced by abrt. But abrt coredump handler affects it. It would be much better to improve current situation - to not show that confusing message for user generated SIGQUIT. At the moment some users see "Ah, core dump, that's bad, I have to report it somewhere!" although nothing bad happened. That's not good and has to be improved.
Sigh it looks like the Fedora kernel now has this kernel behaviour. I.E. one can't get the kernel to stop calling the external handler. [root@f12 ~]# uname -r 2.6.31.12-174.2.3.fc12.i686 [root@f12 ~]# echo "|/bin/true" > /proc/sys/kernel/core_pattern [root@f12 ~]# ulimit -c 0 [root@f12 ~]# cat ^\Quit (core dumped) That's going to be slow when one wants immediate response. There are only a couple of interrupts that can be generated by a user at a terminal: SIGTSTP (^Z), SIGQUIT (^\), exluding SIGINT (^C). Could we log this against the kernel to change things so that `ulimit -c 0` means don't call the external handler.
> > In what way do you want current behavior to be improved? > > 1) > I guess abrt should not monitor and report SIGQUIT reports by default. Maybe as > optional things and only with reproducer, but definitely not by default. Done this in git. > 2) > I'm sure that "(core dumped)" message is not produced by abrt. But abrt > coredump handler affects it. It would be much better to improve current > situation - to not show that confusing message for user generated SIGQUIT. I don't see how this can be achieved.
(In reply to comment #11) > Sigh it looks like the Fedora kernel now has this kernel behaviour. > I.E. one can't get the kernel to stop calling the external handler. > > [root@f12 ~]# uname -r > 2.6.31.12-174.2.3.fc12.i686 > [root@f12 ~]# echo "|/bin/true" > /proc/sys/kernel/core_pattern > [root@f12 ~]# ulimit -c 0 > [root@f12 ~]# cat > ^\Quit (core dumped) > > That's going to be slow when one wants immediate response. What is going to be slow? The dumping is async, user can continue immediately. > There are only a couple of interrupts that can be generated > by a user at a terminal: SIGTSTP (^Z), SIGQUIT (^\), exluding > SIGINT (^C). And only SIGQUIT is calling the helper. > Could we log this against the kernel to change things > so that `ulimit -c 0` means don't call the external handler. Some people want exactly the opposite: they want to see SIGSEGVs etc even in processes with core size limit 0.
> The dumping is async If it wasn't synchronous I wouldn't be complaining :) # echo "|/bin/sleep 3" > /proc/sys/kernel/core_pattern # ulimit -c 0 # time cat ^\Quit (core dumped) real 0m4.760s > And only SIGQUIT is calling the helper. Sorry I was unclear. I meant that there are only a couple of interrupts available to terminal users which can be mapped to various keys. Making one of them really slow is limiting. > Some people want exactly the opposite: they want to see SIGSEGVs etc even in > processes with core size limit 0 OK fair enough, but there should be some way to cater for the more common case where people use `ulimit -c 0` to tell the kernel they don't care.
Since version 1.0.7 abrt ignores the SIGABRT - that means the hook from core_pattern is run in the case of SIGABRT, but quits almost immediately so the slow down is just a few ms.
Not SIGABRT but SIGQUIT... ok, I still think that this message about core dumped is very confusing and should be improved, however I don't see any easy way to get this(maybe just some kernel hacks). But ok, at least no more useless reports from SIGQUITs...
abrt-1.0.8-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/abrt-1.0.8-1.fc13
abrt-1.0.8-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update abrt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2697
abrt-1.0.8-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.