face_head

Just been working trying to fix this one for some weeks now , with a patch that was has been working flawlessly late last year , and had not used it untill im prepping for a tour coming in a few months , obviously there has been a heap of updates to max and osx in this time (im now on 10.12.5) but it seems something has changed , my patch is mainly dealing with reciving udp packets and sending them as midi cc and etc over to live , its a healthy patch , no issues in the max console or anything ... and working perfectly other than this issue , wich is a cold crash with no particular action being done to cause it , sometimes it crashes after 10 min sometimes after 5 hours ... with no other apps running , this only happens when patch is recieving the udp packets ...

also to mention i have tested with all versions of max from 7.3 >7.3.3 in both 32 and 64 in get info launching and also all with app nap off.

here is the latest report , they are all near identical other than one that straight up mentiones intel graphics , wich i have also pasted below.

any assistance is greatly appreciated as stress levels are currently quite high. !!!

----------------------------------------------------------------------------------------------------------------

Just been working trying to fix this one for some weeks now , with a patch that was has been working flawlessly late last year , and had not used it untill im prepping for a tour coming in a few months , obviously there has been a heap of updates to max and osx in this time (im now on 10.12.5) but it seems something has changed , my patch is mainly dealing with reciving udp packets and sending them as midi cc and etc over to live , its a healthy patch , no issues in the max console or anything ... and working perfectly other than this issue , wich is a cold crash with no particular action being done to cause it , sometimes it crashes after 10 min sometimes after 5 hours ... with no other apps running , this only happens when patch is recieving the udp packets ... 

also to mention i have tested with all versions of max from 7.3 >7.3.3  in both 32 and 64 in get info launching and also all with app nap off.

Hello every one 
Just been working trying to fix this one for some weeks now , with a patch that was has been working flawlessly late last y

max-7·3·3-crashing-crbrowsermain

other things to note ive also trashed the prefs folders Max 7 and Max 7 database , this didnt change anything, as mentioned in other forum posts ive read.

it's probably some of your externals causing this... probably... hard to say... had a problem with udp network too and was hard to track down to its origin. I think removing the saddam library helped - but i'm not sure. I tried to move a lot of different externals out of my library, even created another user account on my computer to run max from there and see if without any extension it would work.

Thanks VICHUG , in the process of removing externals for the patch now , but yes i suspect the udp receive and the other older berkely externals there are some newer versions of them in the odot libarys ... just wanto try and see if its something i can fix outside max to startwith as nothign has been touched in max since it last ran perfectly ... well at least the same issue happens across versions 7.3 - 7.3.3 ...

thanks for your help and again would greatly appreciate any assistance with what exactly the chromium library is doing ie (CrBrowserMain) in this case , as for externals , my patch has very few external librarys used in the patch mostly standard objects dealing with the midi and etc..

Thanks VICHUG , in the process of removing externals for the patch now , but yes i suspect the udp receive and the other older berkely externals there are some newer versions of them in the odot libarys ... just wanto try and see if its something i can fix outside max to startwith as nothign has been touched in max since it last ran perfectly ... well at least the same issue happens across versions 7.3 - 7.3.3 ... 

litterally OSC-route is my only external here ... ouch , gonna move to the odot , and also try literally running the patch with no routes and see how it goes simply receiving the udp packets.

Maybe someone knows wich of these use CrBrowserMain ... or something to do with this chromium library ...

as you can see im now testing with the odot o.route , the only (3rd party) external....

Externals and subpatcher files for OSC2humidi_tidy_24_10_16_inv_trackpad 3_odot:

Abstraction ctloutmidi.maxpat USER:/prince humidi/OSC2humidi/ctloutmidi.maxpat

Max Object button.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object clip.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object comment.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object cycle.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object delay.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object dial.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object gswitch.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object hi.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object jit.movie.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/jitter

Max Object jit.pwindow.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/jitter

Max Object jsui.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object kslider.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object line.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object live.guilib.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/extensions/m4l

Max Object loadmess.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object mean.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object message.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object midiflush.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object number.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object o.route.mxo Reecard Farché:/max_geek/odot/externals

Max Object onebang.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object panel.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object past.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object prepend.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object scale.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object slider.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object speedlim.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object swatch.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object textedit.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object togedge.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object toggle.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object udpreceive.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object udpsend.mxo USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Maybe someone knows wich of these use CrBrowserMain ... or something to do with this chromium library ... 

