Jsdom: TypeError: Cannot read property '_location' of null on ubuntu 16.10

[capaj]

Here's the important bit of my output:

 RUNS  src/components/Analyse/Widget/Criteria/DateRange.test.js
/home/capaj/git_projects/be/frontend-be.com/node_modules/jsdom/lib/jsdom/browser/Window.js:148
      return idlUtils.wrapperForImpl(idlUtils.implForWrapper(window._document)._location);
                                                                              ^

TypeError: Cannot read property '_location' of null
    at Window.get location [as location] (/home/capaj/git_projects/be/frontend-be.com/node_modules/jsdom/lib/jsdom/browser/Window.js:148:79)
    at Timeout.callback [as _onTimeout] (/home/capaj/git_projects/be/frontend-be.com/node_modules/jsdom/lib/jsdom/browser/Window.js:525:40)
    at ontimeout (timers.js:380:14)
    at tryOnTimeout (timers.js:244:5)
    at Timer.listOnTimeout (timers.js:214:5)

This happens with jest 19.0.2, node 7.7.2 and jsdom "9.11.0".
My colleagues with Macbooks don't get this error. I get it randomly in any testcases which happen to run at that time.

[capaj]

I tried the most primitive way of patching that exception:
https://github.com/tmpvar/jsdom/compare/master...capaj:patch-1?expand=1

With that I don't get any exceptions but my test run is very slow and I get this at the end:

Test Suites: 1 skipped, 79 passed, 79 of 80 total
Tests:       4 skipped, 218 passed, 222 total
Snapshots:   64 passed, 64 total
Time:        212.404s
Ran all test suites.

<--- Last few GCs --->

[30549:0x4114690]  3066195 ms: Scavenge 1355.7 (1427.3) -> 1355.2 (1427.3) MB, 7.2 / 0.0 ms  allocation failure 
[30549:0x4114690]  3074012 ms: Scavenge 1355.9 (1427.3) -> 1355.4 (1427.3) MB, 6.7 / 0.0 ms  allocation failure 
[30549:0x4114690]  3081466 ms: Scavenge 1356.1 (1427.3) -> 1355.6 (1427.3) MB, 7.4 / 0.0 ms  allocation failure 
[30549:0x4114690]  3089299 ms: Scavenge 1356.4 (1427.3) -> 1355.8 (1427.3) MB, 7.9 / 0.0 ms  allocation failure 


<--- JS stacktrace --->
Cannot get stack trace in GC.
FATAL ERROR: Scavenger: promoting marked
 Allocation failed - process out of memory
 1: node::Abort() [node]
 2: 0x12b78dc [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: 0xa98dfb [node]
 6: void v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::PromotionMode)0, (v8::internal::LoggingAndProfiling)1>::EvacuateObject<(v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::PromotionMode)0, (v8::internal::LoggingAndProfiling)1>::ObjectContents)1, (v8::internal::AllocationAlignment)0>(v8::internal::Map*, v8::internal::HeapObject**, v8::internal::HeapObject*, int) [node]
 7: 0xeca1c3 [node]
 8: v8::internal::Heap::Scavenge() [node]
 9: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
10: v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [node]
11: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
12: v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
13: 0x802474843a7
Aborted (core dumped)

[domenic]

Please post a repro that does not involve third party libraries like jest, and that I can run. Error messages are not sufficient to debug your problem. Will reopen if such a repro is provided.

[cdaringe]

@capaj, did you find a solution?

[capaj]

Not really. I tried running jest in multiple workers and that helped. It would still popup once a while but it did not fail the tests. I don't think I'll be able to reproduce it on a smaller scale.

[rahimrahman]

@capaj, I'm on a Macbook and I get this quite often. Sometimes it crashes my test, sometimes it doesn't.

@domenic what do I need to post to help? What's a repro?

[domenic]

If you open a new issue you'll see an issue template you can fill out; please pay attention to the requirements there.

[rickyk586]

@domenic I believe this is a race condition with window.close() deleting this._document and stopping the timers. It would probably fix it to ensure the timers are all stopped before deleting it.

I notice that get location() is being called from a timer AFTER calling window.close()

[khrome83]

