Hi Pezhman,

Yes, indeed, that was the problem. Unfortunately, for my application the limit for _setmaxstdio, which is 2048, is still rather small, so I'll have to manage these pointers in a more dynamic fashion. Thank you for the quick response!

:) Michael

On Mon, Dec 20, 2010 at 12:09 PM, Pezhman Firoozfam <pezhman.firoozfam@usc.edu> wrote:
Hi Ian and Michael,

This page answers your problem: http://msdn.microsoft.com/en-us/library/kdfaxaay%28vs.71%29.aspx

The C run-time libraries have a 512 limit for the number of files that can be open at any one time (at least on Windows machines). Use _setmaxstdio to change this number.

Pezhman Firoozfam, Ph.D.

On Mon, Dec 20, 2010 at 8:59 AM, Ian Scott <scottim@imorphics.com> wrote:

It sounds like a memory leak. If it happens with only one type of image
format, then either the VXL image format wrapper code or the third party
library would be the place to look. In any case, there isn't much
non-format specific code in vil_load.cxx that could cause this bug. I
think I have loaded large DICOM volumes into vil3d where the
vil3d_slice_loader keeps a vector of live vil_image_resource_sptrs in
the process. Though I couldn't say for certain that I've use the loader
with more than 500 slices.

I don't mind looking into this problem, but it will have to wait until
the new year. If you want to try it, then debug your way into the
vil_load_image_resource on the 510 iteration. The only tricky bit is
patiently debugging though the loop in vil_load_image_resource_raw, as
it tries all the possible image formats.

Other approaches include using valgrind on a linux box. We used to have
a regular valgrind dashboard build. I really ought to get that set up again.


20/12/2010 15:59, Michael Repucci wrote:
> I'm having a strange problem with the vil_load_image_resource function.
> If I try to load a lot of image resources, the function returns
> successfully only the first 509 times. On the 510th time, nullptr is
> returned. This simple example recreates my problem:
> const char* name = "c:\\path\\to\\myfile.whatever";
> vil_image_resource_sptr pResource[510];
> for (unsigned int i = 0; i < 510; ++i) {
>     pResource[i] = vil_load_image_resource(name);
>     if (pResource[i] == nullptr) {
>        vcl_cout << "Could not load " << name << " on attempt " << i <<
> vcl_endl;
>        return 1;
>     }
> }
> I have the same problem even with 510 different files. I've built 32-bit
> binaries from VXL r30525 on Windows XP 64-bit with Visual Studio 2010.
> With just 509 calls, everything works as expected. Has anyone seen this
> before? Does someone with knowledge of the internals of VXL have any
> idea why this might be happening, or where I might look for the bug?
> Thanks for the help!
> :) Michael

Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
Vxl-users mailing list