You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently in the process of developing a testing library, and whenever I call the provided assert() function, the env.abort function reports the filename where the assert() function is located. This is unfortunately not the place where the expect() function was called, and the output is not meaningful to developers.
Can we use this as a tracking issue to develop meaningful stack traces?
This is hard because AS has such a minimal runtime and this will probably become provided by wasm when there is exception support. So perhaps this should be a special debug version that does trace the stacks.
In as-pect I wrote some glue code that runs functions with the following signature:
type NoPropsNoReturnCallback = () => void;
Then in my glue code, I did stuff like this:
/** * This is a web assembly utility function that wraps a function call in a try catch block to * report success or failure. * * @param {number} pointer - The function pointer to call. It must accept no parameters and return * void. * @returns {1 | 0} - If the callback was run successfully without error, it returns 1, else it * returns 0. */tryCall(pointer: number): 1|0{if(pointer===-1)return1;varfunc=this.wasm!.getFunction(pointer);try{func();}catch(ex){this.stack=this.getErrorStackTrace(ex);return0;}return1;}
Now in order to LOG the current stack trace, I had to call into javascript to get it, throw an error, then filter the lines that contain wasm in the string.
Yes. That was as good as I could get it. I'm currently working on using generated sourcemaps to display more relevant information, but it appears that sourcemaps are broken on the master branch, at least pre-resolver commit.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
willemneal commentedon Feb 11, 2019
This is hard because AS has such a minimal runtime and this will probably become provided by wasm when there is exception support. So perhaps this should be a special debug version that does trace the stacks.
jtenner commentedon Feb 19, 2019
I actually found a solution for this. It was very hacky though.
vgrichina commentedon Feb 21, 2019
@jtenner what did you end up doing?
jtenner commentedon Feb 21, 2019
In
as-pectI wrote some glue code that runs functions with the following signature:Then in my glue code, I did stuff like this:
Now in order to LOG the current stack trace, I had to call into javascript to get it, throw an error, then filter the lines that contain
wasmin the string.It was hacky, and I'm not proud of it.
vgrichina commentedon Feb 21, 2019
@jtenner interesting, so basically WASM runtimes embedded into JS VMs already provide wasm-side stack traces?
jtenner commentedon Feb 21, 2019
Yes. That was as good as I could get it. I'm currently working on using generated sourcemaps to display more relevant information, but it appears that sourcemaps are broken on the master branch, at least pre-resolver commit.
stale commentedon Mar 26, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.