Pixy new pixel editor for amigaos4

@jabirulo

Have you tried renaming that ominous SYS:Storage/Hollywood directory?

@Raziel

didn't notice such drawer existed :-O

Deleted full drawer and run again pixy and got the same crash/GR

@all

Maybe the solution :
Edit the "user-startup" file at the end of the file delete the empty lines, save and reboot amiga.

It's strange but that corrects a lot of stability problem with me and with pseudaxos

@Raziel

I am not 100% sure but having looked at this a bit I think the Hollywood directory under storage is dynamically created during the runtime of the Hollywood App. Here are my current sys:storage dir:

11.System:Storage/Hollywood> dir
hollywood.FYQCZV (dir)
hollywood.HHUREE (dir)
hollywood.NRNZYW (dir)
hollywood.NYUQUX (dir)
hollywood.RAWCOF (dir)
hollywood.ROHQXX (dir)
hollywood.UWOBVX (dir)


Cheers,
Bill "tekmage" Borsari

@sinisrus

I tried this on my X5000 and had no luck with the crash on startup.

Bill "tekmage" Borsari

@tekmage

Maybe this is ripe for a bug report to airsoft?

Hollywood shouldn't place temporary files onto the system partition, that's what T: is for imo

@Raziel

Quote:

Absolutely!

Since it creates a new folder everytime and stores MUIRoyale.hwp and ZIP.hwp in it and deletes them but not the folder on exit of the app,
if the app crashes the plugins is still there in the folder.

So yes this belongs in T: not in Storage:

@sinisrus

A little request! Is it possible you can add popup menus(right mouse button) in the project draw window?

@all

I just noticed something on my x5K with Pixy. When I open and close the latest Odyssey then launch Pixy, Pixy does not crash.

Can anyone confirm this on an X5K?

Thanks,
Bill "tekmage" Borsari

@tekmage

Sounds like a bug in Odyssey, maybe a memory leek. Allocating few extra bytes, that’s not freed on exit, as result the next program is not overwriting something impotent.

WebKIT is known for being bad, Chrome also uses WebKIT and it has major memory leek problems.

@sinisrus

Just picked up the latest alpha on OS4Depot and still getting same crash on my X5000 that many have also experienced:


Any updates on root cause and/or a solution? I am running with the latest public codesets.library and latest newlib.

-- eliyahu

Quote:
Hollywood used to create these temp files if a 3rd party application was compiled to link plugins in the executable (this is why I didn't link plugins in my programs but included them in the progdir). Hollywood cleared these temp files when you quitted the program, but files were left there if you rebooted or crashed without quitting the program.

This has improved in Hollywood 9.0 and you can avoid temp files creation even when linking plugins. This is the changelog entry:
Quote:


Quote:
This looks a bit like the issue I have with mui.CreateObject with Hollywood on OS4, I don't know if the same function is used in Pixy. Anyway if you do dynamic runtime object creation on OS4, it seems to be a problem. This doesn't happen on any other platforms, but only on OS4.. so probably codesets.library or OS4's MUI implementation issue. Here's more information about my findings: link

@jPV

Thank you for sharing your experience. I created a thread on OS4 coding to see if someone could take on codesets library. I've looked at the source code, and we just need a debug build to pinpoint the input causing the problem.

The fun part about this situation is it only happens on X5000s. Other OS4 platforms don't have this crash!

Thanks,
Bill "tekmage" Borsari

@tekmageQuote:
I bet the actual bug happens on all setups, but it might be just pure luck if it becomes a visible/fatal issue. For example, if it trashes memory, it trashes it every time, but how it shows up depends on what contents it trashed. Maybe X5000 just happens to have some crucial data (drivers or so) on the affected area more likely than some other setup.

The bug I reported is reproducible on both WinUAE and X5000, but at least on WinUAE it's random and you'll have to try to trigger it a bit more before it actually crashes.

@tekmage

I have x1000 and it crash here too.

I have a finding today on that crash we hunt for so long. I used the new IvoRSS that was just released, and that crashes on my system as well, but it has its source available, so it is a good candidate to experiment.

I am not aware of how Hollywood works, as I bought it a few weeks ago.
What I found so far is that in some places IvoRSS uses something like



If I remove the setencoding calls, then the program never crashes. If I add just the first one, it crashes complaining at the LIB_CodesetsConvertStrA(), as mentioned before.

The thing is that I put some DebugPrints here and there, and when it crashes, they are not printed, so to see where it crashes, but it happens as soon as the application is built. Now, I don't know how Hollywood builds the app on the fly.

I will investigate more on what this method does and will try to build IvoRSS and try this out. I will also contact its developer and see what is his opinion.

I am sure JPV has also a lot of knowledge on the matter and he might be able to help us.

update:
It seems this is not the issue, and I am still hunting it! It seems that it has to do with the MUIRoyale as well.
Does anyone know if it is possible to have debug versions of the hollywood plugins and a way to find were exactly it crashes? Is there a way to build the app with something like gstabs, as we have with GCC?