pthreads and workers support

[shaul-yermol]

Hi all,

I have recently encountered several issues with pthreads and workers in crossbridge. It looks like the pthreads/workers support is not 100% stable and becomes a pitfall for any seriouse efforts to port complex C++ code. I am basically a C++ specialist, so although I have a basic understanding of how the threads were implmeented (both from looking at source and forums), it's really hard for me to debug these issues in the crossbridge code.

I'm using Windows 8 64bit, Crossbridge 1.0.1, Flex 4.12.1, Flash debug player standalone 13.

1) In sample 09, pthread_swc2.swf - pthread_join causes deadlock, when running the main() on the UI wroker with startAsync() - you can try the original sample code.

2) In sample 09, after changing pthread_swc.as by Console.as (basically just running the main() in background worker) the main() works fine, however trying to call spawnThread() from UI events sometimes causes deadlock in pthread_join

Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.
    at flash.concurrent::Condition/wait()
    at global/sample.pthread::threadArbCondWait()
    at global/sample.pthread::F_avm2_msleep()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:6496]
    at global/sample.pthread::F_kmsleep()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:7434]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_cciMgysi_2E_lto_2E_bc_3A_77d5ac99_2D_8207_2D_44be_2D_990e_2D_0fc9c24978f7::F_do_wait()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:76497]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_cciMgysi_2E_lto_2E_bc_3A_77d5ac99_2D_8207_2D_44be_2D_990e_2D_0fc9c24978f7::F___umtx_op_wait()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:71533]
    at global/sample.pthread::F_k_umtx_op()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:71338]
    at global/sample.pthread::F__umtx_op()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:2267]
    at global/sample.pthread::F__thr_umtx_wait()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:59107]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_cciMgysi_2E_lto_2E_bc_3A_77d5ac99_2D_8207_2D_44be_2D_990e_2D_0fc9c24978f7::F_join_common()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:49539]
    at global/sample.pthread::F__pthread_join()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:49319]
    at global/sample.pthread::F_pthread_join_exp()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:66745]
    at global/sample.pthread::spawnThread()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:111]
    at Console/buttonClickHandler()[C:\crossbridge\samples\09_Pthreads\Console.as:132]

And after I've removed the pthread_join(), it sometimes deadlocked in printf().

Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.
    at flash.concurrent::Condition/wait()
    at global/sample.pthread::threadArbCondWait()
    at global/sample.pthread::F_avm2_msleep()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:6488]
    at global/sample.pthread::F_kmsleep()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:7426]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_ccqgHCk8_2E_lto_2E_bc_3A_75e4d886_2D_039d_2D_479d_2D_bd70_2D_fe9c94c1a4e5::F__do_lock_umutex()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:74414]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_ccqgHCk8_2E_lto_2E_bc_3A_75e4d886_2D_039d_2D_479d_2D_bd70_2D_fe9c94c1a4e5::F_do_lock_umutex()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:76178]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_ccqgHCk8_2E_lto_2E_bc_3A_75e4d886_2D_039d_2D_479d_2D_bd70_2D_fe9c94c1a4e5::F___umtx_op_wait_umutex()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:73667]
    at global/sample.pthread::F_k_umtx_op()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:71330]
    at global/sample.pthread::F__umtx_op()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:2259]
    at global/sample.pthread::F___thr_umutex_lock()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:59556]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_ccqgHCk8_2E_lto_2E_bc_3A_75e4d886_2D_039d_2D_479d_2D_bd70_2D_fe9c94c1a4e5::F_mutex_lock_common()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:53582]
    at global/sample.pthread::F__pthread_mutex_lock()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:53961]
    at global/sample.pthread::F__flockfile()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:109241]
    at global/sample.pthread::F_puts()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:97284]
    at global/sample.pthread::spawnThread()[C:\cygwin\tmp\cc5PYYGx.lto.1.as:109]
    at Console/buttonClickHandler()[C:\crossbridge\samples\09_Pthreads\Console.as:132]

Error: Error #1517: Condition cannot notifyAll if associated mutex is not owned.
    at flash.concurrent::Condition/notifyAll()
    at global/sample.pthread::threadArbCondsNotify()
    at global/sample.pthread::F_avm2_wake_one()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:4287]
    at global/sample.pthread__3A__5C_cygwin_5C_tmp_5C_cciMgysi_2E_lto_2E_bc_3A_77d5ac99_2D_8207_2D_44be_2D_990e_2D_0fc9c24978f7::F_uiThunkTickProc()[C:\cygwin\tmp\ccYVhlkk.lto.1.as:7350]
    at sample.pthread::CModule$/callI()
    at sample.pthread::CModule$/serviceUIRequests()
    at Console/enterFrame()[C:\crossbridge\samples\09_Pthreads\Console.as:219]

