Crashes/Freezes on MacPro all the time

[bleicher]

Hi,

I've tried 1.0.11 and 1.0.12 and it keeps freezing all the time - and 10.6 or 10.7 didn't make a difference. Sometimes after 20 seconds, sometimes after 5 minutes... almost impossible to play a single game. Works fine on the MacBook. Using JavaFibs within the Windows VM is not what I'm looking for but a very temporary fix.

Any suggestions on what I might try?

It *looks* like a threading bug... but as there is no source code, there's nothing I can do to track it down.

[moonshadow]

Hi,

I've tried 1.0.11 and 1.0.12 and it keeps freezing all the time - and 10.6 or 10.7 didn't make a difference. Sometimes after 20 seconds, sometimes after 5 minutes... almost impossible to play a single game. Works fine on the MacBook. Using JavaFibs within the Windows VM is not what I'm looking for but a very temporary fix.

Any suggestions on what I might try?

It *looks* like a threading bug... but as there is no source code, there's nothing I can do to track it down.

I've been running Javafibs on Macs since Mac OS 10.0, including 10.6 and now 10.7,  without any of the issues you are encountering, so the issue is not Javafibs.

Try a clean install of Javafibs.

[bleicher]

I've been running Javafibs on Macs since Mac OS 10.0, including 10.6 and now 10.7,  without any of the issues you are encountering, so the issue is not Javafibs.

Try a clean install of Javafibs.

I was using it for a long time, too. Clean downloads and installs didn't help. On all the standard machines (iMac, MacBook, MacBook Air, MacBook Pro) there is no problems. It's just on the MacPro with 24 cores and tons of RAM that gives problems. There have been threading issues in the past with this client, and this really smells like a threading bug. Activity monitor shows > 40 threads for this process, and letting it run on 24 cores will just expose bugs that don't appear on <= 4 cores.

Just because it runs on many machines and configurations doesn't mean the problem isn't real or the software.

Just reproduced: doing clicks here and there, doing some whois queries and resizing the window... beach ball of death.

You might ignore this bug as a "one off", because it will show very rarely on most machines. But then, there are reports of occasional crashes, which supports the thesis of threading issues.

I am a programmer with quite some Java background - and if I can be of any help (i.e. letting a debugger run and look where the dead lock arrives), just let me know. I can reproduce the problem with 1-2 minutes (consistently for several weeks).

[moonshadow]

I am a programmer with quite some Java background - and if I can be of any help (i.e. letting a debugger run and look where the dead lock arrives), just let me know. I can reproduce the problem with 1-2 minutes (consistently for several weeks).

Point taken. Clearly you know what you are talking about and not trying to use tehno babble to befuddle those as ignorant as myself about programming matters.

You need to contact Inim--or he may happen to read the board here and see this thread--as he will be able to speak your "language".

Who knows, you may be the programmer Inim is looking for to assist in javafibs development (smile).

[inim]

The many threads you see are created by javax.sound.sampled.Clip, which is used to play sounds. All Clip Objects are created and each seems to make the JVM create an idle thread waiting to play them. Technically speaking it is Oracle's problem to make this all thread safe, I do not start a single thread of those in my own code.

That said, there are sound problems with recent Linux versions as well, so probably a review of the Sound class makes sense. I would happily accept help here, just send an email to inimfibs<nospam_insert_at_sign>gmail.com and i can send you the (fortunately self contained) code of that class. I can do that because this is 100% inim code, so Peter can impossibly have (c) issues with it.