[Mono-bugs] [Bug 426181] System. AccessViolationException should be raised instead of SIGSEGV alone
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Tue Sep 16 11:00:40 EDT 2008
https://bugzilla.novell.com/show_bug.cgi?id=426181
User lupus at novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=426181#c8
--- Comment #8 from Paolo Molaro <lupus at novell.com> 2008-09-16 09:00:40 MDT ---
I think we need to enable the support for throwing the correct exception,
especially because people blame mono for crashing when it's actually their
incorrect p/invoke signatures.
The issue about memory corruption is a poor excuse: the SEGV happens for the
cases where the corruption doesn't occour (the corruption itself is prevented
by the SEGV), so the program may have executed with corrupted state long before
(or even without any SEGV happening). In fact more hard crashes are caused by
the call to abort() overflowing the limited alt stack setup for the SEGV.
Using dladdr() we can also separate SEGV happening inside the mono code (in
those cases we may still want to abort as the mono runtime may be corrupted, or
to force a bug report) from crashes in user code, which will get the
AccessViolation exception. We need to handle the helper functions used by
marshaling, though, as they operate on user p/invoke data.
An option to consider is to generate the exception also for crashes in the
runtime, but in that case generate the same dump of info we do now in some log
file or stderr and use an ExecutionEngine exception (to more easily get the
info from users that hit bugs in mono).
This behaviour needs to be configurable for embedders anyway.
That said, the code Martin uses to get the fields is completely broken: it
should at the very least get the fields by name and handle the case where they
are missing or have different types.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list