Bug report built into OSX
-
Hello,
I am wondering if it is possible to set values in your application which
would cause the crash reporter that comes up when an application crashes,
to send the report to you.
I don't mean hacking into the system I'm just wondering if apple provided
a means by which to pass values so that the info in the crash reporter can
be sent to the developer of the application.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
At 18:28 Uhr -0400 22.08.2004, <lazee...> wrote:> I don't mean hacking into the system I'm just wondering if apple provided
> a means by which to pass values so that the info in the crash reporter can
> be sent to the developer of the application.
Nope, there's no official way, AFAIK.
However, Avi Drissmann (I think) did a hack this year at ADHOC
(which I had the pleasure to attend), which allowed customizing where
the crash log gets sent. You may want to try getting ahold of that.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> I don't mean hacking into the system I'm just wondering if apple
>> provided
>> a means by which to pass values so that the info in the crash
>> reporter can
>> be sent to the developer of the application.
>
> Nope, there's no official way, AFAIK.
>
> However, Avi Drissmann (I think) did a hack this year at ADHOC (which
> I had the pleasure to attend), which allowed customizing where the
> crash log gets sent. You may want to try getting ahold of that.
I've looked over the 'net for this, and can't seem to find it. Anyone
have details? :)
Alternatively, is there a way to hook into the crash reporter behavior
yourself to put up your own version of the dialog?
--
Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist
"If it is not broken, give me five minutes to redesign it!"
[demime 0.98b removed an attachment of type application/pgp-signature which had a name of PGP.sig]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'm not quite sure about this,
but look into www.adiumx.com
They have been able to do this with their chat program, and it is open
source,
so you might want to take a look at their source.
Matt
On Aug 24, 2004, at 2:06 PM, Rachel Blackman wrote:>>> I don't mean hacking into the system I'm just wondering if apple_______________________________________________
>>> provided
>>> a means by which to pass values so that the info in the crash
>>> reporter can
>>> be sent to the developer of the application.
>>
>> Nope, there's no official way, AFAIK.
>>
>> However, Avi Drissmann (I think) did a hack this year at ADHOC (which
>> I had the pleasure to attend), which allowed customizing where the
>> crash log gets sent. You may want to try getting ahold of that.
>
> I've looked over the 'net for this, and can't seem to find it. Anyone
> have details? :)
>
> Alternatively, is there a way to hook into the crash reporter behavior
> yourself to put up your own version of the dialog?
>
> --
> Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist
> "If it is not broken, give me five minutes to redesign it!"
>
> [demime 0.98b removed an attachment of type application/pgp-signature
> which had a name of PGP.sig]
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 24, 2004, at 1:06 PM, Rachel Blackman wrote:> Alternatively, is there a way to hook into the crash reporter behavior
> yourself to put up your own version of the dialog?
We did something similar. We caught all exceptions, forked a crash
handler and then wrote all the information to a file. Then we throw up
a dialog box explaining what happened and asking if the user wants to
open the file. We don't have a mail button although I doubt that it'd
be too hard to do.
If anyone wants the code, I can post links to it.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
> I've looked over the 'net for this, and can't seem to find it.
> Anyone have details? :)
I think http://www.adhocconf.com should be offering the CD-ROM. And
they also have blog links at "Friday Flashbacks", which should get
you Avi's site.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 24 Aug 2004, at 23:35, Steve Checkoway wrote:> On Aug 24, 2004, at 1:06 PM, Rachel Blackman wrote:The following message was on carbon-dev a while ago. I've used it from
>> Alternatively, is there a way to hook into the crash reporter behavior
>> yourself to put up your own version of the dialog?
>
> We did something similar. We caught all exceptions, forked a crash
> handler and then wrote all the information to a file. Then we throw up
> a dialog box explaining what happened and asking if the user wants to
> open the file. We don't have a mail button although I doubt that it'd
> be too hard to do.
>
>
CFM and Mach-O carbon projects and I don't see why it wouldn't work in
a Cocoa project since all it is doing is add handlers for the relevant
signals that launch the reporting application.
Fred> Message: 22_______________________________________________
> Date: Wed, 6 Aug 2003 13:19:42 -0400
> To: Carbon-Dev <carbon-development...>
> From: "Mark J. Lilback" <mark...>
> Subject: Re: Crashing in 7B21 (Re: Logs folder)
>
> Multiple people have expressed interest in my crash catching code, so
> I've uploaded it to
> <http://www.rtlabs.com/downloads/CrashCatcher.tgz>.
>
> It consists of a PB project to build a CFBundle that is loaded by my
> CFM application (sample code for that is included in the ReadMe
> file). The project also builds a reporting application that grabs the
> crash log, prompts for more information, and then sends us the crash
> report.
>
> The reporting application is Cocoa, but all the code fits in one
> source file of 263 lines. So it is also a good example of a simple
> Cocoa application that is actually useful.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> Multiple people have expressed interest in my crash catching code, so
>> I've uploaded it to
>> <http://www.rtlabs.com/downloads/CrashCatcher.tgz>.
Please check your links before you post - this one is broken.
Wade Tregaskis (aim: wadetregaskis, icq: 40056898)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
We redesigned our website last month and the link was broken in the
process. I've fixed it so it should work again.
The one thing I haven't figured out how to do is disable the Apple
dialog. I have had customers ask why they are prompted twice.
Fortunately, the volume of crash reports has decreased by multiple
orders of magnitude now that we've shipped our Cocoa version. Took
about one man year to rewrite a 160,000 line Carbon/PowerPlant
application as a 100,000 line Cocoa application with some major new
features.
At 1:35 PM +1000 8/25/2004, Wade Tregaskis wrote:>>> Multiple people have expressed interest in my crash catching code, so
>>> I've uploaded it to
>>> <http://www.rtlabs.com/downloads/CrashCatcher.tgz>.
>
>
--
__________________________________________________________________________
"The fetters imposed on liberty at home have ever
Mark J. Lilback been forged out of the weapons provided for
<mark...> defence against real, pretended, or imaginary
http://www.lilback.com/ dangers from abroad." -- James Madison
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 25, 2004, at 8:02 AM, Mark J. Lilback wrote:> The one thing I haven't figured out how to do is disable the Apple
> dialog. I have had customers ask why they are prompted twice.
Exactly! This is a problem that I have as well. If anyone knows what
causes this dialog to pop up, then perhaps I could quit the application
in such a way as to avoid it once my custom crash handler has finished.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 26.8.2004, at 21:20, Steve Checkoway wrote:> Exactly! This is a problem that I have as well. If anyone knows what
> causes this dialog to pop up, then perhaps I could quit the
> application in such a way as to avoid it once my custom crash handler
> has finished.
At the first look, perhaps -[NSApplication terminate:] might be a good
bet?
---
Ondra Hada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
At 12:20 PM -0700 8/26/04, Steve Checkoway wrote:> On Aug 25, 2004, at 8:02 AM, Mark J. Lilback wrote:
>> The one thing I haven't figured out how to do is disable the Apple
>> dialog. I have had customers ask why they are prompted twice.
>
> Exactly! This is a problem that I have as well. If anyone knows what
> causes this dialog to pop up, then perhaps I could quit the
> application in such a way as to avoid it once my custom crash
> handler has finished.
It appears that some parent of the processes is listening for signals
in the children - for example, if you install a handler for sigsegv
and then explicitly do something to cause a segv, the "application
quit unexpectedly" dialog comes up - even if you caught the signal
and carried resumed execution. (See man 2 wait for more details on
how to wait until a signal is delivered in the child).
I ran into this on a debugging "IsPointerValid" utility routine
(where it checks to see if it is safe to derference the address).
There doesn't appear to be anyway around this as near as I can tell
(since even if you catch the signal, the parent still finds out about
it).
--
Glenn Andreas <gandreas...>
mondo blobbo, Cythera, Theldrow, oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 26, 2004, at 1:17 PM, Ondra Cada wrote:> On 26.8.2004, at 21:20, Steve Checkoway wrote:
>
>> Exactly! This is a problem that I have as well. If anyone knows what
>> causes this dialog to pop up, then perhaps I could quit the
>> application in such a way as to avoid it once my custom crash handler
>> has finished.
>
> At the first look, perhaps -[NSApplication terminate:] might be a good
> bet?
Not really an option. The code is about 99% c++ and 1% Objective-C++.
Even that little bit of Obj-C++ will go away once I have nothing better
to do. For it's internals, it does rely on SDL for video (it's cross
platform code, it runs on OS X, Linux, and Windows) which does use a
little Obj-C but that's deep inside the library anyway.
Currently, the crashed process forks a child to handle the reporting of
the error as well as decoding the stack backtrace and writing all the
information to a file. Then the child kills the parent with
kill(getppid(), SIGKILL);
Killing other applications with kill -9 from the command line doesn't
bring up the crashed dialog box.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 26, 2004, at 1:51 PM, Glenn Andreas wrote:> I ran into this on a debugging "IsPointerValid" utility routine (where
> it checks to see if it is safe to derference the address). There
> doesn't appear to be anyway around this as near as I can tell (since
> even if you catch the signal, the parent still finds out about it).
Have you filed a bug report for this?
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 26, 2004, at 1:51 PM, Glenn Andreas wrote:> At 12:20 PM -0700 8/26/04, Steve Checkoway wrote:
>> On Aug 25, 2004, at 8:02 AM, Mark J. Lilback wrote:
>>> The one thing I haven't figured out how to do is disable the Apple
>>> dialog. I have had customers ask why they are prompted twice.
>>
>> Exactly! This is a problem that I have as well. If anyone knows what
>> causes this dialog to pop up, then perhaps I could quit the
>> application in such a way as to avoid it once my custom crash handler
>> has finished.
>
> It appears that some parent of the processes is listening for signals
> in the children - for example, if you install a handler for sigsegv
> and then explicitly do something to cause a segv, the "application
> quit unexpectedly" dialog comes up - even if you caught the signal and
> carried resumed execution. (See man 2 wait for more details on how to
> wait until a signal is delivered in the child).
>
> I ran into this on a debugging "IsPointerValid" utility routine (where
> it checks to see if it is safe to derference the address). There
> doesn't appear to be anyway around this as near as I can tell (since
> even if you catch the signal, the parent still finds out about it).
Don't you just hate parents... they always found out about the stuff I
did... ohh I hated that.
-Shawn
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Mark J. Lilback (<mark...>) on Wed, Aug 25, 2004 11:02 said:> The one thing I haven't figured out how to do is disable the Apple
> dialog. I have had customers ask why they are prompted twice.
You may want to check the Carbon-development list archives for the thread
titled "Supressing the Apple "send a bug report" dialog" started 2003-11-19.
Also check out:
defaults write com.apple.CrashReporter DialogType <setting>
The currently available settings are:
"none" = don't show any dialog at all (crash reports are still silently
written to disk)
"prompt" = show the unexpectedly quit dialog and prompt to see if the
user wants to submit/view the crashreport.
"crashreport" = don't show the unexpectedly quit dialog - instead
immediately show the crashreport/submission screen.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 27, 2004, at 2:50PM, Sean McBride wrote:> defaults write com.apple.CrashReporter DialogType <setting>
But doesn't that disable the crash reporter for ALL apps? Seems like
it would be better if the crash reporter allowed setting these values
for each bundle ID, in addition to a global setting to use when there
is no setting for a bundle ID.
-Frank
------------------------------------
Frank M. Midgley
<knarf...>
http://homepage.mac.com/knarf/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 27, 2004, at 2:57 PM, Frank Midgley wrote:> On Aug 27, 2004, at 2:50PM, Sean McBride wrote:
>
>> defaults write com.apple.CrashReporter DialogType <setting>
>
> But doesn't that disable the crash reporter for ALL apps? Seems like
> it would be better if the crash reporter allowed setting these values
> for each bundle ID, in addition to a global setting to use when there
> is no setting for a bundle ID.
That does indeed sound like a good idea.
Now having read all of these e-mails, as well as many of them in the
Carbon list's thread pointed out earlier as well as
http://developer.apple.com/qa/qa2001/qa1288.html, I'm left with just
one little problem:
When I first tried to read the current value I got
$ defaults read com.apple.CrashReporter DialogType
2004-08-27 23:31:13.680 defaults[10339]
The domain/default pair of (com.apple.CrashReporter, DialogType) does
not exist
Of course, after writing the value, I could read it. I'm going to guess
that it default is prompt if it that key/value pair doesn't exist.
Anyone know for sure?
This is really a hassle that we shouldn't have to deal with. For one
thing, we need to check the system version because according to that
tech note, this only works for 10.3.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
In case anyone is interested, this might be of some use:
#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>
#include <string.h>
#include <assert.h>
#include <sys/wait.h>
#include <stdlib.h>
enum
{
error = -1,
none,
prompt,
crashreport
};
static const char *const CrashReportStrings[] = {"none", "promp",
"crashreport"};
int GetCrashReportSetting()
{
int fds[2];
char buffer[16];
ssize_t ret;
size_t len;
int i;
if (pipe(fds))
return error;
switch (fork())
{
case -1: /* error */
return error;
case 0: /* child */
close(0);
close(fds[0]);
if (dup2(fds[1], 1) == -1)
exit(error);
execl("/usr/bin/defaults", "/usr/bin/defaults", "read",
"com.apple.CrashReporter", "DialogType", NULL);
_exit(error);
}
close(fds[1]);
memset(buffer, 0, 16);
len = 0;
while (16 - len > 0 && (ret = read(fds[0], buffer + len, 16 - len)) >
0)
len += ret;
close(fds[0]);
if (ret == -1)
return error;
if (len == 16) /* more output means it's likely not set */
return prompt; /* return default */
if (buffer[len - 1] == '\n' )
buffer[len - 1] = '\0';
for (i = none; i <= crashreport; ++i)
if (!strcmp(CrashReportStrings[i], buffer))
return i;
/* none of the above, return the default */
return prompt;
}
int SetCrashReportSetting(int type)
{
pid_t pid;
int status;
assert(none <= type && crashreport >= type);
switch((pid = fork()))
{
case -1:
return error;
case 0:
close(0);
/*close(1);*/
close(2);
execl("/usr/bin/defaults", "/usr/bin/defaults", "write",
"com.apple.CrashReporter", "DialogType",
CrashReportStrings[type], NULL);
_exit(error);
}
waitpid(pid, &status, 0);
return WIFEXITED(status) && !WEXITSTATUS(status) ? 0 : -1;
}
It hasn't exactly been extensively tested, but a simple test seemed to
work. If I've made any mistakes, please let me know.
- Steve
On Aug 27, 2004, at 11:40 PM, Steve Checkoway wrote:> On Aug 27, 2004, at 2:57 PM, Frank Midgley wrote:_______________________________________________
>
>> On Aug 27, 2004, at 2:50PM, Sean McBride wrote:
>>
>>> defaults write com.apple.CrashReporter DialogType <setting>
>>
>> But doesn't that disable the crash reporter for ALL apps? Seems like
>> it would be better if the crash reporter allowed setting these values
>> for each bundle ID, in addition to a global setting to use when there
>> is no setting for a bundle ID.
>
> That does indeed sound like a good idea.
>
> Now having read all of these e-mails, as well as many of them in the
> Carbon list's thread pointed out earlier as well as
> http://developer.apple.com/qa/qa2001/qa1288.html, I'm left with just
> one little problem:
> When I first tried to read the current value I got
> $ defaults read com.apple.CrashReporter DialogType
> 2004-08-27 23:31:13.680 defaults[10339]
> The domain/default pair of (com.apple.CrashReporter, DialogType) does
> not exist
>
> Of course, after writing the value, I could read it. I'm going to
> guess that it default is prompt if it that key/value pair doesn't
> exist. Anyone know for sure?
>
> This is really a hassle that we shouldn't have to deal with. For one
> thing, we need to check the system version because according to that
> tech note, this only works for 10.3.
>
> - Steve
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 28, 2004, at 12:47 AM, Steve Checkoway wrote:>
> static const char *const CrashReportStrings[] = {"none", "promp",
> "crashreport"};
It'd help if I could spell prompt correctly.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 28 Aug 2004, at 08:47, Steve Checkoway wrote:> execl("/usr/bin/defaults", "/usr/bin/defaults", "read",
> "com.apple.CrashReporter", "DialogType", NULL);
>
> It hasn't exactly been extensively tested, but a simple test seemed to
> work. If I've made any mistakes, please let me know.
Using /usr/bin/defaults instead of CFPreferences? :-)
-- Finlay
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Aug 28, 2004, at 2:05 AM, Finlay Dobbie wrote:> Using /usr/bin/defaults instead of CFPreferences? :-)
Yes, that would make things a bit easier wouldn't it? I didn't know
such a thing existed, although I probably should have guessed it would.
- Steve
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
