Brad Garton

Arg! This is driving me crazy! I write this as my bang method:

for (i = 0; i < 100000000; i++) ttt[789789*i] = 78978978;

and Max5 doesn't crash! It's built like a tank! Where's my happy 

segmentation fault? Ok, I can imagine I'm blitzing memory that 

doesn't really matter somehow, so I replace the for() look with 

while(1). Still doesn't crash! I get the spinning rainbow, of 

course, and I do a 'force quit' and I STILL CAN'T GET A CRASHLOG TO 

APPEAR!!!!!!! Nothing in /Library/Logs/Crashreporter, nothing in ~/ 

lLibrary/Logs/Crashreporter, I've tried all three of 

How do I make max5 crash? (well, I have, but then:) How do I get my 

crashlog? It really helps to see the traceback...

I'm sure I'm overlooking something really stoopid an basic, but I just 

Arg!  This is driving me crazy!  I write this as my bang method:

int ttt[1], i;
for (i = 0; i < 100000000; i++) ttt[789789*i] = 78978978;

and Max5 doesn't crash!  It's built like a tank!  Where's my happy  
segmentation fault?  Ok, I can imagine I'm blitzing memory that  
doesn't really matter somehow, so I replace the for() look with  
while(1).  Still doesn't crash!  I get the spinning rainbow, of  
course, and I do a 'force quit' and I STILL CAN'T GET A CRASHLOG TO  
APPEAR!!!!!!!  Nothing in /Library/Logs/Crashreporter, nothing in ~/ 
lLibrary/Logs/Crashreporter, I've tried all three of  
CrashReporterPrefs.app options.

How do I make max5 crash?  (well, I have, but then:) How do I get my  
crashlog?  It really helps to see the traceback...

I'm sure I'm overlooking something really stoopid an basic, but I just  
can't see it.

crashing-max5getting-a-crashlog

Try the "; max crash" message. There is also an application called 

