Re: enhancing Force Quit or improving user-driven diagnostics

I'm going to suggest a different tack.

man SubmitDiagInfo(1) describes how Apple takes care of crash reports:
ReportCrash(1) is automatically invoked by launchd when it detects a
program has crashed. That generates a crash report in the user's
~/Library/Logs/DiagnosticReports directory (or
/Library/Logs/DiagnosticReports for root). SubmitDiagInfo comes along
and periodically submits that info to Apple and cleans out logs that
are older than a month.

So why not create a system-wide per-user launchd agent that behaves
like SubmitDiagInfo? Have a periodic launchd task that enumerates the
contents of ~/Library/Logs/DiagnosticReports and sends you any
information you want.

No interposition required, and Apple has set a good precedent for this
technique.

--Kyle Sluder

On Mon, Jan 16, 2012 at 1:56 PM, John Hawkinson <[email protected]> wrote:
> Thanks for the inspiration, Kevin.
>
>> (Certainly a solution that works for all apps is more along the lines
>> of what I am looking for than a solution that works for just one. But
>> I suppose an LD_PRELOAD -- err, I mean DYLD_INSERT_LIBRARIES -- of a
>> signal handler is a possibility if the more general solution doesn't
>> pan out).
>
> Actually, an easier answer is to interpose loginwindow's call to kill(),
> because it doesn't seem to call kill() very often.
> As a first cut, the attached seems to work. Tested under 10.6.8.
>
> I vaguely wonder how hard it would be to add a button next to Force
> Quit (easy: just edit the nib), wired up the same way, and then have
> the interposition handler determine which button was pressed (I really
> have no idea on that one).
>
> In this implementation, loginwindow sends SIGTERM which gets converted
> to SIGABRT, and then since writing core dumps takes awhile, it sends
> a SIGKILL as well. But that's OK, because once the kernel has started
> writing the core dump, SIGKILL does no harm.
>
> [email protected]
> =A0John Hawkinson