Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OpenJPEG 1.5.0 crashes on a ridiculously big file... #151

Closed
GoogleCodeExporter opened this issue Jul 18, 2015 · 7 comments
Closed

OpenJPEG 1.5.0 crashes on a ridiculously big file... #151

GoogleCodeExporter opened this issue Jul 18, 2015 · 7 comments
Labels
auto-migrated Milestone-Release2.1 Priority-High Type-Defect

Comments

@GoogleCodeExporter
Copy link 

What steps will reproduce the problem?
1. Download and unpack 
ftp://ftp.microimages.com/pub/tnt/data/jp2/gtopo30lossless.zip (378MiByte) from 
http://www.microimages.com/gallery/jp2/
2. Execute gdb --args j2k_to_image -i g30mosLossless.jp2 -o test.raw
3. Run the tool inside gdb and obtain a backtrace

What is the expected output? What do you see instead?
I expect a decoded image and the relevant output from the tool.
Instead I see this and a segmentation fault:

[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (0) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (1) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (2) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (3) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (4) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (5) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (6) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (7) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (8) than 
number of tile-parts (0)
[INFO] tile 1 of 1

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bcc076 in t1_decode_cblks (t1=0x8816180, tilec=0x612b80, 
tccp=0x612320) at /home/usr/src/openjpeg-1.5.0/libopenjpeg/t1.c:1560
1560                                                                    
((int*)tiledp)[(j * tile_w) + i] = tmp / 2;
(gdb) bt
#0  0x00007ffff7bcc076 in t1_decode_cblks (t1=0x8816180, tilec=0x612b80, 
tccp=0x612320) at /home/usr/src/openjpeg-1.5.0/libopenjpeg/t1.c:1560
#1  0x00007ffff7bd3b66 in tcd_decode_tile (tcd=<optimized out>, 
    src=0x7fffb9b9a010 "\303\371fp\357\230sV\323\353j\004VV\312\337O\207U\331&\363\177k\220\267\a\376V\032\240\311f\an\031j\221\267\246\027\070#+\323`\313È\237\253\241\344]q\240ԟ\230\374j\264\347zJQ\326n7\034^*\336\306\323q\346\307w\371)\322dȗܜ\207\216诜\303\344\212\002\377!W\257\254\246\250\017\304\300", len=395528744, tileno=0, cstr_info=<optimized out>) at /home/usr/src/openjpeg-1.5.0/libopenjpeg/tcd.c:1383
#2  0x00007ffff7bc22b7 in j2k_read_eoc (j2k=0x60f0c0) at 
/home/usr/src/openjpeg-1.5.0/libopenjpeg/j2k.c:1566
#3  0x00007ffff7bc34d9 in j2k_decode (j2k=0x60f0c0, cio=0x6107d0, 
cstr_info=<optimized out>)
    at /home/usr/src/openjpeg-1.5.0/libopenjpeg/j2k.c:1877
#4  0x00007ffff7bc5c70 in opj_jp2_decode (jp2=0x60f050, cio=0x6107d0, 
cstr_info=<optimized out>)
    at /home/usr/src/openjpeg-1.5.0/libopenjpeg/jp2.c:749
#5  0x000000000040231b in main (argc=<optimized out>, argv=<optimized out>)
    at /home/usr/src/openjpeg-1.5.0/applications/codec/j2k_to_image.c:717

What version of the product are you using? On what operating system?
OpenJPEG-1.5.0 on Debian.

Please provide any additional information below.
Running the same command in valgrind gives these printouts:

==23383== Warning: silly arg (-2812252756) to malloc()
==23383== Invalid write of size 4
==23383==    at 0x4E42076: t1_decode_cblks (t1.c:1560)
==23383==    by 0x4E49B65: tcd_decode_tile (tcd.c:1383)
==23383==    by 0x4E382B6: j2k_read_eoc (j2k.c:1566)
==23383==    by 0x4E394D8: j2k_decode (j2k.c:1877)
==23383==    by 0x4E3BC6F: opj_jp2_decode (jp2.c:749)
==23383==    by 0x40231A: main (j2k_to_image.c:717)
==23383==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23383== 
==23383== 
==23383== Process terminating with default action of signal 11 (SIGSEGV)
==23383==  Access not within mapped region at address 0x0
==23383==    at 0x4E42076: t1_decode_cblks (t1.c:1560)
==23383==    by 0x4E49B65: tcd_decode_tile (tcd.c:1383)
==23383==    by 0x4E382B6: j2k_read_eoc (j2k.c:1566)
==23383==    by 0x4E394D8: j2k_decode (j2k.c:1877)
==23383==    by 0x4E3BC6F: opj_jp2_decode (jp2.c:749)
==23383==    by 0x40231A: main (j2k_to_image.c:717)

