fix (openjpeg): Change the malloc method to dlmalloc to fix memory issue

[emelalkim]

This change fixes the DX decompression problem that occurs in some j2k images with or without the latest changes in the openjpeg extern library and it has very minimal effect on the size of the distribution js files.

The current version of the codecs library cannot decompress some j2k DX images. See the issue for more information. Further investigation narrowed down the issue to malloc which is currently using emmalloc. While trying to allocate 595*4 bytes of memory with opj_aligned_malloc at this line in openjpeg library, it keeps increasing the size of the heap and crashes when it exceeds 2GB.

Changes:

• Changes the malloc method to dlmalloc
• Adds tests for problematic (memory crashing) DX images

Notes:

• I ran all the commented-out tests to make sure it didn't mess up anything.

• I also tested with my fork of openjpeg library (https://github.com/emelalkim/openjpeg) which is in sync with https://github.com/uclouvain/openjpeg.

• The sizes of the js files are affected minimally
  dist folder js sizes with emmalloc
  dist folder js sizes with dlmalloc

[emelalkim]

@wayfarer3130, @sedghi who would be a good person to review this?

[sedghi]

CC @chafey

[wayfarer3130]

Chris - any chance you could take a look? @chafey

[chafey]

A few comments:

1. I haven't done much with EMSCRIPTEN for years so am way out of date.
2. I don't recall making a choice between the different allocators so no concern about changing it.
3. Based on the documentation dmalloc seems like a better choice for potential speed reasons alone.
4. It doesn't seem like we understand the root cause of why emalloc had a problem. The EMSCRIPTEN docs doesn't mention anything about a limitation like this between the two. Suggest we open an issue with EMSCRIPTEN reporting this situation so they can investigate or update docs if this is a known limitation

[emelalkim]

A few comments:

1. I haven't done much with EMSCRIPTEN for years so am way out of date.
2. I don't recall making a choice between the different allocators so no concern about changing it.
3. Based on the documentation dmalloc seems like a better choice for potential speed reasons alone.
4. It doesn't seem like we understand the root cause of why emalloc had a problem. The EMSCRIPTEN docs doesn't mention anything about a limitation like this between the two. Suggest we open an issue with EMSCRIPTEN reporting this situation so they can investigate or update docs if this is a known limitation

Thank you @chafey, Happy to open an issue to report it. Would this repository be the correct place to open the issue?

[chafey]

Yes I think so

[emelalkim]

@chafey I created the issue. Let me know if you this it needs improvement.
I changed the order of the tests so that failure can be tested if built with emmalloc
Does anyone have a problem merging the PR?

[chafey]

@emelalkim issue looks good, thanks for that. Ill add some comments. BTW - impressive debugging work, this stuff is really complicated!

[emelalkim]

@emelalkim issue looks good, thanks for that. Ill add some comments. BTW - impressive debugging work, this stuff is really complicated!

Thank you @chafey. It was hard indeed! I must confess I needed to call reinforcements :) I got help from my brother @erdemalkim who is the actual c developer in the family