Seg Fault when .entryPoint in FragmentState is not set

[Jean-Colas Prunier]

I wanted to report a seg fault caused by the fact that I had forgotten to set .entryPoint in a FragmentState instance. While this was an obvious mistake on my part, I wanted to know if you were aware of this issue. Would you expect this behavior (easily fixed when I found what I was doing wrong) or expect this somehow to be reported via some error cb mechanism in the future?

[Corentin Wallez]

Thanks for the report. Opened https://bugs.chromium.org/p/dawn/issues/detail?id=1680 for this. It will be low on the priority list and also it's not clear that we would produce a validation error for this because it's not technically a valid use of the API to leave this pointer null. So it's more like the Dawn application is malformed. But I agree that silently crashing is not helpful, so maybe we can at least give a warning for pointers that are commonly forgotten.

On Mon, Feb 27, 2023 at 6:52 AM Jean-Colas Prunier <j...@jean-colas.com> wrote:

I wanted to report a seg fault caused by the fact that I had forgotten to set .entryPoint in a FragmentState instance. While this was an obvious mistake on my part, I wanted to know if you were aware of this issue. Would you expect this behavior (easily fixed when I found what I was doing wrong) or expect this somehow to be reported via some error cb mechanism in the future?

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/6adb9439-4e7c-474d-85e3-2bfd8c163874n%40googlegroups.com.

[Jean-Colas Prunier]

Thank you for letting me know. Yes, I agree some reporting mechanism would be good especially when you debug the app.

[Kai Ninomiya]

IMO there should be no graceful error handling for C API errors like this one. It inflates the amount of checking code that any implementation of webgpu.h needs to write to be compatible, but not in a useful way. (Note, Emscripten is very code-size-sensitive.) But I would add an ASSERT(entryPoint != nullptr); in Dawn, if it doesn't have one already, maybe autogenerated?

-Kai (he/they)

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/80a8219d-ab3f-4eab-92fc-1aba68719a09n%40googlegroups.com.

[Jean-Colas Prunier]

Hi Kai,

I am not as qualified as you to judge this, but yes, your point is more important than reporting the error. When I use Dawn or similar real-time APIs, I have to fill up the structure with the specs on the side to ensure I don't miss any variables. So, developers should not miss anything. The crash is just not cool, though) but since this is typically something you find out when you write the app (and not after it has been deployed), that's probably a minor issue. An assert seems a good compromise.