I am seeing this issue is well. I can't share my code, because I have no clue what is triggering this. It shows when I run my jest tests.

The funny thing is that on my MacBook Pro, I don't see it. But in my CI environment which is Linux based I do.

I never saw it before today.

[soulprovidr]

In case anyone else is running into this issue, this is what worked for me in Fedora 25:

yarn add jest jest-cli
yarn global add jest jest-cli

After running these commands, I stopped seeing this error.

[ryanhomer]

I haven't quite figured out exactly why I got this error message but I'll note my situation here in case it helps someone. In my case I have two separate Jest tests in one test file. Each of the tests uses a redux store backed by a mock LocalStorage that's stored in global.localStorage via JSDOM. I am rendering with enzyme's mount.

When I use Jest's beforeAll function to set up my store var and attempt to use this store for both tests, I get the '_location' error. However, when I use beforeEach instead which sets up a new store for the second test (still using the same common store var), then the tests go through without the error.

I do not see why reusing the existing store should cause an issue but it seems like something is getting cleaned up inadvertently before the second test starts.

[brandonaaskov]

This is currently the only open issue tracking this problem: looks like the other ones were closed down due to lack of a way to reproduce it. I too am hitting this, and it's not related to Ubuntu as far as I can tell.

Here are the closed/related issues:

• https://github.com/tmpvar/jsdom/issues/1530
• https://github.com/tmpvar/jsdom/issues/1542
• https://github.com/tmpvar/jsdom/issues/1783
• https://github.com/tmpvar/jsdom/issues/1798
• https://github.com/tmpvar/jsdom/issues/1893
• https://github.com/tmpvar/jsdom/issues/1960

However, @domenic asked for an example that doesn't use a library like Jest. Jest is probably the reason _most_ people are seeing this. But the issue is coming from a file in the jsdom library. If anything, I think you _should_ be using Jest to reproduce the issue. Even if the issue actually is in Jest, it's not perceived that way from users like me when you see an error in the console pointing to a specific line in a specific file provided by jsdom.

[Zirro]

@brandonaaskov Jest is currently using an old version of jsdom (9.12.0), but they will upgrade to version 11.x in their next major release. Until we know whether the issue remains in recent versions, there's not much to do here.

[brandonaaskov]

@Zirro Jest actually _just_ updated to use jsdom@11, but even after upgrading jest I'm still seeing the same issue.

@domenic said he was investigating in issue #1893, but then later just closed the ticket with no feedback.

[domenic]

I remain uninterested in spending my spare time debugging Jest. If people provide any evidence that this problem is caused by jsdom, I'm excited to fix it, but until then, I have to assume it's a problem with Jest, and plan to spend no more time on it.

[brandonaaskov]

@domenic I understand you don't have interest in debugging Jest, but it _is_ kind of the elephant in the room. It's a massively popular library that uses jsdom by default, so I was kind of hoping you'd be more excited to fix it. It doesn't give me the warm and fuzzies that you're so quick to dismiss the issue, no matter how many people bring it up.

[Zirro]

@brandonaaskov While I can see where you're coming from, it is no easier for us to debug this through Jest than it is for you. We're all doing this in our spare time, with this large project being available to you at no cost.

I don't suppose you could help investigate this instead? That would give me the warm-and-fuzzies.

[brandonaaskov]

@Zirro I've been plugging away at it trying to track it down. I actually don't think it's a jsdom issue either, but I still haven't figured out the root cause. I'm building up from the most basic example I can think of to try and reproduce the problem. My current thinking is that it's actually related to one of the redux packages we're using, but we'll see. I'll report back with my findings :)

[Zirro]

@brandonaaskov That's encouraging to hear. Good luck!

[brandonaaskov]

@Zirro and @domenic, I haven't been able to isolate it to the line yet, but I'm 95% sure the culprit is the redux-persist package (at least in my case), which makes sense given its reliance on window. If I completely remove that package from my project, the problem goes away.

I _haven't_ been able to replicate this issue with a standalone project with some basic tests (_not_ including redux-persist yet). This just further shows that jsdom is _not_ the culprit.

I'm about to check out for the weekend but wanted to mention that in case it helps future travelers. I'll keep digging on this over the next week.