Nuitka: "Error, couldn't find attached data. The parameter is incorrect."

OS: Windows 10 21H2 Python: 3.11.2 Nuitka: 1.5rc11

After building with nuitka project/project.py --trace-execution --quiet --onefile --static-libpython=no --enable-plugin=pyside6 --include-module=pytest --include-module=_pytest --include-module=unittest --nofollow-import-to=setuptools --nofollow-import-to=tkinter --windows-icon-from-ico=project/icon/favicon.ico, the executable fails once, and works immediately afterwards:

(project_dev) C:\code\project>project.exe
ONEFILE: Entered main().
ONEFILE: Unpacking payload.
Error, couldn't find attached data.
The parameter is incorrect.

(project_dev) C:\code\project>project.exe
ONEFILE: Entered main().
ONEFILE: Unpacking payload.
ONEFILE: Determining payload start position.
ONEFILE: Checking header for compression.
ONEFILE: Entering decompression.
ONEFILE: Finishing decompression, cleanup payload.
ONEFILE: Preparing forking of slave process.
ONEFILE: Started slave process.
main(): Entered.

I will work on producing a minimal example, but I’ll report this now in case this is a known or easily fixed issue. There is multiple code paths that emit “Error, couldn’t find attached data”, but I guess the traces show it must be this one:

https://github.com/Nuitka/Nuitka/blob/d394679cb31b301806a53fee7461fbeb3fc82125/nuitka/build/static_src/OnefileBootstrap.c#L241-L246

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 23 (15 by maintainers)

Most upvoted comments

So, I updated factory with the enhancement to output the failing function of memory mapping. I didn’t apply it to all function unlike I originally intended, but just the one where it fails what you see, so we can know it sooner.

And I fixed the wrong return value check, and audited Nuitka to not do it elsewhere, which it does not. Unfortunately I believe, in CRC32 checking, this bug was already present (on WIndows), but entirely harmless, since failed checksum calculation was not going to be an issue. I am tempted to rebase develop branch if this proves to be a fix, to retain git bisect for Windows.

We may now see that CreateFileW fails, and it might be due to AV preventing to opening of the executable for reading. If that’s what’s going on, it would be kind of surprising (are we not executing it in that very moment already, why is opening it for shared read an issue, or do we not share?).

Anyway, let me know how this works for you as soon as you can.