High virtual memory usage on macOS Mojave

angryM3thane

• OS: macOS Mojave.
• 1password version: 1Password 7 Version 7.2.1 (70201002) AgileBits Store.
• Browser: Chrome Version 70.0.3538.77 (Official Build) (64-bit) Stable.
• phenomenon: high virtual memory usage after running for about one and a half days.
• Screenshot:
  

---

1Password Version: 7.2.1
Extension Version: 4.7.3.90
OS Version: Mojave
Sync Type: Dropbox

lopinopulos

I have the same issue. macOS Mojave, last version of 1password. Virtual memory usage
Screenshot:

AGAlumB

Hmm. I'm not seeing that here. What build of Mojave are you using, and when did you first encounter this issue?

MrC

I see it immediately upon launch. All the 1Password components show that VM size.

Mojave: 10.14.1 (18B75)

jw120

Same for me on High Sierra. I have 532G virt for the main app, onepassword-helper and 1Password Extension Helper.

AGAlumB

I probably should have asked in the first place to clarify, but what is the difficulty you folks are encountering? The OS handles virtual memory, so it isn't something we have control over. But certainly it would help to know the symptoms you're experiencing if there's a problem in 1Password which needs to be addressed. Thanks!

MrC

These processes have the largest VM range allocated to any processes running on the system minimally by a factor of 4 (WebKit), but on average by about 2 orders of magnitude. So it looks suspicious.

I think the question should be - is this expected and is Agilebits aware of this enormous address range usage?

The statement that "The OS handles virtual memory, so it isn't something we have control over" is only marginally accurate. The OS does indeed handle VM, but it does so on behalf of the requesting program. It is the program that requests large blocks of memory, memory mappings, wired down memory, vast address spaces, etc.

So its worth just double checking that the address ranges are explicitly what was expected.

AGAlumB

@MrC: Absolutely. I'm just trying to get a sense of what the problem might be. You mention WebKit. Are you seeing the same thing without browsers -- especially Safari -- running? 1Password will need exponentially more resources depending on what's open there. You may also see different results with other browsers as opposed to Safari. Safari App Extension is still very new, and there isn't a lot of data to go on yet as far as what is "normal". It's been about a month.

MrC

@brenty,

I'm not noticing any issues, and this may very well be a non-issue.

It seems curious that 1Password will use more "resources", than say, my Firefox with its 40ish open tabs with 1GB resident memory usage and typically < 8GB virtual address space mapped to the process.

The address spaced is mapped the moment anything 1Password starts (main app, mini, extension), so this is not a leak issue; rather, its just something that catches ones attention since the virtual space in use is so large.

fhunleth

I'm seeing this as well - 533G virtual memory size. As far as I can tell, it's not causing me any issues, but it definitely catches one's attention.

I noticed it on the Mojave update, and I think MrC summarized the issue well.

It would be nice to know if this is normal. I'm also curious how 1Password managed this feat.

AGAlumB

@MrC, @fhunleth: Thanks for your comments. I agree with you, but I think there may be one point of confusion: this is an allocation, not actual memory usage. That's why your Macs aren't panicking. I do apologize for the alarm this has caused though. It's unnecessary. We've been looking into it, and I think we may be able to find the cause. I appreciate you (and everyone else here) bringing it to our attention. :)

fhunleth

Thanks for the update. I really hope you can share what is found. My friends and I have a bet on the root cause, but it is not causing us any issues.

Lars

@fhunleth - it really depends on what we discover. Thanks again for bringing it to our attention. :)

AGAlumB

@fhunleth: What's the bet? I don't have a horse in this race, but it may be something we haven't considered...or at the very least we could confirm a winner later on. :lol:

fhunleth

@brenty Well, then our bets are not interesting. The bug ones are stupid things like there was an allocation done as a multiple of page size and Mojave changed the page size being used from the expected 4KB to 2MB or 1GB. The interesting one was that this was done on purpose to make it harder for a malicious app trying to scan 1password's address space for decrypted passwords (or something like that). Ok, so there are flaws in that speculation, but if the large allocation were done on purpose for any vulnerability-related reason at all, we'd give it to them.

AGAlumB

@fhunleth: That sounds pretty interesting, actually. Not a bad theory! I don't think that's it (that would mean the same issue would not present itself on high Sierra, which remains to be seen), but I won't rule it out being a combination of that along with other factors. If we can determine definitively one way or the other, I'll be happy to update the thread to settle the bet. :)

jonduffy

High I am also seeing this issue on Mojave.

MacBook Pro (15-inch, 2018)
2.9 GHz Intel Core i9
32 GB 2400 MHz DDR4
Radeon Pro Vega 20 4080 MB
Intel UHD Graphics 630 1536 MB

Perhaps interestingly, it's not just 1password...

rudy

@jonduffy,

This is expected behavior at this point. We make use of a core library that is written in Go, it is cross-compiled to C and that C runtime package is the thing that's triggering the VM ceiling that you're seeing there. reference

aran_reisman

Hi,

Is there an update as to what is the root cause of this?
I'm seeing this for a while now.

Thanks,
Aran

ag_ana

Hi @aran_reisman!

I believe Rudy's answer, and the link he shared in it, has the explanation for why this is happening:

This is expected behavior at this point. We make use of a core library that is written in Go, it is cross-compiled to C and that C runtime package is the thing that's triggering the VM ceiling that you're seeing there. reference