BUG: crashing vs problem reporter

The latest version 6.3.7 crashes on me a lot (on El Cap) and that launches the Problem Reporter. The even -bigger- problem is that the Reporter doesn’t work either. Spinning beachball forever. Cannot dismiss it. Cannot force quit it except in the activity monitor.

Then I have to reboot. So I do, and the “helpful” Reporter launches instantly when I try to run RW again, asking if I want to report the crash from last time.

But the Reporter is broken. I’m in an infinite cycle I can’t get out of.

Is there some way to DISABLE the Problem Reporter. I’d much rather be able to restart and try again, than be locked out of RW all together by this silly behavior.


May I respectfully suggest that there may be something else going on in your case?

I’m sorry you’re having these difficulties. But they would seem to be atypical.

Could there be some other sort of conflict or malfunction masking itself as a specific RW (6.3.7) crash… an improperly transferred add-on, update or dependent file?

What do your Finder’s crash logs look like?

I had been experiencing multiple crashes in RW since about 6.2x. Mac would lock up and after a Mac reset the Crash reporter would then crash the Mac again. I did report this many times to Realmac. Each next version did exactly the same. Of course when the Crash reporter crashes they don’t get any report.

I stopped using the RW publishing system a few months ago and RW stopped crashing. I use Export and Forklift to FTP the files which works quickly and perfectly (just like every other FTP solution).

Thanks, Mark.

Not sure how I’d find “an improperly transferred add-on, update or dependent file”, but it is certainly likely a problem that is rare (although Conger, above, seems to have it as well.)

Also not sure how an add-on et al would cause the Problem Reporter (apparently a separate, invoked, app) to fail. (At one point [only one time out of many] it claimed it could not connect, and indeed the beachball does make it seem as though it cannot get past that state, despite the fact that my internet access is excellent.)

There are no crashreporter files from RW anywhere on my boot drive.

The console logs complain about a video codec (which is not directly involved AFAIK)
c12/29/15 12:23:51.062 PM RapidWeaver 6[12382]: [12:23:51.062] mv_LowLevelCheckIfVideoPlayableUsingDecoder signalled err=-12956 (kFigMediaValidatorError_VideoCodecNotSupported) (video codec 1) at line 1921
12/29/15 12:23:51.062 PM RapidWeaver 6[12382]: <<<< MediaValidator >>>> mv_TestCodecSupportUsingDecoders: Unrecognized codec 1

and this is the only crash-related entry I can find:

12/29/15 12:24:36.679 PM RapidWeaver 6[12382]: Handling crash with signal 11…

I was hoping there was some preference, or terminal command to make crash reporting optional, or some way of bypassing the fatal lockup that the problem reporter seems to engender.

Like conger, I see it most often when trying to publish, but not always that alone. Today I was in preview mode, and clicked a link on one page to another page, and it promptly crashed.

I did discover that once this happens, then before launching RW again, if I duplicate the project in the finder and launch that copy, the problem reporter is not invoked on launch.

