<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Priority</th>
          <td>medium
          </td>
        </tr>

        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - journalctl crashes when journal is corrupted"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=74714">74714</a>
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>systemd-bugs@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>journalctl crashes when journal is corrupted
          </td>
        </tr>

        <tr>
          <th>QA Contact</th>
          <td>systemd-bugs@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>minor
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux (All)
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>janna.martl109@gmail.com
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>x86 (IA32)
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>general
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>systemd
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Some of my journal files seem to have gotten corrupted as a result of a failing
drive, and journalctl (or 'journalctl -n N' for sufficiently large N) dies with
either a segfault or (more recently) a bus error. I have also sometimes seen
the journalctl process stick around as a D-state process. These crashes happen
immediately after getting an I/O error (see below). This is annoying because
journalctl is one of the tools I'd like to use in troubleshooting hard drive
failure.

Here is a backtrace:

(gdb) bt full
#0  journal_file_move_to_object (f=f@entry=0x969cbc0, type=type@entry=3,
offset=2638264, ret=ret@entry=0xbfc6505c) at src/journal/journal-file.c:434
        r = 1
        t = 0xb2c781b8
        o = 0xb2c781b8
        __PRETTY_FUNCTION__ = "journal_file_move_to_object"
#1  0x0805fb37 in generic_array_get (f=f@entry=0x969cbc0, first=375376,
i=<optimized out>, ret=ret@entry=0xbfc651ac, offset=offset@entry=0xbfc651b0)
    at src/journal/journal-file.c:1443
        o = 0xb2c68b40
        p = <optimized out>
        a = <optimized out>
        t = 3158
        r = <optimized out>
        ci = 0x9687280
        __PRETTY_FUNCTION__ = "generic_array_get"
#2  0x08060269 in journal_file_next_entry (f=f@entry=0x969cbc0,
o=o@entry=0xb2c77c38, p=2636856, direction=direction@entry=DIRECTION_DOWN,
ret=ret@entry=0xbfc651ac,
    offset=offset@entry=0xbfc651b0) at src/journal/journal-file.c:1920
        i = 3181
        r = <optimized out>
        __PRETTY_FUNCTION__ = "journal_file_next_entry"
#3  0x0805855c in next_with_matches (j=j@entry=0x9670850, f=f@entry=0x969cbc0,
direction=direction@entry=DIRECTION_DOWN, ret=ret@entry=0xbfc651ac,
offset=offset@entry=0xbfc651b0)
    at src/journal/sd-journal.c:814
        c = 0xb2c77c38
        cp = 2636856
        __PRETTY_FUNCTION__ = "next_with_matches"
#4  0x0805a744 in next_beyond_location (offset=<synthetic pointer>,
ret=0xbfc651a4, direction=DIRECTION_DOWN, f=0x969cbc0, j=0x9670850) at
src/journal/sd-journal.c:836
        c = 0xb2c77c38
        cp = 2636856
        r = <optimized out>
#5  real_journal_next (j=j@entry=0x9670850,
direction=direction@entry=DIRECTION_DOWN) at src/journal/sd-journal.c:895
        found = <optimized out>
        f = 0x969cbc0
        new_file = 0x969b4e0
        new_offset = 399336
        o = 0xb324f718
        p = <optimized out>
        i = 0x968df04
        r = <optimized out>
        __func__ = "real_journal_next"
#6  0x0805b08e in sd_journal_next (j=0x9670850) at src/journal/sd-journal.c:931
No locals.
#7  0x0804daa1 in main (argc=1, argv=0xbfc65574) at
src/journal/journalctl.c:1573
        flags = <optimized out>
        r = 0
        j = 0x9670850
        need_seek = true
        previous_boot_id = {bytes = "X\357`\266L\307O̟\274\356\232\177\241\b2",
qwords = {14722204839188688728, 3605309071142337695}}
        previous_boot_id_valid = true
        first_line = true
        n_shown = 41695
        ellipsized = false
        __func__ = "main"


and here an I/O error that occured immediately before one of these crashes:

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x5
ata1.00: failed command: READ DMA EXT
ata1.00: cmd 25/00:08:c8:ca:92/00:00:2e:00:00/e0 tag 0 dma 4096 in
         res 51/40:05:cb:ca:92/40:00:2e:00:00/ee Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
sd 0:0:0:0: [sda] Unhandled sense code
sd 0:0:0:0: [sda]
mResult: hostbyte=0x00 driverbyte=0x08
sd 0:0:0:0: [sda]
mSense Key : 0x3 [current] [descriptor]
mDescriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
        2e 92 ca cb
sd 0:0:0:0: [sda] 
mASC=0x11 ASCQ=0x4
sd 0:0:0:0: [sda] CDB:
mcdb[0]=0x28: 28 00 2e 92 ca c8 00 00 08 00
end_request: I/O error, dev sda, sector 781372107
ata1: EH complete</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>