Bug: dat utility/grabber crashes

Bug: dat utility/grabber crashes

BigBertus

Member #2,093

March 2002

Hello folks!
I have the following problem:
Whenever I try to save a datafile using the dat utility or the grabber, it crashes.

Also the grabber doesn't shut down properly whenever I run it: I just start it, select "File->Quit" and there comes a Windows-message about the program not exiting properly...
I have compiled the debug-version of Allegro now, using that the grabber program produces no error at shut-down.
But still, when I try to save a datafile, I get an error message:

>dat -a -t bmp -bpp 16 elevator.dat *.bmp
elevator.dat not found: creating new datafile
Inserting d:\prog\shdw\objs\ELEVATOR\FLY_0001.bmp -> FLY_0001_BMP
Inserting d:\prog\shdw\objs\ELEVATOR\PROP.bmp -> PROP_BMP
Inserting d:\prog\shdw\objs\ELEVATOR\STILL.bmp -> STILL_BMP
Writing elevator.dat
Assert failed at line 2300 of src/file.c

This is about line 2300 of src/file.c:

1/* pack_mputw:
2 *  Writes a 16 bit int to a file, using motorola byte-ordering.
3 */
4int pack_mputw(int w, PACKFILE *f)
5{
6   int b1, b2;
7   ASSERT(f);  /* <---- 2300 is here */
8 
9   b1 = (w & 0xFF00) >> 8;
10   b2 = w & 0x00FF;
11 
12   if (pack_putc(b1,f)==b1)
13      if (pack_putc(b2,f)==b2)
14   return w;
15 
16   return EOF;
17}

I'm running Allegro 4.2 on Windows XP.

edit: Forgot to say, there is no file saved, which is my real problem

Does anyone have any clue?
Thanks!

Evert

Member #794

November 2000

Do you have write permission in the target directory? What happens if you run as root (or whatever the Windows equivalent is called)?

BigBertus

Member #2,093

March 2002

Aaaah! With administrator-privileges, it does write the datafile, thanks!

But I certainly do have permission to create/write files in the target directory.
I forgot to mention, when I don't log on as administrator, there is a file created that has 0 bytes. So when there is a file created, why do I need administrator-privileges to write into it?

Evert

Member #794

November 2000

I don't know, but I've seen this same issue come up before. I don't remember what causes it, but maybe a forum search will help you.

BigBertus

Member #2,093

March 2002

Well, yes.
I found this thread:
http://www.allegro.cc/forums/thread/454214
However the actual cause of the problem is not got rid of by using that fix- I am on an NTFS drive, of course, so it's the same problem...
It's strange, everything but just the grabber and dat-utility works on NTFS?

Peter Wang

Member #23

April 2000

Can you run dat through a debugger? If you see why the assertion is being triggered that would possibly lead you to the source of the problem.

BigBertus

Member #2,093

March 2002

I tried to do that, but my debugger keeps crashing. I'm using Insight, which is more or less a graphical frontend for gdb, I think. Does anyone know another working debugger for MinGW? (except for gdb, but if there is none, I could also try that)

Peter Wang

Member #23

April 2000

I found the bug, but I don't have time to fix it. If someone could fix it, that would be great. Here is the problem: there is a call to pack_fopen_chunk() in datedit.c that fails. Due to some sloppy coding, this was not checked. pack_fopen_chunk() is implemented by opening a temporary file so even if you have write access to the target directory it could fail if you don't have write access to the directory for the temporary file (I think it is the current directory). Someone needs to fix pack_fopen_chunk().

In the meantime, I will apply a patch so at least dat and grabber will return a failure code rather than aborting.

Evert

Member #794

November 2000

Patch for pack_fopen_chunk() attached. Someone please test it in Windows, since I forgot to do this. It works fine now in Linux, but the code used in Windows is slightly different.

BAF

Member #2,981

December 2002

I'd check it, but I've never had problems with grabber under WinXP (and I use NTFS).

BAF.zone | SantaHack!

ReyBrujo

Moderator

January 2001

I have a problem with the following part:

         do {
            size = new_size;
            tmp_dir = realloc(tmp_dir, size);
            new_size = GetTempPath(size, tmp_dir);
         } while ( (size > new_size) && (new_size > 0) );

GetTempPath returns 0 on error. If that piece of code is trying to increase the buffer size to try again, it is not doing so. However, even if it does, it is possible that the temporary directory could not be retrieved, thus creating an infinite loop draining all memory. I would remove the while cycle; after the loop it is checked if it could not be extracted.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Evert

Member #794

November 2000

Quote:

I'd check it, but I've never had problems with grabber under WinXP (and I use NTFS).

It has nothing to do with WinXP - it has to do with trying to create a file in a directory where you do not have write permission (so I was also able to reproduce it in Linux as well).
Go to a directory where you don't have write permission, start the grabber from there and safe a datafile in a directory where you do have write permission. The grabber will then try to create a temporary file in the active directory, where you don't have write permission, and crash.

Quote:

GetTempPath [msdn.microsoft.com] returns 0 on error. If that piece of code is trying to increase the buffer size to try again, it is not doing so. However, even if it does, it is possible that the temporary directory could not be retrieved, thus creating an infinite loop draining all memory.

That's why there's a && (new_size > 0) in there.
The code should run until it either fails or retrieves the directory after a couple of iterations.

ReyBrujo

Moderator

January 2001

Oh, didn't read the second part, the one saying it would return only the size :-[

Since it returns the size in TCHAR, it may have problems with unicode (can Allegro be compiled in a Unicode project in MSVC?). Maybe it would be safer to multiply sizes with sizeof(TCHAR)? If not, dismiss that

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale