how to parse crash stack function symbols cross MAIN Module and SIDE Module

[oatgnauh]

if i have only one wasm, i can generate a symbol file which contain function index & function name, that's good.

now I use wasm dynamic link, there are two wasm, and two symbol files.
Assume I got a crash stack like this:

which is log inside SIDE module, how can i figure out which mudule such function index belong to ?
Both main and side module's function index starts from 0 in their symbols file

[kripken]

The stack trace includes the wasm filename that the browser loaded the wasm from. In your case perhaps 03e8.. is a data URL or other encoding of it. Here is what a typical stack trace looks like in Chrome:

    at 1114 (http://localhost:6931/a.js:363:10)
    at runEmAsmFunction (http://localhost:6931/a.js:398:26)
    at _emscripten_asm_const_int (http://localhost:6931/a.js:401:59)
    at a.wasm.main (http://localhost:6931/a.wasm:wasm-function[2]:0x105)
    at Module._main (http://localhost:6931/a.js:513:90)
    at callMain (http://localhost:6931/a.js:539:13)
    at doRun (http://localhost:6931/a.js:563:21)
    at http://localhost:6931/a.js:572:4

Note the a.wasm there, which is the name of the wasm file. Similar in Firefox too:

runEmAsmFunction@http://localhost:6931/a.js:398:26
_emscripten_asm_const_int@http://localhost:6931/a.js:401:75
a.wasm.main@http://localhost:6931/a.wasm:wasm-function[2]:0x105
Module._main@http://localhost:6931/a.js:513:90
callMain@http://localhost:6931/a.js:539:26
doRun@http://localhost:6931/a.js:563:21
run/<@http://localhost:6931/a.js:572:4

[oatgnauh]

I have to trim function symbol from wasm which build with release, since it's pretty large( abort 8M). So the online wasm contains no symbols, when log error or crash catching, the stack I got is quite simple.
once oline crash happen, I have to get fucntion index from my crash stack, searching the symbols file locally, matching the function index, and finally restore origin calling stack.

here is the symbols file looks like, [function index]:[symbols name]
`
0:lv_api_ret_to_main_thread_internal
1:emscripten_asm_const_int
2:__assert_fail
3:_emval_decref
4:emscripten_asm_const_int_sync_on_main_thread
5:_embind_register_enum
6:_embind_register_enum_value
7:_embind_register_value_object
8:_embind_register_value_object_field
9:_embind_finalize_value_object
10:_embind_register_class

`

[oatgnauh]

If there is no way to distinguish which module the function index belongs to, I got an idea. The function index maybe duplicated, but the mean while, crash stack contains function id: such as 0x105 as you post
a.wasm.main@http://localhost:6931/a.wasm:wasm-function[2]:0x105

I think I can combine function index & id as a key. in most cases, I don't think function id will be the same among MAIN & SIDE

[sbc100]

IIUC, 0x105 is a byte index into the wasm file, not a function id.

The function ID is 2 and there is almost certainly be function with ID 2 in every module.

However I believe there should also always be unique ID for the module instance on each line. Something like a URL (e.g. http://localhost:6931/a.wasm) or at least some kind of unique ID. In your stack trace image above I imagine that the unique ID is the thing after the @ on each line. There you see that all native functions are followed by one of two different IDs (one starting 03E and the other starting 048 ).. normally I would expect them to be URLs.. are there no URLs following those unique IDs?

[oatgnauh]

Thanks for your correction, I do mixd id and index. your idea is inspiring, using /@ ([^:]+):/g to match module could be helpful.
The point is, let's take 0484ca3a and 03e83276 as two module, I am not sure that which is MAIN and which is SIDE. Anyway, it's a good way to have a try.

As the unique URL you mentioned, it also confuse me a lot. In my application, each CPP function inside stack, there's no URL like http://localhost:6931/xx.wasm.
You can see that it is something like wasm://03e8e276

In this img, the wasm I compile with
`
default_ld_options="-Wl,--error-limit=0
-sSTACK_SIZE=1MB
"
fast_debug_options=" -g2 -O1 "
fast_debug_ld_options="${default_ld_options}
-s ASSERTIONS=1
-sSAFE_HEAP=0
--emit-symbol-map
-sWASM_BIGINT
-sERROR_ON_WASM_CHANGES_AFTER_LINK
-sPTHREAD_POOL_SIZE="Module['pthreadPoolSize'] || 20"
-sEXCEPTION_STACK_TRACES
"

`
contains origin function symbols, I wonder why the browser can parse these correctly. If browser can do, there must be a official way to matching symbols among MAIN & SIDE