selalou10@yahoo.com

Is anyone else encountering this? I am using a MacPro quad 3.0 and os x 10.4.9 . I brought my system software completely up to date before installing max.

Pretty much without fail, I will encounter a kernal panic anywhere from 10minutes to an hour after i start creating a patch. I havnt been doing anything complicated and the patches ive been using lately have been tiny in size.

Please help! I cant stand not feeling 'safe' while working in max/MSP. its breaking my heart. :-( .

I have all the crash.log files and panic.log files from the crashes as of late. please let me know if you'd like to see them.

Is anyone else encountering this?  I am using a MacPro quad 3.0 and os x 10.4.9   .  I brought my system software completely up to date before installing max.  

Pretty much without fail, I will encounter a kernal panic anywhere from 10minutes to an hour after i start creating a patch.  I havnt been doing anything complicated and the patches ive been using lately have been tiny in size.

Please help!  I cant stand not feeling 'safe' while working in max/MSP.  its breaking my heart.  :-( .

I have all the crash.log files and panic.log files from the crashes as of late.   please let me know if you'd like to see them.

frequent-kernel-panic-4-6-3-and-4-6-2-macintel

It's pretty doubtful that MaxMSP is the actual culprit here. Usually

this sort of thing is caused by bad device drivers or a problem on the

Are you using any external audio devices?

At one point I was using a USB microphone that would cause frequent

kernel panics. I think the drivers were buggy. You might have a look

at the logs to see if it lists where the OS crash was caused.

You might also post them here for us to see as well.

> Is anyone else encountering this? I am using a MacPro quad 3.0 and os x 10.4.9 . I brought my system software completely up to date before installing max. 

> Pretty much without fail, I will encounter a kernal panic anywhere from 10minutes to an hour after i start creating a patch. I havnt been doing anything complicated and the patches ive been using lately have been tiny in size.

> Please help! I cant stand not feeling 'safe' while working in max/MSP. its breaking my heart. :-( .

> I have all the crash.log files and panic.log files from the crashes as of late. please let me know if you'd like to see them.

Hi Seth,
It's pretty doubtful that MaxMSP is the actual culprit here.  Usually
this sort of thing is caused by bad device drivers or a problem on the
OS level.

Are you using any external audio devices?
At one point I was using a USB microphone that would cause frequent
kernel panics.  I think the drivers were buggy.  You might have a look
at the logs to see if it lists where the OS crash was caused.

Cheers,
Andrew B.
seth wrote:
> Is anyone else encountering this?  I am using a MacPro quad 3.0 and os x 10.4.9   .  I brought my system software completely up to date before installing max.  
>
> Pretty much without fail, I will encounter a kernal panic anywhere from 10minutes to an hour after i start creating a patch.  I havnt been doing anything complicated and the patches ive been using lately have been tiny in size.
>
> Please help!  I cant stand not feeling 'safe' while working in max/MSP.  its breaking my heart.  :-( .
>
> I have all the crash.log files and panic.log files from the crashes as of late.   please let me know if you'd like to see them.
>
>
> thanks
> -seth
>
>


> Is anyone else encountering this? I am using a MacPro quad 3.0 and 

> os x 10.4.9 . I brought my system software completely up to date 

> Pretty much without fail, I will encounter a kernal panic anywhere 

> from 10minutes to an hour after i start creating a patch.

If you're experiencing kernel panic, the two first things to look 

Since Max is a user space application, we shouldn't be able to cause 

kernel panics directly. So it pretty much has to be a driver, OS, or 

> Is anyone else encountering this?  I am using a MacPro quad 3.0 and  
> os x 10.4.9   .  I brought my system software completely up to date  
> before installing max.
>
> Pretty much without fail, I will encounter a kernal panic anywhere  
> from 10minutes to an hour after i start creating a patch.

If you're experiencing kernel panic, the two first things to look  
into are:

Since Max is a user space application, we shouldn't be able to cause  
kernel panics directly. So it pretty much has to be a driver, OS, or  
hardware problem.

Hey guys. thanks for the help so far. I am going to look at the logs. Im not sure id be able to figure out much myself as the logs read like sanskrit to me. But im definitely going to try.

Here are the logs attached as a zipped file.

Hey guys.  thanks for the help so far.  I am going to look at the logs.  Im not sure id be able to figure out much myself as the logs read like sanskrit to me.  But im definitely going to try.

I was using a single channel USB in/out interface (Edirol AudioCapture UA-1A) as my audio device. I have disconnected that now, and will see if im still getting those panics.

I was using a single channel USB in/out interface (Edirol AudioCapture UA-1A) as my audio device.  I have disconnected that now, and will see if im still getting those panics.


I disconnected the USB audio interface and am using my built-in line out to avoid any possible bad drivers.

After a restart, I opened Max/MSP. THen i opened the project that i was working on when i last had this kernel panic. INSTANT Kernel panic again!! Hot damn!

I am begininning to think it has something to do with tapin~, or my use of tapin~. I am always working on a patch that uses tapin~ tapout~.

I also noticed that there is a reference to the tapin~ object in the crash reports.... hmmmm.

After a restart, I opened Max/MSP.  THen i opened the project that i was working on when i last had this kernel panic.  INSTANT Kernel panic again!!  Hot damn! 

I am begininning to think it has something to do with tapin~, or my use of tapin~.  I am always working on a patch that uses tapin~ tapout~.

I also noticed that there is a reference to the tapin~ object in the crash reports.... hmmmm.


> I am begininning to think it has something to do with tapin~, or my 

> use of tapin~. I am always working on a patch that uses tapin~ 

> I also noticed that there is a reference to the tapin~ object in 

Please clarify. You have a CRASH? or a kernel panic? They are two 

different things. The latter freezes your whole computer and means 

you need to restart. If this is the issue, then I would suggest 

If the former, provide illustrative patch with crash logs...

> I am begininning to think it has something to do with tapin~, or my  
> use of tapin~.  I am always working on a patch that uses tapin~  
> tapout~.
>
> I also noticed that there is a reference to the tapin~ object in  
> the crash reports.... hmmmm.

Please clarify. You have a CRASH? or a kernel panic? They are two  
different things. The latter freezes your whole computer and means  
you need to restart. If this is the issue, then I would suggest  
checking out the RAM.

kernel panic. This is for sure a kernal panic. The screens go out for a second, then one turns back on with the grey box stating, "You must restart your computer.... blah blah".

I do have 2GB of OtherWorldComputing RAM installed in my mac. Ive never had a problem with it though, before the last two weeks, and ive had this mac since march. So i guess i should try to remove the 3rd party ram and run the troublesome patches.

I have noticed that so long as im not working with the tapin tapout objects, i do not get the kernal panic.

I imagine, however, that even once i remove the 3rd party ram, opening one of the patches that 'caused' the panic earlier will 'cause' it again. BUt im going to try anyway. will post results...

Joshua- I have posted both the max/MSP crash log file and the panic.log file in a previous post.

kernel panic.  This is for sure a kernal panic.  The screens go out for a second, then one turns back on with the grey box stating, "You must restart  your computer.... blah blah".

I do have 2GB of OtherWorldComputing RAM installed in my mac.  Ive never had a problem with it though, before the last two weeks, and ive had this mac since march.  So i guess i should try to remove the 3rd party ram and run the troublesome patches.

I have noticed that so long as im not working with the tapin tapout objects, i do not get the kernal panic.  

I imagine, however, that even once i remove the 3rd party ram, opening one of the patches that 'caused' the panic earlier will 'cause' it again.  BUt im going to try anyway.  will post results... 

Joshua-  I have posted both the max/MSP crash log file and the panic.log file in a previous post. 

> Joshua- I have posted both the max/MSP crash log file and the 

Crash log seems to be happening when reallocating the tapin/tapout 

memory. What if you don't resize your tapin/tapout size and just use 

a maximum size? We can look at fixing any issues you have if you 

provide us a stripped down version of your tapin/tapout example which 

crashes, and try to fix them in a future release, but for now, not 

changing the tapin/tapout size while audio is on should be acceptable 

to your application and eliminate that crash.

I have no idea if that crash is related to the kernel panic however. 

Kernel Panic looks like it's happening in the graphics card driver. 

It is actually possible that we could be corrupting user space 

application memory that then gets passed to the graphics card driver 

which can't handle it properly (but one would hope that the driver 

would be more robust than this). So that's one way we could be 

responsible for kernel panics that I kind of brushed off in my mail. 

If that's the issue, sorry for seeming like there was no way it could 

So I'd try the suggested fix first, and only do the RAM diagnostics 

> Joshua-  I have posted both the max/MSP crash log file and the  
> panic.log file in a previous post.

Crash log seems to be happening when reallocating the tapin/tapout  
memory. What if you don't resize your tapin/tapout size and just use  
a maximum size? We can look at fixing any issues you have if you  
provide us a stripped down version of your tapin/tapout example which  
crashes, and try to fix them in a future release, but for now, not  
changing the tapin/tapout size while audio is on should be acceptable  
to your application and eliminate that crash.

I have no idea if that crash is related to the kernel panic however.  
Kernel Panic looks like it's happening in the graphics card driver.  
It is actually possible that we could be corrupting user space  
application memory that then gets passed to the graphics card driver  
which can't handle it properly (but one would hope that the driver  
would be more robust than this). So that's one way we could be  
responsible for kernel panics that I kind of brushed off in my mail.  
If that's the issue, sorry for seeming like there was no way it could  
be our fault.

So I'd try the suggested fix first, and only do the RAM diagnostics  
if you still get the kernel panics.

THANK YOU!!!! I had no idea how to interpret those logs!!! THis is very interesting news.

Thanks for your help. I'll keep you posted.

Here is the stripped down version of the patch thats been causing all the trouble... And yes, I had been frequently resizing the tapin~ memory.

THANK YOU!!!!  I had no idea how to interpret those logs!!!  THis is very interesting news.

Thanks for your help.  I'll keep you posted.

> THANK YOU!!!! I had no idea how to interpret those logs!!! THis 

When Max crashes, check out the crash log (~/Library/Logs/ 

CrashReporter on OS X, unavailable on XP). Look at the topmost entry, 

and the portion which reads "Thread N crashed". The top portion of 

that call stack will give you a clue. If it says "counter_bang", then 

the crash happened inside of the counter object's bang method. 

Sometimes crash logs are misleading, but this might help. Here's a 

nice tutorial on reading crash logs from MacFixIt:

http://www.macfixit.com/article.php?story=20060309075929717

For your kernel panic, the clue that it might be the graphics card is 

"Kernel loadable modules in backtrace (with dependencies):

dependency: com.apple.iokit.IOPCIFamily(2.2)@0x5ed000

dependency: com.apple.iokit.IOGraphicsFamily(1.4.5) 

dependency: com.apple.iokit.IONDRVSupport(1.4.5)@0x6da000

dependency: com.apple.NVDAResman(4.5.2)@0x6e9000"

> THANK YOU!!!!  I had no idea how to interpret those logs!!!  THis  
> is very interesting news.

When Max crashes, check out the crash log (~/Library/Logs/ 
CrashReporter on OS X, unavailable on XP). Look at the topmost entry,  
and the portion which reads "Thread N crashed". The top portion of  
that call stack will give you a clue. If it says "counter_bang", then  
the crash happened inside of the counter object's bang method.  
Sometimes crash logs are misleading, but this might help. Here's a  
nice tutorial on reading crash logs from MacFixIt:
http://www.macfixit.com/article.php?story=20060309075929717

For your kernel panic, the clue that it might be the graphics card is  
the following:

"Kernel loadable modules in backtrace (with dependencies):
          com.apple.GeForce(4.5.2)@0x8e5000
             dependency: com.apple.iokit.IOPCIFamily(2.2)@0x5ed000
             dependency: com.apple.iokit.IOGraphicsFamily(1.4.5) 
@0x6bf000
             dependency: com.apple.iokit.IONDRVSupport(1.4.5)@0x6da000
             dependency: com.apple.NVDAResman(4.5.2)@0x6e9000"

frequent kernel panic 4.6.3 and 4.6.2. MacIntel