Bugzilla

I don't have a good handle on all the information that can be included in `__crash_info`. But, like I said in comment #0, I'm confident it's all very low-level. For example I doubt it can ever contain a URL. This is helped by the fact that Gecko tends to do everything itself, and not rely on system code for any high-level stuff. I'll know more when I've finished my survey of the `__crash_info` sections in all the system modules that Firefox pulls in which have one. That's only about 50 modules. They shouldn't take too long to work through.

The only `__crash_info` section I'm already familiar with is the one in `/System/Library/PrivateFrameworks/GPUSupport.framework/Libraries/libGPUSupportMercury.dylib`. Code in its `gpusGenerateCrashLog.cold.1()` can write either of the following two messages to `__crash_info`'s 'signature_string' field:

        Graphics kernel error: 0x%08x\\n

        Graphics hardware encountered an error and was reset: 0x%08x\\n

> Where do the rest of them come from?

One place to see all the fields is in the code I added to `ConvertProcessStateToJSON()`, [here](https://github.com/mozilla-services/minidump-stackwalk/pull/29/commits/013f0bcbd855be09d127834fc1864fa2d128c247#diff-4daf899ce753adf1eaf342f4240837dfe7505e5319fdc1fb5f116a7081045f00R807).

I agree that `num_records` won't be interesting to most people. But *I'm* quite interested in it. The reason is that I don't what's the largest number of records that's practically possible, or even the number to expect in a "typical" crash report.

The other fields are self-explanatory, I think. Any of them might contain critically useful information. Because Apple hasn't documented `__crash_info`, I don't really know what to expect. Aside from the research I've promised to do into those 50 modules I mentioned above, I have no way of finding out except to look at them as they come in. Unless these fields are searchable, doing that will be like looking for a needle in a haystack.

You should probably treat all the "string" fields (`message`, `signature_string`, `backtrace` and `message2`) as free-form strings. Searching on them should mean finding out whether or not they contain a given substring. The other fields (`thread`, `dialog_mode` and `abort_cause`) are numeric -- at least Apple's very sparse documentation seems to indicate that.

> Examples of sensitive data that shouldn't be public:

Thanks very much for these! Your list is very helpful.

I don't have a good handle on all the information that can be included in `__crash_info`. But, like I said in comment #0, I'm confident it's all very low-level. For example I doubt it can ever contain a URL. This is helped by the fact that Gecko tends to do everything itself, and not rely on system code for any high-level stuff. I'll know more when I've finished my survey of the `__crash_info` sections in all the system modules that Firefox pulls in which have one. That's only about 50 modules. They shouldn't take too long to work through.

The only `__crash_info` section I'm already familiar with is the one in `/System/Library/PrivateFrameworks/GPUSupport.framework/Libraries/libGPUSupportMercury.dylib`. Code in its `gpusGenerateCrashLog.cold.1()` can write either of the following two messages to `__crash_info`'s 'signature_string' field:

        Graphics kernel error: 0x%08x\\n

        Graphics hardware encountered an error and was reset: 0x%08x\\n

> Where do the rest of them come from?

One place to see all the fields is in the code I added to `ConvertProcessStateToJSON()`, [here](https://github.com/mozilla-services/minidump-stackwalk/pull/29/commits/013f0bcbd855be09d127834fc1864fa2d128c247#diff-4daf899ce753adf1eaf342f4240837dfe7505e5319fdc1fb5f116a7081045f00R807).

I agree that `num_records` won't be interesting to most people. But *I'm* quite interested in it. The reason is that I don't what's the largest number of records that's practically possible, or even the number to expect in a "typical" crash report.

The other fields are self-explanatory, I think. Any of them might contain critically useful information. Because Apple hasn't documented `__crash_info`, I don't really know what to expect. Aside from the research I've promised to do into those 50 modules I mentioned above, I have no way of finding out except to look at crash reports as they come in. Unless these fields are searchable, doing that will be like looking for a needle in a haystack.

You should probably treat all the "string" fields (`message`, `signature_string`, `backtrace` and `message2`) as free-form strings. Searching on them should mean finding out whether or not they contain a given substring. The other fields (`thread`, `dialog_mode` and `abort_cause`) are numeric -- at least Apple's very sparse documentation seems to indicate that.

> Examples of sensitive data that shouldn't be public:

Thanks very much for these! Your list is very helpful.