crashing max5/getting a crashlog


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

    • Jan 09 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
      >
    • Jan 09 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
      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
    • Jan 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;
      }
      ?
    • Jan 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
      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:
      > iCE Tools:
      >
    • Jan 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…
    • Jan 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
    • Jan 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
    • Jan 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
      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
      >
    • Jan 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
    • Jan 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;
      }
      }
      }
    • Jan 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
      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.
      >
      >
    • Jan 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
      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;
      > }
      > }
      > }
      >