Library can crash while loading JP2s with 4-bits per channel

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load the attached file into j2k_dump for example.

What is the expected output? What do you see instead?

Not sure about expected, what I see is:

On Windows 1.5.0, I see:

C:\Documents and Settings\alex.macfarlane-smith\Desktop>j2k_dump -i 
mem-b2b86b74-2753.jp2

[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057
[ERROR] read error: passed the end of the codestream (start = 2584304, current =
 2141646699, end = 2587057

On Linux subversion, I see:

aardvark@hamster:~/openjpeg/openjpeg-read-only/applications/codec$ ./j2k_dump 
-i ~/mem-b2b86b74-2753.jp2

lt-j2k_dump: cio.c:261: opj_read_bytes_LE: Assertion `p_nb_bytes > 0 && 
p_nb_bytes <= sizeof(OPJ_UINT32)' failed.

What version of the product are you using? On what operating system?

1.5.0 on Windows, or current subversion on Linux.

Please provide any additional information below.

Also attached proposed patch.

Original issue reported on code.google.com by archifis...@gmail.com on 3 May 2012 at 12:44

Attachments:

• mem-b2b86b74-2753.jp2
• jp2-patch.txt

[GoogleCodeExporter]

Actually I'm not 100% certain about this change - here's another .jp2 with 
channel_size[i] of 1, which breaks as reading 1 byte of data per channel 
overruns the object. I haven't looked at the spec (is it available somewhere?) 
to work out what the correct behaviour should be.

Original comment by archifis...@gmail.com on 3 May 2012 at 2:18

Attachments:

• mem-b2ace68c-1381.jp2

[GoogleCodeExporter]

I have applied the patch to openjpeg-trunk-r1656.

'j2k_to_image' fails with SEGMENTATION fault for both images.

My viewer - using openjpeg-branch15-r1626 - shows:
 mem-b2b86b74-2753.jp2 : fuzzy 'Miami' text;prec(4), compno(1)
 mem-b2ace68c-1381.jp2 : a grey plane;prec(1), compno(4)

My simple JP2 reader shows:

 FILE(mem-b2ace68c-1381.jp2)
 LENG(1381)

 [1]BOX_NAME(ftyp) BOX_LEN(28)

   brand(jp2 ) minv(0)
   CL[0](jp2 )
   CL[1](jpxb)
   CL[2](jpx )

 FILE(mem-b2b86b74-2753.jp2)
 LENG(2753)

 [1]BOX_NAME(ftyp) BOX_LEN(28)

   brand(jp2 ) minv(0)
   CL[0](jp2 )
   CL[1](jpxb)
   CL[2](jpx )

winfried 

Original comment by szukw...@arcor.de on 4 May 2012 at 2:33

[GoogleCodeExporter]

j2k_to_image segfaults because it tries to call fprintf on a NULL FILE *. If I 
fix that (suggested patch attached), then for mem-b2b86b74-2753.jp2, I get:

[ERROR] In SOT marker, TPSot (5) is not valid regards to the current number of 
tile-part (5), giving up
[ERROR] Fail to read the current marker segment (0xff90)
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> j2k_to_image: failed to decode image!

Original comment by archifis...@gmail.com on 4 May 2012 at 6:29

Attachments:

• j2k_to_image.txt

[GoogleCodeExporter]

mem-b2ace68c-1381.jp2 has a bug in PCLR.

My simple JP2 reader shows:

[1]BOX_NAME(pclr) BOX_LEN(15)
   nr_entries(1) nr_channels(4)
----------- start pclr ----------------
   [0]signed(0) depth(1)
   [1]signed(0) depth(1)
   [2]signed(0) depth(1)
   [3]signed(0) depth(1)
---------------------------------------
   entry[000]0 0 0 24
----------- end pclr ------------------
read_jp2.c:553:EXIT read_pclr
    s(0x1e232d6) box_end(0x1e232d2) s - box_end(4)
[1]BOX_NAME() BOX_LEN(1668112752)
           ==         ==========
The contents of the pclr box is 4 bytes larger than
it should be:
size of boxhead: 8 BYTE
nr_entries.....: 2 BYTE
nr_channels....: 1 BYTE
prec[4]........: 4 BYTE
entries[1][4]..: 4 BYTE
--------------------------------
box_len 15 BYTE vs. contents 19 BYTE

Changing the reader such that read_pclr returns box_end:

[1]BOX_NAME(pclr) BOX_LEN(15)
   nr_entries(1) nr_channels(4)
----------- start pclr ----------------
   [0]signed(0) depth(1)
   [1]signed(0) depth(1)
   [2]signed(0) depth(1)
   [3]signed(0) depth(1)
---------------------------------------
   entry[000]0 0 0 24
----------- end pclr ------------------
read_jp2.c:553:EXIT read_pclr
    s(0xb802d6) box_end(0xb802d2) s - box_end(4)
//----- now return box_end: -----
[1]BOX_NAME(cmap) BOX_LEN(24)
----------- start cmap -------------------
[0]cmp(0) mtyp(1) pcol(0)
[1]cmp(0) mtyp(1) pcol(1)
[2]cmp(0) mtyp(1) pcol(2)
[3]cmp(0) mtyp(1) pcol(3)
--------- end cmap ---------------------

winfried

Original comment by szukw...@arcor.de on 6 May 2012 at 3:31

[GoogleCodeExporter]

Both input files have been added to svn/data. Thanks

Original comment by mathieu.malaterre on 21 May 2012 at 9:40

[GoogleCodeExporter]

See discussion at:

https://groups.google.com/group/openjpeg/msg/9cca539dc8250428

Original comment by mathieu.malaterre on 29 May 2012 at 1:50

[GoogleCodeExporter]

This issue was updated by revision r1696.

Original comment by mathieu.malaterre on 29 May 2012 at 1:54

[GoogleCodeExporter]

This issue was closed by revision r1697.

Original comment by mathieu.malaterre on 29 May 2012 at 1:55

• Changed state: Fixed