Closed Bug 2000472 Opened 11 months ago Closed 5 months ago

Crash [@ dns_res_send ] in new account setup

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Version:
Thunderbird 145
Platform:
Unspecified
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mschmitt, Unassigned)

References

Details

Crash Data

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15

Steps to reproduce:

I'm attempting to setup an account; I've never got past this point:

  1. Launch Thunderbird
  2. Account Setup > Set Up Your Existing Email Address appears
  3. Enter my full name, email address, password. Remember password is selected.
  4. Continue
  5. <crash>

Actual results:

Thunderbird crashes. It does this 100% of the time.

Expected results:

It should go to the next panel in the account setup process.

Note: I've tried this at 143.0.1, 144.0.1, and now 145.0, with the same results each time.

Hello,

Tried to reproduce this issue but couldn’t.
I have tried on TB 144.0.1(20251016001905), and TB 145.0(20251112194829) and the account was added without any issues. I have added a new account through Account hub, and also through the old wizard account setup and the account was added without any issue.
Also created a fresh profile and added a new account and it worked as expected.

Michael, please find your crash IDs in Help > Troubleshooting Information and post them here. Thanks

Flags: needinfo?(mschmitt)

Submitted Crash Reports:

My suspicion is that the crash is connected to automatic setup using my mail provider (@fastmail.net)

Flags: needinfo?(mschmitt)

See bug 1998274 -> bug 1987786.
Is this for any particular domain?

Summary: Crash in new account setup → Crash [@ dns_res_send ] in new account setup
See Also: → 1998274
OS: Unspecified → macOS

As an experiment, I tried using @fastmail.com. The results were a little different:

  • There was a brief "looking up config" (or something to that effect)
  • then it crashed
  • and then Little Snitch popped up a (terminated) alert for Thunderbird wanting to connect to autoconfig.fastmail.com on TCP port 80.

Note that Little Snitch had not previously popped up that alert, which implies that before it never tried to make that connection.

This one generated crash report bp-47d9fd2e-8eb1-464d-832f-d38ea0251117

(In reply to Michael Schmitt from comment #5)

...
This one generated crash report bp-47d9fd2e-8eb1-464d-832f-d38ea0251117

Crash report: https://crash-stats.mozilla.org/report/index/47d9fd2e-8eb1-464d-832f-d38ea0251117

Reason:

EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames:

0  libresolv.9.dylib  res_nsearch_2
1  libresolv.9.dylib  res_9_nsearch
2  XUL  ffi_call_unix64
3  XUL  ffi_call_int  js/src/ctypes/libffi/src/x86/ffi64.c:679
4  XUL  js::ctypes::FunctionType::Call(JSContext*, unsigned int, JS::Value*)  js/src/ctypes/CTypes.cpp:7144
5  XUL  CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::...  js/src/vm/Interpreter.cpp:490
5  XUL  js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstru...  js/src/vm/Interpreter.cpp:572
6  XUL  InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)  js/src/vm/Interpreter.cpp:653
6  XUL  js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)  js/src/vm/Interpreter.cpp:658
6  XUL  js::Interpret(JSContext*, js::RunState&)  js/src/vm/Interpreter.cpp:3276

Thanks for this info.

Can you please try https://www.thunderbird.net/en-US/download/daily ? It will create a new profile that will be used only for daily builds.

It has a patch that is not on version 145 - bug 1987786 comment 12

Flags: needinfo?(mschmitt)

Tested 147.0a1 with @fastmail.net, same symptom. Crash id is bp-5ab127fa-c643-4e3f-867b-1e9170251117

Flags: needinfo?(mschmitt)

Thanks. I just saw that pop up in the crash system. And that crash is using today's daily build, so it has the patch from bug 1987786 comment 12.

Crash Signature: [@ dns_res_send ]
Depends on: 1987786
Flags: needinfo?(edicharry)

I just reopened bug 1987786, and it's not crashing for me with a fastmail.net address, but this looks like the same crash as bug 1987786. I'm going to try another fix for that one.

Flags: needinfo?(edicharry)

Michael, have you customized the DNS settings in any way on your Mac? This would be doing something like using a third-party DNS provider such as cloudflare (1.1.1.1) or google (8.8.8.8) in System Settings -> Network -> [your network] -> Details -> DNS or installing a profile to use DNS over HTTPS. I'm asking because we're still trying to track down the specific circumstances under which this happens.

Flags: needinfo?(mschmitt)

Nope.

macOS is picking up IPv4 and IPv6 DNS addresses from my Netgear router. Router is getting 209.18.47.61, 209.18.47.62 from Spectrum. Nor do I have any VPNs running.

I'm running Little Snitch and Sophos Antivirus Home.

Do you want me to do any digs to see what I'm getting? Try with a different DNS? See what happens on my MacBook Pro (M2 Pro) running Sequoia?

Flags: needinfo?(mschmitt)

Thank you! I'd be interested in knowing if you see the same behavior on your Sequoia MBP, and can you try with Little Snitch disabled to see if you have the same behavior?

Tested Daily version on iMac with Little Snitch network filter off, but macOS firewall on. Crashed.

I'll try it on my MBP this evening. Do you prefer the daily version or 145 released?

I'd ask if you want me to try rebooting the iMac, router, or both, but the problem is that if it fixes the problem, you'd never be able to figure out why it was crashing.

Another thing I could try is running it in a Windows 10 (Intel) or Windows 11 (ARM) VM.

Daily, if possible. We landed a fix for one potential issue for this just before 146 went to beta. Thanks again for being willing to try things to help us isolate this! If I think of anything else that would be helpful for you to try, I'll post it here.

Testing with 147.0a1 (2025-11-17) (aarch64) on my MacBook Pro (16-inch, 2023) running Sequoia 15.7.2, on the same network albeit Wi-Fi, clicking Continue at the point where it crashed does some networking:

  • autodiscover.fastmail.com TCP 443
  • fastmail.net TCP 80
  • fastmail.net TCP 443
  • and maybe others but I had already set Little Snitch to allow connections in the thunderbird.net, Mozilla.org, and Mozilla.com domains. Plus DNS is allowed, of course.

and then displays "Configuration found at email provider".

So, it doesn't always crash on my network.

...but it hung when I attempted to quit! And eventually crashed.

bp-6b1d8f17-70d5-459d-a575-8c1860251117

(In reply to Michael Schmitt from comment #17)

...but it hung when I attempted to quit! And eventually crashed.

bp-6b1d8f17-70d5-459d-a575-8c1860251117

@ mozilla::dom::workerinternals::RuntimeService::CrashIfHanging, so different signature. But could be the same issue.

(In reply to Michael Schmitt from comment #17)

...but it hung when I attempted to quit! And eventually crashed.

bp-6b1d8f17-70d5-459d-a575-8c1860251117

That was 147.0a1.
Do you still crash?

Flags: needinfo?(mschmitt)

I tried it on my iMac with Thunderbird 151.0. It works!

Flags: needinfo?(mschmitt)

Thanks for the update. Doesn't make sense to me, but we'll take it :)

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.