Forums > Dev

crashing max5/getting a crashlog

January 9, 2009 | 4:37 pm

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


January 9, 2009 | 7:11 pm

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

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
>


January 9, 2009 | 7:19 pm

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

brad

http://music.columbia.edu/~brad

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
> how deep the report is gonna be.
>
> ej


January 12, 2009 | 4:11 pm

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

Something like

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

?


January 12, 2009 | 5:01 pm

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

brad

http://music.columbia.edu/~brad

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

>
> 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: < http://www.bek.no/~pcastine/Litter/>
> iCE Tools: <
http://www.dspaudio.com/software/ice/ice_overview.php>
>


January 13, 2009 | 8:00 pm

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…


January 13, 2009 | 9:20 pm

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.

brad

http://music.columbia.edu/~brad


January 13, 2009 | 9:50 pm

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


January 13, 2009 | 10:07 pm

Here’s what I did:

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.

This in the Console looking at the system.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

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.
But I am curious for The Future…

brad

http://music.columbia.edu/~brad

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


January 13, 2009 | 10:29 pm

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.

-Joshua


January 13, 2009 | 10:38 pm

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


January 13, 2009 | 10:38 pm

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

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

brad

http://music.columbia.edu/~brad

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]:
>> ——–> 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.
>
>


January 13, 2009 | 10:41 pm

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.

brad

http://music.columbia.edu/~brad

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


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