gdal_translate fails on GeoJP2 created by ERDAS Imagine

[mlepley@…]

GeoJP2 files exported from Imagine 8.7 when input into 
gdal_translate  crash with the following error message.
ERROR 2: CPLMalloc(): Out of memory allocating 1291845601

This happens for every GeoJP2 created by Imagine 8.7.
The same files are readable by the MSI GeoJP2 Viewer
http://www.lizardtech.com/download/dl_options.php?page=third 

The properties are similar to what gdal_translate -of JP2KAK
would create *except* for

Imagine JP2 property subset:
GTCitationGeoKey (Ascii,266): "IMAGINE GeoTIFF Support
Copyright 1991 - 2005 by Leica Geosystems Geospatial Imaging, LLC. All
Rights Reserved
@(#)$RCSfile: egtf.c $ IMAGINE 9.0 $Revision: 10.0 $ $Date: 2005/07/26
15:10:00 EST $
Projection Name = Geographic (Lat/Lon)
Units = dd
GeoTIFF Units = dd"
GeographicTypeGeoKey (Short,1): GCS_WGS_84

vs gdal_translate JP2 property subset:
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogCitationGeoKey (Ascii,7): "WGS 84"

The rest of the properties listed by MSI GeoJP2 viewer
are the same and appear in the same order. (I realize
MSI GeoJP2 viewer is old/defunct. But the info it
reports might be useful to you.)

Sample file causing the crash available via email.

Build info: 
GDAL 1.3.1.0, FWTools 1.0.0a6, released 2005/11/03  

[Alternatively, I'd be happy to file a bug report 
with Imagine if they are at fault.  But would need 
some evidence to show they are wrong.]

[warmerdam]

OK - waiting for a sample file to proceed.

There was a problem at one point with the long citations produced by
Erdas but I thought that got fixed.  Perhaps this is something different.

[warmerdam]

This was a bug in the GDALJP2Box code (ReadBox() method) that
only affected files using the "XLBox" field normally reserved
for boxes larger than 4GB.  It seems that Erdas was using it 
even for small boxes.  

I have committed a fix.   I will look into producing a new
FWTools build as soon as practical.

So, in summary, my bug, but Erdas is doing something peculiar.