'long' should be avoided for cross platform code. On Windows, sizeof(long) is 
always 4, on most other platforms it's 4 or 8 depending on the architecture.

-Stefan

On 09.09.2013, at 13:56, Larry Gritz <[email protected]> wrote:

> Ah, ok, great.  I think it's still probably worth an audit of the OIIO-side 
> code to make sure there aren't any similar mistakes lurking.  Sorry, other 
> than short replies to your emails, I haven't had a chance to do this yet -- 
> it's shaping up to be a bit of a busy day for me for very unrelated reasons.
> 
> BTW, I don't think you can guarantee that 'long' is big enough on all 
> platforms.  I would use size_t (which will be 64 bit on 64 bit systems), or 
> OIIO::imagesize_t (which will be 64 bit everywhere).
> 
>       -- lg
> 
> 
> On Sep 9, 2013, at 11:56 AM, Ramiro Pereira de Magalhães wrote:
> 
>> Okay, I just found out what's wrong, and the mistake was mine.
>> 
>> The variable size should be of type long instead of int, like that:
>> 
>>     const long size = (long)spec.width * spec.height;
>> 
>> Since it wasn't, the unsigned char buffer was too small for the whole image. 
>> I have just tested this again and the program runs pretty well now...
>> 
>> I'm really sorry for troubling you and taking your time with that silly 
>> mistake. On the bright side, we've got some aditional data about OIIO 
>> robustness.
>> 
>> 
>> 2013/9/9 Larry Gritz <[email protected]>
>> Neat.  No, there's nothing wrong with wanting to do this; it's just odd for 
>> this format to be used for big images, so the 64 bit safety has probably not 
>> been adequately exercised.
>> 
>> 
>> On Sep 9, 2013, at 11:46 AM, Ramiro Pereira de Magalhães wrote:
>> 
>>> Although weird, this is desirable.
>>> 
>>> This image will be used as a database of 20x20 clutter objects that will be 
>>> used to train a face classifier I'm working on. This was probably the 
>>> simplest arrangement of pixels devised for this purpose.
>>> 
>>> 
>>> 2013/9/9 Larry Gritz <[email protected]>
>>> Does that look correct?  It's not just big overall, but very long and thin?
>>> 
>>> OK, I'll take a quick skim over that code and see if I can spot where the 
>>> overflow is happening.
>>> 
>>> 
>>> 
>>> On Sep 9, 2013, at 11:33 AM, Ramiro Pereira de Magalhães wrote:
>>> 
>>>> /home/ramiro/Imagens/0.pgm : 536468780 x   20, 1 channel, uint8 pnm
>>>>     channel list: I
>>>>     pnm:binary: 1
>>>>     oiio:BitsPerSample: 8
>>>> 
>>>> 
>>>> 
>>>> 2013/9/9 Larry Gritz <[email protected]>
>>>> If you do this:
>>>> 
>>>> iinfo -v myfile.pgm        # or whatever the name of your file actually is
>>>> 
>>>> what does it say?
>>>> 
>>>> 
>>>> On Sep 9, 2013, at 8:16 AM, Ramiro Pereira de Magalhães wrote:
>>>> 
>>>> > Hi,
>>>> >
>>>> > I have just learned about OIIO and I wrote a simple program with 
>>>> > OpenImageIO to load a 10GB PGM file into memory. To try things out I 
>>>> > wrote a simple program to load a 10GB PGM (yeah, PGM) file into memory. 
>>>> > Sadly, the program crashes prior to completing its task with a 
>>>> > Segmentation Fault. The machine where this is running has 64GB RAM, most 
>>>> > of it free. Can anyone help me figure out this issue?
>>>> >
>>>> > Bellow is the program I wrote. It is pretty simple: load the image given 
>>>> > as argument to it into a buffer, then close the file, clean the buffers 
>>>> > and leave.
>>>> >
>>>> > ================CODE================
>>>> > #include <iostream>
>>>> > #include <string>
>>>> > #include <sstream>
>>>> > #include <OpenImageIO/imageio.h>
>>>> >
>>>> > OIIO_NAMESPACE_USING
>>>> >
>>>> > int main(int argc, char* args[])
>>>> > {
>>>> >     if (argc != 2)
>>>> >     {
>>>> >         return 1;
>>>> >     }
>>>> >     const std::string filePath = args[1];
>>>> >
>>>> >     ImageInput *in = ImageInput::open (filePath);
>>>> >     const ImageSpec & spec = in->spec();
>>>> >     const int size = spec.width * spec.height;
>>>> >
>>>> >     unsigned char * pixels = new unsigned char[size];
>>>> >     in->read_image(TypeDesc::UCHAR, pixels);
>>>> >     std::cout << "Done reading." << std::endl;
>>>> >     in->close();
>>>> >     std::cout << "Closed file." << std::endl;
>>>> >
>>>> >     delete in;
>>>> >     delete pixels;
>>>> >
>>>> >     std::cout << "Outta here." << std::endl;
>>>> >     return 0;
>>>> > }
>>>> > ================CODE================
>>>> >
>>>> >
>>>> > Segfault happens at line 173 of onminput.cpp. Here is the call stack 
>>>> > given by Qt Builder:
>>>> >
>>>> > 0    OpenImageIO::v1_3::raw_to_raw<unsigned char>    pnminput.cpp    173 
>>>> >    0x7ffff798c1e6
>>>> > 1    OpenImageIO::v1_3::PNMInput::read_file_scanline    pnminput.cpp    
>>>> > 272    0x7ffff798b09c
>>>> > 2    OpenImageIO::v1_3::PNMInput::read_native_scanline    pnminput.cpp   
>>>> >  385    0x7ffff798b91e
>>>> > 3    OpenImageIO::v1_3::ImageInput::read_native_scanlines    
>>>> > imageinput.cpp    260    0x7ffff76d9280
>>>> > 4    OpenImageIO::v1_3::ImageInput::read_scanlines    imageinput.cpp    
>>>> > 197    0x7ffff76d8c24
>>>> > 5    OpenImageIO::v1_3::ImageInput::read_scanlines    imageinput.cpp    
>>>> > 165    0x7ffff76d8977
>>>> > 6    OpenImageIO::v1_3::ImageInput::read_image    imageinput.cpp    631  
>>>> >   0x7ffff76db3c8
>>>> > 7    main    show.cpp    31    0x4012b7
>>>> >
>>>> >
>>>> > I compiled OIIO from the git commit 
>>>> > d64b9ac8a63261040ae0263b0709924d8fecf4df (Tue Sep 3 12:53:12 2013 -0700).
>>>> >
>>>> > I appreciate any help.
>>>> > _______________________________________________
>>>> > Oiio-dev mailing list
>>>> > [email protected]
>>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> 
>>>> --
>>>> Larry Gritz
>>>> [email protected]
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> 
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> 
>>> --
>>> Larry Gritz
>>> [email protected]
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> 
>>> 
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> --
>> Larry Gritz
>> [email protected]
>> 
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> --
> Larry Gritz
> [email protected]
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to