Build: B2G 18 12/21/2012 Device: Unagi Steps: 1. Try to import a calendar on a data connection Expected: The calendar should be successfully imported. Actual: The calendar app abnormally terminates the process (SIGKILL). 100% reproducible too. Interesting piece of logcat: 12-21 23:06:13.114: I/Gecko(742): [Parent 742] WARNING: waitpid failed pid:1257 errno:10: file ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 260 12-21 23:06:13.124: I/Gecko(742): [Parent 742] WARNING: Failed to deliver SIGKILL to 1257!(3).: file ../../../gecko/ipc/chromium/src/chrome/common/process_watcher_posix_sigchld.cc, line 118

Chris - Is this related to some of the issues we hit with why marketplace dev didn't load in the browser? The behavior here seems quite similar.

Yup.

This one smells like system XHR not using the right context.

Calendar only uses XHR from workers if that helps at all.

(gdb) bt #0 0x405389c4 in mozilla::net::HttpChannelChild::AsyncOpen (this=0x44582800, listener=0x0, aContext=<value optimized out>) at /home/cjones/mozilla/new-b2g/gecko/netwerk/protocol/http/HttpChannelChild.cpp:1040 #1 0x40869e66 in nsXMLHttpRequest::Send (this=0x445a7920, aVariant=<value optimized out>, aBody=<value optimized out>) at /home/cjones/mozilla/new-b2g/gecko/content/base/src/nsXMLHttpRequest.cpp:3095 #2 0x4086a290 in nsXMLHttpRequest::Send (this=0x80, aBody=0xbeb621c0) at /home/cjones/mozilla/new-b2g/gecko/content/base/src/nsXMLHttpRequest.cpp:2768 #3 0x40ac32e6 in (anonymous namespace)::SendRunnable::MainThreadRun (this=0x444d6cc0) at /home/cjones/mozilla/new-b2g/gecko/dom/workers/XMLHttpRequest.cpp:1214 #4 0x40abf926 in (anonymous namespace)::WorkerThreadProxySyncRunnable::Run (this=0x444d6cc0) at /home/cjones/mozilla/new-b2g/gecko/dom/workers/XMLHttpRequest.cpp:843

It looks like we need to be able to GetInterface() from XMLHttpRequest::Proxy through its WorkerPrivate to the PIDOMWindow to TabChild. There should be a helper for the last step already.

Blocks a blocker.

Generalizing this since this bug reproduces if you try to import a calendar with wifi or data connection.

Are you using systemXHR from the worker, or normal XHR? Bobby, this sounds like a good one for you. Most likely we are somehow getting the wrong nsILoadContext for the load here somehow. Note that even worker XHRs are running normal XHR objects on the main thread. So I'm actually inclined to guess that this is more of a system-xhr problem than a worker-xhr problem. But that's a guess.

Ah, missed comments 5-6, sounds like this is a workerxhr problem then? Sorry, my brain is still mushy from being sick all week.

Yeah, fix looks pretty straightforward. I would written a patch already if I weren't deathly afraid of GetInterface() ;).

(In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > It looks like we need to be able to GetInterface() from > XMLHttpRequest::Proxy through its WorkerPrivate to the PIDOMWindow to > TabChild. There should be a helper for the last step already. This requirement surprises me. The XHR's channel is part of the document loadgroup, and I would have expected the nsITabChild to be reachable through the loadgroup's notification callbacks.

Re #9 systemXHR from a worker.

So, after having spent about a day trying to reproduce, here's where I am with this: * Given what I've found poking around the calendar UI, I'm not entirely sure what it means to "import a calendar". My best guess is that it involves adding an account in the settings pane of the calendar. I'm testing by adding one of my gmail accounts. If this is incorrect, please let me know. * I can't reproduce it in a b2g desktop build, presumably because there needs to be OOP involved, which is disabled for desktop b2g builds. I've enabled OOP, but ran into a segfault in the content process on startup. I filed bug 824581 and wrote a patch, which lets me boot. However, any time I try to do anything that involves the content process, the IPC layout code freaks out and prints a bunch of "WARNING: Remote iframe not rendered: file /files/mozilla/repos/t/layout/ipc/RenderFrameParent.cpp, line 670". Nobody I've asked knows what the deal is, but presumably the answer has something to do with OOP-on-desktop being unsupported. * I tried to make an emulator-x86 build, but the build failed. I investigated and finally filed a bug on NSPR: bug 824742. I wrote a patch there, waiting for wtc's review. With that patch, the emulator builds and boots. I can successfully enter in my google credentials and have events from my google account appear on the phone no crashes. cjones, what exactly were you doing when you reproduced this in comment 5?

The other important bit is to have the patches from bug 782542 applied :)

(In reply to Josh Matthews [:jdm] from comment #15) > The other important bit is to have the patches from bug 782542 applied :) Yup, that's right. If you test this on trunk right now, importing the calendar will work. So you need to: 1. Apply the patches from bug 782542 2. Launch calendar 3. Select add an account 4. Provide valid account info and save it

(In reply to Josh Matthews [:jdm] from comment #15) > The other important bit is to have the patches from bug 782542 applied :) How was I supposed to know that? :\

I just talked to jst about this. I'm lacking a lot of context here, both in terms of code (I don't know anything about necko/ipc) and history (nothing in this bug indicated that it required applying other patches, though this was obvious to others). So working on this is coming with a pretty extreme drop in effectiveness compared to the other work I could be doing. Since cjones seems to know what to do in comment 11, it's not clear that it makes sense for me to work on this. cjones/jdm, is this something you can throw together a patch for in half an hour? Reassigning to nobody just to make sure this gets noticed.

I actually think that cjones proposed solution isn't entirely right. We should be picking up the right context through the notifications callbacks on the loadgroup. But yes, my bad, Bobby is probably not the best assignee.

Hum. I can't reproduce this problem in a desktop build with all relevant patches applied. I'm stepping through the channel creation in the chrome process, and we always receive the correct PBrowser actor over the wire.

Jason/Chris, do you have any more concrete steps? I've been using my Mozilla account with no success.

I just tried to add a zimbra account, and boom.

More precisely, my STR were (1) Try to add zimbra calendar

We established that the patch from bug 753981 is not present on mozilla-b2g18 and is present on mozilla-central, leading to the behaviour discrepancy.

Fixed bug uplifting bug 753981.

Importing a calendar appears to work again with that uplift and the other patch landed. Marking as verified.