Description of problem:

When you close a Capture file, minicom still uses the old pointer to FILE
structure for write attemts, which might result in Segmentation fault and
subsequent crash of the tool.

Version-Release number of selected component (if applicable):

minicom-2.2-4.fc8

How reproducible:

Always, thought the crashes are rather random

Steps to Reproduce:
1. Launch minicom, open a capture file (^a+l)
2. Close the capture file (^a+l)
3. Manage to get some input from the serial device
4. See minicom crash, or inspect it with a debugger to see what happened

Additional info:

The crash happens in vt_out() in minicom-2.2/src/vt100.c:

1081   /* Flush output to capture file so that all output is visible there
1082    * immediately. Causes a write syscall for every call though. */
1083   if (vt_capfp)
1084     fflush(vt_capfp);
1085 }

When closing or pausing the Capture file, minicom just sets capfp, not vt_capfp.
Btw I see no good reason why two distinct variables with the same value are used
for the very same purpose.

1460             fclose(capfp);
1461             capfp = (FILE *)NULL;

The two variables are meant to be synchronized by calls to vt_set().
Unfortunatelly, vt_set() does this:

 283   if (capfp != NULL)
 284     vt_capfp = capfp;

It is meant to be called with NULL argument when vt_capfp is not to be changed,
but there's no way it can set vt_capfp to NULL at all.

This is the state after the capture file was open:

(gdb) print vt_capfp       
$2 = (FILE *) 0x9e0c9e0
(gdb) print capfp
$3 = (FILE *) 0x9e0c9e0
        
And this is after it was closed.

(gdb) print capfp
$4 = (FILE *) 0x0
(gdb) print vt_capfp
$5 = (FILE *) 0x9e0c9e0