Original issue reported on code.google.com by seb...@gmail.com on 16 Jun 2012 at 2:05
@GoogleCodeExporter
Copy link
Author 

The image 'g30mosLossless.jp2' has a precision of 14.

Does libopenjpeg automatically extend to 16 bit?

Using openjpeg-branch-r1656, I get:

[INFO] tile 1 of 1
Segmentation fault

Using openjpeg-branch15-r1718, I get:

[INFO] tile 1 of 1
[ERROR] Out of memory
[ERROR] Failed to decode J2K image
ERROR -> j2k_to_image: failed to decode image!

winfried

Original comment by szukw...@arcor.de on 18 Jun 2012 at 10:30

@GoogleCodeExporter
Copy link
Author 

D'oh! I should of course have tried svn HEAD. And on your recommendation I did, 
but r1718 built from scratch still segfaults for me:

gdb --args bin/j2k_to_image -i g30mosLossless.jp2  -o test.ppm
(gdb) r
[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 0 / 0 has been read.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bb8290 in t1_decode_cblks_v2 (t1=0x61d760, tilec=0x61aec0, 
    tccp=0x61ca00) at t1.c:1834
1834 ((OPJ_INT32*)tiledp)[(j * tile_w) + i] = tmp / 2;
(gdb) p tiledp
$1 = (void *) 0x7fffe5b41eb0
(gdb) p j
$2 = 60
(gdb) p tile_w
$3 = 166392
(gdb) p i
$4 = 0
(gdb) bt
#0  0x00007ffff7bb8290 in t1_decode_cblks_v2 (t1=0x61d760, tilec=0x61aec0, 
    tccp=0x61ca00) at t1.c:1834
#1  0x00007ffff7bcae05 in tcd_t1_decode (p_tcd=0x61ae50) at tcd.c:2933
#2  0x00007ffff7bca684 in tcd_decode_tile_v2 (p_tcd=0x61ae50, 
    p_src=0x7fffd0783010 "\303\371fp\357\230sV\323\353j\004VV\312\337O\207U\331&\363\177k\220\267\a\376V\032\240\311f\an\031j\221\267\246\027\070#+\323`\313È\237\253\241\344]q\240ԟ\230\374j\264\347zJQ\326n7\034^*\336\306\323q\346\307w\371)\322dȗܜ\207\216诜\303\344\212\002\377!W\257\254\246\250\017\304\300", 
    p_max_length=395528744, p_tile_no=0, p_cstr_index=0x619f80) at tcd.c:2650
#3  0x00007ffff7b9a765 in j2k_decode_tile (p_j2k=0x618420, p_tile_index=0, 
    p_data=0x7ffecbe78010 "", p_data_size=2888840912, p_stream=0x618250, 
    p_manager=0x618328) at j2k.c:10047
#4  0x00007ffff7b9e6a1 in j2k_decode_tiles (p_j2k=0x618420, p_stream=0x618250, 
    p_manager=0x618328) at j2k.c:11670
#5  0x00007ffff7b99006 in j2k_exec (p_j2k=0x618420, p_procedure_list=0x61a9b0, 
    p_stream=0x618250, p_manager=0x618328) at j2k.c:9406
#6  0x00007ffff7b9eca1 in j2k_decode_v2 (p_j2k=0x618420, p_stream=0x618250, 
    p_image=0x61af00, p_manager=0x618328) at j2k.c:11856
#7  0x00007ffff7ba3c33 in jp2_decode_v2 (jp2=0x618380, cio=0x618250, 
    p_image=0x61af00, p_manager=0x618328) at jp2.c:1777