(I spent 35 years writing code, so while this is frustrating, it’s not generally unfamiliar… :slight_smile:


How frustrating! You seem to be taking it all in good part - but it must be a real disincentive. I wish I could be of more direct help.

RealMac has been focussing a lot in recent releases of 6 on ftp and publishing; trying to address the huge variety of circumstances which arise in that phase. It’s possible that you have hit on a combination which they have yet to fix. May I suggest contacting them directly?

I know I put off upgrading from 5 to 6 for many months as I just couldn’t face what appeared complex where upgrading then moving then configuring add ons and stacks was concerned. In the end I just treated the whole thing as a re-install and rebuilt all my sites in the 6 environment.

I feared that if I failed to start afresh I might run into probs. Could it be that inadvertently dragging an incompatible (with 6) add-on has made your installation unstable?

Having said that, the fact that your crash reporter fails really to find any specific RW-related crashes is telling, and that - chiefly as you publish - you’re hitting a combination of conditions of which RW is part, but some underlying incompatibility is causing the crashes?

I wonder whether this video codec that one of your apps (RW??) doesn’t like is just giving up and passing the buck to RW?

As I say, try emailing RealMac support directly. They may be off until after the weekend. But I’m sure they’ll be able to help. My commiserations; and good luck!

Every one, a sound and logical comment, Mark. Thanks again, and best wishes for 2016.

Have the same problem - tried it with Maverick, Yosemite and ElCaptain. After a crash RW6 try to send a Report Log, use all available memory and freeze all other apps and show the spinning beach ball, dead keyboard so I can not stop the program. I alway have to restart the Mac.
If I restart RW after a crash I have to wait a looooong time before I the Problem Reporter appears. I also ask for a option to disable that. I think the Problem Reporter try to read all informations at my Mac and eat up all available …

I’d have to add that the reporter after a RW6 crash is very problematic for me as well. I get nothing but continuous beachball when I try to send in a report - it requires a force quit to even get it to close.

I really hate not being able to send in reports after a RW crash, but I now just quickly exit the reporter as soon as it comes up. :disappointed:

One thing I found was that if you never update to the latest version you will get the update nag screen come up before the Crash Reporter crashes, which may give you enough time to Force Quit the Crash reporter. FWIW I also requested that RW gets an option to disable the Crash reporter months ago.

It’s nice to know I’m not alone. Happened again this morning. After a reboot, I still get the Problem Reporter, but now if I wait about 3 minutes, RW will finally launch, and I can close the PR window. Nonetheless, lockups, reboots and so on are not indicative of RW’s general high quality.

Today, for the very first time, before the crash I got an actual crash dialog: Exception while exporting site. -[NSCFType attachments]: unrecognized selector sent to instance 0x7fd9ed434b70

Does anyone know if the programmers see these bug reports on the forum?

I’m getting the same issue. More frequent crashes than before 6.3.7- usually in the middle of something quite mundane like a text change - and then the crash reporter hangs instead of sending and, after I close it, re-appears with the message I put in it - apparently not sent.

I’d recommend that you try things with the forthcoming update to Stacks that may very well fix these issues for you.


For those of you that are encountering this issue, please try the following:

  1. Delete your existing copy of RapidWeaver 6. Empty the trash.
  2. Download the latest version from the following link. Place it in /Applications.
  3. Do not open RapidWeaver. Restart your computer, then try to open RapidWeaver 6.

If you continue to experience this issue, don’t hesitate to send us an email support[at]realmacsoftware[dot]com and we’ll get you sorted!

Is this a beta version of RapidWeaver or a final release. Not that it matters to me, but I do know there are people who do not want to use beta software.

@zeebe The link in my message above is version 6.3.7.

Good to hear! Thanks!

UNFORTUNATELY… it just happened again, with an entirely different project. I tried the “trick” of replacing the app, and it still happens.

I get the same error message I typed in months ago, and the same lockup of the problem reported.

AAron is a nice guy, but I’ve spent 38 years in the computer industry, and the old “just reinstall the software” routine is virtually always trotted out… and some times it works, and sometimes it doesn’t.

I’m STILL asking for WHERE the crash info is kept, so I can delete the trigger. (Aaron: that means that, programmatically, when an app crashes, and has a reporter feature, the issue of the crash, and the user notes about it are stored in a file on the hard drive. That way it can all be bundled up and set to you, the developer.

But if the app that does the sending ITSELF IS BUGGY, then 1) the file is never sent, and 2) because of that, the next time the software starts, the file is still there, and the buggy reporter launches itself all over again.

If that file that contains the report of the crash, and the uses “what happened” text, is NEVER removed, there is no way out of this.

I’ve written literally millions of lines of application code. I know exactly how hard (or NOT hard) it is to stick in a bit to TURN OFF bug reporters, and just simply ignore any problems. That -should- be a user preference.

If not then perhaps you have a terminal command that will turn it off?

I’ve asked and asked for a resolution to this. I’ve pleaded for SOME way to get past the bug reporter and get on with my work.

It’s not important whose fault this is. It’s not important or even relevant if it’s something in my system. NONE of that has anything to do with bypassing the bug reporter on a fresh install and fresh start of the RW software.

I’d be willing to bet $100 that one of the programmers there knows -exactly- what I’m talking about and how to get around the problem.

I’m happy playing around in the terminal; I’m happy wiht invisible files and package contents. Hell, I even know how to use (and own several hex-editors.)

I’d be -delighted- if someone there would just ASK for my help in debugging this.

There are obviously several of us with the same problem here. Can’t we do better from you folks than “It’s your fault; reinstall the software?”


[sorry for the rant, but this is getting to be not only -really- frustrating, but it’s costing me $$$ and time.]

I have felt your pain for many months of this.

After frequently reporting almost exactly the same things to Realmac I was sent the following:

If you enter the following into Terminal.app, you can disable the crash handling in RapidWeaver:
defaults write com.realmacsoftware.rapidweaver6 RWEnableExceptionHandling -bool NO

I never had to do this because by that time I learnt 2 tricks to stop RW crashing.

  1. Never ever update to the latest version. This allows the Update mesage to pop up before the Crash Reporter crashes. This can sometimes allow you to Force Quit RW.
  2. Never ever use the RW Publish which is fundamentaly flawed and broken IMO and has been for a long time. Use Export and an FTP folder sync App such as Forklift or Transmit.

My crashes were being blamned by Realmac on Stacks Beta, then Stacks, Addons (I don’t have any), etc. I even went to the trouble of changing my HD and did a fresh reinstall, but RW still crashed and the Crash Reporter crashed too.

My crashes started in the early 6.3x versions and seemed to get worse with every version. I am now on 6.3.4 which used to crash 2 or 3 times a day but hasn’t crashes in a few monts since stopping using teh RW Publish.

I believe this problem to be much bigger than is reported becasue many users don’t use the RW Publish system and therefore don’t see the crashing.

I never had problems with the FTP Tool in RW, since more than 10 years, in all versions, since RW 3.

… I use always the newest RW version.
… and I do not use the autosave option in OSX (system settings) and also in RapidWeaver. I don’t like autosave :wink:
Perhaps, this gives me no problems with crashes and the crash reporter.

Same here.

The interesting thing here is that the crashing only affects some people. However, because the Crash reporter also crashes, the information needed to point to the cause of the problem is not available.