Stack overflow - second version. 1

[gummibaer]

Well, following up on the yorelchr's recent thread on stack overflow, here is my version, that I would like to have solved better than I have now.

The following codelines are part of a longer program that I tried to boil down on the essentials:

   type metatile
.
.
      integer*1, dimension (:), pointer :: pTexPixels	! pointer to array of pixels for texture
.
.
      type (metatile), pointer :: pNext
      type (metatile), pointer :: pLast
   end type metatile
.
   type (metatile), pointer :: ppMetaTileHead, ppMetaTileTemp, ppMetaTileTail
.
.
   (allocating memory for ppMetaTileTail )
.
.
   iByteNumber = 3 * iiTexWidth * iiTexHeight
!      typically value of iiTexWidth and iiTexHeight are 1024 or 2048 each.
   allocate (ppMTilesTail.pTexPixels (iByteNumber), stat = irslt)
   if (irslt .ne. 0) then
   (errormessage)
   endif
.
.
   open (unit = IO_BMP, file = cFile, form ='BINARY', status = 'OLD', iostat = irslt)
.
.
!   (Version 1)
!   if (irslt .eq. 0) read (IO_BMP, iostat = irslt) (ppMTilesTail.pTexPixels (j), j = 1, iByteNumber)
					
!   (Version 2)
  if (irslt .eq. 0) read (IO_BMP, iostat = irslt) ppMTilesTail.pTexPixels
.
.					
   if (irslt .ne. 0) then
   (errormessage)

If I use the read statement version 1 everything is fine - except that the read takes some time - whereas version 2 gives me a stack overflow error.

This routine is my data input routine and is executed only once per program run. However, as the data are saved in a linked list, this part of the prog is executed as often as tiles are available. I simply hate to increase memory allocation, as there might be bigger files to read in the future and then my prog would fail again.

So what to do ?

Norbert


The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[xwb]

This is very compiler dependent. Version 2 will work on some compilers but not on others. To be safe, use Version 1.

Version 2 will only work on all compilers if ppMTilesTail.pTexPixels is not dynamically allocated. An implicit loop is generated by the compiler. If the variable is dynamically allocated, then the array limit may be set to some arbitrary number which may be more than the size of the allocated array: hence the stack overflow.

To answer the question: use Version 1.

 

[gummibaer]

Thanks xwb. I did figure out something like this, but from a recent thread I got the impression that stack overflow just would not occur in read statements and that I may stand a chance to speed up my input routine.

ppMTilesTail.pTexPixels is dynamically allocated, for the filesize that is read is what the user has available.

So I got to stick with version 1.

Norbert

The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[FJacq]

I don't know what is your Fortran compiler but, from my point of view, your two read statements are strickly equivalent is your allocatable array ppMTilesTail.pTexPixels has been allocated at the size iByteNumber.

I even suppose that most of compilers will translate the second version into the first one automatically. So do not expect any improvement.

If you get an error with the second form, then I suspect a bug in the compiler.

Normally a "stack overflow" message is not associated to a READ statement.

François Jacq

 

[gummibaer]

I am using the Compaq-compiler (which now merged with the Intel compiler, I think). And the two versions of the read statement are not the same. Yes, they have the same effect as the array is in memory after the statement is executed, but there must be some difference.

In fixed size arrays, version 2 completes much faster than version 1. May be something about index evaluation only, but still, version 1 with the implied loop takes let us say ten times longer than version 2.

And with dynamically dimensioned arrays version 1 works but version 2 produces a stack overflow.

But I take it, that version 1 is the best I can do and I just have present a status bar or anything to indicate to the user that he has to wait until input is completed. Increasing the size of the stack is absloutely no option for me as this might blow in the users face, once his file increase in size.

Thanks for your support.

Norbert


The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[xwb]

Just as a matter of interest, which version of the compiler are you using? Is it version 6 or one of the later Intel versions?

 

[gummibaer]

My compiler is Compaq Visual Fortran Standard Edition Version 6.6 a.

I know this is fairly old (2006ish) and I will have to update sooner or later. As I am writing commercial software for sale, I will have to pay for it and cannot use any free of charge compiler. And I want to make sure, my proggy is well accepted in the market before I spend a big amount of money on it...

Norbert

The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[xwb]

Try this

      integer*1, dimension (:), allocatable:: pTexPixels    ! array of pixels for texture

I don't know how well having a pointer as an allocatable works. This doesn't work in Powerstation (CVF 4.0) but it works in IVF 11.0 so it might work on your version.

 

[salgerman]

Norbert:
What was that? That you need commercial compiler because you are selling your software? I don't think that's necessary true....you are free to use free (GPL) tools, like the GCC chain, for example, to compile programs that you are planning to sell.

If you are taking advantage of third party libraries, that's another matter...

Then again...what do I know, I don't write software for sale nor am a lawyer...will you care to confirm your statement? I am just curious.

Germán

 

[salgerman]

By the way:

http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

Germán

 

[gummibaer]

Thank you all for your support.

Now I have to answer quite some questions:

xwb:
That was my starting point. But this did not work on my compiler. I cam to the conclusion, that having an allocatable array as an item of a derived datatype does not work at all. After I saved data to such an array - not just reading but evaluating them - I receive strange things recalling them. Just as if the retrieveal happens from another part of memory or something. (But I did not try explicit interfacing, now that I think about it...)

salgerman:
That is good news.

Being no lawyer myself - and no native speaker of English - I have difficulty in completely understanding the GNU-licence. So I lived under the impression that using the free tools of GNU would require me to deliver a free product - which would be a completely fair deal in my eyes by the way. I want to make a little money from my prog - so I must allow those that help me with their tools and software to make a little money as well - and pay for what I use. (I will think of some donation then, if I use the GNU compiler.)

Thanks again.

Norbert




The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[salgerman]

Norbert:

Native English speaker or not...nobody understands legal documents, it is as if lawyers write in a separate language of their own that the rest of us affectionately refer to as legalese.

In any case, I think you are safe using free editors to edit your sources and free compilers to compile of non-free programs...that is, of course, if you are linking third party libraries...for as long as you are just compiling you should be fine.


Germán

 

[gummibaer]

Thanks German.
This will save me some money.

Norbert


The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.