I will really appritiate any suggestions and will be glad to assist, as right now this is the major pitfall of our porting efforts.

Thanks!

[vpmedia]

Hi, I've tried to reproduce your problem and can confirm it exists..

Currently i'm doing some maintenance on the SDK,

you can find the fork here: https://github.com/vpmedia/crossbridge ..and the project site here: https://sourceforge.net/projects/crossbridge-community/ If you have some free time please try to build the SDK so I can have feedbacks.

Most of the thread impl. is in these files: posix\ C_Run.as CModule.as libcHack.c

I'll try to look more into it later..

[vpmedia]

I would start to enable the trace statements, so have some sense about the execution flow.. Also worth to try to enable the try catch exception here: C_Run.as : 249 : public function threadArbCondWait(timo:Number):Boolean

[vpmedia]

Also i think the whole implementation should be reviewed according to AS3 API updates.

[vpmedia]

it looks like that the issue is quite old: https://forums.adobe.com/message/5143791 any chance for Adobe support on this one?

[shaul-yermol]

Hi

Well, I'm a little frustrated.

1) SDK build: I have cygwin, java, installed cygwin tools for autoconf and so on. But building SDK failes. Do you have a "how-to" explaining of enviroment setup on Windows or Linux?

2) The traces and debugging. GDB does not work with SWC/SWF samples (it can not connect at all), and crashes with segfault with multithreaded swf. FDB does not work with multithreaded applications at all, or maybe I'm just missing something.

So even if I compile the C_Run.as file to ABC and somehow compile it into my SWF - how can I see the traces? Flash Scout maybe?

Sorry for the stupid questions, but my tech background is really miles away from Flash and Windows.

[vpmedia]

Some help for debugging SWFs:

1. Download Flash Debug Player: https://www.adobe.com/support/flashplayer/downloads.html (I would recommend to setup both for browsers and standalone, second is essential for CrossBridge)
2. Setup Flash Player logging/debugging: https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html (You will find a flashlog.txt if setup is succeeded, like: \Users\USERNAME\AppData\Roaming\Macromedia\Flash Player\Logs\ on Win7)
3. Set _FLASH_PLAYEREXE environment variable pointing to Flash Player Standalone location, like: _FLASH_PLAYEREXE=C:\Work\tools\flashplayer.exe
4. _Set FLASCC_GDBRUNTIME env. variable pointing to F.P. Standalone with Cygwin style path, like: _FLASCC_GDBRUNTIME=/cygdrive/c/Work/tools/flashplayer.exe
5. Download Adobe AIR SDK from: https://www.adobe.com/devnet/air/air-sdk-download.html
6. Set _AIRHOME env. variable pointing to SDK location, like: _AIRHOME=C:\Work\sdks\adobe-air\14.0
7. Learn about FDB for CrossBridge debugging here: https://www.adobe.com/devnet-docs/flascc/docs/gdb_nonstop.html
8. Learn more about FDB for Flex/Flash here: http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7ffb.html

[vpmedia]

Some help for building CrossBridge SDK from source:

1. Download Cygwin pre-installed distribution from here (Needed only for Win.): http://sourceforge.net/projects/crossbridge-community/files/cygwin-for-sdk-devs.zip/download
2. Take a look at README.md inside the ZIP package
3. Take a look at: https://github.com/vpmedia/crossbridge/blob/master/INSTALL.md
4. Check build logs at \crossbridge\build\win\logs\
5. Check config log at failing build target, like: \build\win\llvm-gcc-42\config.log
6. Provide these logs if you cannot solve the issue by self

[shaul-yermol]

Thanks so much for the help!

[vpmedia]

Hi,

After decompiling two different versions of the test program I've found out that the following statement causes the issue:

\posix\CModule.as

public static function startAsync

// try to set us as the ui thread
try {
C_Run.workerClass["current"].setSharedProperty("flascc.uiThread.threadId", realThreadId);
} catch(e:*) {}

If I comment this out I can run the embedded SWCs spawnThread method in my application (If I run it using startAsync rather than startBackground).

I'll release soon a new version of CrossBridge here with the fix: http://sourceforge.net/projects/crossbridge-community/files/1.0.4/

Anyway some feedback from the previous maintainers would be awesome, why this change has been applied since Flascc (CrossBridge) 1.0.0

• Edit:

Reviewing the changelist from 1.0.1 this one is a candidate:

• avm2_uithunk no longer fails when content was started using CModule.startAsync() due to incorrect assignment of thread ids
• Edit 2:

https://github.com/vpmedia/crossbridge/commit/294c54fb988dcdc9ca6cae1625f48ff1dff53a95

[vpmedia]

Hi, I've uploaded a release with the fix for the issue: http://sourceforge.net/projects/crossbridge-community/files/1.0.4/CrossBridge_1.0.4.2.zip/download