Closed CrossAlchemy closed 9 years ago
Hi folks, any news about that problem?
Off-topic: can you please share a list of popular games made with crossbridge?
For the issue, i haven't found the time to look at it yet. I hope to do so before the end of the week.
As for the list of popular games, I doubt you will find much except the demos adobe and unreal made long ago. The community isn't big and people usually just use it without talking about it. If you have some project made with it, I encourage you to post them in the new forum http://forum.crossbridge.io. I want to feature some project on the website some day.
How about this guy https://github.com/alexmac alexmac@adobe.com May be he could tell us something ?
Hi, Some tips:
--Edited--
I reported some bugs to the bugbase handled by the charming Indian guys. Believe me, you're talking to a wall.
2015-02-11 8:25 GMT+01:00 Andras Csizmadia notifications@github.com:
Hi, Some tips:
- Try testing you app with a 'real' browser from network (like localhost\index.html)
- Try updating FlashPlayer 16 to latest build version
- Report the issue at bugbase.adobe.com (As far as I understand Adobe outsourced the whole Flash Platform development to Asia/India - so good luck with that :( )
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-73842507 .
So why dont you try your tips by yourself? May be you'll see that problem at last..
I stopped using CrossBridge and Flash generally, moving to HTML5 and emscripten.
2015-02-11 9:49 GMT+01:00 CrossAlchemy notifications@github.com:
So why dont you try your tips by yourself? May you'll see that problem at last..
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-73849433 .
Sorry to say but same here. I'm actually working on native development (java,swift,cpp), so I'm not planning to upgrade CrossBridge with any major stuff - forking was a learning project for me. I'll try to support minor bugfixing but you know time is really precious thing and nowadays I have none free..
Thats fair. Thanx.
2015-02-11 13:59 GMT+03:00 Andras Csizmadia notifications@github.com:
Sorry to say but same here. I'm actually working on native development (java,swift,cpp), so I'm not planning to upgrade CrossBridge with any major stuff - forking was a learning project for me. I'll try to support minor bugfixing but you know time is really precious thing and nowadays I have none free..
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-73864023 .
https://bugbase.adobe.com/index.cfm?event=bug&id=3938269 please vote up this issue report if possible.
I can confirm the issue by the way.. I've compiled the shipped hello world sample and sure it does throws the mentioned exception.
In the worst case, where there is nothing to do to save threads, I was thinking about making the threads “fake”. Running them on the same worker by doing asynchronous work, but on the same “real” thread. Meaning we could share stuff between thread, but we’d take a hit in performance. At least, app would not break. Just take a hit in performance. It could also be implemented as a fallback, only used with an option in case there is a problem with threads (like right now).
Deleted CrossAlchemy's troll posts. Such behaviour don't help at all.
Hi,
Adobe feedback: 'We've had to impose some restrictions on ByteArrays to address security issues in the wild. ByteArrays can either be compressed or shared, but not both. Also, a shared ByteArray can no longer be used as ApplicationDomain.domainMemory. We'll take a look to see if we can improve the situation. '
My tip for fast patch: https://github.com/crossbridge-community/crossbridge/blob/master/posix/C_Run.as Line 319-321
public const ram_init:ByteArray =
(workerClass ? workerClass.current.getSharedProperty("flascc.ram") : null) ||
(domainClass.currentDomain.domainMemory ? domainClass.currentDomain.domainMemory : new ByteArray);
should be:
public const ram_init:ByteArray = new ByteArray();
// I think we'll loose some performance gain Not using domainMemory, but at least it does not require any major refactor.
Also any other reference to domainMemory needed to be changed.
//// Edit: As someone tried to mention it's not so simple because CrossBridge AS3 codebase is depending on avm2.intrinsics.memory.* which only manipulates one domainmemory.. I really hope FP engineers can do something to ease this security fix..
I've unlocked the issue so other users can add their point (I believe in open web..) Just please be kind, stay on topic and post constructive thoughts..
I agree. Though it seems to be the only option except deleting insult post (that seems to keep coming now) github leaves us.
What's interesting that the following sample works for me with FP 16.0.0.305: http://www.vpmedia.hu/crossbridge/neverball/ But this one throws error: http://www.vpmedia.hu/crossbridge/helloworld/ (Edited)
Going through in the code i've found this one: https://github.com/crossbridge-community/crossbridge/blob/master/posix/C_Run.as Line 138: '.. We use workerClass != null as a test for existence of thread support' So workers are already optional because of older FP support..
i checked sources and did not found that it uses threads. may be i missed something ?
2015-02-11 23:26 GMT+03:00 Andras Csizmadia notifications@github.com:
What's interesting that the following sample works for me with FP 16.0.0.305: http://www.vpmedia.hu/crossbridge/neverball/ Maybe this is only a sandbox issue runing SWFs locally?
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-73957783 .
I think the simpliest solution to disable threading is passing a swf-version=17 parameter to the CrossBridge GCC (Older FP had no workers..)
To disable it at all i think the following const property should be null, because its checked against it..
public const workerClass:Class = null;
i see
2015-02-11 23:40 GMT+03:00 Andras Csizmadia notifications@github.com:
I think the simpliest solution to disable threading is passing a swf-version=15 parameter to the CrossBridge GCC (Older FP had no workers..)
To disable it at all i think the following const property should be null, because its checked against it..
public const workerClass:Class = null;
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-73960171 .
I have to digest this issue a bit, what I can think of is introducing a newer feature checking method, which tries to instantiate an ApplicationDomain shared between Workers and gives a Bool it is useable or not (Trying to catch the exception).
About neverball.. I checked with scout it shows no additinal workers. primordial only. Are you sure it comes to newThread ? Could you check with trace ?
No-no.. my point was that is already possible to cross-compile an application with only one thread.
Soo...when do you think this can be fixed? Or can I do something myself to fix this in the sources? From what I've gathered on this thread it's not trivial to fix. I've gotten into this as FlasCC user(not Crossbridge / AVM expert), never thought Adobe would let it just go(&break later), and my lib is 100% depending on threading to work. So in turn, this breaks various apps of other people using my lib.
As a fast fix maybe you can try using CModule.startAsync
rather than CModule.startBackground
in your Console.as.. Also you can try it compiling using swf-version=17
(Edited)
I'll try to setup my dev env. on the weekend and see what can I do on CrossBridge's side - but as stated in above comments both AppDomainMemory and Workers are essential parts of the stuff so I'm not really optimistic right now.
Adobe is investigating, not sure when they'll give a new update (I'm not in contact with them).
Please everyone vote on the ticket who is affected/interested so their engineers take it more seriously: https://bugbase.adobe.com/index.cfm?event=bug&id=3938269
Thanks for the reply. I did vote and comment..My lib is using pthreads. Basically its encoding video on another thread / worker in FlasCC version which would otherwise make the app unusable. Its doing realtime encoding while recording at the same time...Its SWC. So in the way they broke it, it seems the fix depends on Adobe?:(
Yes it depends on Adobe (there were no problems before the last FP version..), if I understood right a security fix was more important than backward compatibility.
Ok, I'll wait for the weekend - if I can help in any way let me know (with testing at least). Thanks!
Alex MacDonald the guy from Adobe asks for good example
post it here, ill put them to my answer.
That's funny, I've emailed Alec today as well, and he responded the same thing. So I've emailed him the link to my online demo where its clearly borken in FP16 (the ogv video encoding progress bar is stuck in FP16 & throws the error underneath while in FP15 it works fine).
Fingers crossed its really in the "next version" then because my online demo is broken, not a good sight, people will think I'm joking :P
Just a short update: I pinged some people (customers using my lib) to vote on the "bug" as well, 2 voted so far, that's 3 including me:) I hope some more join in yet..
Any news ?
Well, as for me I'm following the bug report every day, I see votes are being added on regular basis so thats good at least. I'm trying to get more votes in, some of my customers voted but we need more of course. I've put a link to my lib demo with an explanation of why it doesn't work currently and where to go to vote for a fix. I saw people voting as a result already(going there from my demo), so thats good, more might come that way.
I plan to carefully e-mail Alec again, I wanted to have some delay to get more votes & avoid being thought of as spammer and annoying him. I'm not sure if he has any influence there other than asking about the issue. So maybe few more people could e-mail him again in a polite manner...as he is the guy taking care of FlasCC formerly, so might feel a bit of responsibility etc.
You do well, man!
2015-02-25 18:25 GMT+03:00 rainbowcreatures notifications@github.com:
Well, as for me I'm following the bug report every day, I see votes are being added on regular basis so thats good at least. I'm trying to get more votes in, some of my customers voted but we need more of course. I've put a link to my lib demo with an explanation of why it doesn't work currently and where to go to vote for a fix. I saw people voting as a result already(going there from my demo), so thats good, more might come that way.
I plan to carefully e-mail Alec again, I wanted to have some delay to get more votes & avoid being thought of as spammer and annoying him. I'm not sure if he has any influence there other than asking about the issue. So maybe few more people could e-mail him again in a polite manner...as he is the guy taking care of FlasCC formerly, so might feel a bit of responsibility etc.
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-75979481 .
Yeee!!! We have a status update Status ToFix https://bugbase.adobe.com/index.cfm?event=bug&id=3938269
2015-02-25 22:18 GMT+03:00 Serj Golovin golovinmsc@gmail.com:
You do well, man!
2015-02-25 18:25 GMT+03:00 rainbowcreatures notifications@github.com:
Well, as for me I'm following the bug report every day, I see votes are being added on regular basis so thats good at least. I'm trying to get more votes in, some of my customers voted but we need more of course. I've put a link to my lib demo with an explanation of why it doesn't work currently and where to go to vote for a fix. I saw people voting as a result already(going there from my demo), so thats good, more might come that way.
I plan to carefully e-mail Alec again, I wanted to have some delay to get more votes & avoid being thought of as spammer and annoying him. I'm not sure if he has any influence there other than asking about the issue. So maybe few more people could e-mail him again in a polite manner...as he is the guy taking care of FlasCC formerly, so might feel a bit of responsibility etc.
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-75979481 .
Actually I saw this status there for some time now, but yeah that's a good sign, not many bugs get that, at least from when I browsed their bugbase (most of them were unverified or something like that).
Good news, this seems to be fixed in 17.0.0.134 ! Just tested and multithreading in my demo is working agian with it (with 16.X broken previously).
I think this is the only time I've ever seen a bug put into a bugtracker of a large product actually get fixed. Awesome!
Hey, hey! Is there any productivity losses comparing to flash player < 16 ?
2015-03-13 3:38 GMT+03:00 rainbowcreatures notifications@github.com:
Good news, this seems to be fixed in 17.0.0.134 ! Just tested and multithreading in my demo is working agian with it (with 16.X broken previously).
— Reply to this email directly or view it on GitHub https://github.com/crossbridge-community/crossbridge/issues/77#issuecomment-78717983 .
Closing the ticket, thanks for all the votes, as you can see they actually listen to the community if enough voice has raisen.. Cheers!
ArgumentError: Error #3735: This API cannot accept shared ByteArrays. (ArgumentError: Error #3735: This API cannot accept shared ByteArrays.
This line causing that. C_Run.as:302 ram_init.shareable = true; // ensure shared!
Well, you know what it means, if domainMemory cannot be shared across workers. If you guys stay intouch with adobe, could you ask them what the hell is going on?