Skip to content

ci: Debug symbols are built from incorrect dll/exe files, rendering them useless #20033

@jcsteh

Description

@jcsteh

Detailed description of the issue

For official snapshots and releases, NVDA builds are signed. In addition, a symbol store is built and the symbols are uploaded to Mozilla using the dll and exe files built in the buildNVDA job.

Unfortunately, it seems that when a build is to be signed, the createLauncher -> Create launcher and controller client step rebuilds all of the dll and exe files before signing them. That means that the dll and exe files distributed in the launcher are different to those which we use to build the symbols. Since they have a different debug id, they don't match and thus the symbols are useless.

This is quite problematic when trying to debug crashes from users who aren't building locally.

Steps to reproduce or illustrate the issue (if applicable)

  1. Examine the log output of the "Create launcher and controller client" step in this signed run.
  2. Compare with the same step in this unsigned pull request run.

Expected outcome or behaviour (if applicable)

In the signed run, observe that dll files are linked again. For example:

link /nologo /incremental:no /WX /subsystem:windows,10.00 /release /LTCG /OPT:REF /export:DllGetClassObject,private /export:DllCanUnloadNow,private /export:GetProxyDllInfo,private /manifest:embed /manifestinput:build\arm64\IAccessible2proxy.manifest /dll /out:build\arm64\IAccessible2proxy.dll /implib:build\arm64\IAccessible2proxy.lib rpcrt4.lib oleaut32.lib ole32.lib /PDB:build\arm64\IAccessible2proxy.dll.pdb /DEBUG build\arm64\ia2_i.obj build\arm64\ia2_p.obj build\arm64\ia2_data.obj

In the unsigned run, there is no dll linking. The files from the buildNVDA cache are used as is. This is the correct behaviour.

To fix this, we need to do one of two things:

  1. Prevent the rebuild. I think this is the most correct solution, as it also avoids the performance hit of a redundant rebuild. The trouble is that I don't quite understand why the rebuild is occurring. I guess adding a post action triggers a rebuild because the post action wasn't there during the first scons run. Or perhaps it triggers a rebuild because scons realises that the post action will modify the file.
  2. Use the dll and exe files from the createLauncher job for the createSymbols and uploadSymbols jobs, rather than the files from the buildNVDA job. This is going to be a bit messy because we'll need to cache those files and that means we'll need to list the files somewhere. They're already listed in ci/scripts/buildSymbolStore.ps1, but I don't see how we can make that reusable. I guess if we only cache the files we need, we could just make buildSymbolStore.ps1 add everything in the current directory to the store, but that feels fragile.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ci-cdp3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#prioritytriagedHas been triaged, issue is waiting for implementation.

    Type

    No fields configured for Task.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions