Crash reporter can't submit reports without network access

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
11 years ago
9 years ago

People

(Reporter: roman.fiedler, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.9a8pre) Gecko/2007091101 SeaMonkey/2.0a1pre
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/seamonkey-2.0a1pre.en-US.linux-i686.tar.bz2 2007-07-27

Mozilla is used in closed environment to view pages.  Sending of crash-reports is not possible:

* Mozilla does not allow to store report to file so that it could be transfered to a location with full network access. This feature would be also interesting for paranoids, that do not want to send a crash report without reading it first in binary (make feature request for that?)

* When adding host entries for crash-reports.mozilla.com to etc/hosts to intercept the report, then the reporter fails before opening a TCP connection to the report server. Last action is that the OS sends a DNS query for [hostname] to local DNS, although the local name is included in etc/hosts also

When crashreporter comes with report dialog. When 

Reproducible: Always

Steps to Reproduce:
1. Start mozilla on a machine without internet access
2. Crash mozilla
3. Try send report
Actual Results:  
Not possible to gather any information about crash

Expected Results:  
Allow storing of crash report, allow sending to fake http server to intercept

The bug that crashes seamonkey is not present in current nightly, so I cannot verify behavior with new build.
(Reporter)

Updated

11 years ago
Version: unspecified → Trunk

Comment 1

11 years ago
you can always emulate a crash with "kill -SEGV _seamonkey-bin_pid_"
Assignee: general → nobody
Component: General → Breakpad Integration
Product: Mozilla Application Suite → Toolkit
QA Contact: general → breakpad.integration
You can disable the crash reporter via environment variables:
http://developer.mozilla.org/en/docs/Environment_variables_affecting_crash_reporting

We don't currently have any plans for alternate means to submit crash reports.  Changing the IP in /etc/hosts won't work, as the crash reporter submits the report via HTTPS.
Summary: Talkback: Crash reporter failed → Crash reporter can't submit reports without network access
I'm just going to resolve this WONTFIX.  You can disable the crash reporter in this environment, we're not planning on making an alternate method to send crash reports.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX

Comment 4

9 years ago
Bug 378528 makes it easy to resubmit reports if you connect the machine to a network later, btw.
(Reporter)

Comment 5

9 years ago
NP. I just hoped, that the developers had some undocumented but convenient way to extract and read these reports during debugging.

Since the machines in question will not be connected to the IP-Network known as internet at any moment in their whole lifetime, disabling the reporter functionality will be the best solution. Otherwise mozilla would just cause useless audit and IDS events.

Comment 6

9 years ago
in theory the crashes that are collected end up in a folder, and it should be possible to walk the folder plus perhaps some small amount of additional metadata to another computer where the crash reporter could then be used to retransmit the reports.

I've never investigated doing this, and if you can figure out how, i'd imagine we'd accept a wiki entry explaining how to do that.

That said, if you're actually using a truly closed network, I'd expect you don't really want any data leaving the network even by sneakernet. In which case you're better served by collecting the crashes yourself and doing your own analysis. We have a repository of symbols for our builds and some minimal documentation you can use to retrieve them. With those symbols and symbols for the rest of your platform, you should be able to use gdb (on Linux) to retrieve stack traces and then find/file bugs here.
You need to log in before you can comment on or make changes to this bug.