#8  0x00007ffff7baab28 in opj_decode_v2 (p_codec=0x6182d0, p_stream=0x618250, 
    p_image=0x61af00) at openjpeg.c:1214
#9  0x0000000000413ba4 in main (argc=5, argv=0x7fffffffe1e8)
    at j2k_to_image.c:821
(gdb)

I also convinced myself that j2k_to_image included the correct libopenjpeg.so, 
since I already have one installed on my system. Oh and as you probably can 
tell from above I'm on a 64-bit system (which ought to be able to handle the 
7GByte raw image that will be generated by this ridiculously big image...).

Original comment by seb...@gmail.com on 18 Jun 2012 at 10:41

@GoogleCodeExporter
Copy link
Author 

Re-running valgrind confirms my problems:

valgrind ./bin/j2k_to_image -i ~g30mosLossless.jp2  -o test.ppm

==15719== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
[...]
[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[...]
[INFO] Header of tile 0 / 0 has been read.
==15719== Warning: set address range perms: large range [0x2563a4428, 
0x3026a7710) (undefined)
==15719== Invalid write of size 4
==15719==    at 0x4E70290: t1_decode_cblks_v2 (t1.c:1834)
==15719==    by 0x4E82E04: tcd_t1_decode (tcd.c:2933)
==15719==    by 0x4E82683: tcd_decode_tile_v2 (tcd.c:2650)
==15719==    by 0x4E52764: j2k_decode_tile (j2k.c:10047)
==15719==    by 0x4E566A0: j2k_decode_tiles (j2k.c:11670)
==15719==    by 0x4E51005: j2k_exec (j2k.c:9406)
==15719==    by 0x4E56CA0: j2k_decode_v2 (j2k.c:11856)
==15719==    by 0x4E5BC32: jp2_decode_v2 (jp2.c:1777)
==15719==    by 0x4E62B27: opj_decode_v2 (openjpeg.c:1214)
==15719==    by 0x413BA3: main (j2k_to_image.c:821)
==15719==  Address 0x91efa120 is not stack'd, malloc'd or (recently) free'd

Original comment by seb...@gmail.com on 18 Jun 2012 at 10:56

@GoogleCodeExporter
Copy link
Author 

Using openjpeg-trunk-r1718 and valgrind-3.8.0.SVN, I get:

==14831== Invalid write of size 4
==14831==    at 0x4E6E8CB: t1_decode_cblks_v2 (t1.c:1834)
==14831==    by 0x4E816B0: tcd_t1_decode (tcd.c:2937)
==14831==    by 0x4E80EE4: tcd_decode_tile_v2 (tcd.c:2653)
==14831==    by 0x4E50B32: j2k_decode_tile (j2k.c:10047)
==14831==    by 0x4E54A40: j2k_decode_tiles (j2k.c:11670)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)
==14831==    by 0x413E0F: main (j2k_to_image.c:821)
==14831==  Address 0x920390a0 is 16 bytes before a block of size 64 alloc'd
==14831==    at 0x4C28271: malloc (vg_replace_malloc.c:263)
==14831==    by 0x4E804EA: tcd_init_decode_tile (in 
/usr/local/lib64/libopenjpeg.so.1.99.0)
==14831==    by 0x4E508AE: j2k_read_tile_header (j2k.c:9997)
==14831==    by 0x4E549A0: j2k_decode_tiles (j2k.c:11643)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)
==14831==    by 0x413E0F: main (j2k_to_image.c:821)
==14831==
==14831== Conditional jump or move depends on uninitialised value(s)
==14831==    at 0x4E6EB19: t1_decode_cblk_v2 (t1.c:1891)
==14831==    by 0x4E6E652: t1_decode_cblks_v2 (t1.c:1793)
==14831==    by 0x4E816B0: tcd_t1_decode (tcd.c:2937)
==14831==    by 0x4E80EE4: tcd_decode_tile_v2 (tcd.c:2653)
==14831==    by 0x4E50B32: j2k_decode_tile (j2k.c:10047)
==14831==    by 0x4E54A40: j2k_decode_tiles (j2k.c:11670)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)
==14831==    by 0x413E0F: main (j2k_to_image.c:821)
==14831==
==14831== Invalid write of size 4
==14831==    at 0x4C2AC6C: memset (mc_replace_strmem.c:966)
==14831==    by 0x4E6CF21: allocate_buffers (t1.c:1239)
==14831==    by 0x4E6EA37: t1_decode_cblk_v2 (t1.c:1869)
==14831==    by 0x4E6E652: t1_decode_cblks_v2 (t1.c:1793)
==14831==    by 0x4E816B0: tcd_t1_decode (tcd.c:2937)
==14831==    by 0x4E80EE4: tcd_decode_tile_v2 (tcd.c:2653)
==14831==    by 0x4E50B32: j2k_decode_tile (j2k.c:10047)
==14831==    by 0x4E54A40: j2k_decode_tiles (j2k.c:11670)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)
==14831==  Address 0x3033b5ab0 is 0 bytes after a block of size 16,384 alloc'd
==14831==    at 0x4C28271: malloc (vg_replace_malloc.c:263)
==14831==    by 0x4E6CED3: allocate_buffers (t1.c:1233)
==14831==    by 0x4E6EA37: t1_decode_cblk_v2 (t1.c:1869)
==14831==    by 0x4E6E652: t1_decode_cblks_v2 (t1.c:1793)
==14831==    by 0x4E816B0: tcd_t1_decode (tcd.c:2937)
==14831==    by 0x4E80EE4: tcd_decode_tile_v2 (tcd.c:2653)
==14831==    by 0x4E50B32: j2k_decode_tile (j2k.c:10047)
==14831==    by 0x4E54A40: j2k_decode_tiles (j2k.c:11670)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)
==14831==
==14831==
==14831== Process terminating with default action of signal 11 (SIGSEGV)
==14831==  Access not within mapped region at address 0x30355D000
==14831==    at 0x4C2AC6C: memset (mc_replace_strmem.c:966)
==14831==    by 0x4E6CF21: allocate_buffers (t1.c:1239)
==14831==    by 0x4E6EA37: t1_decode_cblk_v2 (t1.c:1869)
==14831==    by 0x4E6E652: t1_decode_cblks_v2 (t1.c:1793)
==14831==    by 0x4E816B0: tcd_t1_decode (tcd.c:2937)
==14831==    by 0x4E80EE4: tcd_decode_tile_v2 (tcd.c:2653)
==14831==    by 0x4E50B32: j2k_decode_tile (j2k.c:10047)
==14831==    by 0x4E54A40: j2k_decode_tiles (j2k.c:11670)
==14831==    by 0x4E4F4C4: j2k_exec (j2k.c:9406)
==14831==    by 0x4E55046: j2k_decode_v2 (j2k.c:11856)
==14831==    by 0x4E5A007: jp2_decode_v2 (jp2.c:1777)
==14831==    by 0x4E60F99: opj_decode_v2 (openjpeg.c:1214)

This test runs on Linux 3.3.6 x86_64 AMD with:
free -m

             total       used       free     shared    buffers     cached
Mem:         15966       1053      14913          0         66        737
-/+ buffers/cache:        248      15717
Swap:        32767          0      32767


winfried

Original comment by szukw...@arcor.de on 19 Jun 2012 at 8:37

@GoogleCodeExporter
Copy link
Author 

As seen on opj 1.5 branch:


==29174== Warning: set address range perms: large range [0x5a34040, 0x1d397866) 
(undefined)
==29174== Warning: set address range perms: large range [0x5a34040, 0x1d397040) 
(defined)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (0) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (1) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (2) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (3) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (4) than 
number of tile-parts (0)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (5) than 
number of tile-parts (0)
==29174== Warning: set address range perms: large range [0x1df74030, 
0x301f2863) (noaccess)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (6) than 
number of tile-parts (0)
==29174== Warning: set address range perms: large range [0x3959d030, 
0x4ce0fd34) (noaccess)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (7) than 
number of tile-parts (0)
==29174== Warning: set address range perms: large range [0x1df74030, 
0x33103f93) (noaccess)
[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (8) than 
number of tile-parts (0)
==29174== Warning: set address range perms: large range [0x3959d030, 
0x4f243927) (noaccess)
==29174== Warning: set address range perms: large range [0x1df74030, 
0x33dc3e5a) (noaccess)
[INFO] tile 1 of 1
==29174== Warning: silly arg (-2812252756) to malloc()
==29174== Invalid write of size 4
==29174==    at 0x4E400B2: t1_decode_cblks (t1.c:1560)
==29174==    by 0x4E44605: tcd_decode_tile (tcd.c:1383)
==29174==    by 0x4E36856: j2k_read_eoc (j2k.c:1566)
==29174==    by 0x4E37E2D: j2k_decode (j2k.c:1877)
==29174==    by 0x4E3A91C: opj_jp2_decode (jp2.c:749)
==29174==    by 0x402F0A: main (j2k_to_image.c:717)
==29174==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29174== 
==29174== 
==29174== Process terminating with default action of signal 11 (SIGSEGV)
==29174==  Access not within mapped region at address 0x0
==29174==    at 0x4E400B2: t1_decode_cblks (t1.c:1560)
==29174==    by 0x4E44605: tcd_decode_tile (tcd.c:1383)
==29174==    by 0x4E36856: j2k_read_eoc (j2k.c:1566)
==29174==    by 0x4E37E2D: j2k_decode (j2k.c:1877)
==29174==    by 0x4E3A91C: opj_jp2_decode (jp2.c:749)
==29174==    by 0x402F0A: main (j2k_to_image.c:717)
==29174==  If you believe this happened as a result of a stack
==29174==  overflow in your program's main thread (unlikely but
==29174==  possible), you can try to increase the size of the
==29174==  main thread stack using the --main-stacksize= flag.
==29174==  The main thread stack size used in this run was 8388608.
==29174== 
==29174== HEAP SUMMARY:
==29174==     in use at exit: 1,334,321,399 bytes in 2,661,256 blocks
==29174==   total heap usage: 2,792,096 allocs, 130,840 frees, 3,637,511,598 
bytes allocated
==29174== 
==29174== LEAK SUMMARY:
==29174==    definitely lost: 0 bytes in 0 blocks
==29174==    indirectly lost: 0 bytes in 0 blocks
==29174==      possibly lost: 0 bytes in 0 blocks
==29174==    still reachable: 1,334,321,399 bytes in 2,661,256 blocks
==29174==         suppressed: 0 bytes in 0 blocks
==29174== Rerun with --leak-check=full to see details of leaked memory
==29174== 
==29174== For counts of detected and suppressed errors, rerun with: -v
==29174== Use --track-origins=yes to see where uninitialised values come from
==29174== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2)
[2]    29174 segmentation fault  valgrind j2k_to_image -i  -o test.raw

