Deun wrote on Thursday, September 06, 2007 10:40 AM
trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 1 bpp X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 3155 Current serial number in output stream: 3163
This occured after an attempt to load a bmp file that can't be found
anywhere.
The size of the bitmap seems crazy... So I've made a patch to fix this in bitmap.c by setting 1x1 size in case of stupid input instead of failing
with
BadAlloc. However, since it works fine on real windows, so I'm not sure
about
the behaviour that the function should have. However this patch let me run the game now :
First your patch is not very useful as the diff was run from inside the directory where the two files where, instead of from the main wine directory. So the patch does not contain the necessary full project path for the patch maintainer to apply It without guessing, which he won't do without some very compelling reasons.
But the more serious problem is that it is really just a hack and as such won't get into wine. Trapping on some arbitrary size is not an acceptable patch for Wine. Instead the root cause should be found.
Since you say that this comes from trying to load a bitmap that can be nowhere found I wonder if this is the result of some unitialized structures that result in garbage but somehow the loading is not aborted with an error for whatever reasons but just passed further to X11DRV_CreateBitmap with whatever garbage happened to be in memory and here probably on the stack.
I see two possibilities and they both are likely to be fixed in the actual caller of X11DRV_CreateBitmap instead of in this function itself:
1) Wine code has a bug and should not ever attempt to call X11DRV to create the bitmap after it couldn't find the according file on disk to initialize the bitmap members. Instead that function should just return to the caller with an error.
2) Windows allows to load a nonexisting bitmap file and returns in that case a default bitmap, brush or whatever without causing an error. In that case the structure should be either initialized to some meaningful values like a 0 * 0 or 1 * 1 bitmap before attempting to load the file from disk and when the load fails just fall through to create that default bitmap or on failure of the loading some special code needs to be executed to create whatever Windows returns here.
So in any case I think you need to figure out from which function exactly X11DRV_CreateBitmap is called with these silly parameters and concentrate on fixing that one instead. Your patch is still very likely to crash on a 0x7e000000 * 0x7e000000 bitmap and therefore didn't adress the root cause of this problem.
Not knowing anything about the stack trace it is completely impossible for anyone not running that application to look for the likely cause of this problem as there are quite a few functions in Wine that call X11DRV_CreateBitmap somewhere and somehow.
Rolf Kalbermatter
On 9/6/07, Rolf Kalbermatter r.kalbermatter@hccnet.nl wrote:
Since you say that this comes from trying to load a bitmap that can be nowhere found I wonder if this is the result of some unitialized structures that result in garbage but somehow the loading is not aborted with an error for whatever reasons but just passed further to X11DRV_CreateBitmap with whatever garbage happened to be in memory and here probably on the stack.
In testing the dib engine I found that I could pass in corrupt bitmaps to the LoadImage function and wine would attempt to load it. I can't remember the details exactly but I knew that it would not exactly fail, while all image programs and windows itself didn't like the bitmaps. There are some conformance issues there that I do not have time to research. I do not think this problem is exactly related to LoadImage, but however it might be having to do with uninitialized structures like you say so I still suggest to trace the problem to the original call.
Jesse
Hi,
I know that my patch was ugly, but since the program doesn't crash there's no stack trace : it exits quietly on the X Error message... Since the program seems to load lots of images, if I run it with winedbg it will take ages before reaching the bad one, it was the purpose of my patch to provide a line where a breakpoint can be put to catch the case... But since I'm not (yet) a wine guru, all I can do is provide the way to catch the case with a lousy patch and the link to the game (which is free, but it's still in japanese only) : http://download.mk-style.com/ccmedia/PW/Install_PW.exe (it's around 2.5G big) You even don't need to create an account, starting the client after install is enough to meet the problem...
On a side note, there's a crash later in the game after selecting character and entering the world, but that's another story...
Regards,
Denis Huguet.
--- Rolf Kalbermatter r.kalbermatter@hccnet.nl wrote:
Deun wrote on Thursday, September 06, 2007 10:40 AM
trace:x11drv:X11DRV_CreateBitmap (0xed4)
2147483646x2147483646
1 bpp X Error of failed request: BadAlloc (insufficient resources
for operation)
Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 3155 Current serial number in output stream: 3163
This occured after an attempt to load a bmp file that can't
be found anywhere.
The size of the bitmap seems crazy... So I've made a patch
to fix this in
bitmap.c by setting 1x1 size in case of stupid input instead
of failing with
BadAlloc. However, since it works fine on real windows, so
I'm not sure about
the behaviour that the function should have. However this
patch let me run
the game now :
First your patch is not very useful as the diff was run from inside the directory where the two files where, instead of from the main wine directory. So the patch does not contain the necessary full project path for the patch maintainer to apply It without guessing, which he won't do without some very compelling reasons.
But the more serious problem is that it is really just a hack and as such won't get into wine. Trapping on some arbitrary size is not an acceptable patch for Wine. Instead the root cause should be found.
Since you say that this comes from trying to load a bitmap that can be nowhere found I wonder if this is the result of some unitialized structures that result in garbage but somehow the loading is not aborted with an error for whatever reasons but just passed further to X11DRV_CreateBitmap with whatever garbage happened to be in memory and here probably on the stack.
I see two possibilities and they both are likely to be fixed in the actual caller of X11DRV_CreateBitmap instead of in this function itself:
- Wine code has a bug and should not ever attempt to call
X11DRV to create the bitmap after it couldn't find the according file on disk to initialize the bitmap members. Instead that function should just return to the caller with an error.
- Windows allows to load a nonexisting bitmap file and
returns in that case a default bitmap, brush or whatever without causing an error. In that case the structure should be either initialized to some meaningful values like a 0 * 0 or 1 * 1 bitmap before attempting to load the file from disk and when the load fails just fall through to create that default bitmap or on failure of the loading some special code needs to be executed to create whatever Windows returns here.
So in any case I think you need to figure out from which function exactly X11DRV_CreateBitmap is called with these silly parameters and concentrate on fixing that one instead. Your patch is still very likely to crash on a 0x7e000000 * 0x7e000000 bitmap and therefore didn't adress the root cause of this problem.
Not knowing anything about the stack trace it is completely impossible for anyone not running that application to look for the likely cause of this problem as there are quite a few functions in Wine that call X11DRV_CreateBitmap somewhere and somehow.
Rolf Kalbermatter
____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
-
Deun -
Jesse Allen -
Rolf Kalbermatter