Crashreporter (well I'm not really sure about the name) which is for 

sure imcluded with the Developer tools which allows you to specify how 

On 9 janv. 09, at 17:37, Brad Garton wrote:

> Arg! This is driving me crazy! I write this as my bang method:

> for (i = 0; i < 100000000; i++) ttt[789789*i] = 78978978;

> and Max5 doesn't crash! It's built like a tank! Where's my happy 

> segmentation fault? Ok, I can imagine I'm blitzing memory that 

> doesn't really matter somehow, so I replace the for() look with 

> while(1). Still doesn't crash! I get the spinning rainbow, of 

> course, and I do a 'force quit' and I STILL CAN'T GET A CRASHLOG TO 

> APPEAR!!!!!!! Nothing in /Library/Logs/Crashreporter, nothing in ~/ 

> lLibrary/Logs/Crashreporter, I've tried all three of 

> How do I make max5 crash? (well, I have, but then:) How do I get my 

> crashlog? It really helps to see the traceback...

> I'm sure I'm overlooking something really stoopid an basic, but I 

Try the "; max crash" message. There is also an application called  
Crashreporter (well I'm not really sure about the name) which is for  
sure imcluded with the Developer tools which allows you to specify how  
deep the report is gonna be.

On 9 janv. 09, at 17:37, Brad Garton  wrote:

> Arg!  This is driving me crazy!  I write this as my bang method:
>
> int ttt[1], i;
> for (i = 0; i < 100000000; i++) ttt[789789*i] = 78978978;
>
> and Max5 doesn't crash!  It's built like a tank!  Where's my happy  
> segmentation fault?  Ok, I can imagine I'm blitzing memory that  
> doesn't really matter somehow, so I replace the for() look with  
> while(1).  Still doesn't crash!  I get the spinning rainbow, of  
> course, and I do a 'force quit' and I STILL CAN'T GET A CRASHLOG TO  
> APPEAR!!!!!!!  Nothing in /Library/Logs/Crashreporter, nothing in ~/ 
> lLibrary/Logs/Crashreporter, I've tried all three of  
> CrashReporterPrefs.app options.
>
> How do I make max5 crash?  (well, I have, but then:) How do I get my  
> crashlog?  It really helps to see the traceback...
>
> I'm sure I'm overlooking something really stoopid an basic, but I  
> just can't see it.
>
> brad
> http://music.columbia/edu/~brad
>

Thanks ej -- that worked, and I do have a crashlog. I had tried 

various settings of the CrashReportPrefs app, but the hard part was 

getting max5 to crash. Yikes. Now I have to figure out why my code 

seems to exit rather than crash (no exit()'s that I can find so far...)

On Jan 9, 2009, at 2:11 PM, Emmanuel Jourdan wrote:

> Try the "; max crash" message. There is also an application called 

> Crashreporter (well I'm not really sure about the name) which is for 

> sure imcluded with the Developer tools which allows you to specify 

Thanks ej -- that worked, and I do have a crashlog.  I had tried  
various settings of the CrashReportPrefs app, but the hard part was  
getting max5 to crash.  Yikes.  Now I have to figure out why my code  
seems to exit rather than crash (no exit()'s that I can find so far...)

> Try the "; max crash" message. There is also an application called  
> Crashreporter (well I'm not really sure about the name) which is for  
> sure imcluded with the Developer tools which allows you to specify  
> how deep the report is gonna be.
>
> ej


And if you just try to write to NULL, doesn't that crash?

And if you just try  to write to NULL, doesn't that crash?

void CrashMe()
 {
 long* x = NULL;
 *x = 0xdeadbeef;
 }

It does, but it doesn't generate a crashlog for me. I just get an

"Exited with exit code: 1" in my logs. The [; max crash] message

did work, though (and produced a crashlog). I was able to track down

what was causing my problem, but this time I wished that max5 was a

On Jan 12, 2009, at 11:11 AM, Peter Castine wrote:

> And if you just try to write to NULL, doesn't that crash?

It does, but it doesn't generate a crashlog for me.  I just get an
"Exited with exit code: 1" in my logs.  The [; max crash] message
did work, though (and produced a crashlog).  I was able to track down
what was causing my problem, but this time I wished that max5 was a
ittle less 'robust'.  weird

>
> And if you just try  to write to NULL, doesn't that crash?
>
> Something like
>
> void CrashMe()
> {
> long* x = NULL;
> *x = 0xdeadbeef;
> }
>
> ?
> --
> ----
> Peter Castine
> Litter Power: 
> iCE Tools: 
>


No crash log, huh? Well, ok, back to the drawing board. I'll let you know if I have another idea that works from inside C code (obviously, the ;max crash message is great for inside patches).

I suppose you can send ;max messages from inside C code… something like gensym("max") and I'd have to look up the rest of the mantra. Maybe after supper, but something in the kitchen smells pretty good…

On Jan 13, 2009, at 3:00 PM, Peter Castine wrote:

> No crash log, huh? Well, ok, back to the drawing board. I'll let you 

> know if I have another idea that works from inside C code 

> (obviously, the ;max crash message is great for inside patches).

Thanks. It's really strange -- all my happy seg faults, NULL pointer- 

writing, somehow Max5 is catching the errors (some thread-safe thing?) 

and giving a nice tidy "exit code 1" in the console.

> No crash log, huh? Well, ok, back to the drawing board. I'll let you  
> know if I have another idea that works from inside C code  
> (obviously, the ;max crash message is great for inside patches).

Thanks.  It's really strange -- all my happy seg faults, NULL pointer- 
writing, somehow Max5 is catching the errors (some thread-safe thing?)  
and giving a nice tidy "exit code 1" in the console.

On Jan 13, 2009, at 1:20 PM, Brad Garton wrote:

> Thanks. It's really strange -- all my happy seg faults, NULL 

> pointer-writing, somehow Max5 is catching the errors (some thread- 

> safe thing?) and giving a nice tidy "exit code 1" in the console.

    *p = 5;    // dereference null pointer.

So if this kind of code in your external isn't achieving the same 

results as the ;max crash message, then perhaps your code is being 

executed in the context of some kind of exception handling, which in 

turn exits the application rather than passing the memory access 

violation on to the OS. Or something along these lines... More info 

about the context in which this is happening might be useful. I assume 

it's in one of the language binding externals or similar, and I 

wouldn't be surprised if one of these language bindings were handling 

> Thanks.  It's really strange -- all my happy seg faults, NULL  
> pointer-writing, somehow Max5 is catching the errors (some thread- 
> safe thing?) and giving a nice tidy "exit code 1" in the console.

void max_crash(void *x)
{
	char *p = 0;
	*p = 5;	// dereference null pointer.
}

So if this kind of code in your external isn't achieving the same  
results as the ;max crash message, then perhaps your code is being  
executed in the context of some kind of exception handling, which in  
turn exits the application rather than passing the memory access  
violation on to the OS. Or something along these lines... More info  
about the context in which this is happening might be useful. I assume  
it's in one of the language binding externals or similar, and I  
wouldn't be surprised if one of these language bindings were handling  
exceptions as such.

and the patch was just a bang into the [rtcmix~] object. Exits 

This in the Console looking at the system.log:

Jan 13 17:00:26 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: 

Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: JUCE 

Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: 

Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: <<< 

Jan 13 17:00:42 woof com.apple.launchd[78] 

([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit code: 1

Max 5.0.5 (36470), Intel MacBook running 10.5.6

Weird, huh? [;max crash] crashes and does leave a crash report.

By the way, this is just for info-purposes now, I have all my stuff 

ported and running (yay!), just finishing the updated help patches. 

On Jan 13, 2009, at 4:50 PM, Joshua Kit Clayton wrote:

> On Jan 13, 2009, at 1:20 PM, Brad Garton wrote:

>> Thanks. It's really strange -- all my happy seg faults, NULL 

>> pointer-writing, somehow Max5 is catching the errors (some thread- 

>> safe thing?) and giving a nice tidy "exit code 1" in the console.

>     *p = 5;    // dereference null pointer.

> So if this kind of code in your external isn't achieving the same 

> results as the ;max crash message, then perhaps your code is being 

> executed in the context of some kind of exception handling, which in 

> turn exits the application rather than passing the memory access 

> violation on to the OS. Or something along these lines... More info 

> about the context in which this is happening might be useful. I 

> assume it's in one of the language binding externals or similar, and 

> I wouldn't be surprised if one of these language bindings were 

void rtcmix_bang(t_rtcmix *x)
{
	char *p = 0;
	*p = 5;	// dereference null pointer.
}

and the patch was just a bang into the [rtcmix~] object.  Exits  
immediately, no crash log.

Jan 13 17:00:26 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]:  
sqlite version 3.5.4
Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: JUCE  
v1.45
Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]:  
--------> RTcmix-UB-mm 4.0.1.5
Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: <<<  
Caught internal signal (10) >>>
Jan 13 17:00:42 woof com.apple.launchd[78]  
([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit code: 1

Weird, huh?  [;max crash] crashes and does leave a crash report.

By the way, this is just for info-purposes now, I have all my stuff  
ported and running (yay!), just finishing the updated help patches.  
But I am curious for The Future...

>
> On Jan 13, 2009, at 1:20 PM, Brad Garton wrote:
>
>> Thanks.  It's really strange -- all my happy seg faults, NULL  
>> pointer-writing, somehow Max5 is catching the errors (some thread- 
>> safe thing?) and giving a nice tidy "exit code 1" in the console.
>
> FWIW, here's what ;max crash calls:
>
> void max_crash(void *x)
> {
> 	char *p = 0;
> 	*p = 5;	// dereference null pointer.
> }
>
> So if this kind of code in your external isn't achieving the same  
> results as the ;max crash message, then perhaps your code is being  
> executed in the context of some kind of exception handling, which in  
> turn exits the application rather than passing the memory access  
> violation on to the OS. Or something along these lines... More info  
> about the context in which this is happening might be useful. I  
> assume it's in one of the language binding externals or similar, and  
> I wouldn't be surprised if one of these language bindings were  
> handling exceptions as such.
>
> -Joshua
>


On Jan 13, 2009, at 2:07 PM, Brad Garton wrote:

> Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: 

> Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: <<< 

> Jan 13 17:00:42 woof com.apple.launchd[78] 

> ([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit code: 1

I'm pretty sure that RTcmix is installing an exception/signal handler 

and exiting. You might need to hunt though the RTcmix sources further. 

A search online for "Caught internal signal" seemed to me to show that 

this string is also what gets printed out in the commandline version 

of RTcmix, and in no other software. Find that string in the RTcmix 

source and you are on your way to figuring out the cause.

On Jan 13, 2009, at 2:07 PM, Brad Garton wrote:
> Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]:  
> --------> RTcmix-UB-mm 4.0.1.5
> Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: <<<  
> Caught internal signal (10) >>>
> Jan 13 17:00:42 woof com.apple.launchd[78]  
> ([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit code: 1

I'm pretty sure that RTcmix is installing an exception/signal handler  
and exiting. You might need to hunt though the RTcmix sources further.  
A search online for "Caught internal signal" seemed to me to show that  
this string is also what gets printed out in the commandline version  
of RTcmix, and in no other software. Find that string in the RTcmix  
source and you are on your way to figuring out the cause.

On Jan 13, 2009, at 2:29 PM, Joshua Kit Clayton wrote:

> Find that string in the RTcmix source and you are on your way to 

Just #ifdef out the exit() call in the following handler, or 

set_sig_handlers(); as called in RTcmixMain::RTcmixMain(). I would 

imagine you don't need either the signal or interrupt handlers in the 

    // Dont do handler work more than once

        signal_handler_called = 1;

     fprintf(stderr, "n<<< Caught internal signal (%d) >>>n", signo);

> Find that string in the RTcmix source and you are on your way to  
> figuring out the cause.

Just #ifdef out the exit() call in the following handler, or  
set_sig_handlers(); as called in RTcmixMain::RTcmixMain(). I would  
imagine you don't need either the signal or interrupt handlers in the  
MaxMSP version.

void
RTcmixMain::signal_handler(int signo)
{
	// Dont do handler work more than once
	if (!signal_handler_called) {
		signal_handler_called = 1;
	   fprintf(stderr, "n<<< Caught internal signal (%d) >>>n", signo);

	   run_status = RT_ERROR;
	   switch (signo) {
	   default:
		   fflush(stdout);
		   fflush(stderr);
   	 	   exit(1);
	       break;
	   }
	}
}


aHA! that's it! I thought you guys were doing some serious magic 

thanks for helping the scales to fall from me eyes.

This was also manifesting in chuck~ (for the same reason), and I 

hadn't seen it before. I changed the way I'm dynloading for Max5 and 

it has exposed more to the loading context than the earlier scheme did 

(I also had some variable-name conflicts that surfaced).

On Jan 13, 2009, at 5:29 PM, Joshua Kit Clayton wrote:

> On Jan 13, 2009, at 2:07 PM, Brad Garton wrote:

>> Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: 

>> Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]: 

>> Jan 13 17:00:42 woof com.apple.launchd[78] 

>> ([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit 

> I'm pretty sure that RTcmix is installing an exception/signal 

> handler and exiting. You might need to hunt though the RTcmix 

> sources further. A search online for "Caught internal signal" seemed 

> to me to show that this string is also what gets printed out in the 

> commandline version of RTcmix, and in no other software. Find that 

> string in the RTcmix source and you are on your way to figuring out 

aHA!  that's it!  I thought you guys were doing some serious magic  
with Max5...

This was also manifesting in chuck~ (for the same reason), and I  
hadn't seen it before.  I changed the way I'm dynloading for  Max5 and  
it has exposed more to the loading context than the earlier scheme did  
(I also had some variable-name conflicts that surfaced).

>
> On Jan 13, 2009, at 2:07 PM, Brad Garton wrote:
>> Jan 13 17:00:33 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]:  
>> --------> RTcmix-UB-mm 4.0.1.5
>> Jan 13 17:00:42 woof [0x0-0x44c44c].com.cycling74.MaxMSP[61216]:  
>><<< Caught internal signal (10) >>>
>> Jan 13 17:00:42 woof com.apple.launchd[78]  
>> ([0x0-0x44c44c].com.cycling74.MaxMSP[61216]): Exited with exit  
>> code: 1
>
> I'm pretty sure that RTcmix is installing an exception/signal  
> handler and exiting. You might need to hunt though the RTcmix  
> sources further. A search online for "Caught internal signal" seemed  
> to me to show that this string is also what gets printed out in the  
> commandline version of RTcmix, and in no other software. Find that  
> string in the RTcmix source and you are on your way to figuring out  
> the cause.
>
>


Good lord jkc you amaze me. You even found the source for it before I 

I drag around a bunch of unused code to keep RTcmix and ChucK semi- 

synced with the originating languages. This summer I hope to install 

a bunch of #ifdefs, the more sane way to do this.

On Jan 13, 2009, at 5:38 PM, Joshua Kit Clayton wrote:

> On Jan 13, 2009, at 2:29 PM, Joshua Kit Clayton wrote:

>> Find that string in the RTcmix source and you are on your way to 

> Just #ifdef out the exit() call in the following handler, or 

> set_sig_handlers(); as called in RTcmixMain::RTcmixMain(). I would 

> imagine you don't need either the signal or interrupt handlers in 

>     // Dont do handler work more than once

>         signal_handler_called = 1;

>      fprintf(stderr, "n<<< Caught internal signal (%d) >>>n", signo);

Good lord jkc you amaze me.  You even found the source for it before I  
had a chance to do a quick fgrep.

I drag around a bunch of unused code to keep RTcmix and ChucK semi- 
synced with the originating languages.  This summer I hope to install  
a bunch of #ifdefs, the more sane way to do this.

>
> On Jan 13, 2009, at 2:29 PM, Joshua Kit Clayton wrote:
>
>> Find that string in the RTcmix source and you are on your way to  
>> figuring out the cause.
>
>
> Just #ifdef out the exit() call in the following handler, or  
> set_sig_handlers(); as called in RTcmixMain::RTcmixMain(). I would  
> imagine you don't need either the signal or interrupt handlers in  
> the MaxMSP version.
>
> -Joshua
>
>
> void
> RTcmixMain::signal_handler(int signo)
> {
> 	// Dont do handler work more than once
> 	if (!signal_handler_called) {
> 		signal_handler_called = 1;
> 	   fprintf(stderr, "n<<< Caught internal signal (%d) >>>n", signo);
>
> 	   run_status = RT_ERROR;
> 	   switch (signo) {
> 	   default:
> 		   fflush(stdout);
> 		   fflush(stderr);
>  	 	   exit(1);
> 	       break;
> 	   }
> 	}
> }
>


crashing max5/getting a crashlog