Closed Bug 1516133 Opened 6 years ago Closed 6 years ago

nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures triggered twice to the main thread

Categories

(Toolkit :: Safe Browsing, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla66
Tracking Status
firefox66 --- fixed

People

(Reporter: mayhemer, Assigned: baku)

References

Details

Attachments

(1 file, 3 obsolete files)

Not sure if this is intentional, but apparently we do two sequential dispatches Parent process MT->URL Classifier->MT->URL Classifier->MT which are on load critical paths. The two URL Classifier->MT dispatches may get delayed when there is a large number of parallel resources. Could we optimize to just one dispatch or do the two dispatches in parallel? backtrack listing: EXECUTE_BEGIN "nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures" @18670.15ms Main Process(17124)/Main Thread delay: 42.09ms, blocker count: 1054 DISPATCH "" @18628.06ms Main Process(17124)/URL Classifier delay: 0.05ms EXECUTE_BEGIN "nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures" @18628.01ms Main Process(17124)/URL Classifier delay: 1.07ms, blocker count: 12 DISPATCH "" @18626.94ms Main Process(17124)/Main Thread delay: 0.02ms EXECUTE_BEGIN "nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures" @18626.91ms Main Process(17124)/Main Thread delay: 24.03ms, blocker count: 772 DISPATCH "" @18602.88ms Main Process(17124)/URL Classifier delay: 0.11ms EXECUTE_BEGIN "nsUrlClassifierDBService::AsyncClassifyLocalWithFeatures" @18602.77ms Main Process(17124)/URL Classifier delay: 0.38ms, blocker count: 6 DISPATCH "" @18602.38ms Main Process(17124)/Main Thread delay: 0.03ms EXECUTE_BEGIN "MozPromise::Then @DoAsyncOpen" @18602.35ms Main Process(17124)/Main Thread
> Not sure if this is intentional, but apparently we do two sequential > dispatches Parent process MT->URL Classifier->MT->URL Classifier->MT which Yes, this is intentional. What you are describing, was previously called nsUrlClassifierDBService::AsyncClassifyLocalWithTables. During the URL-Classifier refactoring many things have been changed, but not the number of runnables from/to the main-thread and from/to the URL-Classifier thread. I'm planning to optimize it in this or next cycle.
Thanks for the explanation and taking care, baku!
Component: DOM: Security → Safe Browsing
Priority: -- → P2
Product: Core → Toolkit
This is not related to the recent changes of AsyncClassifyLocalWithFeatures API. The behavior has existed for a long time and maybe we could optimize it with recent changes. But I don't want to rush to fix this because we have changed a lot of stuff recently and it will be safer to make sure everything is stable before optimization.
Attached patch thread.patch (obsolete) — Splinter Review

Would be nice to unify this code with the other consumers of AsyncClassifyLocalWithFeatures, but that could be a follow up.

Assignee: nobody → amarchesini
Attachment #9035378 - Flags: review?(dlee)

Verified as fixed!

DISPATCH "QUEUE:[CacheIOThread::OPEN]" @70717.42ms
  Main Process(9748)/Main Thread  
delay: 0.33ms

...

EXECUTE_BEGIN "AsyncUrlChannelClassifier::CheckChannel - return" @70716.13ms
  Main Process(9748)/Main Thread  
delay: 0.07ms

DISPATCH "QUEUE:[nsThread]" @70716.07ms
  Main Process(9748)/URL Classifier  
delay: 0.62ms

EXECUTE_BEGIN "AsyncUrlChannelClassifier::CheckChannel" @70715.44ms
  Main Process(9748)/URL Classifier  
delay: 0.04ms

DISPATCH "QUEUE:[nsThread]" @70715.40ms
  Main Process(9748)/Main Thread  
delay: 0.92ms

EXECUTE_BEGIN "net::ExecuteCallback" @70714.48ms
  Main Process(9748)/Main Thread  
delay: 0.09ms

DISPATCH "QUEUE:[nsThread]" @70714.39ms
  Main Process(9748)/ProxyResolution  
delay: 1.18ms

Thanks.

Comment on attachment 9035378 [details] [diff] [review] thread.patch Review of attachment 9035378 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the patch, baku! I would like to discuss with you about where we implementing the logic before reviewing more detailly. (actually already spent a lot of time reviewing :) ) I am concerned about the idea using worker outside the DBService, so I am thinking if we can avoid providing the worker instance outside the DBService, keep the related the logic in DBService and make the use of this API easier. I suggest we change the |aListType| of AsyncClassifyLocalWithFeatures to a bit flag(or remove it) and move the blacklist/whitelist logic in the API. Because the use cases we have right now is when a feature has both blacklist and whitelist table, it needs to classify both of them with the "check blacklist first and if a match is found, then check the whitelist" logic. So maybe we could just move the logic to FeatureHolder::DoLookup, includes the UriData, TableData, CheckHostPreference ...etc. If the |aListType| is blacklist & whitelist, we check blacklist first and then check whitelist. How do you think?
Comment on attachment 9035378 [details] [diff] [review] thread.patch Review of attachment 9035378 [details] [diff] [review]: ----------------------------------------------------------------- Discussed with baku offline, we would like to try a new approach to clean this up
Attachment #9035378 - Flags: review?(dlee)
Attached patch thread.patch (obsolete) — Splinter Review
Attachment #9035378 - Attachment is obsolete: true
Attachment #9036647 - Flags: review?(dlee)

