1826392 - Crash [ @ GoogleDesktopNetwork3.pdb@0x12ffe ]

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[:gerard-majax]

Reported on https://www.mathies.com/mozilla/crashes/utilrelease.html but no crash on crash-stats.

Top 3, and many clients, so likely interesting.

GoogleDesktopNetwork3.pdb seems to point to Google Search Desktop

0  kernelbase.pdb RaiseException
1  GoogleDesktopNetwork3.pdb 0x12ffe
2  GoogleDesktopNetwork3.pdb 0x8345
3  GoogleDesktopNetwork3.pdb 0xb955

it fails with ERROR_MOD_NOT_FOUND

Comment 1

[:gerard-majax]

Should be blocked already? https://searchfox.org/mozilla-central/rev/8433b62e54fd30663e82f090c4d31554531a2e66/toolkit/xre/dllservices/mozglue/WindowsDllBlocklistDefs.in#49-51

Comment 2

[Yannis Juglaret [:yannis]]

(In reply to Alexandre LISSY :gerard-majax from comment #1)

Should be blocked already? https://searchfox.org/mozilla-central/rev/8433b62e54fd30663e82f090c4d31554531a2e66/toolkit/xre/dllservices/mozglue/WindowsDllBlocklistDefs.in#49-51

Only UNVERSIONED variants of the DLLs are blocked, which, as the comment suggests, means old versions in this case. Those are variants of the DLL which do not specify a version number.

Comment 3

[Yannis Juglaret [:yannis]]

Note also that the DLL is listed is chromium's own list of DLLs "known (or under strong suspicion) of causing crashes when they are loaded in the renderer".

Comment 4

[:gerard-majax]

(In reply to Yannis Juglaret [:yannis] from comment #3)

Note also that the DLL is listed is chromium's own list of DLLs "known (or under strong suspicion) of causing crashes when they are loaded in the renderer".

From reading that list, they block everything? Should we just update and do the same?

Comment 5

[Yannis Juglaret [:yannis]]

(In reply to Alexandre LISSY :gerard-majax from comment #4)

(In reply to Yannis Juglaret [:yannis] from comment #3)

Note also that the DLL is listed is chromium's own list of DLLs "known (or under strong suspicion) of causing crashes when they are loaded in the renderer".

From reading that list, they block everything? Should we just update and do the same?

Yes it seems that they block these DLLs unconditionally in sandboxed processes. It looks like the chromium sandbox code has four folders (win, linux, mac, policy) of which we use two (win, linux), and this code lives in policy. If we're not relying on policy because we want to do our own things, then maybe we should just add all the DLLs in their list to our blocklist for sandboxed processes, independently of DLL version. Bob would know better whether it's intentional that we don't use the policy folder, I don't know about this part.

Comment 6

[Bob Owen (:bobowen)]

(In reply to Yannis Juglaret [:yannis] from comment #5)

(In reply to Alexandre LISSY :gerard-majax from comment #4)

(In reply to Yannis Juglaret [:yannis] from comment #3)

Note also that the DLL is listed is chromium's own list of DLLs "known (or under strong suspicion) of causing crashes when they are loaded in the renderer".

From reading that list, they block everything? Should we just update and do the same?

Yes it seems that they block these DLLs unconditionally in sandboxed processes. It looks like the chromium sandbox code has four folders (win, linux, mac, policy) of which we use two (win, linux), and this code lives in policy. If we're not relying on policy because we want to do our own things, then maybe we should just add all the DLLs in their list to our blocklist for sandboxed processes, independently of DLL version. Bob would know better whether it's intentional that we don't use the policy folder, I don't know about this part.

Yes, as I understand it for windows, this folder holds some cross-process utility code for their sandbox policy setup, which is used by the process specific code where a fair bit of the logic for the policy setup exists.
Having said that even in sandbox_win.cc, for example, there is a lot of process specific logic for various parts of the policy set up.
So, using this in our code would be problematic and we have our own policy set up code.

Over that particular DLL I guess we could move to blocking all versions (or maybe we can block unversioned and before a certain version).
I don't think we should just copy their list wholesale as that might cause more problems that it solves.
I think its main use for us is just to see that chromium based browsers also have a problem with a particular DLL.

Comment 7

[:gerard-majax]

Attachment: blocklist questionnaire

Comment 8

[:gerard-majax]

Attachment: Bug 1826392 - Block GoogleDesktopNetwork3.dll from Utility r?gstoll!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b821cac9ad43
Block GoogleDesktopNetwork3.dll from Utility r=gstoll

Comment 10

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b821cac9ad43

Comment 11

[:gerard-majax]

I was wondering the other day why we still see this on recent builds, and from bug 1837242 it looks like we might not block ...