Re: A call to std::rethrow_exception prints Abort() error

[Heejin Ahn]

I'm not sure if I understand the whole thread. For
starters, BailErrorStrategy::recover in the first post takes two arguments
and it looks you only provided one, making the second argument null
automatically? Also I don't understand what you mean by "JS incarnation of
C++ exceptions" either... Anyway, my comments for the last email are inline.

On Tue, Aug 22, 2023 at 9:26 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Tue, Aug 22, 2023 at 1:56 AM 'Mike Lischke' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>>
>> Taking a quick look at rethrow_exception, it looks like it calls
>> `terminate` if the `ptr` is NULL:
>>
>>
>> https://github.com/emscripten-core/emscripten/blob/097290ded2746c6ba703d556fd53b23e5aef760a/system/lib/libcxx/src/support/runtime/exception_pointer_cxxabi.ipp#L66-L71
>>
>> Can you trace the value of the `std::exception_ptr` you are trying to
>> rethrow to confirm?
>>
>>
>> That was spot on Sam! The error is thrown in JS, so calling
>> `std::current_exception()` in C++ returns a null ptr. What I do now is to
>> forward the thrown exception from JS (which is one of the C++ exceptions)
>> and call std::make_exception_ptr to convert it to an exception pointer
>> (to create a nested exception).
>>
>>
>> Regarding handling C++ exceptions in JS, I think you will always need to
>> do things like getExceptionMessage to unpack information if all you have is
>> a thrown object from C++.
>>
>>
>> Well, the thrown error has its name set to the C++ exception, so what I
>> do now is:
>>
>> private isCancellationException(e: Error): boolean {
>> return e.name === "std::__nested";
>> }
>>
>> Not really elegant, nor type safe, but it works.
>>
>>
>> Can you explain what you mean by "if I throw a C++ exception in its JS
>> incarnation".. what is a JS incarnation?
>>
>>
>> Sure. There are 4 ways you can throw an exception/error with wasm:
>>
>> - throw JSError in JS
>>
>
> My JSError do you mean something that is the result of calling `new Error`
> in JS?   I don't think that can or should interact at all with the C++
> exception handling mechanism.   I see them as two orthogonal systems and
> trying to mix them or conflate them is likely to lead to trouble.
>
>
>> - throw C++ exception in C++
>>
>
> This should clearly work.
>
>
>> - throw C++ exception in JS
>>
>
> I don't think it possible (or should be possible) to use a JS `throw`
> statement to throw C++ exception.. C++ exceptions must be thrown by the
> native `__cxa_throw` mechanism.  In order words even if you have a handle
> to C++ object you want to throw, I believe the only way to throw is to call
> back into native code to perform a C++ throw.
>
> I could be wrong about this though.. @Heejin Ahn  can
> probably say more on this.
>

You can do that for Wasm exceptions by using the JS API
<https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Exception>
.

An example of such code is in our JS library:
https://github.com/emscripten-core/emscripten/blob/9bb02c0182bcfc32450ea15d5be69eab494042df/src/library_exceptions.js#L328-L344
This code does some string manipulation to make the stack trace tidy, but
what you need for creating an exception and throwing is just these lines:
```
var e = new WebAssembly.Exception(getCppExceptionTag(), [ex], {traceStack:
true});
throw e;
```
I'm not sure you can do that for the old way of Emscripten exceptions.


> - throw a JS error in C++ (I believe, never tried that)
>>
>
> IIRC would just be throwing C++ object that happened to be a val that
> pointed to JS object.. which I think should work fine.
>
>
>
>> To throw a C++ exception in JS that exception must be bound as usual with
>> embind (and that thrown JS error is the JS incarnation of the C++
>> exception).
>>
>
> I don't see why embind would need to be involved necessarily.  Not all
> programs use embind, and its possible to refer to C++ object via simple
> pointers in JS.   If you have a simple pointer to C++ object I don't think
> there is anything stopping you from just doing `throw ptr` in JS.  However,
> as I say above that is not that same as throwing in C++.. and what you
> would really want to do is callback into native code. e.g.
> `_throw_in_cpp(ptr)`.
>

I'm also not sure why embind should be involved. By the way, Wasm
exceptions will not be represented as simple integer pointers in the JS
world. They are WebAssembly.Exception
<https://developer.mozilla.org/en-US/docs/WebAssembly/J

Re: Debug info for 'this' pointer vanished from 3.1.24 to 3.1.26?

[Heejin Ahn]

I think this is likely to be an LLVM upstream problem than wasm-specific
problem. If you have a reproducer, that'd be helpful as well.

On Wed, Dec 7, 2022 at 1:02 PM Gregory Propf  wrote:

> Interesting. I didn't know about git bisect before so this is a good tool
> to have. I mainly just wanted to let the devs and users know this was
> happening. Like I said for now I can just use 3.1.24. It won't be a problem
> unless it turns out I can never upgrade beyond that. Unfortunately I don't
> think I'll have time to go through this right now since it sounds like a
> pretty time consuming iterative process.
>
> On Tuesday, December 6, 2022 at 4:25:53 PM UTC-8 alon...@gmail.com wrote:
>
>> Bisection might be useful here, as in theory any LLVM change could cause
>> such a difference or a bug. It's pretty simple to bisect using the emsdk:
>>
>> https://emscripten.org/docs/contributing/developers_guide.html#bisecting
>>
>>
>> On Tue, Dec 6, 2022 at 4:22 PM Gregory Propf  wrote:
>>
>>> I just noticed something while debugging a program. A few days ago I
>>> migrated from 3.1.24 to 3.1.26. It now seems that, in Chrome at least, I
>>> only see the literal value of the 'this' pointer but can't see the
>>> components of the object. My CFLAGS are still the same: -O0 -g -std=c++17.
>>> For now I'm fine just setting the toolchain back to 3.1.24 but I was
>>> curious as to whether others had noticed this or if it's just that I need
>>> some additional CFLAGS settings to get that level of debug detail now.
>>>
>>> - Greg
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/4086b3e0-d720-464e-b93f-800adbd514a3n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c5ddd312-87bf-4c53-ba43-c5030298d882n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CALJpS1PxEayjvjr0t9K2_pZua6Epsy0HAwUfyJNLQLpa4RyRiQ%40mail.gmail.com.

Re: Trying to understand invoke_* wrappers

[Heejin Ahn]

Could you dump you .emscripten file and command line option used?

On Thu, Oct 11, 2018 at 6:51 AM 'Stephen Weber' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Adding `-s DISABLE_EXCEPTION_CATCHING=1` to cflags did not have an
> effect.  I have looked into it more and it seems my C code *is* using
> longjmp which this is also used for in the normal emscripten target --
> perhaps it is detecting that and turning it back on anyway?  Since I'm
> using an alternate VM I'll need to write my own longjmp implementation, but
> it won't need (or benefit from, since go has no native exception mechanism)
> the invoke_* wrappers so I'd still like to be able to disable their
> generation if possible.
>
> On Wed, Oct 10, 2018 at 9:28 PM Heejin Ahn  wrote:
>
>> They are generated for exception handling support. You can pass '-s
>> DISABLE_EXCEPTION_CATCHING=1' to emcc, but I think this is already the
>> default, so I'm not sure why you are getting that.
>>
>> On Wed, Oct 10, 2018 at 11:20 AM stephen.weber via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>> Hello!
>>>
>>> I am trying to compile some C code with emscripten to use with a
>>> non-browser WASM VM, so I can't use the generate JS shims and have to fill
>>> in anything actually needed on my own.  The bulk of what I need after an
>>> `-O3` is not a big deal (Math.pow and such) but all of the invoke_*
>>> wrappers have me stumped.  What are these wrappers for?  Will calling a
>>> WASM C function from another WASM C function, even via pointer, ever
>>> generate a JavaScript exception (in the browser context)?  If not, is there
>>> any way to tell emcc "hey, this is all C code here" or something and have
>>> the `invoke_*` wrappers not be used?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
> You received this message because you are subscribed to a topic in the
>> Google Groups "emscripten-discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/emscripten-discuss/jyLsB0b6j70/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> emscripten-discuss+unsubscr...@googlegroups.com.
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> singpolyma.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trying to understand invoke_* wrappers

[Heejin Ahn]

They are generated for exception handling support. You can pass '-s
DISABLE_EXCEPTION_CATCHING=1' to emcc, but I think this is already the
default, so I'm not sure why you are getting that.

On Wed, Oct 10, 2018 at 11:20 AM stephen.weber via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Hello!
>
> I am trying to compile some C code with emscripten to use with a
> non-browser WASM VM, so I can't use the generate JS shims and have to fill
> in anything actually needed on my own.  The bulk of what I need after an
> `-O3` is not a big deal (Math.pow and such) but all of the invoke_*
> wrappers have me stumped.  What are these wrappers for?  Will calling a
> WASM C function from another WASM C function, even via pointer, ever
> generate a JavaScript exception (in the browser context)?  If not, is there
> any way to tell emcc "hey, this is all C code here" or something and have
> the `invoke_*` wrappers not be used?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.