dimensional-de / napi-canon-cameras

Node AddOn Api module for Canon cameras
GNU General Public License v3.0
53 stars 22 forks source link

Updating Stubs Fails to Run (unordered_map initialization error in labels.cc) #4

Closed Olliebrown closed 2 years ago

Olliebrown commented 2 years ago

This is related to #2 and results in the same error, but that is a very generic error and I have found that my problem seems to require a different solution from what was posed in that issue.

The error comes up when you do npm run package and is the result of the update-stubs.js script:

> @dimensional/napi-canon-cameras@0.1.0 _update:stubs D:\Programming-School\napi-canon-cameras
> node ./helpers/update-stubs.js

internal/modules/cjs/loader.js:1122
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: A dynamic link library (DLL) initialization routine failed.
\\?\D:\Programming-School\napi-canon-cameras\prebuilds\win32-x64\node.napi.node
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1122:18)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at load (D:\Programming-School\napi-canon-cameras\node_modules\node-gyp-build\index.js:21:10)
    at Object.<anonymous> (D:\Programming-School\napi-canon-cameras\camera-api.js:1:40)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)

I followed the guide here to setup LLDB for running node_api addons and was able to isolate the error as originating from line 738 in 'labels.cc.' The unordered list being created here triggers an error when it tries to run the constructor for the list items. I tried commenting out the initialization items and that got past the error:

    std::unordered_map<int, LabelMap> Labels::Option = {
        // {kEdsPropID_AEMode, AEMode},
        // {kEdsPropID_AEModeSelect, AEModeSelect},
        // {kEdsPropID_AFMode, AFMode},
        // {kEdsPropID_BatteryQuality, BatteryQuality},
        // {kEdsPropID_Bracket, Bracket},
        // {kEdsPropID_ColorSpace, ColorSpace},
        // {kEdsPropID_DC_Strobe, DCStrobe},
        // {kEdsPropID_DriveMode, DriveMode},
        // {kEdsPropID_Evf_AFMode, EvfAFMode},
        // {kEdsPropID_Evf_HistogramStatus, EvfHistogramStatus},
        // {kEdsPropID_Evf_OutputDevice, EvfOutputDevice},
        // {kEdsPropID_Evf_WhiteBalance, WhiteBalance},
        // {kEdsPropID_Evf_Zoom, EvfZoom},
        // {kEdsPropID_ImageQuality, ImageQuality},
        // {kEdsPropID_LensBarrelStatus, LensBarrelStatus},
        // {kEdsPropID_LensStatus, LensStatus},
        // {kEdsPropID_MeteringMode, MeteringMode},
        // {kEdsPropID_MirrorLockUpState, MirrorUpStatus},
        // {kEdsPropID_MovieParam, MovieQuality},
        // {kEdsPropID_NoiseReduction, NoiseReduction},
        // {kEdsPropID_RedEye, RedEye},
        // {kEdsPropID_Record, Record},
        // {kEdsPropID_SaveTo, SaveTo},
        // {kEdsPropID_WhiteBalance, WhiteBalance}
    };

I am not sure exactly what is wrong here. I will keep investigating to see if I can get to the bottom of these initializers and why they are failing but if something jumps out at you lmk!

Here is my npm version info:

{
  '@dimensional/napi-canon-cameras': '0.1.0',
  npm: '6.14.11',
  ares: '1.16.1',
  brotli: '1.0.9',
  cldr: '37.0',
  icu: '67.1',
  llhttp: '2.1.3',
  modules: '83',
  napi: '7',
  nghttp2: '1.41.0',
  node: '14.16.0',
  openssl: '1.1.1j',
  tz: '2020a',
  unicode: '13.0',
  uv: '1.40.0',
  v8: '8.4.371.19-node.18',
  zlib: '1.2.11'
}
Olliebrown commented 2 years ago

I think this is a dynamic initialization order problem. It seems that line 738 of labels.cc is running BEFORE line 171. The variable declared at line 171 (the AEMode LabelMap) is used at 738 inside of the "Option" unordered_map. Since the LabelMap variables used by "Option" are not yet initialized (they are still null references), they are all failing to copy as the "Option" unordered_map is constructed.

At least, this is the observed behavior when I set breakpoints on those two lines: 738 breaks before 171. The real question is why the heck the compiler is ordering them that way (and how can we get it to stop it). I might investigate if this is a known issue with my particular version of the MSVC compiler.

egipurwana commented 2 years ago

@Olliebrown Thank you very much

ThomasWeinert commented 2 years ago

Merged, Thank you!

ThomasWeinert commented 2 years ago

It seems to be a known issue. I refactored all the static lists/maps into functions. This should take care of the dynamic initialization order. :-)