startup Crash in res_nsearch_2 or dns_res_send if chat account logs in at startup
Categories
(Thunderbird :: Instant Messaging, defect)
Tracking
(Not tracked)
People
(Reporter: unicorn.consulting, Unassigned)
References
()
Details
(Keywords: crash, Whiteboard: [startupcrash][rare])
Crash Data
User Story
Bug filed from support request in URL.
This bug was filed from the Socorro interface and is report bp-29cb54eb-5ea6-4fad-a03e-7bc220180227. ============================================================= Top 10 frames of crashing thread: 0 libresolv.9.dylib res_nsearch_2 1 libresolv.9.dylib res_9_nsearch 2 XUL ffi_call_unix64 3 XUL ffi_call js/src/ctypes/libffi/src/x86/ffi64.c:535 4 XUL js::ctypes::FunctionType::Call js/src/ctypes/CTypes.cpp:7143 5 XUL js::InternalCallOrConstruct js/src/jscntxtinlines.h:239 6 XUL Interpret js/src/vm/Interpreter.cpp:510 7 XUL js::RunScript js/src/vm/Interpreter.cpp:405 8 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:477 9 XUL <name omitted> js/src/vm/Interpreter.cpp:523 =============================================================
Comment 1•7 years ago
|
||
Patrick, perhaps this is a chat bug? https://support.mozilla.org/en-US/questions/1207124 Mac crashes when two chat accounts are set to auto-login (this is the user in comment 0) bp-a2a604df-cb43-4d31-ab25-208980180212 is probably the same user (has the same install time) "It only happens when I set two chat accounts to log-on at startup. When I disable either one it doesn't crash. Also, it only happens on Mac, not on PC. And it's happened for the last year or so." ONly 10 crashes per week for 52.6.0, so very low crash rate. As far as I can tell this is not a new crash. In the past two months there have been a few 58.0b2 crashes and one 58.0b3. None so far for 59.0b1. The stacks actually start with 35 XUL NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:361 36 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:368 37 XUL MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:232 38 XUL nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:467 39 libnss3.dylib _pt_root nsprpub/pr/src/pthreads/ptthread.c:216 40 libsystem_pthread.dylib _pthread_body 41 libsystem_pthread.dylib _pthread_start 42 libsystem_pthread.dylib thread_start 43 libnss3.dylib libnss3.dylib@0x1b83df A couple users also crash with dns_res_send bp-5dee46e8-4d2c-493b-9fd9-1525a0171229 52.4.0 which has a similar stack so I suspect the same root cause 0 libresolv.9.dylib dns_res_send 1 libresolv.9.dylib res_9_nsend_2 2 libresolv.9.dylib res_nquery_soa_min 3 libresolv.9.dylib res_nquerydomain_2 4 libresolv.9.dylib res_nsearch_2 5 libresolv.9.dylib res_9_nsearch 6 XUL ffi_call_unix64 7 XUL ffi_call js/src/ctypes/libffi/src/x86/ffi64.c:535 8 XUL js::ctypes::FunctionType::Call js/src/ctypes/CTypes.cpp:7143 ... 40 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 41 XUL MessageLoop::Run() 42 XUL nsThread::ThreadFunc(void*) 43 libnss3.dylib _pt_root 44 libsystem_pthread.dylib _pthread_body 45 libsystem_pthread.dylib _pthread_start 46 libsystem_pthread.dylib thread_start 47 libnss3.dylib libnss3.dylib@0x1b83df
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Interesting. Looks to me like this might be from our DNS SRV code. (https://dxr.mozilla.org/comm-central/source/comm/chat/modules/DNS.jsm). I wonder if there's a condition that doesn't allow multiple requests in flight at once.
Philipp, do you know if this code was written to allow for multiple in-flight requests at once? Some of the lookup code gets a bit thick for me! Unfortunately the stack doesn't seem to go into JavaScript land.
Comment 3•6 years ago
|
||
Based on http://man7.org/linux/man-pages/man3/res_nsearch.3.html it seems res_search is not threadsafe, so this could be a result of it. Maybe we could use res_nsearch instead? I'm not sure it is always available. Or we need to queue up the requests.
Comment 4•6 years ago
|
||
Hmm it seems res_nsearch is already being used under the hood, so my previous comment may be wrong. If this crash is reproducible I think we should rather check if all buffers are correctly allocated.
Comment 5•5 years ago
|
||
Hey Paul, you were looking at this code recently. Any idea what's happening here?
Comment 6•5 years ago
|
||
As I mentioned on IRC the other day, I haven't had a chance to look into this yet. Will add it to my list.
Comment 8•5 years ago
|
||
Windows uses a completely different implementation. It is possible that this bug also affects Linux, see https://dxr.mozilla.org/comm-central/rev/2a29ee0adb310b54a6a2df72034953fed8f2b043/comm/chat/modules/DNS.jsm#310-313
Updated•4 years ago
|
Updated•4 years ago
|
Comment 9•3 years ago
|
||
Matt, does this still happen when using a current version, and is it reproducible for you?
Both signatures still occur for version 91
- dns_res_send bp-8f2089fb-f96b-44ea-a9a9-3ce510211029
- res_nsearch_2 bp-18dd1a6d-d97e-4b6d-be96-844d70211109 (more frequent than the above)
Reporter | ||
Comment 10•3 years ago
|
||
I have deleted all my chat accounts from Thunderbird, so I really can not assist with this any longer Wayne.
To resolve my issues with account ordering and other messed up layout decisions along with internet connectivity issues, I am minimising my Thunderbird accounts to only the essentials.
Comment 11•3 years ago
|
||
Both signatures occur only for older versions of Mac, so I'm going to declare this issue as resolved
Description
•