Exercises:Exceptions: Difference between revisions

From COMP15212 Wiki
gravatar Yuron [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m (1 revision imported)
gravatar W81054ch [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m (1 revision imported)
 
(One intermediate revision by one other user not shown)
Line 11: Line 11:


----
----
This demonstration is primarily intended to illustrate what is <em>possible</em> with exceptions.  This may not be completely ‘bulletproof’ code; before applying these principles in a ‘real’ application (at some future time), read (and
This demonstration is primarily intended to illustrate what is <em>possible</em> with exceptions.  This may not be completely ‘bulletproof’ code; before applying these principles in a ‘real’ application (at some future time), read (and understand!) some more background material.
understand!) some more background material.


The code also shows the <em>sort</em> of principle used by [[interrupts]] – i.e. the insertion of some ‘foreign’ code fragment at ‘random’ points during execution – with you as the interrupting device.
The code also shows the <em>sort</em> of principle used by [[interrupts]] – i.e. the insertion of some ‘foreign’ code fragment at ‘random’ points during execution – with you as the interrupting device.
Line 21: Line 20:


<blockquote>
<blockquote>
This is about the most useless counting program possible; although
This is about the most useless counting program possible; although it is incrementing a variable, it never outputs it and it never
it is incrementing a variable, it never outputs it and it never
stops (of its own accord, at least).
stops (of its own accord, at least).
</blockquote>
</blockquote>
Line 30: Line 28:


<blockquote>
<blockquote>
The program is marginally more useful in that now you can see the
The program is marginally more useful in that now you can see the value reached when it terminates, with a friendly little printout.
value reached when it terminates, with a friendly little printout.
</blockquote>
</blockquote>
The statements which were added set up a data structure and then link
The statements which were added set up a data structure and then link that structure to a (predefined, in <code>signal.h</code>) [[Unix Signals|signal]] <code>'SIGINT'</code>; <code>SIGINT</code> is sent (for example) by the shell when you press <code>^C</code>.  The structure contains a <em>pointer</em> to the function <code>goodbye()</code>; this function is then executed in preference to the default action when a <code>SIGINT</code> occurs.
that structure to a (predefined, in <code>signal.h</code>) [[Unix Signals|signal]]
<code>'SIGINT'</code>; <code>SIGINT</code> is sent (for example) by the shell when you press <code>^C</code>.  The structure contains a <em>pointer</em> to the function <code>goodbye()</code>; this function is then executed in preference to the default action when a <code>SIGINT</code> occurs.


Here, the function then terminates the application.
Here, the function then terminates the application.
Line 45: Line 40:
# Compile and execute <code>escape.c</code>
# Compile and execute <code>escape.c</code>


The difference here is that, instead of ‘exit’ting the
The difference here is that, instead of ‘exit’ting the function (renamed <code>escape()</code>) ‘return’s to the loop.
function (renamed <code>escape()</code>) ‘return’s to the loop.


After, perhaps, a moment of panic you should observe that persistence
After, perhaps, a moment of panic you should observe that persistence will pay off, and you <strong>can</strong> get out.
will pay off, and you <strong>can</strong> get out.


If that get-out clause were not there, there are other signals which
If that get-out clause were not there, there are other signals which have not been trapped here: you could still, for example, <code>kill</code> that process.  It would be a good idea to know how to do this if you want to tinker further with this example.
have not been trapped here: you could still, for example, <code>kill</code> that
process.  It would be a good idea to know how to do this if you want
to tinker further with this example.


This exercise also illustrates the <em>principle</em> of an
This exercise also illustrates the <em>principle</em> of an ‘[[Interrupts|interrupt]]’.  The body of your code (which
‘[[Interrupts|interrupt]]’.  The body of your code (which
could be doing more useful stuff) does its own thing but a function call can be invoked from the external ‘hardware’.
could be doing more useful stuff) does its own thing but a function
(In this case the signal is sent by the O.S. software to the application rather than the hardware to the kernel as in an interrupt,
call can be invoked from the external ‘hardware’.
(In this case the signal is sent by the O.S. software to the
application rather than the hardware to the kernel as in an interrupt,
but the effect is the same.)
but the effect is the same.)


In this case your frantic jabbing at the keyboard provided the
In this case your frantic jabbing at the keyboard provided the ‘interrupts’.  Usually in a ‘real’ (machine) interrupt the function is called an “Interrupt Service Routine” (“ISR”) and will do something with the appropriate hardware and then return.  As is observable, the exact timing – hence the position in the code – of the interrupt is not predictable.
‘interrupts’.  Usually in a ‘real’ (machine)
interrupt the function is called an “Interrupt Service
Routine” (“ISR”) and will do something with the
appropriate hardware and then return.  As is observable, the exact
timing – hence the position in the code – of the interrupt is not
predictable.


=== Part 3 ===
=== Part 3 ===
Line 77: Line 58:
#Uncomment the statements from “<code>/*</code>” to “<code>*/</code>” and repeat the process above.  This has trapped a different exception: <code>SIGSEGV</code>.
#Uncomment the statements from “<code>/*</code>” to “<code>*/</code>” and repeat the process above.  This has trapped a different exception: <code>SIGSEGV</code>.


These traps are not exclusive.  The function <code>broken()</code> has a
These traps are not exclusive.  The function <code>broken()</code> has a parameter which can be used to sort out what happened.  A hint at how this might be done has been left in the code and you can play if you’re feeling keen.
parameter which can be used to sort out what happened.  A hint at how
this might be done has been left in the code and you can play if
you’re feeling keen.


=== Puzzle ===
=== Puzzle ===
Identify and intercept at least one more Unix signal.  For example,
Identify and intercept at least one more Unix signal.  For example, you could combine this with your previous ‘processes’ code
you could combine this with your previous ‘processes’ code
and signal from child to parent. There is some reference material below, which may help with ideas.
and signal from child to parent.
There is some reference material below, which may help with ideas.
<!--
<span style=color:red>** TODO sanity check! **</span>
-->
----
 
=== Submission ===
Submit your exception interceptor as [<code>ex8.c</code>].  It should include
enough <em>comments</em> for it to be clear what you have done.  Please make
it clear which exceptions it handles and add a short (i.e. one
sentence) comment as to what they are <em>for</em> in general.  (There are
some reference sources below, in case
[https://www.google.co.uk Google] still baffles you.)
----


==== Reference material ====
==== Reference material ====
Line 108: Line 71:


----
----
{{PageGraph}}
{{PageGraph}}
{{Category|Exercises}}
{{Category|Exercises}}

Latest revision as of 10:22, 9 August 2019

On path: Exercises 0: Exercises • 1: Pointer Exercise • 2: Arguments Exercise • 3: Malloc Exercise • 4: Structs Exercise • 5: Processes Exercise • 6: Shared memory Exercise • 7: Pipes Exercise • 8: Exceptions Exercise • 9: Synchronisation Exercise • 10: Files Exercise • 11: Threads Exercise • 12: Unix proc Exercise
Depends on ExceptionsUnix Signals

Download exercise files

The purposes of this exercise are:

  • A first look at Unix exceptions: what they might do and how to intercept them
  • To illustrate how, for example, interrupts work

This demonstration is primarily intended to illustrate what is possible with exceptions. This may not be completely ‘bulletproof’ code; before applying these principles in a ‘real’ application (at some future time), read (and understand!) some more background material.

The code also shows the sort of principle used by interrupts – i.e. the insertion of some ‘foreign’ code fragment at ‘random’ points during execution – with you as the interrupting device.

Part 1

  1. Compile and execute sigint.c in a Unix shell. Note: this is set up to be compiled without optimisation. This is to prevent the compiler from spotting the code apparently does nothing and removing the increment.

This is about the most useless counting program possible; although it is incrementing a variable, it never outputs it and it never stops (of its own accord, at least).

  1. Press ^C (that’s Ctrl+C) in the shell to stop it.
  2. Uncomment the statements from /* to */ and repeat the process above.

The program is marginally more useful in that now you can see the value reached when it terminates, with a friendly little printout.

The statements which were added set up a data structure and then link that structure to a (predefined, in signal.h) signal 'SIGINT'; SIGINT is sent (for example) by the shell when you press ^C. The structure contains a pointer to the function goodbye(); this function is then executed in preference to the default action when a SIGINT occurs.

Here, the function then terminates the application.

Exception handler

Part 2

  1. Compile and execute escape.c

The difference here is that, instead of ‘exit’ting the function (renamed escape()) ‘return’s to the loop.

After, perhaps, a moment of panic you should observe that persistence will pay off, and you can get out.

If that get-out clause were not there, there are other signals which have not been trapped here: you could still, for example, kill that process. It would be a good idea to know how to do this if you want to tinker further with this example.

This exercise also illustrates the principle of an ‘interrupt’. The body of your code (which could be doing more useful stuff) does its own thing but a function call can be invoked from the external ‘hardware’. (In this case the signal is sent by the O.S. software to the application rather than the hardware to the kernel as in an interrupt, but the effect is the same.)

In this case your frantic jabbing at the keyboard provided the ‘interrupts’. Usually in a ‘real’ (machine) interrupt the function is called an “Interrupt Service Routine” (“ISR”) and will do something with the appropriate hardware and then return. As is observable, the exact timing – hence the position in the code – of the interrupt is not predictable.

Part 3

  1. Compile and execute segfault.c As supplied this tries to follow a NULL pointer (*p) which should cause a segmentation fault.
  2. Uncomment the statements from “/*” to “*/” and repeat the process above. This has trapped a different exception: SIGSEGV.

These traps are not exclusive. The function broken() has a parameter which can be used to sort out what happened. A hint at how this might be done has been left in the code and you can play if you’re feeling keen.

Puzzle

Identify and intercept at least one more Unix signal. For example, you could combine this with your previous ‘processes’ code and signal from child to parent. There is some reference material below, which may help with ideas.

Reference material