as you can see im now testing with the odot   o.route , the only (3rd party) external.... 

Abstraction    ctloutmidi.maxpat    USER:/prince humidi/OSC2humidi/ctloutmidi.maxpat

Max Object     button.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     clip.mxo            USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     comment.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     cycle.mxo            USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     delay.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     dial.mxo             USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     gswitch.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     hi.mxo               USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     jit.movie.mxo        USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/jitter

Max Object     jit.pwindow.mxo      USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/jitter

Max Object     jsui.mxo             USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     kslider.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     line.mxo             USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     live.guilib.mxo      USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/extensions/m4l

Max Object     loadmess.mxo         USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     mean.mxo             USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     message.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     midiflush.mxo        USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     number.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     o.route.mxo          Reecard Farché:/max_geek/odot/externals

Max Object     onebang.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     panel.mxo            USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     past.mxo             USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     prepend.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     scale.mxo            USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     slider.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     speedlim.mxo         USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     swatch.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     textedit.mxo         USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     togedge.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     toggle.mxo           USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     udpreceive.mxo       USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

Max Object     udpsend.mxo          USER:/Applications/Max_7.3.3.app/Contents/Resources/C74/externals/max

aside form the o.route , all objects are standard , any help at this point massivly appreciated ...

Hey i may have had those problems with the odot library. But, by saying "removing externals" i didn´t mean simply removing them from your patch, i meant removing them completely from your lax search paths/library/packages...

As for chromium : i'm not sure what it does exactlt, but afaik it does a lot of stuff low level inside max, related to networking, database managing, doc browsing etc

yes i did try completely removing from the path as you mentioned also ,the fact that the odot or osc route was the only 3rd party external in use , i started focusing on the Max Object live.guilib.mxo and removing these externals , as m4l for me in the past has generally been a nightmare , so i 1st removed the live.dials from the patch , wich then seemd to stop the crashes , and i was then able to wind the osc buffer size down to 2 from 20 that i had always run it on without dropping packets , seems the m4l externals somehow slow things down and were maybe causeing this crash , i really dont know whats going on here .....

yes i did try completely removing from the path as you mentioned also ,the fact that the odot or osc route was the only 3rd party external in use ,  i started focusing on the Max Object live.guilib.mxo  and removing these externals , as m4l for me in the past has generally been a nightmare , so i 1st removed the live.dials from the patch , wich then seemd to stop the crashes , and i was then able to wind the osc buffer size down to 2 from 20 that i had always run it on without dropping packets , seems the m4l externals somehow  slow things down and were maybe causeing this crash , i really dont know whats going on here .....

FWIW, and of absolutely no help to you, but with the intent of keeping the thread alive...

I would guess that around 80% of the crashes I get with various patchers show the crashed thread as being CRBrowserMain. Despite asking about it here several times, no-one has ever responded with any suggestions as to what that might point to. Maybe it's so broad and low level that it doesn't provide any useful diagnostic info. (I'm totally guessing as I'm operating on no information!) I'd really like to know if the CRBrowserMain crashing points towards anything in a patch that might be causing the problem, or not, as at least then I wouldn't be hoping that there was useful debug info hiding there. Either a post here, or something in the docs.

I would guess that around 80% of the crashes I get with various patchers show the crashed thread as being  CRBrowserMain. Despite asking about it here several times, no-one has ever responded with any suggestions as to what that might point to. Maybe it's so broad and low level that it doesn't provide any useful diagnostic info. (I'm totally guessing as I'm operating on no information!) I'd really like to know if the CRBrowserMain crashing points towards anything in a patch that might be causing the problem, or not, as at least then I wouldn't be hoping that there was useful debug info hiding there. Either a post here, or something in the docs.

Hey David , all good and totally agreed !!!

It seems there are quite a few mentions of CrBrowserMain on the max forums and also all over the place outside max issues , been finding posts on gaming websites and a ton on Chrome / google forums.

just continuing my searching on the forum as seems all the other threads just died with no resolutions, would be just good to close this so others can get some help here.

But as for the ones on the max forum there is really no answers from Cycling, at least letting us know , as you mentioned , that it is to low level to even point into the direction of a problem , all ive been getting from suppot to this point is , if its happening to all versions of max (as id tested from 7.3 > now, 7.3.4) then it must be an issue with your system , id have to say thats the least help ive ever had from cycling , usually they are so helpful and do absulutly anything they can to help me out , but yeah , not this time ....

would be good to find out a bit about the chromium libary and at least a little abut whats happening.

this is the best i found to try and understand what its about is this

https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/trace-event-reading

But as for the ones on the max forum there is really no answers from Cycling, at least letting us know , as you mentioned , that it is to low level to even point into the direction of a problem , all ive been getting from suppot to this point is , if its happening to all versions of max (as id tested from 7.3 > now, 7.3.4) then it must be an issue with your system , id have to say thats the least help ive ever had from cycling , usually they are so helpful and do absulutly anything they can to help me out , but yeah , not this time .... 

this is the best i found to try and understand what its about is this 

https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/trace-event-reading 

So now for what it seems is the issue with my patch.

After removing the only 3rd party external 1stly being OSC-route , then while trying to solve this i moved over to the more recent o.route , wich is the newer drop in replacement.

i started going threw the other standard library externals looking for something , the 1st ones i focused on where ui objects i used for the patch, wich were part of the live.guilib.mxo

if anyone wants to look ^ at my crash report , this one and the other 20 odd were all 99% the same , but as you can see there is some mention of graphics in the threads following the apparent crashed thread "0" , i know it mentions all open mxo's and im generally not great at reading crash reports as im a total heck , but yeah , this is the logic that made sense to me , and i just looked at things that i thought were graphics related .. ui

there was also one rougue crash report that mentioned only graphics in all the threads

here is a section of it for others ref (the complete report is above)

VM Regions Near 0:
--> 
    __TEXT                 000000000000a000-00000000007dc000 [ 8008K] r-x/rwx SM=COW  /Applications/Max_7.3.3.app/Contents/MacOS/Max

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   com.apple.CoreGraphics            0x948c810e x_malloc + 28
1   com.apple.CoreGraphics            0x94994265 aa_new_edge + 44
2   com.apple.CoreGraphics            0x9498f476 aa_add_edges + 353
3   com.apple.CoreGraphics            0x9498f2f3 aa_lineto + 588
4   com.apple.CoreGraphics            0x9499a46d ripr_path_fill + 105
5   com.apple.CoreGraphics            0x949d94a8 (anonymous namespace)::adaptor::callback(void*, CGPathElementType, CGPoint const*) + 108
6   com.apple.CoreGraphics            0x94b0fdc0 CG::Chunk::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 40
7   com.apple.CoreGraphics            0x946cb194 CG::Path::Subpath::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 46
8   com.apple.CoreGraphics            0x94733a64 CG::Path::Sequence::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 36
9   com.apple.CoreGraphics            0x948c452c CG::Path::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 26
10  com.apple.CoreGraphics            0x949d92fb CGPathApply + 93
11  com.apple.CoreGraphics            0x949999f9 RIPRenderPath + 184
12  com.apple.CoreGraphics            0x94704128 ripc_DrawPath + 217
13  com.apple.CoreGraphics            0x949353e5 CGContextDrawPath + 184
14  com.apple.CoreGraphics            0x94935534 CGContextFillPath + 19


the 1st one i went for was the live.dial , as in the past when i was using m4l they usedto give me a ton of issues when i had them in pop out windows and all kind of sluggish issues with ui wich lead to audio buffer noise and all kinds of weird issues.

these we being used puerly for asthetics .... along with a few other live. objects like the buttons and text etc.

i just replaced ONLY the live.dial with int objects and now after all this the patch now runs perfectly again on max 7.3 > 7.3.4 32 nd 64

Not sure if there is some issue with those live.dial , for me they have caused so many probelems over the years.

i started going threw the other standard library externals looking for something , the 1st ones i focused on where ui objects i used for the patch, wich were part of the live.guilib.mxo 

VM Regions Near 0:
--> 
    __TEXT                 000000000000a000-00000000007dc000 [ 8008K] r-x/rwx SM=COW  /Applications/Max_7.3.3.app/Contents/MacOS/Max

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   com.apple.CoreGraphics        	0x948c810e x_malloc + 28
1   com.apple.CoreGraphics        	0x94994265 aa_new_edge + 44
2   com.apple.CoreGraphics        	0x9498f476 aa_add_edges + 353
3   com.apple.CoreGraphics        	0x9498f2f3 aa_lineto + 588
4   com.apple.CoreGraphics        	0x9499a46d ripr_path_fill + 105
5   com.apple.CoreGraphics        	0x949d94a8 (anonymous namespace)::adaptor::callback(void*, CGPathElementType, CGPoint const*) + 108
6   com.apple.CoreGraphics        	0x94b0fdc0 CG::Chunk::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 40
7   com.apple.CoreGraphics        	0x946cb194 CG::Path::Subpath::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 46
8   com.apple.CoreGraphics        	0x94733a64 CG::Path::Sequence::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 36
9   com.apple.CoreGraphics        	0x948c452c CG::Path::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const + 26
10  com.apple.CoreGraphics        	0x949d92fb CGPathApply + 93
11  com.apple.CoreGraphics        	0x949999f9 RIPRenderPath + 184
12  com.apple.CoreGraphics        	0x94704128 ripc_DrawPath + 217
13  com.apple.CoreGraphics        	0x949353e5 CGContextDrawPath + 184
14  com.apple.CoreGraphics        	0x94935534 CGContextFillPath + 19


i just replaced ONLY the live.dial  with int objects and now after all this the patch now runs perfectly again on max 7.3 > 7.3.4 32 nd 64 

p.s would e great if a higher power could maybe explain what was happening here ...

just chiming in to +1 David E. Stevens, would be nice to have more pointers about that mysterious crbrowsermain :)

also glad to hear your problem is solved :)

i'm experiencing the same crbrowsermain crash in the project i'm developing right now.

Have you found an explanation or possible solution to it?

it's a pity there's no c74 explanation or communication in the forums for this....

Hello Face_head,
i'm experiencing the same crbrowsermain crash in the project i'm developing right now.

Have you found an explanation or possible solution to it?

Sorry playmodes , all i have for you is the above ...

like i mentioned there the thing that was causing this for me was the live.dial i removed these from my ui and the issue has never happened again , if i was you id remove any of the live.guilib.mxo objects , if you have them in your patch , but yeah , sadly cycling dont wanto say anything about this.

Sorry playmodes , all i have for you is the above ...
like i mentioned there the thing that was causing this for me was the live.dial i removed these from my ui and the issue has never happened again , if i was you id remove any of the live.guilib.mxo objects , if you have them in your patch , but yeah , sadly cycling dont wanto say anything about this.

good luck


actually, i have a good bunch of live.dial... i'm going to try if replacing by native max gui objects solves the issue

maybe post your results here and send a mail through to support so they have a look at it !!

.....
ill put money on them as the cause ;)
maybe post your results here and send a mail through to support so they have a look at it !!
Best !

Experiencing the same still - Version 8.1.3 (da28f19) (64-bit mac)

this is a very old issue, but sa mentioned above, just dont use anything from live.guilib.mxo 

Hey ALEX, 
this is a very old issue, but sa mentioned above, just dont use anything from live.guilib.mxo 
none of the M4l Ui stuff...
hope you sort it out

if you find anything new maybe add it here, i also would be interested and im sure there are many others

This is happening for me in quite a big and complex patch, but I've been able to reduce the occurrences by taking very close care of my initialization routine, making sure objects aren't accessed/triggered while they're being instantiated.

This not a definite fix but, in my case, it got me closer to a crash-free opening of the main patch (that includes all the content/sub-patchers).

EDIT: I advise to also check any recursive or throttled tasks that use async updaters internally, for me, a big issue was simply a umenu being populated while some other objects were still allocating memory for initialization.

EDIT: I advise to also check any recursive or throttled tasks that use async updaters internally, for me, a big issue was simply a umenu being populated while some other objects were still allocating memory for initialization.
Hope this helps! :)

Hi, just FYI I experienced the same crash, with the same Max 7. Bizarrely, somehow an alias of my entire HD was generated and saved in the Max project folder I happened to be working in, with system files scattered about between the normal patcher, code and media folders. Once I cleaned that out, Max worked fine again. Very weird though.

max 7.3.3 crashing CrBrowserMain