Comment on attachment 9035378 [details] [diff] [review]
thread.patch

baku, I am super sorry. I change my mind after reading the latest patch.
let's use the old one

Attachment #9035378 - Attachment is obsolete: false
Attachment #9035378 - Flags: review?(dlee)
Attachment #9036647 - Attachment is obsolete: true
Attachment #9036647 - Flags: review?(dlee)
Comment on attachment 9035378 [details] [diff] [review] thread.patch Review of attachment 9035378 [details] [diff] [review]: ----------------------------------------------------------------- Hi baku, This is great! I think this patch can really improve performance a lot. Too bad that we don't have a good measurement to know the difference. As we discussed offline, please help update the patch with "AsyncUrlChannelClassifier friend class of nsUrlClassifierDBService and make GetWorker a private method." Thank you! ::: netwerk/url-classifier/AsyncUrlChannelClassifier.cpp @@ +291,5 @@ > + > + if (isBlacklisted == false) { > + for (TableData* tableData : mBlacklistTables) { > + if (tableData->DoLookup(aWorkerClassifier)) { > + isBlacklisted = true; This could be a follow up that for features that don't require to process all the tables, maybe we can optimize them by breaking here. @@ +300,5 @@ > + UC_LOG(("FeatureData::DoLookup[%p] - blacklisted before whitelisting: %d", > + this, isBlacklisted)); > + > + if (!isBlacklisted) { > + mState = eUnclassified; eUnclassified looks like the FeatureData is not yet classified before, like what is in the TableData. We should change the name, maybe enum State { eUnclassified, eNoMatch, eMatchBlacklist, eMatchWhitelist, }; ? @@ +311,5 @@ > + UC_LOG(("FeatureData::DoLookup[%p] - whitelisted by pref", this)); > + > + mState = eUnclassified; > + return; > + } We could check both of mHostInPrefTables at the beginning of this function. The check should be the highest priority so if a match is found then we can skip checking the local table. One question is what if the URL exists in both of the host preference. I guess whitelist has higher priority. @@ +372,5 @@ > + list.AppendLiteral(","); > + } > + > + list.Append(tableData->Table()); > + } I think the list should only contain tables that are found in blacklist? If I understand correctly, mBlacklistTables are tables we looked up? @@ +451,5 @@ > + UC_LOG(("FeatureTask::Create[%p] - FeatureTask created for channel %p", > + task.get(), aChannel)); > + > + for (nsIUrlClassifierFeature* feature : features) { > + FeatureData* featureData = task->mFeatures.AppendElement(); We have FeatureTask, FeatureData, TableData, and UriData. It's a little bit overwhelming when first look at this. I see we already have comments about the usage of the individual component. But would you mind also adding some comment in a place to describe the overall relationship between these classes? I think that will be really useful. @@ +455,5 @@ > + FeatureData* featureData = task->mFeatures.AppendElement(); > + nsresult rv = featureData->Initialize(task, aChannel, feature); > + if (NS_WARN_IF(NS_FAILED(rv))) { > + return rv; > + } It should be safer if we use continue instead of return here
Attachment #9035378 - Flags: review?(dlee)

This could be a follow up that for features that don't require to process
all the tables,
maybe we can optimize them by breaking here.

If we don't care about having the full list of tables, we can skip immediately. Yes. Follow up!

One question is what if the URL exists in both of the host preference. I
guess whitelist has higher priority.

Whitelist always wins.

Attached patch thread.patch (obsolete) — Splinter Review
Attachment #9035378 - Attachment is obsolete: true
Attachment #9036853 - Flags: review?(dlee)
Attached patch thread1.patchSplinter Review
Attachment #9036853 - Attachment is obsolete: true
Attachment #9036853 - Flags: review?(dlee)
Attachment #9036862 - Flags: review?(dlee)
Comment on attachment 9036862 [details] [diff] [review] thread1.patch Review of attachment 9036862 [details] [diff] [review]: ----------------------------------------------------------------- Looks good!!! ::: netwerk/url-classifier/AsyncUrlChannelClassifier.cpp @@ +45,5 @@ > +// object. > +// > +// It can happen that multiple features share the same tables. In order to do > +// the lookup just once, we have TableData class. When multiple features > +// contain the same table, they have references to the same TableData object. Maybe it is also worth mentioning that a TableData is per (TableName + URL) object. @@ +52,5 @@ > +// create these fragments just once, we use the URIData class, which is pointed > +// by TableData classes. > +// > +// The creation of these classes happens on the main-thread. The classification > +// happens on the worker thread. This is super clear! thanks! @@ +162,5 @@ > + nsIURI* URI() const; > + > + const nsACString& Table() const; > + > + const LookupResultArray& Results() const; I guess this is only for Length() to know if we found a match? How about using enum State { eUnclassified, eNoMatch eMatch, }; then we can remove this. @@ +223,5 @@ > + > + const nsTArray<nsCString>& fragments = mURIData->Fragments(); > + nsresult rv = aWorkerClassifier->DoSingleLocalLookupWithURIFragments( > + fragments, mTable, mResults); > + Unused << NS_WARN_IF(NS_FAILED(rv)); This reminds me that we also optimize the AsyncClassifyLocalWithFeatures. A not so important and a weird question is, Do you think we should remove the optimization of AsyncClassifyLocalWithFeatures? The reason I am thinking that is maybe no one gonna use the optimization. All the possible consumer(include SafeBrowsing) won't contain the same table in the API call. Maybe we just keep it easy to read for now.
Attachment #9036862 - Flags: review?(dlee) → review+

A not so important and a weird question is,
Do you think we should remove the optimization of
AsyncClassifyLocalWithFeatures?

Better to keep them all in place. We don't know how AsyncClassifyLocalWithFeatures will be used in the future.
Plus, at the moment, we already have multiple tables in about:url-classifiers.

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/cf370ec3969a Avoid extra main-thread jumps during the URL-classification, r=dimi
Flags: needinfo?(amarchesini)
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/ff0feb041ccc Avoid extra main-thread jumps during the URL-classification, r=dimi
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/fef99cfead16 Avoid extra main-thread jumps during the URL-classification, r=dimi

Backed out for service-workers failures with crashes on MOZ_CrashOOL.
-wpt failures and mochitest failures service-workers related with application crashed [@ static void MOZ_CrashOOL(const char *, int, const char *)]

backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/795a8cb833cd1c28b6e4afb65333a69c01e75938

push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception&classifiedState=unclassified&searchStr=e10s%2Ctest-windows7-32%2Fdebug&revision=fef99cfead16d68737b741e6579c91d1d09ae395

failure logs:
WPT: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=223382182&repo=mozilla-inbound&lineNumber=60452
with PROCESS-CRASH | /service-workers/service-worker/fetch-event-respond-with-readable-stream.https.html | application crashed [@ static void MOZ_CrashOOL(const char *, int, const char *)]

MOCHITEST: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=223393407&repo=mozilla-inbound&lineNumber=8699
with PROCESS-CRASH | dom/serviceworkers/test/test_eventsource_intercept.html | application crashed [@ static void MOZ_CrashOOL(const char *, int, const char *)]

Flags: needinfo?(amarchesini)
Flags: needinfo?(amarchesini)
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e310a6576d51 Avoid extra main-thread jumps during the URL-classification, r=dimi

Backed out changeset e310a6576d51 (bug 1516133) for service-workers failures with crashes on MOZ_CrashOOL

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/24be3a3e0faa957699636bd988ec678c68295365

Failure push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=e310a6576d515656daf0598220d7fc579b96df97

Failure log:
Mochitest: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=223472800&repo=mozilla-inbound&lineNumber=8917
WPT: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=223472794&repo=mozilla-inbound&lineNumber=60885

10:29:22 INFO - TEST-PASS | dom/serviceworkers/test/test_hsts_upgrade_intercept.html | Security info present on intercepted value
10:29:22 INFO - Buffered messages finished
10:29:22 ERROR - TEST-UNEXPECTED-FAIL | dom/serviceworkers/test/test_hsts_upgrade_intercept.html | application terminated with exit code 1
10:29:22 INFO - runtests.py | Application ran for: 0:00:41.091000
10:29:22 INFO - zombiecheck | Reading PID log: c:\users\task_1548238368\appdata\local\temp\tmph5fge9pidlog
10:29:22 INFO - ==> process 1548 launched child process 4684 ("Z:\task_1548238368\build\application\firefox\firefox.exe" -contentproc --channel="1548.0.1840245546\289581665" -childID 1 -isForBrowser -prefsHandle 2024 -prefMapHandle 2020 -prefsLen 1 -prefMapSize 193635 -parentBuildID 20190123092946 -greomni "Z:\task_1548238368\build\application\firefox\omni.ja" -appomni "Z:\task_1548238368\build\application\firefox\browser\omni.ja" -appdir "Z:\task_1548238368\build\application\firefox\browser" - 1548 "\.\pipe\gecko-crash-server-pipe.1548" 2096 tab)
10:29:22 INFO - ==> process 1548 launched child process 5460 ("Z:\task_1548238368\build\application\firefox\firefox.exe" -contentproc --channel="1548.6.1588701769\1092383662" -childID 2 -isForBrowser -prefsHandle 2316 -prefMapHandle 2320 -prefsLen 185 -prefMapSize 193635 -parentBuildID 20190123092946 -greomni "Z:\task_1548238368\build\application\firefox\omni.ja" -appomni "Z:\task_1548238368\build\application\firefox\browser\omni.ja" -appdir "Z:\task_1548238368\build\application\firefox\browser" - 1548 "\.\pipe\gecko-crash-server-pipe.1548" 1988 tab)
10:29:22 INFO - ==> process 1548 launched child process 6028 ("Z:\task_1548238368\build\application\firefox\firefox.exe" -contentproc --channel="1548.12.733270520\489291438" -childID 3 -isForBrowser -prefsHandle 2276 -prefMapHandle 2280 -prefsLen 185 -prefMapSize 193635 -parentBuildID 20190123092946 -greomni "Z:\task_1548238368\build\application\firefox\omni.ja" -appomni "Z:\task_1548238368\build\application\firefox\browser\omni.ja" -appdir "Z:\task_1548238368\build\application\firefox\browser" - 1548 "\.\pipe\gecko-crash-server-pipe.1548" 2320 tab)
10:29:22 INFO - zombiecheck | Checking for orphan process with PID: 5460
10:29:22 INFO - zombiecheck | Checking for orphan process with PID: 6028
10:29:22 INFO - zombiecheck | Checking for orphan process with PID: 4684
10:29:22 INFO - mozcrash Copy/paste: Z:\task_1548238368\build\win32-minidump_stackwalk.exe c:\users\task_1548238368\appdata\local\temp\tmp9fmwce.mozrunner\minidumps\c893491a-5533-4856-80b0-009a7270a515.dmp Z:\task_1548238368\build\symbols
10:29:35 INFO - mozcrash Saved minidump as Z:\task_1548238368\build\blobber_upload_dir\c893491a-5533-4856-80b0-009a7270a515.dmp
10:29:35 INFO - mozcrash Saved app info as Z:\task_1548238368\build\blobber_upload_dir\c893491a-5533-4856-80b0-009a7270a515.extra
10:29:35 INFO - PROCESS-CRASH | dom/serviceworkers/test/test_hsts_upgrade_intercept.html | application crashed [@ static void MOZ_CrashOOL(const char *, int, const char *)]
10:29:35 INFO - Crash dump filename: c:\users\task_1548238368\appdata\local\temp\tmp9fmwce.mozrunner\minidumps\c893491a-5533-4856-80b0-009a7270a515.dmp
10:29:35 INFO - Operating system: Windows NT
10:29:35 INFO - 6.1.7601 Service Pack 1
10:29:35 INFO - CPU: x86
10:29:35 INFO - GenuineIntel family 6 model 63 stepping 2
10:29:35 INFO - 8 CPUs
10:29:35 INFO -
10:29:35 INFO - GPU: UNKNOWN
10:29:35 INFO -
10:29:35 INFO - Crash reason: EXCEPTION_BREAKPOINT
10:29:35 INFO - Crash address: 0x52e64a84
10:29:35 INFO - Process uptime: 18 seconds
10:29:35 INFO -
10:29:35 INFO - Thread 54 (crashed)
10:29:35 INFO - 0 xul.dll!static void MOZ_CrashOOL(const char *, int, const char *) [Assertions.h:844767deacdb7d0335824703238c941a52a306a5 : 314 + 0x0]
10:29:35 INFO - eip = 0x52e64a84 esp = 0x11fcf2ec ebp = 0x11fcf2f0 ebx = 0x11d89ef0
10:29:35 INFO - esi = 0x593e4d3e edi = 0x0ef7e760 eax = 0x7137e6ac ecx = 0x00000028
10:29:35 INFO - edx = 0x00000000 efl = 0x00000202
10:29:35 INFO - Found by: given as instruction pointer in context
10:29:35 INFO - 1 xul.dll!nsAutoOwningThread::AssertCurrentThreadOwnsMe(char const *) [nsISupportsImpl.cpp:844767deacdb7d0335824703238c941a52a306a5 : 40 + 0x8]
10:29:35 INFO - eip = 0x52e64a4c esp = 0x11fcf2f8 ebp = 0x11fcf2fc
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 2 xul.dll!void std::_Func_impl_no_alloc<lambda at z:/build/build/src/netwerk/protocol/http/TrackingDummyChannelParent.cpp:37:23',void>::_Delete_this(bool) [functional:844767deacdb7d0335824703238c941a52a306a5 : 1240 + 0x2f] 10:29:35 INFO - eip = 0x533dbaa4 esp = 0x11fcf304 ebp = 0x11fcf310 10:29:35 INFO - Found by: previous frame's frame pointer 10:29:35 INFO - 3 xul.dll!void mozilla::net::anonymous namespace'::FeatureTask::~FeatureTask() [AsyncUrlChannelClassifier.cpp:844767deacdb7d0335824703238c941a52a306a5 : 532 + 0x10]
10:29:35 INFO - eip = 0x53490abe esp = 0x11fcf318 ebp = 0x11fcf334
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 4 xul.dll!static void RefPtr<mozilla::net::(anonymous namespace)::FeatureTask>::ConstRemovingRefPtrTraits<mozilla::net::(anonymous namespace)::FeatureTask>::Release(class mozilla::net::anonymous namespace'::FeatureTask *) [RefPtr.h:844767deacdb7d0335824703238c941a52a306a5 : 362 + 0x40] 10:29:35 INFO - eip = 0x53490890 esp = 0x11fcf33c ebp = 0x11fcf340 10:29:35 INFO - Found by: previous frame's frame pointer 10:29:35 INFO - 5 xul.dll!static void mozilla::detail::RunnableFunction<lambda at z:/build/build/src/netwerk/url-classifier/AsyncUrlChannelClassifier.cpp:738:7'>::~RunnableFunction() [nsThreadUtils.h:844767deacdb7d0335824703238c941a52a306a5 : 537 + 0x30]
10:29:35 INFO - eip = 0x53491360 esp = 0x11fcf348 ebp = 0x11fcf350
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 6 xul.dll!mozilla::Runnable::Release() [nsThreadUtils.cpp:844767deacdb7d0335824703238c941a52a306a5 : 49 + 0x9]
10:29:35 INFO - eip = 0x52f08dac esp = 0x11fcf358 ebp = 0x11fcf364
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 7 xul.dll!nsThread::ProcessNextEvent(bool,bool *) [nsThread.cpp:844767deacdb7d0335824703238c941a52a306a5 : 1208 + 0x28]
10:29:35 INFO - eip = 0x52f024c2 esp = 0x11fcf36c ebp = 0x11fcf844
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 8 xul.dll!NS_ProcessNextEvent(nsIThread *,bool) [nsThreadUtils.cpp:844767deacdb7d0335824703238c941a52a306a5 : 468 + 0x11]
10:29:35 INFO - eip = 0x52f05084 esp = 0x11fcf84c ebp = 0x11fcf868
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 9 xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate *) [MessagePump.cpp:844767deacdb7d0335824703238c941a52a306a5 : 333 + 0xa]
10:29:35 INFO - eip = 0x535631da esp = 0x11fcf870 ebp = 0x11fcf89c
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 10 xul.dll!MessageLoop::RunInternal() [message_loop.cc:844767deacdb7d0335824703238c941a52a306a5 : 315 + 0x5]
10:29:35 INFO - eip = 0x5351b191 esp = 0x11fcf8a4 ebp = 0x11fcf8c0
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 11 xul.dll!MessageLoop::RunHandler() [message_loop.cc:844767deacdb7d0335824703238c941a52a306a5 : 308 + 0x7]
10:29:35 INFO - eip = 0x5351b0ac esp = 0x11fcf8c8 ebp = 0x11fcf8f4
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 12 xul.dll!MessageLoop::Run() [message_loop.cc:844767deacdb7d0335824703238c941a52a306a5 : 290 + 0x5]
10:29:35 INFO - eip = 0x5351af7f esp = 0x11fcf8fc ebp = 0x11fcf914
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 13 xul.dll!nsThread::ThreadFunc(void *) [nsThread.cpp:844767deacdb7d0335824703238c941a52a306a5 : 449 + 0xa]
10:29:35 INFO - eip = 0x52efef8b esp = 0x11fcf91c ebp = 0x11fcf940
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 14 nss3.dll!_PR_NativeRunThread [pruthr.c:844767deacdb7d0335824703238c941a52a306a5 : 397 + 0x6]
10:29:35 INFO - eip = 0x67d6fc45 esp = 0x11fcf948 ebp = 0x11fcf960
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 15 nss3.dll!static unsigned int pr_root(void *) [w95thred.c:844767deacdb7d0335824703238c941a52a306a5 : 137 + 0x7]
10:29:35 INFO - eip = 0x67d5ed0d esp = 0x11fcf968 ebp = 0x11fcf96c
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 16 ucrtbase.dll!__RtlConvertUlongToLargeInteger + 0x7fe9
10:29:35 INFO - eip = 0x67fae16f esp = 0x11fcf974 ebp = 0x11fcf9a8
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 17 kernel32.dll!RtlMultiByteToUnicodeN + 0x73c
10:29:35 INFO - eip = 0x76fa3c45 esp = 0x11fcf9b0 ebp = 0x11fcf9b4
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 18 mozglue.dll!static void patched_BaseThreadInitThunk(int, void *, void *) [WindowsDllBlocklist.cpp:844767deacdb7d0335824703238c941a52a306a5 : 727 + 0x41]
10:29:35 INFO - eip = 0x71326ea4 esp = 0x11fcf9bc ebp = 0x11fcf9f0
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 19 ntdll.dll!__RtlUserThreadStart + 0x27
10:29:35 INFO - eip = 0x776a37f5 esp = 0x11fcf9f8 ebp = 0x11fcfa30
10:29:35 INFO - Found by: previous frame's frame pointer
10:29:35 INFO - 20 ntdll.dll!_RtlUserThreadStart + 0x1b
10:29:35 INFO - eip = 0x776a37c8 esp = 0x11fcfa38 ebp = 0x11fcfa48
10:29:35 INFO - Found by: call frame info
10:29:35 INFO -

Flags: needinfo?(amarchesini)
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1bf3cec003ab Avoid extra main-thread jumps during the URL-classification, r=dimi
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: