jai-imageio-core
  1. jai-imageio-core
  2. JAI_IMAGEIO_CORE-174

Native JPEG-LOSSLESS decoder causes VM to crash!

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: milestone 1
    • Component/s: codeclib
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      174

      Description

      Uncompress a dicom multiframe image encoded with Jpeg LS lossless causes VM to
      crash.

      1. 743AE19C
        870 kB
        fwiller
      1. 743AE19C.jpg
        826 kB
      2. LosslessSample.jpg
        919 kB

        Activity

        Hide
        fwiller added a comment -

        Created an attachment (id=133)
        Sample DICOM file that causes the VM crash

        Show
        fwiller added a comment - Created an attachment (id=133) Sample DICOM file that causes the VM crash
        Hide
        jxc added a comment -

        The JPEG bitstream starts from offset 0xB1FE in the DICOM file 743AE19C.
        It appears to be a JPEG-LOSSLESS bitstream. The problem can be reproduced
        on Solaris SPARC with libclib_jiio.so:

        — called from signal handler with signal 11 (SIGSEGV) —
        d6fa0f9c jpeg_DecoderHuffmanFillLine (1245b0, 2bcec8, 400, 0, ff, 3fc) + b8
        d6f87aa0 jpeg_read_ls_16 (2bcec8, 3ff, 530f6, fffacf0a, 3ff, 124518) + 228
        d6f7a5e0 jpeg_read_image (124270, 124270, 0, 0, 124270, 10000) + 164
        d6f743f4 jpeg_read_markers (124518, 124270, 0, 4, 5, 8081) + 1c
        d6f74aa0 jpeg_decode (0, 124270, 2b820, 30b88, 30f44, 71fc58) + 2c
        d6f07214 Java_com_sun_medialib_codec_jpeg_Decoder_njpeg_1decode (304ec,
        fe67f8d4, 0, 242b40, fe67f8c8, 242b58) + 18

        Show
        jxc added a comment - The JPEG bitstream starts from offset 0xB1FE in the DICOM file 743AE19C. It appears to be a JPEG-LOSSLESS bitstream. The problem can be reproduced on Solaris SPARC with libclib_jiio.so: — called from signal handler with signal 11 (SIGSEGV) — d6fa0f9c jpeg_DecoderHuffmanFillLine (1245b0, 2bcec8, 400, 0, ff, 3fc) + b8 d6f87aa0 jpeg_read_ls_16 (2bcec8, 3ff, 530f6, fffacf0a, 3ff, 124518) + 228 d6f7a5e0 jpeg_read_image (124270, 124270, 0, 0, 124270, 10000) + 164 d6f743f4 jpeg_read_markers (124518, 124270, 0, 4, 5, 8081) + 1c d6f74aa0 jpeg_decode (0, 124270, 2b820, 30b88, 30f44, 71fc58) + 2c d6f07214 Java_com_sun_medialib_codec_jpeg_Decoder_njpeg_1decode (304ec, fe67f8d4, 0, 242b40, fe67f8c8, 242b58) + 18
        Hide
        jxc added a comment -

        Created an attachment (id=134)
        JPEG bitstream extracted from the DICOM file

        Show
        jxc added a comment - Created an attachment (id=134) JPEG bitstream extracted from the DICOM file
        Hide
        jxc added a comment -

        Here is the jpegdump of 743AE19C.jpg:

        offset $0 SOI
        offset $2 SOF3 (spatial lossless Huffman) (length 11)
        sample precision 12
        width 1024, height 1024 components 1
        id 0 horizontal sampling 1, vertical sampling 1, quantization table 0
        offset $f DHT (length 36)
        table 0
        bits 1 (codes= 0)
        bits 2 (codes= 3) $03 $04 $05
        bits 3 (codes= 0)
        bits 4 (codes= 3) $00 $02 $06
        bits 5 (codes= 1) $01
        bits 6 (codes= 1) $07
        bits 7 (codes= 1) $08
        bits 8 (codes= 1) $09
        bits 9 (codes= 1) $0a
        bits 10 (codes= 1) $0b
        bits 11 (codes= 1) $0c
        bits 12 (codes= 0)
        bits 13 (codes= 4) $0d $0e $0f $10
        bits 14 (codes= 0)
        bits 15 (codes= 0)
        bits 16 (codes= 0)
        offset $35 SOS (length 8)
        components 1
        id 0 dc table 0, ac table 0
        spectral selection 1 to 0
        bit position high 0, low 0
        offset $ce79b EOI

        The Huffman table generated from the above DHT looks like:

        huffsize[ 0] = 2, huffcode[ 0] = 0x0
        huffsize[ 1] = 2, huffcode[ 1] = 0x1
        huffsize[ 2] = 2, huffcode[ 2] = 0x2
        huffsize[ 3] = 4, huffcode[ 3] = 0xC
        huffsize[ 4] = 4, huffcode[ 4] = 0xD
        huffsize[ 5] = 4, huffcode[ 5] = 0xE
        huffsize[ 6] = 5, huffcode[ 6] = 0x1E
        huffsize[ 7] = 6, huffcode[ 7] = 0x3E
        huffsize[ 8] = 7, huffcode[ 8] = 0x7E
        huffsize[ 9] = 8, huffcode[ 9] = 0xFE
        huffsize[10] = 9, huffcode[10] = 0x1FE
        huffsize[11] = 10, huffcode[11] = 0x3FE
        huffsize[12] = 11, huffcode[12] = 0x7FE
        huffsize[13] = 13, huffcode[13] = 0x1FFC
        huffsize[14] = 13, huffcode[14] = 0x1FFD
        huffsize[15] = 13, huffcode[15] = 0x1FFE
        huffsize[16] = 13, huffcode[16] = 0x1FFF

        Note that the last one, huffcode[16] is an all-1-bits code word, which
        is at odds with the spec, in Annex C of T.81,

        "..., the codes shall be generated such that the all-1-bits code word
        of any length is reserved as a prefix for longer code words."

        It probably should be something like this:

        huffsize[16] = 14, huffcode[16] = 0x3FFE

        The clib JPEG decoder found this problem, but it failed to handle it
        in a graceful way. For this specific bitstream, the code word 0x1FFF
        does not seem to be really used, so the decoder might be able to work
        around this problem, or at least not to cause a VM crash.

        Show
        jxc added a comment - Here is the jpegdump of 743AE19C.jpg: offset $0 SOI offset $2 SOF3 (spatial lossless Huffman) (length 11) sample precision 12 width 1024, height 1024 components 1 id 0 horizontal sampling 1, vertical sampling 1, quantization table 0 offset $f DHT (length 36) table 0 bits 1 (codes= 0) bits 2 (codes= 3) $03 $04 $05 bits 3 (codes= 0) bits 4 (codes= 3) $00 $02 $06 bits 5 (codes= 1) $01 bits 6 (codes= 1) $07 bits 7 (codes= 1) $08 bits 8 (codes= 1) $09 bits 9 (codes= 1) $0a bits 10 (codes= 1) $0b bits 11 (codes= 1) $0c bits 12 (codes= 0) bits 13 (codes= 4) $0d $0e $0f $10 bits 14 (codes= 0) bits 15 (codes= 0) bits 16 (codes= 0) offset $35 SOS (length 8) components 1 id 0 dc table 0, ac table 0 spectral selection 1 to 0 bit position high 0, low 0 offset $ce79b EOI The Huffman table generated from the above DHT looks like: huffsize[ 0] = 2, huffcode[ 0] = 0x0 huffsize[ 1] = 2, huffcode[ 1] = 0x1 huffsize[ 2] = 2, huffcode[ 2] = 0x2 huffsize[ 3] = 4, huffcode[ 3] = 0xC huffsize[ 4] = 4, huffcode[ 4] = 0xD huffsize[ 5] = 4, huffcode[ 5] = 0xE huffsize[ 6] = 5, huffcode[ 6] = 0x1E huffsize[ 7] = 6, huffcode[ 7] = 0x3E huffsize[ 8] = 7, huffcode[ 8] = 0x7E huffsize[ 9] = 8, huffcode[ 9] = 0xFE huffsize [10] = 9, huffcode [10] = 0x1FE huffsize [11] = 10, huffcode [11] = 0x3FE huffsize [12] = 11, huffcode [12] = 0x7FE huffsize [13] = 13, huffcode [13] = 0x1FFC huffsize [14] = 13, huffcode [14] = 0x1FFD huffsize [15] = 13, huffcode [15] = 0x1FFE huffsize [16] = 13, huffcode [16] = 0x1FFF Note that the last one, huffcode [16] is an all-1-bits code word, which is at odds with the spec, in Annex C of T.81, "..., the codes shall be generated such that the all-1-bits code word of any length is reserved as a prefix for longer code words." It probably should be something like this: huffsize [16] = 14, huffcode [16] = 0x3FFE The clib JPEG decoder found this problem, but it failed to handle it in a graceful way. For this specific bitstream, the code word 0x1FFF does not seem to be really used, so the decoder might be able to work around this problem, or at least not to cause a VM crash.
        Hide
        marconeol added a comment -

        Another lossless JPEG bitstream sample, extracted from a DICOM file, which
        causes the native JAI Image I/O JPEG decoder to crash.

        Show
        marconeol added a comment - Another lossless JPEG bitstream sample, extracted from a DICOM file, which causes the native JAI Image I/O JPEG decoder to crash.
        Hide
        marconeol added a comment -

        Created an attachment (id=137)
        Another JPEG bitstream extracted from a DICOM file

        Show
        marconeol added a comment - Created an attachment (id=137) Another JPEG bitstream extracted from a DICOM file
        Hide
        jxc added a comment -

        Fixed in jclib4jai.20080724, and therefore in daily build 2008-07-25 and later.

        Show
        jxc added a comment - Fixed in jclib4jai.20080724, and therefore in daily build 2008-07-25 and later.

          People

          • Assignee:
            jxc
            Reporter:
            fwiller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: