Bug 302081
| Summary: | Minicom attempts to write to the capture file even after it has been closed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lubomir Kundrak <lkundrak> | ||||
| Component: | minicom | Assignee: | Lubomir Rintel <lkundrak> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | Keywords: | EasyFix, Patch | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 2.2-5.fc8 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-09-25 10:26:50 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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.
|
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