zipb

I've a huge MaxMSP Runtime crashlog, all with the same crash. It 

looks like regexp is the culprit. Is anyone able to shed some more 

light on the crash and possible causes/suspect objects?

Path: /Applications/MaxMSP461/MaxMSP.app/Contents/MacOS/MaxMSP 

Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000009

0 com.cycling74.regexp     0x04ab4720 check_re + 852 

1 com.cycling74.regexp     0x04ab42c0 regexp_anything + 448 

2 com.cycling74.MaxMSPRuntime46     0x000217a0 typedmess_fun + 1164 

3 com.cycling74.MaxMSPRuntime46     0x000a5348 outlet_anything + 212 

4 com.cycling74.MaxMSPRuntime46     0x000217a0 typedmess_fun + 1164 

5 com.cycling74.MaxMSPRuntime46     0x000224a8 aeval + 964 (message.c: 

6 com.cycling74.MaxMSPRuntime46     0x000071d4 atombuf_eval + 120 

7 com.cycling74.MaxMSPRuntime46     0x000a4a40 outlet_bang + 216 

8 com.cycling74.MaxMSPRuntime46     0x000a4a40 outlet_bang + 216 

9 com.cycling74.MaxMSPRuntime46     0x0007dba4 trigger_iterate 

(unpack*, long, double, symbol*, symbol*, short, atom*, short) + 504 

10 com.cycling74.MaxMSPRuntime46     0x0007de24 trigger_bang(unpack*) 

11 com.cycling74.MaxMSPRuntime46     0x0002196c typedmess_fun + 1624 

12 com.cycling74.MaxMSPRuntime46     0x000a5348 outlet_anything + 212 

13 com.cycling74.MaxAPI     0x0100ba48 outlet_atoms + 88 

14 com.cycling74.jsui     0x05736224 jsthis_outlet + 220 

15 com.cycling74.MaxJSRef     0x057793c0 js_Invoke + 1788 

16 com.cycling74.MaxJSRef     0x057766b0 js_Interpret + 28644 

17 com.cycling74.MaxJSRef     0x05779404 js_Invoke + 1856 

18 com.cycling74.MaxJSRef     0x05779624 js_InternalInvoke + 

19 com.cycling74.MaxJSRef     0x0574bcc4 JS_CallFunctionName + 

20 com.cycling74.jsui     0x0573a33c js_calljsfun + 1192 

21 com.cycling74.jsui     0x0573a8a0 jsui_drag + 196 

22 com.cycling74.MaxMSPRuntime46     0x000105f8 max_dragguts + 252 

23 com.cycling74.MaxMSPRuntime46     0x00010684 max_dodrag + 60 

I've a huge MaxMSP Runtime crashlog, all with the same crash. It  
looks like regexp is the culprit. Is anyone able to shed some more  
light on the crash and possible causes/suspect objects?

Host Name:      G5-studio-2
Date/Time:      2007-02-21 14:15:01.001 +0100
OS Version:     10.4.8 (Build 8L127)
Report Version: 4

Command: MaxMSP Runtime
Path:    /Applications/MaxMSP461/MaxMSP.app/Contents/MacOS/MaxMSP  
Runtime
Parent:  WindowServer [60]

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

Thread 0 Crashed:
0   com.cycling74.regexp           	0x04ab4720 check_re + 852  
(bundle1.s:283)
1   com.cycling74.regexp           	0x04ab42c0 regexp_anything + 448  
(bundle1.s:283)
2   com.cycling74.MaxMSPRuntime46  	0x000217a0 typedmess_fun + 1164  
(message.c:631)
3   com.cycling74.MaxMSPRuntime46  	0x000a5348 outlet_anything + 212  
(inletoutlet.c:960)
4   com.cycling74.MaxMSPRuntime46  	0x000217a0 typedmess_fun + 1164  
(message.c:631)
5   com.cycling74.MaxMSPRuntime46  	0x000224a8 aeval + 964 (message.c: 
1062)
6   com.cycling74.MaxMSPRuntime46  	0x000071d4 atombuf_eval + 120  
(atombuf.c:235)
7   com.cycling74.MaxMSPRuntime46  	0x000a4a40 outlet_bang + 216  
(inletoutlet.c:654)
8   com.cycling74.MaxMSPRuntime46  	0x000a4a40 outlet_bang + 216  
(inletoutlet.c:654)
9   com.cycling74.MaxMSPRuntime46  	0x0007dba4 trigger_iterate 
(unpack*, long, double, symbol*, symbol*, short, atom*, short) + 504  
(trigger.c:85)
10  com.cycling74.MaxMSPRuntime46  	0x0007de24 trigger_bang(unpack*)  
+ 60 (trigger.c:146)
11  com.cycling74.MaxMSPRuntime46  	0x0002196c typedmess_fun + 1624  
(message.c:694)
12  com.cycling74.MaxMSPRuntime46  	0x000a5348 outlet_anything + 212  
(inletoutlet.c:960)
13  com.cycling74.MaxAPI           	0x0100ba48 outlet_atoms + 88  
(icplusplus.c:28)
14  com.cycling74.jsui             	0x05736224 jsthis_outlet + 220  
(bundle1.s:283)
15  com.cycling74.MaxJSRef         	0x057793c0 js_Invoke + 1788  
(icplusplus.c:28)
16  com.cycling74.MaxJSRef         	0x057766b0 js_Interpret + 28644  
(icplusplus.c:28)
17  com.cycling74.MaxJSRef         	0x05779404 js_Invoke + 1856  
(icplusplus.c:28)
18  com.cycling74.MaxJSRef         	0x05779624 js_InternalInvoke +  
200 (icplusplus.c:28)
19  com.cycling74.MaxJSRef         	0x0574bcc4 JS_CallFunctionName +  
84 (icplusplus.c:28)
20  com.cycling74.jsui             	0x0573a33c js_calljsfun + 1192  
(bundle1.s:283)
21  com.cycling74.jsui             	0x0573a8a0 jsui_drag + 196  
(bundle1.s:283)
22  com.cycling74.MaxMSPRuntime46  	0x000105f8 max_dragguts + 252  
(dragging.c:109)
23  com.cycling74.MaxMSPRuntime46  	0x00010684 max_dodrag + 60  
(dragging.c:78)
24  com.cycling74.MaxMSPRuntime46  	0x0001c0fc app_eventhandler 
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1552 (main.c: 
1630)
25  com.apple.HIToolbox            	0x93204554 DispatchEventToHandlers 
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
26  com.apple.HIToolbox            	0x93203cac  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 372
27  com.apple.HIToolbox            	0x9320aa60 SendEventToEventTarget  
+ 40
28  com.apple.HIToolbox            	0x93296d48  
HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned  
short) + 236
29  com.apple.HIToolbox            	0x932962c0 HandleMouseEvent 
(OpaqueEventRef*) + 368
30  com.apple.HIToolbox            	0x9320adcc  
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,  
OpaqueEventRef*, void*) + 496
31  com.apple.HIToolbox            	0x932047a4 DispatchEventToHandlers 
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
32  com.apple.HIToolbox            	0x93203cac  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 372
33  com.apple.HIToolbox            	0x9320aa60 SendEventToEventTarget  
+ 40
34  com.apple.HIToolbox            	0x9324b7a0 ToolboxEventDispatcher  
+ 92
35  com.apple.HIToolbox            	0x9324b72c HLTBEventDispatcher + 16
36  com.apple.HIToolbox            	0x93249ce4  
RunApplicationEventLoop + 148
37  com.cycling74.MaxMSPRuntime46  	0x0001b774 app_run + 72 (main.c: 
1458)
38  com.cycling74.MaxMSPRuntime46  	0x0001ba6c main + 744 (main.c:415)
39  com.cycling74.MaxMSPRuntime46  	0x00001ef0 _start + 340 (crt.c:272)
40  com.cycling74.MaxMSPRuntime46  	0x00001d98 start + 60


help-with-interpreting-crashlog

What's with the sudden regexp freakout these days? OK, I'll look at 

it. Do you have the re and input string that caused this?

Am 21.02.2007 um 22:01 schrieb Zip Boterbloem:

> I've a huge MaxMSP Runtime crashlog, all with the same crash. It 

> looks like regexp is the culprit. Is anyone able to shed some more 

> light on the crash and possible causes/suspect objects?

What's with the sudden regexp freakout these days? OK, I'll look at  
it. Do you have the re and input string that caused this?

> I've a huge MaxMSP Runtime crashlog, all with the same crash. It  
> looks like regexp is the culprit. Is anyone able to shed some more  
> light on the crash and possible causes/suspect objects?


Thanks for your prompt reply. Is it 100%(well, fairly) sure from the 

log it is the regexp object that is crashing, not something else?

Anyway, I've started replacing the regexp object with JS stuff. More 

work than I thought. The subtle differences in regexp implementations 

This is one(test to see if the ftp-server is online):

weg met de extra spaties: get rid of the extra spaces

nee, wissen: not an email address, wipe slate

Op 21-feb-2007, om 22:18 heeft Jeremy Bernstein het volgende geschreven:

> What's with the sudden regexp freakout these days? OK, I'll look at 

> it. Do you have the re and input string that caused this?

