Closed Bug 693531 Opened 9 years ago Closed 9 years ago

Caught unexpected exception Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE)

Categories

(Cloud Services :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 704539

People

(Reporter: hmmwhatsthisdo, Unassigned)

References

Details

Attachments

(3 files)

Got a yellow error bar with the "Server Incorrectly Configured" text. It's been happening intermittently, which is rather odd. If it happens again, I might upload another log.
Thanks for your report. We've gotten a handful of user reports for this so far, so any data is useful.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm not entirely sure it will help, but if you could provide us with some detailed log output that'd be great:

* Go to about:config and change 'services.sync.log.logger.network.resources' to 'Trace' (without the single quotes and with the capital T)
* Restart the browser.
* Wait for the error to happen again.

Note that the log may now contain confidential data such as the keys that are downloaded from server. Be sure to obfuscate or remove actual data (it's easily recognized, it's base64 encoded.)
Attachment #566132 - Attachment description: Another failoed sync, this time with services.sync.log.logger.network.resources set to Trace. → Another failed sync, this time with services.sync.log.logger.network.resources set to Trace.
Also, it would appear that the two debug-enabled logs are exactly the same, with the only difference being the timestamps.
Thanks for the log. No solution yet, but every little helps...
:atoll and I received client logs from Hmmwhatsthisido.

There were a few interesting patterns that amount to what :atoll says are a few server-side bugs. Not sure if they are related to this bug or not. He seemed to have a better grasp on it, so I'll let him chime in...
In this specific log, there is evidence that a PUT 200 was followed immediately by a GET 404, which supposedly is a broken place, and appears to have directly preceded the crash. I need to review the detailed protocol overview to be certain, but that's my concern from the log attached.  Others with more keyex knowledge may wish to chime in.
(In reply to Richard Soderberg [:atoll] from comment #8)
> In this specific log, there is evidence that a PUT 200 was followed
> immediately by a GET 404, which supposedly is a broken place, and appears to
> have directly preceded the crash. I need to review the detailed protocol
> overview to be certain, but that's my concern from the log attached.  Others
> with more keyex knowledge may wish to chime in.

atoll: where does keyex tie in to this? None of the logs in this bug are during setup.

If you're seeing 404s in J-PAKE, I wonder if there's a link to Bug 699916. Can you un-confuse me?
This is possibly fixed in bug 690170 (Firefox 10). If not, it is almost certainly fixed in bug 704539 (Firefox 12).

If you still experience the issue after upgrading, please reopen this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 704539
You need to log in before you can comment on or make changes to this bug.