[minicom-Bugs][311024] segmentation fault in a corner case
minicom-bugs at alioth.debian.org
minicom-bugs at alioth.debian.org
Sun May 30 20:42:31 UTC 2010
Bugs item #311024, was changed at 2008-08-26 16:40 by Adam Lackorzynski
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=100031&aid=311024&group_id=30018
>Status: Closed
Priority: 3
Submitted By: Paul Bolle (pebolle-guest)
Assigned to: Nobody (None)
Summary: segmentation fault in a corner case
Category: None
Group: None
Resolution: None
Initial Comment:
0) minicom segfaults in this corner case:
- start minicom on a device (here ttyS0);
- insert a PCMCIA modem (using cs_serial);
- watch one error appear in the main window, watch the main window disappear and notice more errors appear on the clear terminal screen;
- suspend minicom on the terminal (e.g. by using ^z);
- bring minicom to the foreground.
1) screenscraping:
Welcome to minicom 2.3
OPTIONS: I18n
Compiled on Mar 13 2008, 00:58:14.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
Device /dev/ttyS0 access failed: No such file or directory.
[...]
CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.3 | VT102 | Offline
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Device /dev/ttyS0 access failed: No such file or directory.
Suspended. Type "fg" to resume.
[1]+ Stopped sudo minicom ttyS0
$ fg
sudo minicom ttyS0
Segmentation fault (core dumped)
2) backtrace and related info:
$ gdb minicom core.12991
[...]
Core was generated by `minicom ttyS0'.
Program terminated with signal 11, Segmentation fault.
[New process 12991]
#0 mc_wreturn () at window.c:728
728 _write(e->value, -1, x, y, e->attr, e->color);
(gdb) bt
#0 mc_wreturn () at window.c:728
#1 0x0804a360 in shjump (sig=20) at minicom.c:125
#2 <signal handler called>
#3 0x00110416 in __kernel_vsyscall ()
#4 0x0081a63d in ___newselect_nocancel () from /lib/libc-2.8.so
#5 0x08061c7d in check_io (fd1=28, fd2=0, tmout=<value optimized out>, buf=0xbfa515ac "", buflen=0xbfa515a8) at ipc.c:56
#6 0x08064fc0 in do_terminal () at main.c:753
#7 0x0804b9ce in main (argc=2, argv=0xbfa52344) at minicom.c:1373
gdb) f 0
#0 mc_wreturn () at window.c:728
728 _write(e->value, -1, x, y, e->attr, e->color);
(gdb) info locals
x = 0
y = 0
e = (ELM *) 0x0
Analysis: e == NULL because gmap == NULL; gmap was set to NULL in src/window.c/win_end(). win_end() was called by src/window.c/mc_wclose(), which was called (in this case) by src/main.c/open_term().
3) version etc.:
minicom version 2.3 (compiled Mar 13 2008) is minicom-2.3-2.fc9.i386 (current Fedora minicom rpm)
4) This is sort of related to https://bugzilla.redhat.com/show_bug.cgi?id=246465 Also of interest are the recent changes regarding disappearing devices: https://alioth.debian.org/plugins/scmcvs/cvsweb.php/minicom/src/main.c.diff?r1=1.21;r2=1.22;cvsroot=minicom (though here a device sort of appears during a session).
5) I've been trying to find a solution. Not sure what should be done.
My best _guess_ right now would be to remove this call to mc_wclose() in open_term():
[...]
lockfile[0] = 0;
if (doinit >= 0) {
int rc = ttylock(dial_tty);
if (rc < 0) {
if (access(dial_tty, W_OK) == -1)
fprintf(stderr, _("Device %s access failed: %s.\n"),
dial_tty, strerror(errno));
else
fprintf(stderr, _("Device %s lock failed: %s.\n"),
dial_tty, strerror(-rc));
} else if (rc > 0) {
fprintf(stderr, _("Device %s is locked.\n"), dial_tty);
} else if (rc == 0) {
snprintf(lockfile, sizeof(lockfile), "%s", dial_tty);
}
if (rc) {
if (stdwin) mc_wclose(stdwin, 1);
drop_privs();
return(-1);
}
}
[...]
I _assume_ this would mean that:
- the main window will remain on device ;
- all errors will be printed to the main window;
- suspending (^A J) and bringing to the foreground do work as expected.
If this makes senses, I'm happy to write and test a patch.
----------------------------------------------------------------------
Comment By: Paul Bolle (pebolle-guest)
Date: 2008-08-26 17:05
Message:
I just noticed my _guess_ at a solution focuses on a Red Hat/Fedora patch.
My bug might as well be a Red Hat/Fedora specific problem. So, if nobody is able to reproduce this in upstream code, this bug may be closed (and I'll have to file a bug with the Red Hat/Fedora bugzilla).
----------------------------------------------------------------------
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=100031&aid=311024&group_id=30018
More information about the minicom-devel
mailing list