[sldev] OpenJPEG MAX_PATH issue

[Phoenix]

Good catch. We had also experienced 'crashiness' on linux when using  
openjpeg but did not spend a lot of time looking for the root cause.  
I also believe that a patch to openjpeg with a better named max path  
is the right way to go.

:)

On 2007 Jan 20, at 14:43, David Fries wrote:
> Give it a read through and let me know what you think?
>
> Summary: MAX_PATH or PATH_MAX, and how to make everything see the same
> size?  My suggestion?  See if OpenJPEG can just do,
> #define OPJ_PATH_LEN 4096
> and use that in their data structures.  (patch attached against
> openjpeg_v1_1.tar.gz)
>
> I was having a problem that was causing the open source version of the
> Second Life viewer to crash with the OpenJPEG library.  I tracked it
> down to openjpeg.h and the opj_cparameters structure.  There are three
> character arrays in that data structure that are of size MAX_PATH.
> openjpeg.h contains a check to define MAX_PATH to 260 if it isn't
> defined.  When I compiled OpenJPEG it wasn't defined.  Second Life on
> the other hand defines it, to some other size, so that
> LLImageJ2COJ::encodeImpl creates a structure that is bigger in size
> and passes a pointer for OpenJPEG to initialize.  OpenJPEG's library
> has a different and smaller layout for the data variables in that
> structure.  Thus encodeImpl reads garbage when it goes to process what
> OpenJPEG initialized and crashes.
>
> I started looking through the header files on my system to see what
> has PATH_MAX listed in it, no standard system libraries define it or
> use it.  Here are the results.
>
> /usr/include/boost/regex/v4/fileiter.hpp
> 	boost regular expression library, defines MAX_PATH to 256 if
> 	it isn't already defined.
> /usr/include/lcms.h
> 	Color management library, defines MAX_PATH to 256 without even
> 	checking to see if it was previously defined.
> /usr/include/X11/Xos.h
> 	X11 core library, doesn't even check just
> 	#define MAX_PATH _POSIX_PATH_MAX
> 	(and then doesn't even use it).
>
> On the other hand there are 20 files that use PATH_MAX and it is
> mentioned in various man pages.
>
> /usr/include/limits.h is the place to pick up PATH_MAX
> /usr/include/linux/limits.h (which shouldn't be included directly)
> #define PATH_MAX        4096	/* # chars in a path name including  
> nul */
>
> Then there is one that will change the size of PATH_MAX on windows.
> /usr/include/X11/Xwindows.h
> #if defined(WIN32) && (!defined(PATH_MAX) || PATH_MAX < 1024)
> #undef PATH_MAX
> #define PATH_MAX 1024
> #endif
>
> Looking around there are a few different sizes for PATH_MAX
> /usr/include/linux/limits.h:#define PATH_MAX        4096
> /usr/include/X11/Xwindows.h:#define PATH_MAX 1024
> /usr/include/X11/InitialI.h:#define PATH_MAX 512
>
> I think this is telling,
>
> /usr/include/postgresql/pg_config_manual.h
> /*
>  * MAXPGPATH: standard size of a pathname buffer in PostgreSQL (hence,
>  * maximum usable pathname length is one less).
>  *
>  * We'd use a standard system header symbol for this, if there weren't
>  * so many to choose from: MAXPATHLEN, MAX_PATH, PATH_MAX are all
>  * defined by different "standards", and often have different values
>  * on the same platform!  So we just punt and use a reasonably
>  * generous setting here.
>  */
> #define MAXPGPATH               1024
>
> -- 
> David Fries <david at fries.net>
> http://fries.net/~david/ (PGP encryption key available)
> <openjpeg_OPJ_PATH_LEN.patch>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070123/cab54f5c/PGP.pgp