gflFreeBitmapData stack overflow ?

[pber]

Hello !

I am using the gfllib with a C# wrapper, and there are a few points that I would like to be explained a bit further:


- When I call gflFreeBitmapData, I sometimes catch a StackOverflow exception. Is there any reason for that ? I can't see why gflFreeBitmapData could raise such an error, since its structure does not require recursive calls for freeing it.

- Another question is : What is the difference between gflFreeBitmap and gflFreeBitmapData? The first seems to set all values to 0x00000000, whereas the second sets almost all values to 0xfeeefeee. I couldn't find the answer in the Help file ("both functions free the content of the GFL_BITMAP structure").
Is there a correct way of using those ? (for instance, should I first call gflFreeBitmapData, and afterward, gflFreeBitmap ?)


here's an extract of my code :

Code: Select all

GFL_BITMAP bmp = new GFL_BITMAP();
GFL_ERROR err = new GFL_ERROR();
GFL_FILE_INFORMATION info = new GFL_FILE_INFORMATION();
GFL_LOAD_PARAMS ldp;
gflGetDefaultLoadParams(out ldp);
string my_file = "\\images\\bmp.bmp";

err = gflLoadBitmap(my_file, out bmp, ref ldp, ref info);
Console.WriteLine("load: " + err + " size: " + info.FileSize);
gflFreeBitmapData(ref bmp); //here is where StackOverflow occurs
gflFreeFileInformation(ref info);
gflFreeBitmap(ref bmp);

I'll also add that info.FileSize is not always the same. Is there any reason for that?
In particular in threaded processi, if two threads attempt to load the file, both will succeed, but the info.FileSize is not the same for both threads.

[xnview]

I am using the gfllib with a C# wrapper, and there are a few points that I would like to be explained a bit further:

Perhaps it will be a good idea to post your C# wrapper for others developers...

- When I call gflFreeBitmapData, I sometimes catch a StackOverflow exception. Is there any reason for that ? I can't see why gflFreeBitmapData could raise such an error, since its structure does not require recursive calls for freeing it.

Strange, and the bitmap is correctly loaded?

- Another question is : What is the difference between gflFreeBitmap and gflFreeBitmapData? The first seems to set all values to 0x00000000, whereas the second sets almost all values to 0xfeeefeee. I couldn't find the answer in the Help file ("both functions free the content of the GFL_BITMAP structure").
Is there a correct way of using those ? (for instance, should I first call gflFreeBitmapData, and afterward, gflFreeBitmap ?)

gflFreeBitmap call gflFreeBitmapData
gflFreeBitmapData free only the data of the bitmap not the GFL_BITMAP
So call only gflFreeBitmap

I'll also add that info.FileSize is not always the same. Is there any reason for that?
In particular in threaded processi, if two threads attempt to load the file, both will succeed, but the info.FileSize is not the same for both threads.

And the filesize is bad?

[pber]

* Wrapper C#
Until now, the wrapper is only used inside my company, and it is not yet complete. That's why I prefer keeping it.

--

* StackOverflow
Yes. Files are correctly loaded. I can save them (before freeing the bitmap, of course), and they're the same as originals.
link to my magnificient image.

--

* gflFreeBitmap
That seems perfect. Almost all my problems are solved
Maybe a little tip about not using gflFreeBitmapData could be helpful, in the Help app.

--

* GFL_FILE_INFORMATION.fileSize
The two info.FileSize cannot be both correct *and* different one from another.
In my tests, one was correct, the other was higher. But when the files were saved to the hard drive, they had the correct filesize.
Here is my C++ code for that :

Code: Select all

#include "stdafx.h"
#include "stdio.h"
#include <iostream>
#include <libgfl>
#include <libgfle>
#include <windows>
#include <strsafe>

#define MAX_THREADS 3
#define NB_LOOPS 2

using namespace std;

typedef struct _MyData{
	int val1;
} MYDATA, *PMYDATA;

DWORD WINAPI LoadImage(LPVOID lpParam)
{
	for(int i = 0 ; i LOWER_THAN NB_LOOPS; i++) //change this line, the phpbb did not like it :(

{

GFL_ERROR err;
			GFL_FILE_INFORMATION info;
			GFL_LOAD_PARAMS loadparams;
			GFL_BITMAP* bitmap;
			GFL_SAVE_PARAMS svp;
			const char* my_file = "images\\bmp.bmp";

			gflGetDefaultLoadParams(&loadparams);

			err = gflLoadBitmap(my_file, &bitmap, &loadparams, &info);
			
			PMYDATA pData = (PMYDATA) lpParam;
			const char* stringerror = gflGetErrorString(err);
			char t[256];
			sprintf(t,  "thread %d; error: %s; loaded: %d\n" , pData->val1 , stringerror , info.FileSize);

// Here I printed the t string, but phpbb does really not like the LOWER_THAN / GREATER_THAN symbols :(

				gflGetDefaultSaveParams(&svp);
			(&svp)->FormatIndex = gflGetFormatIndexByName("bmp");
			sprintf(t, "saves\\bmp%d-%d.bmp", i, pData->val1);
			err = gflSaveBitmap(t, bitmap, &svp);

		
			//gflFreeBitmapData(bitmap);
			gflFreeFileInformation(&info);
			gflFreeBitmap(bitmap);
		

	}
	return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{

	PMYDATA pData;
	DWORD dwThreadId[MAX_THREADS];
	HANDLE hThread[MAX_THREADS];
	int i;

	gflLibraryInit();

	for(i = 0; i LOWER_THAN MAX_THREADS; i++) // Change this line too ...
	{
		pData = (PMYDATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(MYDATA));
		if(pData == NULL)
			ExitProcess(2);

		pData->val1 = i;
		hThread[i] = CreateThread(
			NULL,
			0,
			LoadImage,
			pData,
			0,
			&dwThreadId[i]);

		if(hThread[i] == NULL)
		{
			ExitProcess(i);
		}
	}
	WaitForMultipleObjects(MAX_THREADS, hThread, TRUE, INFINITE);

	for(int i = 0; i < MAX_THREADS; i++)
	{
		CloseHandle(hThread[i]);
	}



	char c = getchar();
	return 0;
}

When applied to the previous bmp.bmp file (the one from the imageshack link), I get those results :

Code: Select all

thread 0; error: No error; loaded: 983094
thread 1; error: No error; loaded: 11796052
thread 2; error: No error; loaded: 12844628
thread 0; error: No error; loaded: 983094
thread 1; error: No error; loaded: 983094
thread 2; error: No error; loaded: 983094

But the bmpx-y.bmp files are still all the same. And have the same size (983094 bytes).



EDIT : there seems to be a problem with my inserting code character "<" was not accepted without skipping everything till the next ">"

[xnview]

Ok, the problem with filesize was a sharing problem. If you wan i can send you the fixed version (send me your email by PM)