Wireshark-dev: [Wireshark-dev] Problems with Exception Handling on Windows.
From: "Luis Ontanon" <[email protected]>
Date: Tue, 17 Apr 2007 00:21:51 +0200
I been fighting for quite a while, TRYing to figure out a way to have
both exception handling mechanisms that are used in windows.

First and mostly we use our macros based on kazlib's  exception code
(which build arround ANSI's setjmp and longjmp).

Then for catching "exceptional exceptions" (actual bugs in the code)
we use window's own __try {} __finally {} and __except {} mechanism.

One problem is that longjmp forces the execution of the __finally
block. so when THROW is called execyution jumps to the ENDTRY and not
necessarily to the CATCH

Removing these __finaly blocks I added to the TRY ENDTRY macros on the
other hand would cause ENDTRY's code not to be evaluated when a
windows exception is thrown and thus leaving kazlib's stack in an
inconsistent state possibly causing errors when handling THROW()
triggered exceptions.


In any case I'll back up the changes to the exception mechanism I made
that are actually causing more problems than those they solved.

But then, at this point we have various choices:

a) Rewrite the TRY THROW CATCH and ENDTRY macros on windows so that we
only use win32's SEH and not kazlib to avoid the unpredictable effects
of mixing both exception mechanisms. We need to add another macro at
the end of the try block and other than the above listed macros
there's CLEANUP_PUSH userers that need being refactored to use
ep_allocs instead.

b) Dump the "exceptional exception" mechanism used in windows to catch
bugs in the code as they were exceptions (i.e. crash instead of trying
to go ahead when such a problem happens)

c) Live with the problems caused when an "exceptional exception"
leaves the kazlib's stack in an inconsistent state. (It still handles
most would be crashes without misbehaving.)

Ideas or suggestions.

Notes:

Users of TRY ... ENDTRY
[id-est:~/src/ws/trunk] lego% grep ENDTRY `find . -name '*.c'` | wc
     64     142    2504
Users of CLEANUP_PUSH
[id-est:~/src/ws/trunk] lego% grep CLEANUP_PUSH `find . -name '*.c'`
./asn1/h245/packet-h245-template.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-dcerpc-spoolss.c:      CLEANUP_PUSH(g_free, key_name);
./epan/dissectors/packet-giop.c:  CLEANUP_PUSH(g_free, tmpbuf);
./epan/dissectors/packet-giop.c:  CLEANUP_PUSH(g_free, objkey);
./epan/dissectors/packet-giop.c:  CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c:  CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c:  CLEANUP_PUSH(g_free, repobuf);
./epan/dissectors/packet-h245.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-multipart.c:   /*
CLEANUP_PUSH(cleanup_multipart_info, m_info); */
./epan/dissectors/packet-radius.c:    CLEANUP_PUSH(g_free, eap_buffer);
./epan/dissectors/packet-socks.c:
CLEANUP_PUSH(clear_in_socks_dissector_flag, NULL);


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan