itwinjs-core: cloud manifest request failure in `CloudContainer::Connect` when taking javascript CPU profile of iTwin backend process [linux]

Describe the bug Segfault in CloudContainer::Connect (see additional context for stack) when taking javascript CPU profile of transformer in chrome devtools. This occurs on Ubuntu Linux, I have not yet tried any other OSes.

This means to measure performance differences in changes I’m making I need to go back further on master to find a working addon which I will do soon.

To Reproduce

git clone https://github.com/iTwin/itwinjs-core.git
cd itwinjs-core
git checkout single-transformer-test-cloudcont-crash
rush install
rush build -t @itwin/core-transformer
(cd core/backend && node --inspect-brk node_modules/mocha/bin/mocha.js)
# at this point it will wait for you to connect with a debugger. I have only tested with chrome devtools
# you can open chrome devtools by opening the chrome browser and navigating to chrome://inspect
# it should detect the process waiting for a debugger to attach and you can just click the "inspect" link under "remote target" 
# once it connects, in the "profiler" tab, press the blue "start" button (see image below)

image

Expected behavior No segfault, able to use chrome devtools to produce javascript CPU profiles of iTwin.js code.

Screenshots N/A

Desktop (please complete the applicable information):

  • OS: ubuntu linux 21.04
  • Browser: N/A
  • Version: N/A
  • iTwin.js Version: Local master, 25952e299b1d4132336a5d55f4ae5eb03526a8a5, native addon 3.4.6 aka b0e8520af50a86ef02c6dd660259dda9d84ab14d

Additional context

I could not reproduce with a locally built debug and non-debug addon. Any pointers for what might be different between the released addon and my local build of b0e8520af50a86ef02c6dd660259dda9d84ab14d with DEBUG and then NDEBUG? Also if someone could confirm that b0e8520af50a86ef02c6dd660259dda9d84ab14d is the corresponding commit to @bentley/imodeljs-native@3.4.6 I would appreciate that.

Stack from attaching via gdb to the process:

#0  0x00007ffd4a686638 in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#1  0x00007ffd4a686ffb in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#2  0x00007ffd4a663ec8 in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#3  0x00007ffd4a662923 in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#4  0x00007ffd4a6631bd in BentleyM0200::BeSQLite::CloudContainer::Connect(BentleyM0200::BeSQLite::CloudCache&) ()
   from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#5  0x00007ffd4a396fb3 in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#6  0x00007ffd4a397135 in ?? () from /home/mike/work/imodeljs/common/temp/node_modules/.pnpm/@bentley+imodeljs-native@3.4.6/node_modules/@bentley/imodeljs-native/imodeljs-linux-x64/imodeljs.node
#7  0x0000000000ab44dd in v8impl::(anonymous namespace)::FunctionCallbackWrapper::Invoke(v8::FunctionCallbackInfo<v8::Value> const&) ()
#8  0x0000000000d53cfe in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::int
ernal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
#9  0x0000000000d5511f in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) ()
#10 0x00000000015f0b79 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit ()
#11 0x000000000158354a in Builtins_InterpreterEntryTrampoline ()
#12 0x00003079bf9c1599 in ?? ()
#13 0x000033876bd31c19 in ?? ()
... goes to #27 but its just ??

gdb also gives me these hundreds of these warnings if someone knows what it means. I haven’t looked into it yet.

warning: Corrupted shared library list: 0x50eb0c0 != 0x7ffff7ffda48
warning: Corrupted shared library list: 0x50eb0c0 != 0x7ffff7ffda48
warning: Corrupted shared library list: 0x50eb0c0 != 0x7ffff7ffda48

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

@nick4598 can you see if any of the above makes sense to Dan?

I have a fix for bcvfs’s abort which was a dangling stack reference, I gave details to @nick4598 to pass on to Dan. But I haven’t been able to pin down why curl doesn’t successfully request. Verbose curl logging doesn’t say anything and c-ares doesn’t seem to have its own logging. I do see timeouts but I’m not sure if that’s because of me stepping through code too slowly. Both gdb and lldb crash on parts of this code.