Bug 1368714
| Summary: | /usr/lib/systemd/systemd-journald crasched on writing firefox core file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomasz Kłoczko <kloczko.tomasz> | ||||
| Component: | systemd | Assignee: | systemd-maint | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | johannbg, lnykryn, msekleta, muadda, ssahani, s, systemd-maint, zbyszek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-08-26 09:30:37 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Tomasz Kłoczko
2016-08-20 17:23:31 UTC
Created attachment 1192482 [details]
core.systemd-journal.0.1e8af79~13ac3.592.1471625154000000.lz4
It probably didn't crash per se, but was terminated by systemd because it missed the watchdog ping. But it seems that it's just writing a short message, so it shouldn't do that. Was the machine under heady load? Do you have an ssd or rotation drive? Can you provide the logs from around the crash? I had another firefox crash in meantime. Strange but after uncompressing core*.lz4 I found only 2GB file and of course by this it was corrupted. If it any limit of max core file size? maybe it is limited by max file size which is able compess lz4? $ sudo ulimit -c unlimited Nevertheless as you see in case of the crash which I've reported systemd-journal generated own core file. There's a default limit of 2GB for core dumps. The file is not corrupted, just truncated. GDB should be able to extract useful information from this anyway. I don't think this abort is directly related to the firefox crash. I think the system was overloaded because of memory and cpu contention as an effect of the firefox crash and processing of the core dump or something. FTR, journald was trying to write the following: (gdb) p (char*)iovec[0].iov_base $13 = 0x5567f9e060f0 "_SOURCE_MONOTONIC_TIMESTAMP=154852337252" (gdb) p (char*)iovec[1].iov_base $14 = 0x5567f960780e "_TRANSPORT=kernel" (gdb) p (char*)iovec[2].iov_base $15 = 0x5567f9e28bb0 "PRIORITY=7" (gdb) p (char*)iovec[3].iov_base $16 = 0x5567f9e292b0 "SYSLOG_FACILITY=4" (gdb) p (char*)iovec[4].iov_base $17 = 0x5567f9e403c0 "SYSLOG_IDENTIFIER=systemd-logind" (gdb) p (char*)iovec[5].iov_base $18 = 0x5567f9e1be80 "SYSLOG_PID=912" (gdb) p (char*)iovec[6].iov_base $19 = 0x5567f9e0a340 "MESSAGE=Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/unit/httpd_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=35388 reply_"... (gdb) p (char*)iovec[7].iov_base $20 = 0x7fffb362ba56 "_BOOT_ID=1e8af79af2854019bba8d91966113ac3" (gdb) p (char*)iovec[8].iov_base $21 = 0x7fffb362ba29 "_MACHINE_ID=02dfc25c60b54e85bc6096668e58e42c" (gdb) p (char*)iovec[9].iov_base $22 = 0x5567f9dfd850 "_HOSTNAME=domek" *** This bug has been marked as a duplicate of bug 1300212 *** gdb been reporting that core file was corrupted and it was not able to show registers or stack back trace content. I think that default 2GB limit should be increased. Yeah, IIRC, we already increased it upstream. |