O.K. I used the same SDK/GCC as you are using. I was testing with the program in RAM: so I tried again with the program on an FFS partition. After repeating the "select different ROM/iconify/uniconify" procedure 20-30 times I did get a freeze of the snex9xGUI program that prevented me from opening any other programs. It didn't crash to a Grim Reaper but I was unable to do anything on my system other than moving the mouse pointer. I rebooted and attempted to reproduce the freeze or crash for 20 minutes and was unable to reproduce the problem. I was using 6 ROMS that match the first 6 images in the Previews directory. I'm running snex9xGUI on Workbench; not a seperate screen. Unless you can find a way for others to reliably reproduce the problem, it's going to be really difficult to solve your issue. Sorry I can't help much.javierdlr wrote:Maybe is a filesystem/timing issue ¿:-/
Crash using button.gadget+bitmap.image
Re: Crash using button.gadget+bitmap.image
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Crash using button.gadget+bitmap.image
@javierdlr
As an afterthought I do see some system differences. I tested with the regular program and not the debug version. I'm using the WarpPNG datatype instead of the OS4 PNG datatype. I'm not runing the debug kernal and don't use MUNGE.
As an afterthought I do see some system differences. I tested with the regular program and not the debug version. I'm using the WarpPNG datatype instead of the OS4 PNG datatype. I'm not runing the debug kernal and don't use MUNGE.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: Crash using button.gadget+bitmap.image
@xenic
THX for all test/help, really.
I'm puzzeld too why it crashes in that part of code and not always ¿:-(
THX for all test/help, really.
I'm puzzeld too why it crashes in that part of code and not always ¿:-(
Re: Crash using button.gadget+bitmap.image
In your second code block, why don't you dispose of the image first (instead of swapping pointers), then load the new image? The image won't disappear/flash on screen. Something to try.
Workbench Explorer - A better way to browse drawers
- thomasrapp
- Posts: 310
- Joined: Sat Jun 18, 2011 11:22 pm
Re: Crash using button.gadget+bitmap.image
You must not dispose an image which is still connected to a button. Either detach the image from the button before you dispose it (which might impose flicker) or attach the new image to the button and then dispose the old one.
Re: Crash using button.gadget+bitmap.image
When a program doesn't crash when not using MUNGE debugging (like my system) but does crash when using MUNGE debugging (like your system), that usually means there is some illegal memory access.javierdlr wrote:I'm puzzeld too why it crashes in that part of code and not always ¿:-(
I mentioned in an earlier post that when I ran snes9xGUI with no ROMS installed the snes9xGUI debug output showed random characters like this:
ROM preview: 'PROGDIR:Previews/NÀ{>ä.PNG'.
That looks like it could be the result of illegal memory access. I think the reason for that is that your code is not checking the return value in this line:
IIntuition->GetAttr(LISTBROWSER_SelectedNode, OBJ(OID_LISTBROWSER), (uint32 *)&res_n);
and is not checking for a valid value of "res_n" before executing the IListBrowser->GetListBrowserNodeAttrs lines. In the case where there were no ROMS installed, res_n is 0 (zero) which is probably not a valid input value for the following code. I would also suggest initializing the res_n, res_s & res_t variables to zero or NULL; just to be on the safe side.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: Crash using button.gadget+bitmap.image
Already fixed that bug in my interin version . Thxxenic wrote:...
I mentioned in an earlier post that when I ran snes9xGUI with no ROMS installed the snes9xGUI debug output showed random characters like this:
ROM preview: 'PROGDIR:Previews/NÀ{>ä.PNG'.
That looks like it could be the result of illegal memory access. I think the reason for that is that your code is not checking the return value in this line:
...
http://jabirulo.site90.com/temp/snes9xgui.lha
Code: Select all
void LaunchShowRom(struct Window *pw, BOOL launch) // TRUE:launchROM; FALSE:showPNG
{
uint32 res_n;
STRPTR res_t = NULL, res_s = NULL, txt_s, filename, covers3d;
// struct RomUserData *rud = NULL;
//APTR winlock;
IIntuition->GetAttr(LISTBROWSER_SelectedNode, OBJ(OID_LISTBROWSER), (uint32 *)&res_n);
if(res_n == 0) return;
txt_s = IExec->AllocVecTags(512, AVT_ClearWithValue,0, TAG_DONE),
filename = IExec->AllocVecTags(1024, AVT_ClearWithValue,0, TAG_DONE),
covers3d = IExec->AllocVecTags(1024, AVT_ClearWithValue,0, TAG_DONE);
IListBrowser->GetListBrowserNodeAttrs( (struct Node *)res_n, LBNA_Column,COL_ROM, LBNCA_Text,&res_s, TAG_DONE );
..
A1:Nop, still get the crash :-/
Q2: Myabe is the bitmap.image loading the PNGs?
Just changed to show always the 'availablepreview.png' image, put 'strlcpy()' before 'newobj = NewObject()...' creation
Code: Select all
IUtility->Strlcpy(filename, ROMS"Previews/availablepreview.png", 1024);
// Create/set new preview, refresh button/preview and dispose old
newobj = IIntuition->NewObject(BitMapClass, NULL, //"bitmap.image",..
Re: Crash using button.gadget+bitmap.image
I don't think there's any guarantee that IIntuition->GetAttr() will zero the res_n variable if it fails for any reason. If it doesn't put a zero in res_n when it fails, the value of res_n could be some random junk if it's not initialized to zero. I think you should also initialize res_n to zero (uint32 res_n = 0L).javierdlr wrote: Already fixed that bug in my interin version . Thx
http://jabirulo.site90.com/temp/snes9xgui.lhaCode: Select all
void LaunchShowRom(struct Window *pw, BOOL launch) // TRUE:launchROM; FALSE:showPNG { uint32 res_n; STRPTR res_t = NULL, res_s = NULL, txt_s, filename, covers3d; // struct RomUserData *rud = NULL; //APTR winlock; IIntuition->GetAttr(LISTBROWSER_SelectedNode, OBJ(OID_LISTBROWSER), (uint32 *)&res_n); if(res_n == 0) return;
I did notice that "bitmap.image" is in the stack trace before the crash inside Intuition, so maybe you're right. The only thing you can do is backup a ROMS directory, create an empty ROMS directory and copy a few (10?) at a time to the new directory and test to see if snes9xGUI crashes. I only tested with 6 ROMS with no unusual characters in the names and am using WarpPNG datatype instead of the OS4 PNG datatype; which may be why I had no problems.Myabe is the bitmap.image loading the PNGs?
Just changed to show always the 'availablepreview.png' image, put 'strlcpy()' before 'newobj = NewObject()...' creationA2: mmmm, tried several times (un)iconify and clicking on differnet lb's entries and no problem/crash, maybe some PNGs images have something weird?Code: Select all
IUtility->Strlcpy(filename, ROMS"Previews/availablepreview.png", 1024); // Create/set new preview, refresh button/preview and dispose old newobj = IIntuition->NewObject(BitMapClass, NULL, //"bitmap.image",..
AmigaOne X1000 with 2GB memory - OS4.1 FE
- thomasrapp
- Posts: 310
- Joined: Sat Jun 18, 2011 11:22 pm
Re: Crash using button.gadget+bitmap.image
@javierdlr:
You should be aware that while your window is iconified, the user can close the workbench screen. So when you uniconify the screen can be a different one.
This means that before you iconify you have to free all objects which got the screen pointer, for example every bitmap image with the BITMAP_Screen attribute. And don't foreget to detach these objects from their parent objects before disposing them.
Freeing screen-related objects before iconify may also fix your problem.
You should be aware that while your window is iconified, the user can close the workbench screen. So when you uniconify the screen can be a different one.
This means that before you iconify you have to free all objects which got the screen pointer, for example every bitmap image with the BITMAP_Screen attribute. And don't foreget to detach these objects from their parent objects before disposing them.
Freeing screen-related objects before iconify may also fix your problem.