This content has been marked as final. Show 40 replies
The gcc 3.3 compiler does come with the new 4.x compiler in the Xcode download, but isn't installed by default. You can go back to the installer and click on the configure-button (or something like that) to choose extra options, including gcc 3.3
However, there's no gcc_select any more. But since it's only a shellscript, I just copied it over from another machine. Seems to work OK.
It is important to use gcc 3.3 : it won't work correctly if you use anything later.
I believe that I have discovered the problem in Apple's 10.5 kernel that causes the kernel panic when the Oracle server starts with "processes" larger than about 50. I've built and booted a Darwin kernel with a patch to fix the problem and was able to start Oracle with "processes=400". No kernel panic.
I've reported the problem to Apple along with a description of the cause and a solution. Hopefully Apple will patch the kernel to fix this bug for the next release. The Apple problem ID is 5574916.
The change is to the source file,
in routine semop
There is a block of code between
that is in the wrong location. It should be moved following the "if" statement that immediately follows it. That if statement checks the validity of the value of the nsops variable and Oracle apparently passes a value in the stmop_args structure which exceeds MAX_SOPS. The code between #if CONFIG_MACF and #endif uses nsops but if the value exceeds MAX_SOPS that causes the kernel panic. Moving the code between #if CONFIG_MACF and #endif after the validity check prevents the kernel panic and Oracle is able to startup successfully, in my tests.
I just tested to see if Apple fix the bug that I reported and told them what was wrong and how to fix it. I'm sorry to say that Apple did not fix the bug in 10.5.2 and the kernel still panics if processes is set to something larger than about 75.
The two bug report numbers are:
bug id 5736091 for Mac OS X 10.5.1
bug id 5574916 for Mac OS X 10.5.2
Suggest people start complaining to Apple that this bug has not been fixed. It was originally reported on November 1, 2007.
I contacted apple via my apple developer connection account to find out about this bug.
Here is their response:
Thank you for contacting us regarding the status of Bug ID# 5574916.
At this time, there isn't any new information available for this issue. I have checked with engineering, and the issue is still being investigated.
I've a Mac with OSX 10.5.1 installed on it. Now I'd like to have an Oracle database running, so I downloaded the 10g release for Mac. But well, doesn't seem to work so far.
I followed these instructions:
I'm new on Mac and 10.5.1 is my first system. I can't go back to a 10.4 installation to get stuff from there.
I'm at the point where I have to call runInstaller -> Oracle Installer opens but when I click on Next it crashes.
Does anyone know how I could proceed?
Ah, well, and one more thing. I'm running the normal OS X version. Not OS X Server... could this be a problem?
I've been able to get 10.1.0.3 running ok on Leopard with the processes set to 65, but I also reduced the job_queue_processes from 10 to 5. When I set processes to 50, I had some other problems with oracle so the change for the job_queue_processes was an attempt to reduce the overall amount of processes tied to oracle. Don't take this as anything more than a "for what it's worth", I'm not saying these are related for sure, just that by changing both I was able to have a higher value for processes.
Message was edited by:
Oh - thanks for the quick replies.
Well, I have an Intel processor. I didn't read anything on Oracle's site or in the documentation that it would run on PPC only, so wasn't aware of that.
I hope Oracle will update their release for OSX... I mean, Apple delivers Intel Macs for quite a long time now. What about all these people? Well, so the only solution for me seems to be to install a VM with Windows or Linux and install Oracle in that VM...