Forums > MaxMSP

help with interpreting crashlog

February 21, 2007 | 9:01 pm

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?

Any insights very much appreciated.

Best.

Zip

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]

Version: ??? (4.6.1)

PID: 267
Thread: 0

Exception: EXC_BAD_ACCESS (0×0001)
Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000009

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 0×05736224 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 0×05779404 js_Invoke + 1856
(icplusplus.c:28)
18 com.cycling74.MaxJSRef 0×05779624 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 0×00010684 max_dodrag + 60
(dragging.c:78)
24 com.cycling74.MaxMSPRuntime46 0x0001c0fc app_eventhandler
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1552 (main.c:
1630)
25 com.apple.HIToolbox 0×93204554 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


February 21, 2007 | 9:18 pm

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?


February 21, 2007 | 10:25 pm

Hi Jeremy,

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.

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

This is another(more likely at fault):

max v2;
#N vpatcher 10 59 895 911;
#P hidden button 195 170 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P hidden comment 265 138 144 196617 lijkt het op een email-adres?;
#P hidden newex 39 108 182 196617 regexp @re (\\S)\\s @substitute
%1;
#P hidden newex 39 136 219 196617 regexp [-a-z0-9._%]+@[-a-z0-9.]+\
.[a-z]+;
#N comlet email-adres of stop;
#P hidden outlet 457 241 15 0;
#P window setfont Arial 14.;
#P window linecount 0;
#P message 39 72 414 131137550;
#P noclick;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P hidden comment 228 111 140 196617 weg met de extra spaties;
#P hidden comment 223 170 100 196617 nee , wissen;
#P hidden comment 146 222 100 196617 email adres;
#P connect 3 0 6 0;
#P hidden connect 6 0 5 0;
#P hidden connect 5 3 8 0;
#P hidden fasten 5 2 4 0 148 215 462 215;
#P pop;

Translation:

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

Regards,

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

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?
>
> 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?
>


February 22, 2007 | 9:44 pm

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


February 23, 2007 | 12:25 am

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
>


February 23, 2007 | 12:38 am

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
>>
>


February 23, 2007 | 10:50 am

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.

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.
>
> 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
>>>
>>
>


February 23, 2007 | 11:47 am

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

Am 23.02.2007 um 11:50 schrieb Zip Boterbloem:

> 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.


February 23, 2007 | 12:06 pm

Hooray! Thanks!

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


February 23, 2007 | 4:02 pm

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
a task.

Trying to come up with very clear examples of buggy max object
behaviour or unexpected side effects in the hope they wil get fixed
is often too much work. Sorry.
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
crash
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.

Best,

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

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
> soon to a website near you.
>
> jb
>
> Am 23.02.2007 um 11:50 schrieb Zip Boterbloem:
>
>> 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.
>


Viewing 10 posts - 1 through 10 (of 10 total)