Original comment by mathieu.malaterre on 11 Jul 2012 at 3:21

@GoogleCodeExporter
Copy link
Author

Original comment by mathieu.malaterre on 25 Feb 2014 at 4:09

  • Added labels: Milestone-Release2.1, Priority-High
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author 

Same issue, single (large) tile image:

$ kdu_jp2info -i g30mosLossless.jp2

<JP2_family_file>
  <ftyp name="file-type box" header="8" body="12" pos="12">
    <brand> "jp2_" 0x6A703220 </brand>
    <minor_version> 0 </minor_version>
    <compatible_brand> "jp2_" 0x6A703220 </compatible_brand>
  </ftyp>
  <jp2h name="JP2-header box" header="8" body="37" pos="32">
    <ihdr name="image-header box" header="8" body="14" pos="40"></ihdr>
    <colr name="colour box" header="8" body="7" pos="62"></colr>
  </jp2h>
  <jp2c name="contiguous-codestream box" header="8" body="rubber" pos="77">
    <codestream>
      <width> 166392 </width>
      <height> 21587 </height>
      <components> 1 </components>
      <tiles> 1 </tiles>
    </codestream>
  </jp2c>
</JP2_family_file>

Original comment by mathieu.malaterre on 27 Feb 2014 at 1:32

  • Changed state: Duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Milestone-Release2.1 Priority-High Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter