Bug 302081 - Minicom attempts to write to the capture file even after it has been closed
Minicom attempts to write to the capture file even after it has been closed
Product: Fedora
Classification: Fedora
Component: minicom (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
: EasyFix, Patch
Depends On:
  Show dependency treegraph
Reported: 2007-09-23 03:59 EDT by Lubomir Kundrak
Modified: 2009-01-07 13:09 EST (History)
0 users

See Also:
Fixed In Version: 2.2-5.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-25 06:26:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The patch to fix minicom's track of open capture file (6.53 KB, patch)
2007-09-23 04:25 EDT, Lubomir Kundrak
no flags Details | Diff

  None (edit)
Description Lubomir Kundrak 2007-09-23 03:59:55 EDT
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):


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
Comment 1 Lubomir Kundrak 2007-09-23 04:25:30 EDT
Created attachment 203351 [details]
The patch to fix minicom's track of open capture file

At first glance this patch seem to work for me. Let me test it for a couple of
days anyways.

Note You need to log in before you can comment on or make changes to this bug.