1861448 - null pointer access violation in xul.dll

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[John]

Steps to reproduce:

Shortly after updating to v115.4.0, a crash warning appeared, Thunderbird continued to run. There was no user interaction.

0xC0000005: Access violation reading location 0x0000000000000000

FAILURE_BUCKET_ID:  NULL_POINTER_READ_c0000005_xul.dll!Unknown
BUCKET_ID:  APPLICATION_FAULT_NULL_POINTER_READ_INVALID_POINTER_READ_xul+1a9332
FAILURE_EXCEPTION_CODE:  c0000005
FAILURE_IMAGE_NAME:  xul.dll

Stack:
xul+0x1a9332
xul!VR_RuntimePath+0xf9180b
xul!soundtouch::SoundTouch::operator=+0x609463
xul+0x232500
xul+0x2ced83
xul+0x232500
xul+0x23bad8
xul+0x23fa18
xul+0x391e9e
xul+0x23baa5
xul+0x23fa18
xul!soundtouch::SoundTouch::numChannels+0x382c1e
xul!soundtouch::SoundTouch::numChannels+0x341070
xul!soundtouch::SoundTouch::numChannels+0x340fe7
xul+0x2390d4
nss3!PRP_TryLock+0x9b6
nss3!PR_MD_UNLOCK+0x1111
ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x93
kernel32!BaseThreadInitThunk+0x1d
mozglue!DllBlocklist_Initialize+0x4d5
ntdll!RtlUserThreadStart+0x28

Are there symbols and .pdb available for Thunderbird?

OS: Windows 11 (10.0.22621.1.amd64fre.ni_release.220506-1250)

Sorry I cannot share dump files for security reasons.

Comment 1

[Magnus Melin [:mkmelin]]

Please provide the crash id. See https://support.mozilla.org/en-US/kb/thunderbird-crashes
But if it didn't actually crash, then there wouldn't be one. But that also means there's nothing to do in this bug.

Comment 2

[Wayne Mery (:wsmwk)]

They don't have a crash ID.

Symbols at http://symbols.mozilla.org/. In windbg I use * SRVc:\symbolshttp://symbols.mozilla.org/thunderbird;SRV*c:\symbols*http://symbols.mozilla.org/firefox;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

• for crash or hang: ~* kp;!analyze -f;lm

More info about windbg at https://firefox-source-docs.mozilla.org/contributing/debugging/stacktrace_windbg.html .... substitute "Thunderbird" where you see "Firefox".

From bug Bug 1728963 comment 2 ...

To extract memory information from a minidump file, you'll typically use debugging tools and software designed for analyzing crash dumps on Windows systems. Here's how you can do it:

Install Debugging Tools: If you don't have it already, you'll need to install the Windows Debugging Tools. You can download them from the Windows SDK, which you can find on the Microsoft website https://www.thedailyaquarium.com/betta-fish-care/.

Open WinDbg: After installing the debugging tools, open WinDbg, which is the Windows Debugger. You can find it in the Start menu or by searching for "WinDbg."

Open Minidump File: In WinDbg, go to "File" and select "Open Crash Dump." Navigate to the location of your minidump file and open it.

Analyze the Dump: WinDbg will load the dump file, and you'll see a lot of technical information. To extract memory information, you can look for details related to memory addresses, module information, and stack traces.

Commands: You can use various WinDbg commands to extract specific memory information. For example:

!address command: This command provides information about memory regions.
!analyze -v or !analyze -hang: These commands can help analyze the crash dump and provide details about what might have caused the crash.
Review the Output: After executing the necessary commands, you'll get information related to memory regions, the stack, loaded modules, and potentially any specific memory issues or errors that were present during the crash.

Please note that analyzing crash dumps and extracting memory information can be quite technical, and the output may vary depending on the nature of the crash and the content of the minidump file. This process is typically used by developers and IT professionals to diagnose and debug software and hardware issues.

Comment 3

[John]

Thanks!

Meanwhile v115.4.1 was installed. The crash has not occurred again so far.

Thunderbird symbols for v115.4.1 seem to be missing at symbols.mozilla.org. Checked using symchk and WinDBG.

Symbol downloading for Thunderbird for WinDBG 10.0.18362.1 fails:

SYMSRV:  HTTPGET: /download/symbols/mozglue.pdb/C2B4F32354D0B6424C4C44205044422E1/mozglue.pdb
SYMSRV:  HttpQueryInfo: 80190194 - HTTP_STATUS_NOT_FOUND
SYMSRV:  HTTPGET: /download/symbols/mozglue.pdb/C2B4F32354D0B6424C4C44205044422E1/mozglue.pd_
SYMSRV:  HttpQueryInfo: 80190194 - HTTP_STATUS_NOT_FOUND
SYMSRV:  HTTPGET: /download/symbols/mozglue.pdb/C2B4F32354D0B6424C4C44205044422E1/file.ptr
SYMSRV:  HttpQueryInfo: 80190194 - HTTP_STATUS_NOT_FOUND

SRV*x:\symbols*https://symbols.mozilla.org/thunderbird;SRV*x:\symbols*https://symbols.mozilla.org/firefox;SRV*x:\symbols*https://msdl.microsoft.com/download/symbols

I tried Mozilla-build too. It gets stuck somewhere while running the first hg line at "adding file changes" and then removes everything.

 ~/source
$ hg clone https://hg.mozilla.org/mozilla-central source/
applying clone bundle from https://hg.cdn.mozilla.net/mozilla-central/[40char].zstd-max.hg
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: An existing connection was forcibly closed by the remote host

https://developer.thunderbird.net/thunderbird-development/building-thunderbird/windows-build-prerequisites

The processingspeed is 1 kilobyte per second at the end of "adding manifests". "Adding file changes" stalls at 3460. Until hg aborts after several minutes, cpu core utilization is close to 95%.

I'd need source code, a debug build, and a build environment to be able to trace problems in Visual Studio. Not only here, in bug 1847137 too.

NULL pointer references can be found and prevented:
https://blog.bytehackr.in/understanding-and-preventing-null-pointer-dereference

Comment 4

[Wayne Mery (:wsmwk)]

Alfred are you able to assist with comment 3?

Comment 5

[Alfred Peters [:infofrommozilla]]

(In reply to John from comment #3)

I tried Mozilla-build too. It gets stuck somewhere while running the first hg line at "adding file changes" and then removes everything.

 ~/source
$ hg clone https://hg.mozilla.org/mozilla-central source/

abort: An existing connection was forcibly closed by the remote host

I prefer TortoiseHg under Windows. The GUI is usually quite useful. But even with that, the command breaks here too.
The data rate starts at ~10Mbit/s, but then drops below 1Mbit/s until it finally stops completely:

Abbruch: stream ended unexpectedly (got 32238 bytes, expected 32768)

With the --stream parameter, however, the download runs through. And it is also much faster:

> hg clone --stream https://hg.mozilla.org/mozilla-central source

Comment 6

[John]

The crash has not occurred again.

(In reply to Alfred Peters from comment #5)
Thanks! --stream works for me too.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to John from comment #6)

The crash has not occurred again.

Thanks John.