> Am 21.02.2007 um 22:01 schrieb Zip Boterbloem:

>> I've a huge MaxMSP Runtime crashlog, all with the same crash. It 

>> looks like regexp is the culprit. Is anyone able to shed some more 

>> light on the crash and possible causes/suspect objects?

Thanks for your prompt reply. Is it 100%(well, fairly) sure from the  
log it is the regexp object that is crashing, not something else?
Anyway, I've started replacing the regexp object  with JS stuff. More  
work than I thought. The subtle differences in regexp implementations  
always get me.

weg met de extra spaties: get rid of the extra spaces
nee, wissen: not an email address, wipe slate

Zip Boterbloem
Media Mechanics
Zwaluwstraat 54
2025 VR  Haarlem
The Netherlands
+31627014758
zip@knoware.nl

> What's with the sudden regexp freakout these days? OK, I'll look at  
> it. Do you have the re and input string that caused this?
>
> jb
>
> Am 21.02.2007 um 22:01 schrieb Zip Boterbloem:
>
>> I've a huge MaxMSP Runtime crashlog, all with the same crash. It  
>> looks like regexp is the culprit. Is anyone able to shed some more  
>> light on the crash and possible causes/suspect objects?
>


Sorry, I need more information. My email address doesn't crash with 

Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:

> weg met de extra spaties: get rid of the extra spaces

> nee, wissen: not an email address, wipe slate

Sorry, I need more information. My email address doesn't crash with  
this.

> weg met de extra spaties: get rid of the extra spaces
> nee, wissen: not an email address, wipe slate


Neither does mine. But we are nice, polite guys.

Users will type all sort of nasty/perverse nonsense that I want to 

Unfortunately, some of this nasty/perverse nonsense, or maybe even 

some allowable email address will crash regexp, according to my crash 

log. At least once or twice a day, which is unacceptable in an 

BTW, I've mentioned this exact problem months ago. Can't reproduce it 

easily, but it's there, I noticed it myself while speedily typing 

perverse nonsense email addresses (jay!).

Here's what happens: people type characters/letters in the message 

box by using a touchscreen. Characters are appended to the message, 

I first get rid of the extra spaces in eg z i p @ k n o w a r e . n l.

The second regexp checks for text that resembles a proper email 

address. Otherwise, wipe the message box and wait for proper input. 

Else send the email address to the next patcher.

Op 22-feb-2007, om 22:44 heeft Jeremy Bernstein het volgende geschreven:

> Sorry, I need more information. My email address doesn't crash with 

> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:

>> weg met de extra spaties: get rid of the extra spaces

>> nee, wissen: not an email address, wipe slate

Neither does mine. But we are nice, polite guys.
Users will type all sort of nasty/perverse nonsense that I want to   
block.
Unfortunately, some of this nasty/perverse nonsense, or maybe even  
some allowable email address will crash regexp, according to my crash  
log. At least once or twice a day, which is unacceptable in an  
installation, as you can imagine.
BTW, I've mentioned this exact problem months ago. Can't reproduce it  
easily, but it's there, I noticed it myself while speedily typing  
perverse nonsense email addresses (jay!).
Here's what happens: people type characters/letters in the message  
box by using a touchscreen. Characters are appended to the message,  
I  first get rid of the extra spaces in eg z i p @ k n o w a r e . n l.
The second regexp checks for text that resembles a proper email  
address. Otherwise, wipe the message box and wait for proper input.  
Else send the email address to the next patcher.

> Sorry, I need more information. My email address doesn't crash with  
> this.
>
> jb
>
> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:
>
>> weg met de extra spaties: get rid of the extra spaces
>> nee, wissen: not an email address, wipe slate
>


Yeah, here's the sad thing: I don't have all day to type perverse 

nonsense into message boxes. And although I'd really like to help 

solve this issue (I do remember this coming up before, with a more or 

less identical crash and a more or less identical email from me in 

response), I can't without a reproducable test case.

So... if this crash is as unacceptable as you say it is, you should 

be motivated to add a simple bit of Maxcode to log the last 20 email 

addresses (or even just the most recent) or so to a file, previous to 

it being sent to the regexp object. After the crash, grab the log, 

copy the guilty string and send it to me. At that point, I'm happy to 

Am 23.02.2007 um 01:25 schrieb Zip Boterbloem:

> Neither does mine. But we are nice, polite guys.

> Users will type all sort of nasty/perverse nonsense that I want to 

> Unfortunately, some of this nasty/perverse nonsense, or maybe even 

> some allowable email address will crash regexp, according to my 

> crash log. At least once or twice a day, which is unacceptable in 

> BTW, I've mentioned this exact problem months ago. Can't reproduce 

> it easily, but it's there, I noticed it myself while speedily 

> typing perverse nonsense email addresses (jay!).

> Here's what happens: people type characters/letters in the message 

> box by using a touchscreen. Characters are appended to the message, 

> I first get rid of the extra spaces in eg z i p @ k n o w a r e . 

> The second regexp checks for text that resembles a proper email 

> address. Otherwise, wipe the message box and wait for proper input. 

> Else send the email address to the next patcher.

> Op 22-feb-2007, om 22:44 heeft Jeremy Bernstein het volgende 

>> Sorry, I need more information. My email address doesn't crash 

>> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:

>>> weg met de extra spaties: get rid of the extra spaces

>>> nee, wissen: not an email address, wipe slate

Yeah, here's the sad thing: I don't have all day to type perverse  
nonsense into message boxes. And although I'd really like to help  
solve this issue (I do remember this coming up before, with a more or  
less identical crash and a more or less identical email from me in  
response), I can't without a reproducable test case.

So... if this crash is as unacceptable as you say it is, you should  
be motivated to add a simple bit of Maxcode to log the last 20 email  
addresses (or even just the most recent) or so to a file, previous to  
it being sent to the regexp object. After the crash, grab the log,  
copy the guilty string and send it to me. At that point, I'm happy to  
look at the problem with all due haste.

> Neither does mine. But we are nice, polite guys.
> Users will type all sort of nasty/perverse nonsense that I want to   
> block.
> Unfortunately, some of this nasty/perverse nonsense, or maybe even  
> some allowable email address will crash regexp, according to my  
> crash log. At least once or twice a day, which is unacceptable in  
> an installation, as you can imagine.
> BTW, I've mentioned this exact problem months ago. Can't reproduce  
> it easily, but it's there, I noticed it myself while speedily  
> typing perverse nonsense email addresses (jay!).
> Here's what happens: people type characters/letters in the message  
> box by using a touchscreen. Characters are appended to the message,  
> I  first get rid of the extra spaces in eg z i p @ k n o w a r e .  
> n l.
> The second regexp checks for text that resembles a proper email  
> address. Otherwise, wipe the message box and wait for proper input.  
> Else send the email address to the next patcher.
>
> Best,
>
> Zip
>
> Op 22-feb-2007, om 22:44 heeft Jeremy Bernstein het volgende  
> geschreven:
>
>> Sorry, I need more information. My email address doesn't crash  
>> with this.
>>
>> jb
>>
>> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:
>>
>>> weg met de extra spaties: get rid of the extra spaces
>>> nee, wissen: not an email address, wipe slate
>>
>


I resorted to doing all my regexp in JS. My tests so far are 

BTW, a way to test this would be to automatically 1. generate some 

string(33 chars max), save it, hit regexp with it, wait for the 

crash, otherwise go back to 1. Then you don't have to type all day. 

You could even run it overnight. I can provide you with some basic 

Op 23-feb-2007, om 1:38 heeft Jeremy Bernstein het volgende geschreven:

> Yeah, here's the sad thing: I don't have all day to type perverse 

> nonsense into message boxes. And although I'd really like to help 

> solve this issue (I do remember this coming up before, with a more 

> or less identical crash and a more or less identical email from me 

> in response), I can't without a reproducable test case.

> So... if this crash is as unacceptable as you say it is, you should 

> be motivated to add a simple bit of Maxcode to log the last 20 

> email addresses (or even just the most recent) or so to a file, 

> previous to it being sent to the regexp object. After the crash, 

> grab the log, copy the guilty string and send it to me. At that 

> point, I'm happy to look at the problem with all due haste.

> Am 23.02.2007 um 01:25 schrieb Zip Boterbloem:

>> Neither does mine. But we are nice, polite guys.

>> Users will type all sort of nasty/perverse nonsense that I want 

>> Unfortunately, some of this nasty/perverse nonsense, or maybe even 

>> some allowable email address will crash regexp, according to my 

>> crash log. At least once or twice a day, which is unacceptable in 

>> BTW, I've mentioned this exact problem months ago. Can't reproduce 

>> it easily, but it's there, I noticed it myself while speedily 

>> typing perverse nonsense email addresses (jay!).

>> Here's what happens: people type characters/letters in the message 

>> box by using a touchscreen. Characters are appended to the 

>> message, I first get rid of the extra spaces in eg z i p @ k n o 

>> The second regexp checks for text that resembles a proper email 

>> address. Otherwise, wipe the message box and wait for proper 

>> input. Else send the email address to the next patcher.

>> Op 22-feb-2007, om 22:44 heeft Jeremy Bernstein het volgende 

>>> Sorry, I need more information. My email address doesn't crash 

>>> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:

>>>> weg met de extra spaties: get rid of the extra spaces

I resorted to doing all my regexp in JS. My tests so far are  
encouraging.

BTW, a way to test this would be to automatically 1. generate some  
string(33 chars max), save it, hit regexp with it, wait for the  
crash, otherwise go back to 1. Then you don't have to type all day.  
You could even run it overnight. I can provide you with some basic  
dutch swearwords, if you like.

> Yeah, here's the sad thing: I don't have all day to type perverse  
> nonsense into message boxes. And although I'd really like to help  
> solve this issue (I do remember this coming up before, with a more  
> or less identical crash and a more or less identical email from me  
> in response), I can't without a reproducable test case.
>
> So... if this crash is as unacceptable as you say it is, you should  
> be motivated to add a simple bit of Maxcode to log the last 20  
> email addresses (or even just the most recent) or so to a file,  
> previous to it being sent to the regexp object. After the crash,  
> grab the log, copy the guilty string and send it to me. At that  
> point, I'm happy to look at the problem with all due haste.
>
> jb
>
> Am 23.02.2007 um 01:25 schrieb Zip Boterbloem:
>
>> Neither does mine. But we are nice, polite guys.
>> Users will type all sort of nasty/perverse nonsense that I want  
>> to  block.
>> Unfortunately, some of this nasty/perverse nonsense, or maybe even  
>> some allowable email address will crash regexp, according to my  
>> crash log. At least once or twice a day, which is unacceptable in  
>> an installation, as you can imagine.
>> BTW, I've mentioned this exact problem months ago. Can't reproduce  
>> it easily, but it's there, I noticed it myself while speedily  
>> typing perverse nonsense email addresses (jay!).
>> Here's what happens: people type characters/letters in the message  
>> box by using a touchscreen. Characters are appended to the  
>> message, I  first get rid of the extra spaces in eg z i p @ k n o  
>> w a r e . n l.
>> The second regexp checks for text that resembles a proper email  
>> address. Otherwise, wipe the message box and wait for proper  
>> input. Else send the email address to the next patcher.
>>
>> Best,
>>
>> Zip
>>
>> Op 22-feb-2007, om 22:44 heeft Jeremy Bernstein het volgende  
>> geschreven:
>>
>>> Sorry, I need more information. My email address doesn't crash  
>>> with this.
>>>
>>> jb
>>>
>>> Am 21.02.2007 um 23:25 schrieb Zip Boterbloem:
>>>
>>>> weg met de extra spaties: get rid of the extra spaces
>>>> nee, wissen: not an email address, wipe slate
>>>
>>
>


Despite your unwillingness to cooperate, I found the problem (this 

was also the problem reported by dlurk on 9 February) and have fixed 

it. I imagine you'll see it in an incremental update coming soon to a 

Am 23.02.2007 um 11:50 schrieb Zip Boterbloem:

> I resorted to doing all my regexp in JS. My tests so far are 

> BTW, a way to test this would be to automatically 1. generate some 

> string(33 chars max), save it, hit regexp with it, wait for the 

> crash, otherwise go back to 1. Then you don't have to type all day. 

> You could even run it overnight. I can provide you with some basic 

Despite your unwillingness to cooperate, I found the problem (this  
was also the problem reported by dlurk on 9 February) and have fixed  
it. I imagine you'll see it in an incremental update coming soon to a  
website near you.

> I resorted to doing all my regexp in JS. My tests so far are  
> encouraging.
>
> BTW, a way to test this would be to automatically 1. generate some  
> string(33 chars max), save it, hit regexp with it, wait for the  
> crash, otherwise go back to 1. Then you don't have to type all day.  
> You could even run it overnight. I can provide you with some basic  
> dutch swearwords, if you like.


> Despite your unwillingness to cooperate, I found the problem (this was 

> also the problem reported by dlurk on 9 February) and have fixed it. I 

> imagine you'll see it in an incremental update coming soon to a website 

Jeremy Bernstein wrote:
> Despite your unwillingness to cooperate, I found the problem (this was 
> also the problem reported by dlurk on 9 February) and have fixed it. I 
> imagine you'll see it in an incremental update coming soon to a website 
> near you.
>
> jb


In the first place: thanks for finding & fixing the problem.

I want to make this clear: I'm quite willing to cooperate in making 

Max the most stable and bugfree programming environment in the 

world , but unfortunately I am pressed for time. This regexp stuff is 

running some 60 km from where I live. Installing/testing/getting hold 

of the resulting log in a venue with strict safety policies is quite 

Trying to come up with very clear examples of buggy max object 

behaviour or unexpected side effects in the hope they wil get fixed 

I'm really busy, have to deal with large projects with lots of people/ 

companies/regulations involved, and am not so well paid that I can 

take time off and hunt bugs.. In fact, I've quite a few Max crash 

logs that I haven't even send on because I can't easily reproduce the 

I have found that getting rid of suspect Max objects and just try 

something else (can I do this in JS? Will it work reliable then? Will 

it mess up scheduler based stuff?)is the quickest and most cost 

effective way to get on with the job, meet deadlines etc.

Op 23-feb-2007, om 12:47 heeft Jeremy Bernstein het volgende geschreven:

> Despite your unwillingness to cooperate, I found the problem (this 

> was also the problem reported by dlurk on 9 February) and have 

> fixed it. I imagine you'll see it in an incremental update coming 

> Am 23.02.2007 um 11:50 schrieb Zip Boterbloem:

>> I resorted to doing all my regexp in JS. My tests so far are 

>> BTW, a way to test this would be to automatically 1. generate some 

>> string(33 chars max), save it, hit regexp with it, wait for the 

help with interpreting crashlog