It seems that all of the models I\'ve downloaded have failed with a client error. Most of these are of the type:

<core_client_version>4.44</core_client_version>
<message>process got signal 10
</message>
<stderr_txt>
MacOS Error -43 occured in Mac_Lib.c line 64
MacOS Error -43 occured in Mac_Lib.c line 64

</stderr_txt>

but there are also errors like:

<core_client_version>4.44</core_client_version>
<message>process exited with code 251 (0xfb)
</message>
<stderr_txt>

</stderr_txt>

I assume from this there is something wrong and I wonder if anyone can suggest how I might fix

Computer Dual 2 GHz G5, OS 10.4.2 Boinc client boinc_4.44ppcALL compiled from MacNNN

Many thanks,

Craig

---

I also have this problem. Running 4.43 superbench menubar client on OS X 10.3.9

After a few weeks, and checking my results, all came back with client error. So I detached from the project. Then I read all the posts about the Mac library add on. I\'ve since made sure the 3 files (like libxlfmath.A.dylib) are in opt>imbcmp>lib and reattached. Since reattaching CP is still returning client errors. What gives, eh?

---

G5 dual 2GHz OSX 10.3.9
G4 dual 867MgHz OSX 10.4.3

I don\'t know the answers to your problems, but it seems that Mac\'s just aren\'t very good at this project.
And there aren\'t many Mac people here, or at any of the other projects, so there is very little informed help available.
It may be something simple and easily fixed, but we may never know.

You could try the MacNN site <a href=\"http://www.macnn.com/\"> here,</a> and their forums <a href=\"http://forums.macnn.com/index.php?s=5482afae064f14a324cd0662cda87923&\"> here.</a>

There seems to be a problem running the climateprediction.net application on dual-processor G5 Macs; it appears to have a concurrency error of some kind. There doesn\'t seem to be much interest in diagnosing or fixing the problem.

I\'d like to participate but at this point the application just doesn\'t work on some Mac models.

If you\'re seeing problems on a machine that does not have a dual processor, then it could be something else. All my non-DP machines seem to be running climateprediction.net just fine.

---

There seems to be a problem running the climateprediction.net application on dual-processor G5 Macs; it appears to have a concurrency error of some kind. There doesn\'t seem to be much interest in diagnosing or fixing the problem.

I\'d like to participate but at this point the application just doesn\'t work on some Mac models.

If you\'re seeing problems on a machine that does not have a dual processor, then it could be something else. All my non-DP machines seem to be running climateprediction.net just fine.

This problem turns up on both DP and SP machines so that doesn\'t seem to be the cause.

I guess if there is no fix for this I may as well detach from this project since I\'m presumably adding nothing to their work.

---

If one looks at the stats for \"Hosts by CPU brand\" and \"Hosts by Operating System\"
on BOINCstats for any project, it shows about 2%.

cpdn has 2 programmers, and only a portable Mac to use for developing software.
The source code is over 50Megs in size, and over a million lines long.

With Intel/AMD being used by over 90% of users, this is where the development effort has to go to be cost effective.

If Mac users can convince 10-20 thousand more Mac users to join distributed computing projects, the Uni boards may grant more resources to support the Mac.
And the other machines, like Sparcs, etc.

Sorry to be a wet blanket, but that\'s how it is.

If one looks at the stats for \"Hosts by CPU brand\" and \"Hosts by Operating System\"
on BOINCstats for any project, it shows about 2%.

cpdn has 2 programmers, and only a portable Mac to use for developing software.
The source code is over 50Megs in size, and over a million lines long.

With Intel/AMD being used by over 90% of users, this is where the development effort has to go to be cost effective.

If Mac users can convince 10-20 thousand more Mac users to join distributed computing projects, the Uni boards may grant more resources to support the Mac.
And the other machines, like Sparcs, etc.

Sorry to be a wet blanket, but that\'s how it is.

I understand your position but I don\'t quite see how you\'re going to persuade 10-20 thousand users to adopt some software that doesn\'t work. Perhaps it would be better to make it clear that the Macintosh platform is not supported and leave it at that.

---

BUMP... still looking for an answer

---

G5 dual 2GHz OSX 10.3.9
G4 dual 867MgHz OSX 10.4.3

You could try the new 5.2.5 version of BOINC and see what happens.

You could try the new 5.2.5 version of BOINC and see what happens.

I have changed to the new version and have this error (Error in Mac_Lib.c line 64) since then!
Before It worked with my iMac G5. So what changed in the project files?

---

For what it is worth, I\'ve detached from Climate Prediction and now run Seti, Predictor and Rosetta projects on my computers with none of the problems noted here.

I assume they have the same mix of Mac and Intel/AMD clients as Climate Prediction, although on reflection, they probably have more (for the obvious reason).

---

You can see the mix of computers / os / cpus <a href=\"http://www.boincstats.com/\"> here</a> under \"project stats\" for each project.

I am having this issue as well; Looks like the process is getting signal 10. I poked around in the crash logs and found this:

Host Name:      Pandora
Date/Time:      2005-11-05 20:16:44.585 -0500
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: sulphur_4.21_powerpc-apple-darwin
Path:    ../../projects/climateprediction.net/sulphur_4.21_powerpc-apple-darwin
Parent:  boinc [23790]

Version: ??? (???)

PID:    25207
Thread: 1

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000ab0

Thread 0:
0   libSystem.B.dylib              	0x9000b208 mach_msg_trap + 8
1   libSystem.B.dylib              	0x9000b15c mach_msg + 60
2   com.apple.CoreFoundation       	0x9075d108 __CFRunLoopRun + 832
3   com.apple.CoreFoundation       	0x9075ca0c CFRunLoopRunSpecific + 268
4   com.apple.HIToolbox            	0x931831e0 RunCurrentEventLoopInMode + 264
5   com.apple.HIToolbox            	0x93182874 ReceiveNextEventCommon + 380
6   com.apple.HIToolbox            	0x931826e0 BlockUntilNextEventMatchingListInMode + 96
7   com.apple.AppKit               	0x93680904 _DPSNextEvent + 384
8   com.apple.AppKit               	0x936805c8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
9   com.apple.glut                 	0x97bbe0c4 -[GLUTApplication _runMainLoopUntilDate:autoreleasePool:] + 72
10  com.apple.glut                 	0x97bbe26c -[GLUTApplication run] + 280
11  com.apple.glut                 	0x97bce954 glutMainLoop + 164
12  ...r_4.21_powerpc-apple-darwin 	0x0004d5ec xwin_graphics_event_loop() + 344 (x_opengl.C:460)
13  ...r_4.21_powerpc-apple-darwin 	0x0004c9bc boinc_init_options_graphics_impl + 84 (graphics_impl.C:168)
14  ...r_4.21_powerpc-apple-darwin 	0x00004850 main + 212 (crt.c:300)
15  ...r_4.21_powerpc-apple-darwin 	0x00002d80 _start + 392 (crt.c:267)
16  dyld                           	0x8fe01048 _dyld_start + 60

Thread 1 Crashed:
0   libGL.dylib                    	0x92dff408 glDeleteTextures + 88
1   ...r_4.21_powerpc-apple-darwin 	0x0001e23c graphics_thread_cleanup + 432 (crt.c:300)
2   ...r_4.21_powerpc-apple-darwin 	0x00005a64 app_cleanup() + 36 (crt.c:300)
3   ...r_4.21_powerpc-apple-darwin 	0x00006f58 checkBOINCStatus(bool) + 228 (crt.c:300)
4   ...r_4.21_powerpc-apple-darwin 	0x000054dc mainLoop() + 76 (crt.c:300)
5   ...r_4.21_powerpc-apple-darwin 	0x00004fbc worker() + 1844 (crt.c:300)
6   ...r_4.21_powerpc-apple-darwin 	0x0004c810 foobar(void*) + 60 (graphics_impl.C:75)
7   libSystem.B.dylib              	0x9002b200 _pthread_body + 96

Thread 2:
0   libSystem.B.dylib              	0x90040258 mach_wait_until + 8
1   libSystem.B.dylib              	0x90040020 nanosleep + 384
2   libSystem.B.dylib              	0x9003fe58 sleep + 152
3   ...r_4.21_powerpc-apple-darwin 	0x0004271c boinc_sleep(double) + 64 (util.C:248)
4   ...r_4.21_powerpc-apple-darwin 	0x00040b7c timer_thread(void*) + 40 (boinc_api.C:637)
5   libSystem.B.dylib              	0x9002b200 _pthread_body + 96

Thread 1 crashed with PPC Thread State 64:
  srr0: 0x0000000092dff408 srr1: 0x000000000000d030                        vrsave: 0x0000000000000000
    cr: 0x42000422          xer: 0x0000000000000001   lr: 0x0000000092dff400  ctr: 0x0000000090008bc0
    r0: 0x0000000000007ff2   r1: 0x00000000f0080b10   r2: 0x0000000000000000   r3: 0x0000000000000000
    r4: 0x0000000000000048   r5: 0x0000000000000080   r6: 0x00000000ffffffff   r7: 0x0000000000000001
    r8: 0x00000000013162be   r9: 0x000000004ff7e000  r10: 0x0000000000000001  r11: 0x00000000a2dfc024
   r12: 0x0000000090008bc0  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x0000000000000000
   r16: 0x0000000000000000  r17: 0x0000000000000000  r18: 0x0000000000000000  r19: 0x0000000000000000
   r20: 0x0000000000000000  r21: 0x0000000000000000  r22: 0x0000000000000000  r23: 0x0000000000000000
   r24: 0x0000000001205000  r25: 0x0000000001205000  r26: 0x000000000033e094  r27: 0x00000000a2dfc004
   r28: 0x0000000000000001  r29: 0x0000000000381260  r30: 0x00000000f0080b10  r31: 0x0000000092dff3b8

The screensaver is broken?

I\'ve seen from my log that each process gets a signal 10, which correlates to a \"client error\" in my results. I did get a bit of a trickle, but the client errors are steady. I\'ve tried asking the guys over at Team MacNN too. Still looking for an answer... anyone?

---

G5 dual 2GHz OSX 10.3.9
G4 dual 867MgHz OSX 10.4.3

See the thread \"Stack overflow/SIGBUS\" in this forum. I believe that this is a problem that only occurs on multiprocessor machines. If anyone knows of this happening on a single-processor machine, please speak up.

I\'ve tried repeatedly to contact the developers to help track it down, but with no success. My speculation is that this is a concurrency error due to the \"weak\" memory model of the PowerPC processor (meaning that reads and writes to main memory can appear out of order between the two processors on a multiprocessor system). Code that runs fine on Intel multiprocessor systems (which have a \"strong\" memory model) often crashes on PowerPC multiprocessors. The fix is to use appropriate concurrency controls (mutex, atomic instructions, etc.) when accessing shared memory.

---

See the thread \"Stack overflow/SIGBUS\" in this forum. I believe that this is a problem that only occurs on multiprocessor machines. If anyone knows of this happening on a single-processor machine, please speak up.

I have got the problem on my iMac G5 which has only one single core processor. After resetting work my computer is now crunching again. It looks like the sulphur models are the main problem.

---

The project team have acquired a dual G5. They\'re expecting to take delivery in a couple of weeks.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

The project team have acquired a dual G5. They\'re expecting to take delivery in a couple of weeks.

That\'s great news! I think I\'ll detach from this project until further notice (since I\'m running 6 BOINC projects). Maybe someday all projects will have optimized clients as well (like SETI and Einstein).

---

G5 dual 2GHz OSX 10.3.9
G4 dual 867MgHz OSX 10.4.3

[/quote]

I understand your position but I don\'t quite see how you\'re going to persuade 10-20 thousand users to adopt some software that doesn\'t work. Perhaps it would be better to make it clear that the Macintosh platform is not supported and leave it at that.
[/quote]


I agree with you. At the moment I\'m running a cpdn-sulphur model and einstein@home at the same time (50 : 50) on my Power Mac G5 1,8 Ghz Single FSB 600. Let\'s wait for some more weeks, so that the programmers can search for the bug. As far as I know the source code for Linux is very similar to the MacOSX-version.
Besides of that cpdn is the only project that crashes regularly while running on my G5. seti@home, einstein@home and rosetta@home don‘t have any problems.

If the programmers need machines for testing a new MacOSX-client they should send an email to the users. Thus the beta-testers wouldn\'t become frustrated about so many crashing models and detach from project.

---

I had a result 10 days working. Then again Signal 10.
But now the new sulphur 4.22 is doing here. Lets see if that is doing better!

Greetings, Uwe

---